rfc9441.original   rfc9441.txt 
lpwan Working Group JC. Zuniga Internet Engineering Task Force (IETF) JC. Zúñiga
Internet-Draft Cisco Request for Comments: 9441 Cisco
Updates: 8724, 9363 (if approved) C. Gomez Updates: 8724, 9363 C. Gomez
Intended status: Standards Track S. Aguilar Category: Standards Track S. Aguilar
Expires: 7 October 2023 Universitat Politecnica de Catalunya ISSN: 2070-1721 Universitat Politècnica de Catalunya
L. Toutain L. Toutain
IMT-Atlantique IMT-Atlantique
S. Cespedes S. Céspedes
Concordia University Concordia University
D. Wistuba D. Wistuba
NIC Labs, Universidad de Chile NIC Labs, Universidad de Chile
5 April 2023 July 2023
SCHC Compound ACK Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)
draft-ietf-lpwan-schc-compound-ack-17
Abstract Abstract
The present document updates the SCHC (Static Context Header This document updates the Static Context Header Compression (SCHC)
Compression and fragmentation) protocol RFC8724 and the corresponding and fragmentation protocol (RFC 8724) and the corresponding YANG
Yang Module RFC9363. It defines a SCHC Compound ACK message format module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK)
and procedure, which are intended to reduce the number of response message format and procedure, which are intended to reduce the number
transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode,
accumulating bitmaps of several windows in a single SCHC message by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK). (i.e., the SCHC Compound ACK).
Both message format and procedure are generic, so they can be used, Both the message format and procedure are generic, so they can be
for instance, by any of the four Low Power Wide Area Networks used, for instance, by any of the four Low-Power Wide Area Network
(LPWANs) technologies defined in RFC8376, being Sigfox, LoRaWAN, NB- (LPWAN) technologies defined in RFC 8376, which are Sigfox, Long
IoT and IEEE 802.15.4w. Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (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 is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 October 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9441.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. SCHC Compound ACK . . . . . . . . . . . . . . . . . . . . . . 4 3. SCHC Compound ACK
3.1. SCHC Compound ACK Message Format . . . . . . . . . . . . 4 3.1. SCHC Compound ACK Message Format
3.2. SCHC Compound ACK Behaviour . . . . . . . . . . . . . . . 7 3.2. SCHC Compound ACK Behavior
8.4.3. ACK-on-Error Mode . . . . . . . . . . . . . . . . . . 8 3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)
4. SCHC Compound ACK Example . . . . . . . . . . . . . . . . . . 16 4. SCHC Compound ACK Example
5. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . . . 17 5. SCHC Compound ACK YANG Data Model
5.1. SCHC YANG Data Model Extension . . . . . . . . . . . . . 17 5.1. SCHC YANG Data Model Extension
5.2. SCHC YANG Tree Extension . . . . . . . . . . . . . . . . 19 5.2. SCHC YANG Tree Extension
6. SCHC Compound ACK Parameters . . . . . . . . . . . . . . . . 20 6. SCHC Compound ACK Parameters
7. Security considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations
8.1. URI Registration . . . . . . . . . . . . . . . . . . . . 21 8.1. URI Registration
8.2. YANG Module Name Registration . . . . . . . . . . . . . . 21 8.2. YANG Module Name Registration
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses
1. Introduction 1. Introduction
The Generic Framework for Static Context Header Compression and The Generic Framework for Static Context Header Compression (SCHC)
Fragmentation (SCHC) specification [RFC8724] describes two and Fragmentation specification [RFC8724] describes two mechanisms:
mechanisms: i) a protocol header compression scheme, and ii) a frame i) a protocol header compression scheme and ii) a frame fragmentation
fragmentation and loss recovery functionality. Either can be used on and loss recovery functionality. Either can be used on top of radio
top of radio technologies such as the four Low Power Wide Area technologies, such as the four Low-Power Wide Area Networks (LPWANs)
Networks (LPWANs) listed in [RFC8376], being Sigfox, LoRaWAN, NB-IoT listed in [RFC8376], which are Sigfox, LoRaWAN, NB-IoT, and IEEE
and IEEE 802.15.4w. These LPWANs have similar characteristics such 802.15.4w. These LPWANs have similar characteristics, such as star-
as star-oriented topologies, network architecture, connected devices oriented topologies, network architecture, and connected devices with
with built-in applications, etc. built-in applications.
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 number of similarities
similarities between them, some differences exist with respect to the between them, some differences exist with respect to the transmission
transmission characteristics, payload sizes, etc. Hence, there are characteristics, payload sizes, etc. Hence, there are optimal
optimal parameters and modes of operation that can be used when SCHC parameters and modes of operation that can be used when SCHC is used
is used on top of a specific LPWAN technology. on top of a specific LPWAN technology.
In ACK-on-Error mode in [RFC8724] the SCHC Packet is fragmented into 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 pieces called tiles, where all tiles are the same size except for the
last one, which can be smaller. Successive tiles are grouped in last one, which can be smaller. Successive tiles are grouped in
windows of fixed size. A SCHC Fragment carries one or several windows of fixed size. A SCHC Fragment carries one or several
contiguous tiles, which may span multiple windows. When sending all contiguous tiles, which may span multiple windows. When sending all
tiles from all windows, the last tile is sent in an All-1 SCHC 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 Fragment. The SCHC receiver will send a SCHC ACK reporting on the
will send a SCHC ACK reporting on the reception of exactly one window reception of exactly one window of tiles after receiving the All-1
of tiles. In case of SCHC Fragment losses, a bitmap is added to the SCHC Fragment. In case of SCHC Fragment losses, a bitmap is added to
failure SCHC ACK, where each bit in the bitmap corresponds to a tile the failure SCHC ACK, where each bit in the bitmap corresponds to a
in the window. If SCHC Fragment losses span multiple windows, the tile in the window. If SCHC Fragment losses span multiple windows,
SCHC receiver will send one failure SCHC ACK per window with losses. the SCHC receiver will send one failure SCHC ACK per window with
losses.
The present document updates the SCHC protocol for frame This document updates the SCHC protocol for frame fragmentation and
fragmentation and loss recovery. It defines a SCHC Compound ACK loss recovery. It defines a SCHC Compound ACK format and procedure,
format and procedure, which is intended to reduce the number of which are intended to reduce the number of response transmissions
response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC
SCHC. The SCHC Compound ACK extends the failure SCHC ACK message Compound ACK extends the failure SCHC ACK message format so that it
format so that it can contain several bitmaps, each bitmap being can contain several bitmaps, with each bitmap being identified by its
identified by its corresponding window number. The SCHC Compound ACK corresponding window number. The SCHC Compound ACK is backwards
is backwards compatible with the SCHC ACK as defined in [RFC8724], compatible with the SCHC ACK as defined in [RFC8724], and introduces
and introduces flexibility, as the receiver has the capability to flexibility, as the receiver has the capability to respond to the
respond to the All-0 SCHC Fragment, providing more downlink All-0 SCHC Fragment, providing more Downlink opportunities and
opportunities, and therefore adjusting to the delay requirements of therefore adjusting to the delay requirements of the application.
the application.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
It is assumed that the reader is familiar with the terms and It is assumed that the reader is familiar with the terms and
mechanisms defined in [RFC8376] and in [RFC8724]. mechanisms defined in [RFC8376] and [RFC8724].
3. SCHC Compound ACK 3. SCHC Compound ACK
The SCHC Compound ACK is a failure SCHC ACK message that can contain The SCHC Compound ACK is a failure SCHC ACK message that can contain
several bitmaps, each bitmap being identified by its corresponding several bitmaps, with each bitmap being identified by its
window number. In [RFC8724], the failure SCHC ACK message only corresponding window number. In [RFC8724], the failure SCHC ACK
contain one bitmap corresponding to one window. The SCHC Compound message only contains one bitmap corresponding to one window. The
ACK extends this format allowing more windows to be acknowledged in a SCHC Compound ACK extends this format, allowing more windows to be
single ACK, reducing the total number of failure SCHC ACK messages, acknowledged in a single ACK and reducing the total number of failure
specially when fragment losses are present in intermediate windows. SCHC ACK messages, especially when fragment losses are present in
intermediate windows.
The SCHC Compound ACK MAY be used in fragmentation modes that use The SCHC Compound ACK MAY be used in fragmentation modes that use
windows and that allow reporting the bitmaps of multiple windows at windows and that allow reporting the bitmaps of multiple windows at
the same time, and MUST NOT be used otherwise. the same time; otherwise, the SCHC Compound ACK MUST NOT be used.
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 SCHC Compound ACK,
* includes the window number (i.e., W) of each bitmap, * includes the window number (i.e., W) of each bitmap,
* might not cover all windows with fragment losses of a SCHC Packet, * might not cover all windows with fragment losses of a SCHC Packet,
and
* and is distinguishable from the SCHC Receiver-Abort. * is distinguishable from the SCHC Receiver-Abort.
3.1. SCHC Compound ACK Message Format 3.1. SCHC Compound ACK Message Format
Figure 1 shows the success SCHC ACK format, i.e., when all fragments Figure 1 shows the success SCHC ACK format, i.e., when all fragments
have been correctly received (C=1), as defined in [RFC8724]. have been correctly received (C=1), as defined in [RFC8724].
|-- SCHC ACK Header --| |--- SCHC ACK Header ---|
|--T-|---M--| 1 | | |--T-|--M--| 1 |
+--------+----+------+---+~~~~~~~~~~~~~~~~~~ +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
| RuleID |DTag| W |C=1| padding as needed | RuleID |DTag| W |C=1| padding as needed
+--------+----+------+---+~~~~~~~~~~~~~~~~~~ +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
Figure 1: SCHC Success ACK message format, as defined in RFC8724 Figure 1: SCHC Success ACK Message Format, as Defined in RFC 8724
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 and Figure 3. ACK message format is shown in Figures 2 and 3.
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----| |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--| |--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+------+~~~~~+ +------+----+------+---+--------+...+------+--------+------+~~~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad | |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
+------+----+------+---+--------+...+------+--------+------+~~~~~+ +------+----+------+---+--------+...+------+--------+------+~~~~~+
next L2 Word boundary ->|<-- L2 Word ->| next L2 Word boundary ->|<-- L2 Word ->|
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi Figure 2: SCHC Compound ACK Message Format. Losses are found in
windows W = w1,...,wi, where w1 < w2 <...< wi.
Figure 2: SCHC Compound ACK message format
The SCHC Compound ACK groups the window number (W) with its The SCHC Compound ACK groups the window number (W) with its
corresponding bitmap. Window numbers do not need to be contiguous. corresponding bitmap. Window numbers do not need to be contiguous.
However, the window numbers and its corresponding bitmaps included in However, the window numbers and their corresponding bitmaps included
the SCHC Compound ACK message MUST be ordered from the lowest- in the SCHC Compound ACK message MUST be ordered from the lowest-
numbered to the highest-numbered window. Hence, if the bitmap of numbered to the highest-numbered window. Hence, if the bitmap of
window number zero is present in the SCHC Compound ACK message, it 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 MUST always be the first one in order and its window number MUST be
in the SCHC ACK Header. placed in the SCHC ACK Header.
If M or more padding bits would be needed after the last bitmap in If M or more padding bits would be needed after the last bitmap in
the message to fill the last L2 Word, M bits at 0 MUST be appended the message to fill the last layer two (L2) Word, M bits at 0 MUST be
after the last bitmap, and then padding is applied as needed (see appended after the last bitmap, and then padding is applied as needed
Figure 2). Since window number 0, if present in the message, is (see Figure 2). Since window number 0 (if present in the message) is
placed as w1, the M bits set to zero can't be confused with window placed as w1, the M bits set to zero can't be confused with window
number 0, and therefore they signal the end of the SCHC Compound ACK number 0; therefore, they signal the end of the SCHC Compound ACK
message. message.
Figure 3 shows the case when the required padding bits are strictly Figure 3 shows the case when the required padding bits are strictly
less than M bits. In this case, the layer-2 MTU (Maximum less than M bits. In this case, the L2 Maximum Transmission Unit
Transmission Unit) does not leave room for any extra window value, (MTU) does not leave room for any extra window value, let alone any
let alone any bitmap, thereby signaling the end of the SCHC Compound bitmap, thereby signaling the end of the SCHC Compound ACK message.
ACK message.
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----| |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--| |--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+~~~+ +------+----+------+---+--------+...+------+--------+~~~+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad| |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
+------+----+------+---+--------+...+------+--------+~~~+ +------+----+------+---+--------+...+------+--------+~~~+
next L2 Word boundary ->| next L2 Word boundary ->|
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 3: SCHC Compound ACK message format with less than M Figure 3: SCHC Compound ACK Message Format with Less than M
padding bits Padding Bits. Losses are found in windows W = w1,...,wi, where
w1 < w2 <...< wi.
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for
intermediate windows/bitmaps (i.e., bitmaps that are not the last one intermediate windows/bitmaps (i.e., bitmaps that are not the last one
of the SCHC Compound ACK message), and therefore intermediate bitmaps of the SCHC Compound ACK message); therefore, intermediate bitmap
fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY
use a Compressed Bitmap format only for the last bitmap in the use a Compressed Bitmap format only for the last bitmap in the
message. The optional usage of this Compressed Bitmap for the last message. The optional usage of this Compressed Bitmap for the last
bitmap MUST be specified by the SCHC technology-specific profile. bitmap MUST be specified by the technology-specific SCHC Profile.
The case where the last bitmap is effectively compressed corresponds The case where the last bitmap is effectively compressed corresponds
to Figure 3, with the last bitmap ending, by construction, on an L2 to Figure 3, with the last bitmap ending (by construction) on an L2
Word boundary, therefore resulting in no padding at all. Word boundary, therefore resulting in no padding at all.
Figure 4 illustrates a bitmap compression example of a SCHC Compound Figure 4 illustrates a bitmap compression example of a SCHC Compound
ACK, where the bitmap of the last window (wi) indicates that the ACK, where the bitmap of the last window (wi) indicates that the
first tile has not been correctly received. Because the compression first tile has not been correctly received. Because the compression
algorithm resulted in effective compression, no padding is needed. algorithm resulted in effective compression, no padding is needed.
|--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------| |--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+--------------+ +------+----+------+---+--------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 | |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
+------+----+------+---+--------+...+------+--------------+ +------+----+------+---+--------+...+------+--------------+
next L2 Word boundary ->| next L2 Word boundary ->|
SCHC Compound ACK with uncompressed Bitmap SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --| |--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
|--T-|---M--|-1-| |...|---M--| |--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+---+ +------+----+------+---+--------+...+------+---+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1| |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
+------+----+------+---+--------+...+------+---+ +------+----+------+---+--------+...+------+---+
next L2 Word boundary ->| next L2 Word boundary ->|
Transmitted SCHC Compound ACK with compressed Bitmap Transmitted SCHC Compound ACK with Compressed Bitmap
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 4: SCHC Compound ACK message format with compressed bitmap Figure 4: SCHC Compound ACK Message Format with Compressed Bitmap
and No Padding Added. Losses are found in windows W = w1,...,wi,
where w1 < w2 <...< wi.
Figure 5 illustrates another bitmap compression example of a SCHC Figure 5 illustrates another bitmap compression example of a SCHC
Compound ACK, where the bitmap of the last window (wi) indicates that Compound ACK, where the bitmap of the last window (wi) indicates that
the second and the fourth tile have not been correctly received. In the second and the fourth tiles have not been correctly received. In
this example, the compression algorithm does not result in effective this example, the compression algorithm does not result in effective
compression of the last bitmap. Besides, because more than M bits of compression of the last bitmap. Besides, because more than M bits of
padding would be needed to fill the last L2 Word, M bits at 0 are padding would be needed to fill the last L2 Word, M bits at 0 are
appended to the message before padding is applied. appended to the message before padding is applied.
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------| |--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |--T-|---M--|-1-| |...|---M--|
+------+----+------+---+------+...+------+--------------+ +------+----+------+---+------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 | |RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+...+------+--------------+ +------+----+------+---+------+...+------+--------------+
next L2 Word boundary ->| next L2 Word boundary ->|
SCHC Compound ACK with uncompressed Bitmap
SCHC Compound ACK with Uncompressed Bitmap
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------| |--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |---M--| |--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+------+...+------+--------------+------+~~~+ +------+----+------+---+------+...+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad| |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 ------>| next L2 Word boundary ->|<------ L2 Word ------>|
Transmitted SCHC Compound ACK
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi Transmitted SCHC Compound ACK
Figure 5: SCHC Compound ACK message format with compressed bitmap Figure 5: SCHC Compound ACK Message Format with Compressed Bitmap
and Padding Added to Reach the L2 Boundary. Losses are found in
windows W = w1,...,wi, where w1 < w2 <...<wi.
If a SCHC sender gets a SCHC Compound ACK with invalid W's, such as If a SCHC sender gets a SCHC Compound ACK with invalid window
duplicate W values or W values not sent yet, it MUST discard the numbers, such as duplicate W values or W values not sent yet, it MUST
whole SCHC Compound ACK message. discard the whole SCHC Compound ACK message.
Note: because it has a C bit reset to 0, the SCHC Compound ACK is | Note that SCHC Compound ACKs are distinguishable from the
distinguishable from the Receiver-Abort message [RFC8724], which has | Receiver-Abort message in the same way that regular SCHC ACKs
a C bit set to 1. | are distinguishable, since the Receiver-Abort pattern never
| occurs in a legitimate SCHC Compound ACK [RFC8724].
3.2. SCHC Compound ACK Behaviour 3.2. SCHC Compound ACK Behavior
The SCHC ACK-on-Error behaviour is described in section 8.4.3 of The SCHC ACK-on-Error behavior is described in Section 8.4.3 of
[RFC8724]. The present document slightly modifies this behaviour, [RFC8724]. The present document slightly modifies this behavior. In
since in the baseline SCHC specification a SCHC ACK reports only one the baseline SCHC specification, a SCHC ACK reports only one bitmap
bitmap for the reception of exactly one window of tiles. The present for the reception of exactly one window of tiles. The present SCHC
SCHC Compound ACK specification extends the SCHC ACK message format Compound ACK specification extends the SCHC ACK message format so
so that it can contain several bitmaps, each bitmap being identified that it can contain several bitmaps, with each bitmap being
by its corresponding window number. identified by its corresponding window number.
The SCHC ACK format, as presented in [RFC8724], can be considered a As presented in [RFC8724], the SCHC ACK format can be considered a
special SCHC Compound ACK case, in which it reports only the tiles of special SCHC Compound ACK case in which it reports only the tiles of
one window. Therefore, the SCHC Compound ACK is backwards compatible one window. Therefore, the SCHC Compound ACK is backwards compatible
with the SCHC ACK format presented in [RFC8724]. The receiver can with the SCHC ACK format presented in [RFC8724]. The receiver can
suspect if the sender does not support the SCHC Compound ACK, if the assume that the sender does not support the SCHC Compound ACK if,
sender does not resend any tiles from windows that are not the first although the SCHC Compound ACK sent by the receiver reports losses in
one in the SCHC Compound ACK and more ACKs are needed. In that case, more than one window, the sender does not resend any tiles from
the receiver can send SCHC Compound ACKs with only one window of windows other than the first window reported in the SCHC Compound
tiles. ACK. In that case, the receiver can send SCHC Compound ACKs with
only one window of tiles.
Also, some flexibility is introduced with respect to [RFC8724], in Also, some flexibility is introduced with respect to [RFC8724] in
that the receiver has the capability to respond to the All-0 with a that the receiver has the capability to respond (or not) to the All-0
SCHC Compound ACK or not, depending on certain parameters, like with a SCHC Compound ACK, depending on certain parameters, like
network conditions, sender buffer/chache size, supported application network conditions, sender buffer/cache size, and supported
delay. Note that even though the protocol allows for such application delay. Note that even though the protocol allows for
flexibility, the actual decision criteria is not specified in this such flexibility, the actual decision criteria is not specified in
document. The application MUST set expiration timer values according this document. The application MUST set expiration timer values
to when the feedback is expected to be received, e.g., after the according to when the feedback is expected to be received, e.g.,
All-0 or after the All-1. after the All-0 or after the All-1.
The following Section 8.4.3 (and its subsections) replaces the Section 3.2.1 (and its subsections) replaces the complete
complete sections 8.4.3 (and its subsections) of RFC 8724. Section 8.4.3 (and its subsections) of [RFC8724].
8.4.3. ACK-on-Error Mode 3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)
The ACK-on-Error mode supports L2 technologies that have variable MTU The ACK-on-Error mode supports L2 technologies that have variable MTU
and out-of-order delivery. It requires an L2 that provides a and out-of-order delivery. It requires an L2 that provides a
feedback path from the reassembler to the fragmenter. See Appendix F feedback path from the reassembler to the fragmenter. See Appendix F
for a discussion on using ACK-on-Error mode on quasi-bidirectional for a discussion on using ACK-on-Error mode on quasi-bidirectional
links. links.
In ACK-on-Error mode, windows are used. In ACK-on-Error mode, windows are used.
All tiles except the last one and the penultimate one MUST be of All tiles except the last one and the penultimate one MUST be of
skipping to change at page 8, line 44 skipping to change at line 368
* The penultimate tile size MUST be the regular tile size, or * The penultimate tile size MUST be the regular tile size, or
* the penultimate tile size MUST be either the regular tile size or * the penultimate tile size MUST be either the regular tile size or
the regular tile size minus one L2 Word. the regular tile size minus one L2 Word.
A SCHC Fragment message carries one or several contiguous tiles, A SCHC Fragment message carries one or several contiguous tiles,
which may span multiple windows. A SCHC Compound ACK reports on the which may span multiple windows. A SCHC Compound ACK reports on the
reception of one window of tiles or several windows of tiles, each reception of one window of tiles or several windows of tiles, each
one identified by its window number. one identified by its window number.
See Figure 23 for an example. See Figure 6 (see Figure 23 of RFC 8724 (https://www.rfc-
editor.org/rfc/rfc8724.html#figure-23)) for an example.
+---------------------------------------------...-----------+ +---------------------------------------------...-----------+
| SCHC Packet | | SCHC Packet |
+---------------------------------------------...-----------+ +---------------------------------------------...-----------+
Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------| SCHC Fragment msg |-----------|
Figure 23: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode Figure 6: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode
(Figure 23 in RFC 8724)
The W field is wide enough that it unambiguously represents an The W field is wide enough that it unambiguously represents an
absolute window number. The fragment receiver sends SCHC Compound absolute window number. The fragment receiver sends SCHC Compound
ACKs to the fragment sender about windows for which tiles are ACKs to the fragment sender about windows for which tiles are
missing. No SCHC Compound ACK is sent by the fragment receiver for missing. No SCHC Compound ACK is sent by the fragment receiver for
windows that it knows have been fully received. windows that it knows have been fully received.
The fragment sender retransmits SCHC Fragments for tiles that are The fragment sender retransmits SCHC Fragments for tiles that are
reported missing. It can advance to next windows even before it has reported missing. It can advance to next windows even before it has
ascertained that all tiles belonging to previous windows have been ascertained that all tiles belonging to previous windows have been
correctly received, and it can still later retransmit SCHC Fragments correctly received, and it can still later retransmit SCHC Fragments
with tiles belonging to previous windows. Therefore, the sender and with tiles belonging to previous windows. Therefore, the sender and
the receiver may operate in a decoupled fashion. The fragmented SCHC the receiver may operate in a decoupled fashion. The fragmented SCHC
Packet transmission concludes when: Packet transmission concludes when:
* integrity checking shows that the fragmented SCHC Packet has been * integrity checking shows that the fragmented SCHC Packet has been
correctly reassembled at the receive end, and this information has correctly reassembled at the receive end, and this information has
been conveyed back to the sender, or been conveyed back to the sender,
* too many retransmission attempts were made, or * too many retransmission attempts have been made, or
* the receiver determines that the transmission of this fragmented * the receiver determines that the transmission of this fragmented
SCHC Packet has been inactive for too long. SCHC Packet has been inactive for too long.
Each Profile MUST specify which RuleID value(s) corresponds to SCHC Each Profile MUST specify which RuleID value(s) corresponds to SCHC
F/R messages operating in this mode. F/R messages operating in this mode.
The W field MUST be present in the SCHC F/R messages. The W field MUST be present in the SCHC F/R messages.
Each Profile, for each RuleID value, MUST define: Each Profile, for each RuleID value, MUST define:
* the tile size (a tile does not need to be multiple of an L2 Word, * the tile size (a tile does not need to be a duplicate of an L2
but it MUST be at least the size of an L2 Word), Word, but it MUST be at least the size of an L2 Word),
* the value of M, * the value of M,
* the value of N, * the value of N,
* the value of WINDOW_SIZE, which MUST be strictly less than 2^N, * the value of WINDOW_SIZE, which MUST be strictly less than 2^N,
* the size and algorithm for the RCS field, * the size and algorithm for the RCS field,
* the value of T, * the value of T,
* the value of MAX_ACK_REQUESTS, * the value of MAX_ACK_REQUESTS,
* the expiration time of the Retransmission Timer, * the expiration time of the Retransmission Timer,
* the expiration time of the Inactivity Timer, * the expiration time of the Inactivity Timer,
* if the last tile is carried in a Regular SCHC Fragment or an All-1 * if the last tile is carried in a Regular SCHC Fragment or an All-1
SCHC Fragment (see Section 8.4.3.1), and SCHC Fragment (see Section 3.2.1.1 (Section 8.4.3.1 in [RFC8724]),
* if the penultimate tile MAY be one L2 Word smaller than the * if the penultimate tile MAY be one L2 Word smaller than the
regular tile size. In this case, the regular tile size MUST be at regular tile size (in this case, the regular tile size MUST be at
least twice the L2 Word size. least twice the L2 Word size),
* Usage or not of the SCHC Compound ACK message. * usage or not of the SCHC Compound ACK message, and
* Usage or not of the compressed bitmap format in the last window of * usage or not of the Compressed Bitmap format in the last window of
the SCHC Compound ACK message. the SCHC Compound ACK message.
For each active pair of RuleID and DTag values, the sender MUST For each active pair of RuleID and DTag values, the sender MUST
maintain: maintain:
* one Attempts counter, and * one Attempts counter and
* one Retransmission Timer. * one Retransmission Timer.
For each active pair of RuleID and DTag values, the receiver MUST For each active pair of RuleID and DTag values, the receiver MUST
maintain: maintain:
* one Inactivity Timer, and * one Attempts counter and
* one Attempts counter. * one Inactivity Timer.
8.4.3.1. Sender Behavior 3.2.1.1. Sender Behavior (Replaces Section 8.4.3.1, RFC 8724)
At the beginning of the fragmentation of a new SCHC Packet: At the beginning of the fragmentation of a new SCHC Packet:
* the fragment sender MUST select a RuleID and DTag value pair for * the fragment sender MUST select a RuleID and DTag value pair for
this SCHC Packet. A Rule MUST NOT be selected if the values of M this SCHC Packet. A Rule MUST NOT be selected if the values of M
and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot
be fragmented in (2^M) * WINDOW_SIZE tiles or less. be fragmented in (2^M) * WINDOW_SIZE tiles or less.
* the fragment sender MUST initialize the Attempts counter to 0 for * the fragment sender MUST initialize the Attempts counter to 0 for
that RuleID and DTag value pair. that RuleID and DTag value pair.
skipping to change at page 11, line 20 skipping to change at line 482
Fragment: Fragment:
* the selected tiles MUST be contiguous in the original SCHC Packet, * the selected tiles MUST be contiguous in the original SCHC Packet,
and and
* they MUST be placed in the SCHC Fragment Payload adjacent to one * they MUST be placed in the SCHC Fragment Payload adjacent to one
another, in the order they appear in the SCHC Packet, from the another, in the order they appear in the SCHC Packet, from the
start of the SCHC Packet toward its end. start of the SCHC Packet toward its end.
Tiles that are not the last one MUST be sent in Regular SCHC Tiles that are not the last one MUST be sent in Regular SCHC
Fragments specified in Section 8.3.1.1. The FCN field MUST contain Fragments as specified in Section 8.3.1.1. The FCN field MUST
the tile index of the first tile sent in that SCHC Fragment. contain the tile index of the first tile sent in that SCHC Fragment.
In a Regular SCHC Fragment message, the sender MUST fill the W field In a Regular SCHC Fragment message, the sender MUST fill the W field
with the window number of the first tile sent in that SCHC Fragment. with the window number of the first tile sent in that SCHC Fragment.
A Profile MUST define if the last tile of a SCHC Packet is sent: A Profile MUST define if the last tile of a SCHC Packet is sent:
* in a Regular SCHC Fragment, alone or as part of a multi-tiles * in a Regular SCHC Fragment, alone or as part of a multi-tiles
Payload, Payload,
* alone in an All-1 SCHC Fragment, or * alone in an All-1 SCHC Fragment, or
* with any of the above two methods. * with either one of the above two methods.
In an All-1 SCHC Fragment message, the sender MUST fill the W field In an All-1 SCHC Fragment message, the sender MUST fill the W field
with the window number of the last tile of the SCHC Packet. with the window number of the last tile of the SCHC Packet.
The fragment sender MUST send SCHC Fragments such that, all together, The fragment sender MUST send SCHC Fragments such that, all together,
they contain all the tiles of the fragmented SCHC Packet. they contain all the tiles of the fragmented SCHC Packet.
The fragment sender MUST send at least one All-1 SCHC Fragment. The fragment sender MUST send at least one All-1 SCHC Fragment.
In doing the two items above, the sender MUST ascertain that the In doing the two items above, the sender MUST ascertain that the
receiver will not receive the last tile through both a Regular SCHC receiver will not receive the last tile through both a Regular SCHC
Fragment and an All-1 SCHC Fragment. Fragment and an All-1 SCHC Fragment.
The fragment sender MUST listen for SCHC Compound ACK messages after The fragment sender MUST listen for SCHC Compound ACK messages after
having sent: having sent:
* an All-1 SCHC Fragment, or * an All-1 SCHC Fragment or
* a SCHC ACK REQ. * a SCHC ACK REQ.
A Profile MAY specify other times at which the fragment sender MUST A Profile MAY specify other times at which the fragment sender MUST
listen for SCHC Compound ACK messages. For example, this could be listen for SCHC Compound ACK messages. For example, this could be
after sending a complete window of tiles. after sending a complete window of tiles.
Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC
ACK REQ: ACK REQ:
skipping to change at page 12, line 31 skipping to change at line 542
* otherwise, the fragment sender MUST send a SCHC Sender-Abort, and * otherwise, the fragment sender MUST send a SCHC Sender-Abort, and
it MAY exit with an error condition. it MAY exit with an error condition.
All message receptions being discussed in the rest of this section All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity. processed", even if not spelled out, for brevity.
On receiving a SCHC Compound ACK: On receiving a SCHC Compound ACK:
* if one of the W field in the SCHC Compound ACK corresponds to the * if one of the W fields in the SCHC Compound ACK corresponds to the
last window of the SCHC Packet: last window of the SCHC Packet:
- if the C bit is set, the sender MAY exit successfully. - if the C bit is set, the sender MAY exit successfully.
- otherwise: - otherwise:
o if the Profile mandates that the last tile be sent in an o if the Profile mandates that the last tile be sent in an
All-1 SCHC Fragment: All-1 SCHC Fragment:
+ if the SCHC Compound ACK shows no missing tile at the + if the SCHC Compound ACK shows no missing tile at the
receiver, the sender: receiver, the sender:
* MUST send a SCHC Sender-Abort, and * MUST send a SCHC Sender-Abort and
* MAY exit with an error condition. * MAY exit with an error condition.
+ otherwise: + otherwise:
* the fragment sender MUST send SCHC Fragment messages * the fragment sender MUST send SCHC Fragment messages
containing all the tiles of all the windows that are containing all the tiles of all the windows that are
reported missing in the SCHC Compound ACK. reported missing in the SCHC Compound ACK.
* if the last of these SCHC Fragment messages is not an * if the last of these SCHC Fragment messages is not an
All-1 SCHC Fragment, then the fragment sender MAY All-1 SCHC Fragment, then the fragment sender MAY
either send in addition a SCHC ACK REQ with the W either send, in addition, a SCHC ACK REQ with the W
field corresponding to the last window, or repeat the field corresponding to the last window or repeat the
All-1 SCHC Fragment to ask the receiver confirmation All-1 SCHC Fragment to ask the receiver to confirm
that all tiles have been correctly received. that all tiles have been correctly received.
* in doing the two items above, the sender MUST * in doing the two items above, the sender MUST
ascertain that the receiver will not receive the last ascertain that the receiver will not receive the last
tile through both a Regular SCHC Fragment and an All-1 tile through both a Regular SCHC Fragment and an All-1
SCHC Fragment. SCHC Fragment.
o otherwise: o otherwise:
+ if the SCHC Compound ACK shows no missing tile at the + if the SCHC Compound ACK shows no missing tile at the
skipping to change at page 13, line 40 skipping to change at line 600
corresponding to the last window. corresponding to the last window.
* otherwise, the fragment sender: * otherwise, the fragment sender:
- MUST send SCHC Fragment messages containing the tiles that are - MUST send SCHC Fragment messages containing the tiles that are
reported missing in the SCHC Compound ACK. reported missing in the SCHC Compound ACK.
- then, it MAY send a SCHC ACK REQ with the W field corresponding - then, it MAY send a SCHC ACK REQ with the W field corresponding
to the last window. to the last window.
See Figure 43/> for one among several possible examples of a Finite See Figure 43 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43)
State Machine implementing a sender behavior obeying this for one among several possible examples of a Finite State Machine
specification. implementing a sender behavior obeying this specification.
8.4.3.2. Receiver Behavior 3.2.1.2. Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724)
On receiving a SCHC Fragment with a RuleID and DTag pair not being On receiving a SCHC Fragment with a RuleID and DTag pair not being
processed at that time: processed at that time:
* the receiver SHOULD check if the DTag value has not recently been * the receiver SHOULD check that the DTag value has not recently
used for that RuleID value, thereby ensuring that the received been used for that RuleID value, thereby ensuring that the
SCHC Fragment is not a remnant of a prior fragmented SCHC Packet received SCHC Fragment is not a remnant of a prior fragmented SCHC
transmission. The initial value of the Inactivity Timer is the Packet transmission. The initial value of the Inactivity Timer is
RECOMMENDED lifetime for the DTag value at the receiver. If the the RECOMMENDED lifetime for the DTag value at the receiver. If
SCHC Fragment is determined to be such a remnant, the receiver MAY the SCHC Fragment is determined to be such a remnant, the receiver
silently ignore it and discard it. MAY silently ignore it and discard it.
* the receiver MUST start a process to assemble a new SCHC Packet * the receiver MUST start a process to assemble a new SCHC Packet
with that RuleID and DTag value pair. The receiver MUST start an with that RuleID and DTag value pair. The receiver MUST start an
Inactivity Timer for that RuleID and DTag value pair. It MUST Inactivity Timer for that RuleID and DTag value pair. It MUST
initialize an Attempts counter to 0 for that RuleID and DTag value initialize an Attempts counter to 0 for that RuleID and DTag value
pair. If the receiver is under-resourced to do this, it MUST pair. If the receiver is under-resourced to do this, it MUST
respond to the sender with a SCHC Receiver-Abort. respond to the sender with a SCHC Receiver-Abort.
On reception of any SCHC F/R message for the RuleID and DTag pair On reception of any SCHC F/R message for the RuleID and DTag pair
being processed, the receiver MUST reset the Inactivity Timer being processed, the receiver MUST reset the Inactivity Timer
pertaining to that RuleID and DTag pair. pertaining to that RuleID and DTag pair.
All message receptions being discussed in the rest of this section All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity. processed", even if not spelled out, for brevity.
On receiving a SCHC Fragment message, the receiver determines what On receiving a SCHC Fragment message, the receiver determines what
tiles were received, based on the payload length and on the W and FCN tiles were received, based on the payload length and on the W and FCN
fields of the SCHC Fragment. fields of the SCHC Fragment.
* if the FCN is All-1, if a Payload is present, the full SCHC * if the FCN is All-1 and if a Payload is present, the full SCHC
Fragment Payload MUST be assembled including the padding bits. Fragment Payload MUST be assembled including the padding bits.
This is because the size of the last tile is not known by the This is because the size of the last tile is not known by the
receiver; therefore, padding bits are indistinguishable from the receiver; therefore, padding bits are indistinguishable from the
tile data bits, at this stage. They will be removed by the SCHC 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 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, equals the size of one regular tile plus the size of an L2 Word,
this SHOULD raise an error flag. this SHOULD raise an error flag.
* otherwise, tiles MUST be assembled based on the a priori known * otherwise, tiles MUST be assembled based on the a priori known
tile size. tile size.
skipping to change at page 15, line 4 skipping to change at line 660
indistinguishable from the tile data bits, at this stage. indistinguishable from the tile data bits, at this stage.
- The payload may contain the penultimate tile that, if allowed - The payload may contain the penultimate tile that, if allowed
by the Profile, MAY be exactly one L2 Word shorter than the by the Profile, MAY be exactly one L2 Word shorter than the
regular tile size. regular tile size.
- Otherwise, padding bits MUST be discarded. This is possible - Otherwise, padding bits MUST be discarded. This is possible
because: because:
o the size of the tiles is known a priori, o the size of the tiles is known a priori,
o tiles are larger than an L2 Word, and o tiles are larger than an L2 Word, and
o padding bits are always strictly less than an L2 Word. o padding bits are always strictly less than an L2 Word.
On receiving a SCHC All-0 SCHC Fragment: On receiving a SCHC All-0 SCHC Fragment:
* if the receiver knows of any windows with missing tiles for the * if the receiver knows of any windows with missing tiles for the
packet being reassembled (and depending on certain parameters, packet being reassembled (and depending on certain parameters,
like network conditions, sender buffer/chache size, supported like network conditions, sender buffer/cache size, and supported
application delay, among others), it MAY return a SCHC Compound application delay, among others), it MAY return a SCHC Compound
ACK for the missing tiles, starting from the lowest-numbered ACK for the missing tiles, starting from the lowest-numbered
window. window.
On receiving a SCHC ACK REQ or an All-1 SCHC Fragment: On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:
* if the receiver knows of any windows with missing tiles for the * if the receiver knows of any windows with missing tiles for the
packet being reassembled, it MUST return a SCHC Compound ACK for packet being reassembled, it MUST return a SCHC Compound ACK for
the missing tiles, starting from the lowest-numbered window. the missing tiles, starting from the lowest-numbered window.
* otherwise: * otherwise:
- if it has received at least one tile, it MUST return a SCHC - if it has received at least one tile, it MUST return a SCHC
Compound ACK for the highest-numbered window it currently has Compound ACK for the highest-numbered window it currently has
tiles for, tiles for,
- otherwise, it MUST return a SCHC Compound ACK for window - otherwise, it MUST return a SCHC Compound ACK for window number
numbered 0. 0.
A Profile MAY specify other times and circumstances at which a A Profile MAY specify other times and circumstances at which a
receiver sends a SCHC Compound ACK, and which window the SCHC receiver sends a SCHC Compound ACK and which window the SCHC Compound
Compound ACK reports about in these circumstances. ACK reports about in these circumstances.
Upon sending a SCHC Compound ACK, the receiver MUST increase the Upon sending a SCHC Compound ACK, the receiver MUST increase the
Attempts counter. Attempts counter.
After receiving an All-1 SCHC Fragment, a receiver MUST check the After receiving an All-1 SCHC Fragment, a receiver MUST check the
integrity of the reassembled SCHC Packet at least every time it integrity of the reassembled SCHC Packet at least every time it
prepares for sending a SCHC Compound ACK for the last window. prepares to send a SCHC Compound ACK for the last window.
Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an
error condition. error condition.
Upon expiration of the Inactivity Timer, the receiver MUST send a Upon expiration of the Inactivity Timer, the receiver MUST send a
SCHC Receiver-Abort, and it MAY exit with an error condition. SCHC Receiver-Abort, and it MAY exit with an error condition.
On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST
send a SCHC Receiver-Abort, and it MAY exit with an error condition. send a SCHC Receiver-Abort, and it MAY exit with an error condition.
Reassembly of the SCHC Packet concludes when: Reassembly of the SCHC Packet concludes when:
* a Sender-Abort has been received, or * a Sender-Abort has been received,
* the Inactivity Timer has expired, or * the Inactivity Timer has expired,
* the Attempts counter has exceeded MAX_ACK_REQUESTS, or * the Attempts counter has exceeded MAX_ACK_REQUESTS, or
* at least an All-1 SCHC Fragment has been received and integrity * at least an All-1 SCHC Fragment has been received and integrity
checking of the reassembled SCHC Packet is successful. checking of the reassembled SCHC Packet is successful.
See Figure 44 for one among several possible examples of a Finite See Figure 44 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-44)
State Machine implementing a receiver behavior obeying this for one among several possible examples of a Finite State Machine
specification. The example provided is meant to match the sender implementing a receiver behavior obeying this specification. The
Finite State Machine of Figure 43. example provided is meant to match the sender Finite State Machine of
Figure 43 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43).
4. SCHC Compound ACK Example 4. SCHC Compound ACK Example
Figure 7 shows an example transmission of a SCHC Packet in ACK-on- 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 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 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. two lost SCHC fragments. Only 1 SCHC Compound ACK is generated.
Sender Receiver Sender Receiver
|-----W=0, FCN=6 ----->| |-----W=0, FCN=6 ----->|
|-----W=0, FCN=5 ----->| |-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->| |-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->| |-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 --X | |-----W=0, FCN=2 --X |
|-----W=0, FCN=1 ----->| |-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->| Bitmap: 1111011 |-----W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK) (no ACK)
skipping to change at page 16, line 50 skipping to change at line 755
|-----W=1, FCN=3 ----->| |-----W=1, FCN=3 ----->|
|-----W=1, FCN=2 ----->| |-----W=1, FCN=2 ----->|
|-----W=1, FCN=1 --X | |-----W=1, FCN=1 --X |
|-- W=1, FCN=7 + RCS ->| Integrity check: failure |-- W=1, FCN=7 + RCS ->| Integrity check: failure
|<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011, |<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011,
|-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101] |-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101]
|-----W=1, FCN=1 ----->| Integrity check: success |-----W=1, FCN=1 ----->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1 |<--- ACK, W=1, C=1 ---| C=1
(End) (End)
Figure 7: SCHC Compound ACK message sequence example Figure 7: SCHC Compound ACK Message Sequence Example
|--- SCHC ACK Header --|- W=00 --|----- W=01 -----| |--- SCHC ACK Header --|- W=00 --|----- W=01 -----|
|--T-|---M--|-1-| |---M--| |---M--| |--T-|---M--|-1-| |---M--| |---M--|
+------+----+------+---+---------+------+---------+------+-----+ +------+----+------+---+---------+------+---------+------+-----+
|RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad | |RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad |
+------+----+------+---+---------+------+---------+------+-----+ +------+----+------+---+---------+------+---------+------+-----+
next L2 Word boundary ->|<-- L2 Word ->| next L2 Word boundary ->|<-- L2 Word ->|
Figure 8: SCHC Compound ACK message format example: Losses are Figure 8: SCHC Compound ACK Message Format Example: Losses are
found in windows 00 and 01 Found in Windows 00 and 01
5. SCHC Compound ACK YANG Data Model 5. SCHC Compound ACK YANG Data Model
The present document also extends the SCHC YANG data model defined in This document also extends the SCHC YANG data model defined in
[RFC9363] by including a new leaf in the Ack-on-Error fragmentation [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 mode to describe both the option to use the SCHC Compound ACK, as
well as its bitmap format. well as its bitmap format.
5.1. SCHC YANG Data Model Extension 5.1. SCHC YANG Data Model Extension
<CODE BEGINS> file "ietf-lpwan-schc-compound-ack@2023-03-16.yang" <CODE BEGINS> file "ietf-schc-compound-ack@2023-07-22.yang"
module ietf-lpwan-schc-compound-ack { module ietf-schc-compound-ack {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:" namespace "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack";
+ "ietf-lpwan-schc-compound-ack";
prefix schc-compound-ack; prefix schc-compound-ack;
import ietf-schc { import ietf-schc {
prefix schc; prefix schc;
} }
organization organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan) "IETF IPv6 over Low Power Wide-Area Networks (lpwan)
working group"; Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/lpwan/about/> "WG Web: <https://datatracker.ietf.org/wg/lpwan/about/>
WG List: <mailto:lp-wan@ietf.org> WG List: <mailto:lp-wan@ietf.org>
Editor: Laurent Toutain Editor: Laurent Toutain
<mailto:laurent.toutain@imt-atlantique.fr> <mailto:laurent.toutain@imt-atlantique.fr>
Editor: Juan Carlos Zuniga Editor: Juan Carlos Zuniga
<mailto:j.c.zuniga@ieee.org> <mailto:j.c.zuniga@ieee.org>
Editor: Sergio Aguilar Editor: Sergio Aguilar
<mailto:sergio.aguilar.romero@upc.edu>"; <mailto:sergio.aguilar.romero@upc.edu>";
description description
skipping to change at page 18, line 10 skipping to change at line 810
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9363 This version of this YANG module is part of RFC 9363
(https://www.rfc-editor.org/info/rfc9363); see the RFC itself (https://www.rfc-editor.org/info/rfc9363); see the RFC itself
for full legal notices. 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 Generic data model for the Static Context Header Compression
Rule for SCHC, based on RFCs 8724 and 8824. Including Rule for SCHC, based on RFCs 8724 and 8824. Including
compression, no-compression, and fragmentation Rules."; compression, no-compression, and fragmentation Rules.";
revision 2023-03-16 { revision 2023-07-22 {
description description
"Initial version for RFC YYYY "; "Initial version for RFC 9441.";
reference reference
"RFC YYYY: SCHC Compound ACK"; "RFC 9441 Static Context Header Compression (SCHC) Compound
Acknowledgement (ACK)";
} }
identity bitmap-format-base-type { identity bitmap-format-base-type {
description description
"Define how the bitmap is formed in ACK messages."; "Define how the bitmap is formed in ACK messages.";
} }
identity bitmap-RFC8724 { identity bitmap-RFC8724 {
base bitmap-format-base-type; base bitmap-format-base-type;
description description
"Bitmap by default as defined in RFC8724."; "Bitmap by default as defined in RFC 8724.";
reference reference
"RFC 8724 SCHC: Generic Framework for Static "RFC 8724 SCHC: Generic Framework for Static Context Header
Context Header Compression and Fragmentation"; Compression and Fragmentation";
} }
identity bitmap-compound-ack { identity bitmap-compound-ack {
base bitmap-format-base-type; base bitmap-format-base-type;
description description
"Compound ACK allows several bitmaps in a ACK message."; "Compound ACK allows several bitmaps in an ACK message.";
} }
typedef bitmap-format-type { typedef bitmap-format-type {
type identityref { type identityref {
base bitmap-format-base-type; base bitmap-format-base-type;
} }
description description
"Type of bitmap used in rules."; "Type of bitmap used in Rules.";
} }
augment "/schc:schc/schc:rule/schc:nature/" augment "/schc:schc/schc:rule/schc:nature/"
+ "schc:fragmentation/schc:mode/schc:ack-on-error" { + "schc:fragmentation/schc:mode/schc:ack-on-error" {
leaf bitmap-format { leaf bitmap-format {
when "derived-from-or-self(../schc:fragmentation-mode, when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')"; 'schc:fragmentation-mode-ack-on-error')";
type schc-compound-ack:bitmap-format-type; type schc-compound-ack:bitmap-format-type;
default "schc-compound-ack:bitmap-RFC8724"; default "schc-compound-ack:bitmap-RFC8724";
description description
"How the bitmaps are included in the SCHC ACK message."; "How the bitmaps are included in the SCHC ACK message.";
} }
leaf last-bitmap-compression { leaf last-bitmap-compression {
when "derived-from-or-self(../schc:fragmentation-mode, when "derived-from-or-self(../schc:fragmentation-mode,
'schc:fragmentation-mode-ack-on-error')"; 'schc:fragmentation-mode-ack-on-error')";
type boolean; type boolean;
default "true"; default "true";
description description
"When true the ultimate bitmap in the SCHC ACK message "When true, the ultimate bitmap in the SCHC ACK message
can be compressed. Default behavior from RFC8724"; can be compressed. Default behavior from RFC 8724.";
reference reference
"RFC 8724 SCHC: Generic Framework for Static "RFC 8724 SCHC: Generic Framework for Static Context Header
Context Header Compression and Compression and Fragmentation";
Fragmentation";
} }
description description
"Augment the SCHC rules to manage Compound Ack."; "Augment the SCHC Rules to manage Compound ACK.";
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 9: SCHC YANG Data Model - Compound ACK extension Figure 9: SCHC YANG Data Model - Compound ACK Extension
5.2. SCHC YANG Tree Extension 5.2. SCHC YANG Tree Extension
module: ietf-lpwan-schc-compound-ack module: ietf-schc-compound-ack
augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/ augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
schc:mode/schc:ack-on-error: schc:mode/schc:ack-on-error:
+--rw bitmap-format? schc-compound-ack:bitmap-format-type +--rw bitmap-format? schc-compound-ack:bitmap-format-type
+--rw last-bitmap-compression? boolean +--rw last-bitmap-compression? boolean
Figure 10: Tree Diagram - Compound ACK extension Figure 10: Tree Diagram - Compound ACK Extension
6. SCHC Compound ACK Parameters 6. SCHC Compound ACK Parameters
This section lists the parameters related to the SCHC Compound ACK This section lists the parameters related to the SCHC Compound ACK
usage that need to be defined in the Profile. This list MUST be 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 appended to the list of SCHC parameters under "Decision to use SCHC
fragmentation mechanism or not. If yes, the document must describe:" fragmentation mechanism or not. If yes, the document must describe:"
in Annex D of [RFC8724]. as defined in Appendix D of [RFC8724].
* Usage or not of the SCHC Compound ACK message. * whether the SCHC Compound ACK message is used or not, and
* Usage or not of the compressed bitmap format in the last window of * whether the compressed bitmap format in the last window of the
the SCHC Compound ACK message. SCHC Compound ACK message is used or not.
7. Security considerations 7. Security Considerations
The current document specifies a message format extension for SCHC. This document specifies a message format extension for SCHC. Hence,
Hence, the same Security Considerations defined in [RFC8724] and in the same security considerations defined in [RFC8724] and [RFC9363]
[RFC9363] apply. apply.
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error: All the data nodes may be modified. The Rule schc:ack-on-error:
contains sensitive information, such as the SCHC F/R mode All the data nodes may be modified. The Rule contains sensitive
configuration and usage and configuration of the SCHC Compound ACK. information, such as the SCHC F/R mode configuration and usage and
An attacker may try to modify other devices' Rules by changing the F/ SCHC Compound ACK configuration. An attacker may try to modify
R mode or the usage of the SCHC Compound ACK and may block other devices' Rules by changing the F/R mode or the usage of the
communication or create extra ACKs. Therefore, a device must be SCHC Compound ACK and may block communication or create extra
allowed to modify only its own rules on the remote SCHC instance. ACKs. Therefore, a device must be allowed to modify only its own
The identity of the requester must be validated. This can be done Rules on the remote SCHC instance. The identity of the requester
through certificates or access lists. Some of the readable data must be validated. This can be done through certificates or
nodes in this YANG module may be considered sensitive or vulnerable access lists.
in some network environments. It is thus important to control read
access (e.g., via get, get-config, or notification) to these data Some of the readable data nodes in this YANG module may be considered
nodes. These are the subtrees and data nodes and their sensitivity/ sensitive or vulnerable in some network environments. It is thus
vulnerability: 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:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error: By reading this module, an attacker may learn the schc:ack-on-error:
F/R mode used by the device and how the device manage the bitmap By reading this module, an attacker may learn the F/R mode used by
creation and also learn the buffer sizes and when the device will the device, how the device manages the bitmap creation, the buffer
request an ACK. sizes, and when the device will request an ACK.
8. IANA Considerations 8. IANA Considerations
This document registers one URI and one YANG data model. This document registers one URI and one YANG data model.
8.1. URI Registration 8.1. URI Registration
IANA registered the following URI in the "IETF XML Registry" IANA registered the following URI in the "IETF XML Registry"
[RFC3688]: [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack URI: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
8.2. YANG Module Name Registration 8.2. YANG Module Name Registration
IANA has registered the following YANG data model in the "YANG Module IANA has registered the following YANG data model in the "YANG Module
Names" registry [RFC6020]. Names" registry [RFC6020].
name: ietf-lpwan-schc-compound-ack name: ietf-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 namespace: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack
FONDECYT Regular 1201893 and Basal Project FB0008.
Diego Wistuba has been funded by the ANID Chile Project FONDECYT prefix: schc-compound-ack
Regular 1201893.
The authors would like to thank Rafael Vidal, Julien Boite, Renaud reference: RFC 9441
Marty, Antonis Platis, Dominique Barthel and Pascal Thubert for their
very useful comments, reviews and implementation design
considerations.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static
Context Header Compression (SCHC)", RFC 9363, Context Header Compression (SCHC)", RFC 9363,
DOI 10.17487/RFC9363, March 2023, DOI 10.17487/RFC9363, March 2023,
<https://www.rfc-editor.org/info/rfc9363>. <https://www.rfc-editor.org/info/rfc9363>.
10.2. Informative References 9.2. Informative References
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
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 through 2017 grant SGR 376 and 2021 grant
SGR 00330.
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.
Authors' Addresses Authors' Addresses
Juan Carlos Zuniga
Juan Carlos Zúñiga
Cisco Cisco
Montreal QC Montreal QC
Canada Canada
Email: juzuniga@cisco.com Email: juzuniga@cisco.com
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya Universitat Politècnica de Catalunya
C/Esteve Terradas, 7 C/Esteve Terradas, 7
08860 Castelldefels 08860 Castelldefels
Spain Spain
Email: carles.gomez@upc.edu Email: carles.gomez@upc.edu
Sergio Aguilar Sergio Aguilar
Universitat Politecnica 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 Cespedes Sandra Céspedes
Concordia University Concordia University
1455 De Maisonneuve Blvd. W. 1455 De Maisonneuve Blvd. W.
Montreal QC, H3G 1M8 Montreal QC, H3G 1M8
Canada Canada
Email: sandra.cespedes@concordia.ca Email: sandra.cespedes@concordia.ca
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: research@witu.cl
 End of changes. 133 change blocks. 
324 lines changed or deleted 365 lines changed or added

This html diff was produced by rfcdiff 1.48.