rfc9441xml2.original.xml   rfc9441.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>-->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType
<?rfc symrefs="yes"?> ="IETF" consensus="true" number="9441" docName="draft-ietf-lpwan-schc-compound-a
<?rfc sortrefs="yes"?> ck-17" category="std" obsoletes="" updates="8724,9363" symRefs="true" sortRefs="
<?rfc strict="yes"?> true" tocInclude="true" xml:lang="en" version="3">
<?rfc compact="yes"?> <!-- xml2rfc v2v3 conversion 3.17.3 -->
<?rfc toc="yes"?>
<rfc ipr="trust200902" submissionType="IETF" consensus="true" docName="draft-iet
f-lpwan-schc-compound-ack-17" category="std" updates="8724,9363">
<front> <front>
<title abbrev="SCHC Compound ACK"> <title abbrev="SCHC Compound ACK">
SCHC Compound ACK Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)
</title> </title>
<seriesInfo name="RFC" value="9441"/>
<author fullname="Juan Carlos Zuniga" initials="JC." surname="Zuniga"> <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
<organization abbrev="Cisco"> <organization abbrev="Cisco">
Cisco Cisco
</organization> </organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Montreal</city> <city>Montreal</city>
<code> QC</code> <code>QC</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>juzuniga@cisco.com</email> <email>juzuniga@cisco.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Gomez" fullname="Carles Gomez">
<author initials="C." surname="Gomez" fullname="Carles Gomez"> <organization>Universitat Politècnica de Catalunya</organization>
<organization>Universitat Politecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</str <street>C/Esteve Terradas, 7</street>
eet> <street>08860 Castelldefels</street>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>carles.gomez@upc.edu</email> <email>carles.gomez@upc.edu</email>
</address> </address>
</author> </author>
<author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
<author initials="S." surname="Aguilar" fullname="Sergio Aguilar"> <organization>Universitat Politècnica de Catalunya</organization>
<organization>Universitat Politecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</str <street>C/Esteve Terradas, 7</street>
eet> <street>08860 Castelldefels</street>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>sergio.aguilar.romero@upc.edu</email> <email>sergio.aguilar.romero@upc.edu</email>
</address> </address>
</author> </author>
<author initials="L." surname="Toutain" fullname="Laurent Toutain">
<author initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization>IMT-Atlantique</organization> <organization>IMT-Atlantique</organization>
<address> <address>
<postal> <postal>
<street>2 rue de la Chataigneraie</street> <street>CS 17607</street> <street>2 rue de la Chataigneraie</street>
<street>CS 17607</street>
<city>35576 Cesson-Sevigne Cedex</city> <city>35576 Cesson-Sevigne Cedex</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>Laurent.Toutain@imt-atlantique.fr</email> <email>Laurent.Toutain@imt-atlantique.fr</email>
</address> </address>
</author> </author>
<author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
<author initials="S." surname="Cespedes" fullname="Sandra Cespedes"> <organization>Concordia University</organization>
<organization>Concordia University</organization>
<address> <address>
<postal> <postal>
<street>1455 De Maisonneuve Blvd. W.</street> <street>1455 De Maisonneuve Blvd. W.</street>
<city>Montreal QC, H3G 1M8</city> <city>Montreal QC, H3G 1M8</city>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>sandra.cespedes@concordia.ca</email> <email>sandra.cespedes@concordia.ca</email>
</address> </address>
</author> </author>
<author initials="D." surname="Wistuba" fullname="Diego Wistuba">
<author initials="D." surname="Wistuba" fullname="Diego Wistuba"> <organization>NIC Labs, Universidad de Chile</organization>
<organization>NIC Labs, Universidad de Chile</organization>
<address> <address>
<postal> <postal>
<street>Av. Almte. Blanco Encalada 1975</street> <street>Santiago</str <street>Av. Almte. Blanco Encalada 1975</street>
eet> <street>Santiago</street>
<country>Chile</country> <country>Chile</country>
</postal> </postal>
<email>wistuba@niclabs.cl</email> <email>research@witu.cl</email>
</address> </address>
</author> </author>
<date year="2023" month="July"/>
<date year="2023" month="April" day="5"/> <workgroup>lpwan</workgroup>
<keyword>SCHC</keyword>
<workgroup>lpwan Working Group</workgroup> <keyword>LPWAN</keyword>
<keyword>IoT</keyword>
<keyword>Fragmentation</keyword>
<keyword>Reliable Delivery</keyword>
<keyword>Link Layer Protocols</keyword>
<keyword>Cross-Layer Protocols</keyword>
<keyword>Adaptation Layer</keyword>
<keyword>Acknowledgment</keyword>
<keyword>Sigfox</keyword>
<keyword>LoRaWAN</keyword>
<keyword>NB-IoT</keyword>
<keyword>Compound ACK</keyword>
<abstract> <abstract>
<t>This document updates the Static Context Header Compression (SCHC) and
<t>The present document updates the SCHC (Static Context Header Compression and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363).
fragmentation) protocol RFC8724 and the corresponding Yang Module RFC9363. It de It defines a SCHC Compound Acknowledgement (ACK) message
fines a SCHC Compound ACK message format and procedure, which are intended to reduce the number of response transm
format and procedure, which are intended to reduce the number of response transm issions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of s
issions (i.e., SCHC ACKs) in the ACK-on-Error mode, by accumulating bitmaps of s everal windows in a single SCHC message
everal windows in a single SCHC message
(i.e., the SCHC Compound ACK). </t> (i.e., the SCHC Compound ACK). </t>
<t>Both message format and procedure are generic, so they can be used, for insta nce, by any of the four Low Power Wide Area Networks (LPWANs) technologies defin ed in RFC8376, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. <t>Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network (LPWAN) technologi es defined in RFC 8376, which are Sigfox, Long Range Wide Area Network (LoRaWAN) , Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t>The Generic Framework for Static Context Header Compression (SCHC) and
<t>The Generic Framework for Static Context Header Compression and Fragmentation Fragmentation specification <xref target="RFC8724"/> describes two mechanisms:
(SCHC) specification <xref target="RFC8724"/> describes two mechanisms: i) a protocol header compression scheme and ii) a frame fragmentation and loss r
i) a protocol header compression scheme, and ii) a frame fragmentation and loss ecovery functionality. Either can be used on top of radio technologies, such as
recovery functionality. Either can be used on top of radio technologies such as the four Low-Power Wide Area Networks (LPWANs) listed in <xref target="RFC8376"/
the four Low Power Wide Area Networks (LPWANs) listed in <xref target="RFC8376"/ >, which are Sigfox, LoRaWAN, NB-IoT, and IEEE 802.15.4w. These LPWANs have simi
>, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. These LPWANs have similar c lar characteristics, such as star-oriented topologies, network architecture, and
haracteristics such as star-oriented topologies, network architecture, connected devices with built-in applications.
connected devices with built-in applications, etc.
</t> </t>
<t>SCHC offers a great level of flexibility to accommodate all these LPWAN techn ologies. Even though there are a great number of similarities between <t>SCHC offers a great level of flexibility to accommodate all these LPWAN technologies. Even though there are a number of similarities between
them, some differences exist with respect to the transmission characteristics, p ayload sizes, etc. Hence, there are optimal parameters and modes of operation them, some differences exist with respect to the transmission characteristics, p ayload sizes, etc. Hence, there are optimal parameters and modes of operation
that can be used when SCHC is used on top of a specific LPWAN technology. that can be used when SCHC is used on top of a specific LPWAN technology.
</t> </t>
<t> <t>
In ACK-on-Error mode in <xref target="RFC8724"/> the SCHC Packet is fragmente In ACK-on-Error mode in <xref target="RFC8724"/>, the SCHC Packet is fragment
d into pieces called tiles, with all tiles of the same size except for the last ed into pieces called tiles, where all tiles are the same size except for the la
one, which can be smaller. Successive tiles are grouped in windows of fixed size st one, which can be smaller. Successive tiles are grouped in windows of fixed s
. ize.
A SCHC Fragment carries one or several contiguous tiles, which may span mult A SCHC Fragment carries one or several contiguous tiles, which may span mult
iple windows. When sending all tiles from all windows, the last tile is sent in iple windows. When sending all tiles from all windows, the last tile is sent in
an All-1 SCHC Fragment. The SCHC receiver, after receiving the All-1 SCHC Fragme an All-1 SCHC Fragment. The SCHC receiver will send a SCHC ACK reporting on the
nt will send a SCHC ACK reporting on the reception of exactly one window of tile reception of exactly one window of tiles after receiving the All-1 SCHC Fragment
s. In case of SCHC Fragment losses, a bitmap is added to the failure SCHC ACK, w . In case of SCHC Fragment losses, a bitmap is added to the failure SCHC ACK, wh
here each bit in the bitmap corresponds to a tile in the window. If SCHC Fragmen ere each bit in the bitmap corresponds to a tile in the window. If SCHC Fragment
t losses span multiple windows, the SCHC receiver will send one failure SCHC ACK losses span multiple windows, the SCHC receiver will send one failure SCHC ACK
per window with losses. per window with losses.
</t> </t>
<t>This document updates the SCHC protocol for frame fragmentation and los
<t>The present document updates the SCHC protocol for frame fragmentation an s recovery. It defines a SCHC Compound ACK format and procedure, which
d loss recovery. It defines a SCHC Compound ACK format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in
is intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC Compound ACK extends the failure SCHC A
the ACK-on-Error mode of SCHC. The SCHC Compound ACK extends the failure SCHC AC CK message
K message format so that it can contain several bitmaps, with each bitmap being identified
format so that it can contain several bitmaps, each bitmap being identified by i by its corresponding window number.
ts corresponding window number. The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in <x
The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in <x ref target="RFC8724"/>, and introduces flexibility, as the receiver has the capa
ref target="RFC8724"/>, and introduces flexibility, as the receiver has the capa bility to respond to the All-0 SCHC Fragment, providing more Downlink opportunit
bility to respond to the All-0 SCHC Fragment, providing more downlink opportunit ies and therefore adjusting to the delay requirements of the application.
ies, and therefore adjusting to the delay requirements of the application.
</t> </t>
</section>
</section> <section anchor="terminology">
<name>Terminology</name>
<section anchor="terminology" title="Terminology"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
<t>It is assumed that the reader is familiar with the terms and mechanisms defin described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
ed in <xref target="RFC8376"/> and when, and only when, they appear in all capitals, as shown here.
in <xref target="RFC8724"/>. </t>
<t>It is assumed that the reader is familiar with the terms and mechanisms
defined in <xref target="RFC8376"/> and <xref target="RFC8724"/>.
</t> </t>
</section>
</section> <section anchor="schc-compound-ack">
<name>SCHC Compound ACK</name>
<section anchor="schc-compound-ack" title="SCHC Compound ACK"> <t>The SCHC Compound ACK is a failure SCHC ACK message that can contain se
veral bitmaps, with each bitmap being identified by its
<t>The SCHC Compound ACK is a failure SCHC ACK message that can contain several
bitmaps, each bitmap being identified by its
corresponding window number. corresponding window number.
In <xref target="RFC8724"/>, the failure SCHC ACK message only contain one b In <xref target="RFC8724"/>, the failure SCHC ACK message only contains one
itmap corresponding to one window. bitmap corresponding to one window.
The SCHC Compound ACK extends this format allowing more windows to be acknow The SCHC Compound ACK extends this format, allowing more windows to be ackno
ledged in a single ACK, reducing the total number of failure SCHC ACK messages, wledged in a single ACK and reducing the total number of failure SCHC ACK messag
specially when fragment losses are present in intermediate windows. es, especially when fragment losses are present in intermediate windows.
</t> </t>
<t>The SCHC Compound ACK <bcp14>MAY</bcp14> be used in fragmentation modes
<t>The SCHC Compound ACK MAY be used in fragmentation modes that use windows and that use windows and that allow
that allow reporting the bitmaps of multiple windows at the same time; otherwise, the SCHC
reporting the bitmaps of multiple windows at the same time, and MUST NOT be used Compound ACK <bcp14>MUST NOT</bcp14> be used.
otherwise.
</t> </t>
<t>The SCHC Compound ACK:</t>
<t>The SCHC Compound ACK:</t> <ul spacing="normal">
<li>provides feedback only for windows with fragment losses,</li>
<t><list style="symbols"> <li>has a variable size that depends on the number of windows with fragm
<t>provides feedback only for windows with fragment losses,</t> ent losses being reported in the single SCHC Compound ACK,</li>
<t>has a variable size that depends on the number of windows with fragment losse <li>includes the window number (i.e., W) of each bitmap,</li>
s being reported in the single Compound SCHC ACK,</t> <li>might not cover all windows with fragment losses of a SCHC Packet, and</li>
<t>includes the window number (i.e., W) of each bitmap,</t> <li>is distinguishable from the SCHC Receiver-Abort.</li>
<!--has the same SCHC ACK format defined in <xref target="RFC8724"/> when only o </ul>
ne window with losses is reported,--> <section anchor="schc-ack-format-1B">
<t>might not cover all windows with fragment losses of a SCHC Packet,</t> <name>SCHC Compound ACK Message Format</name>
<t>and is distinguishable from the SCHC Receiver-Abort.</t> <t><xref target="success-ack-1byte"/> shows the success SCHC ACK format,
</list></t> i.e., when all fragments have been correctly received (C=1), as defined in <xre
f target="RFC8724"/>. </t>
<section anchor="schc-ack-format-1B" title="SCHC Compound ACK Message Format"> <figure anchor="success-ack-1byte">
<name>SCHC Success ACK Message Format, as Defined in RFC 8724</name>
<t><xref target="success-ack-1byte"/> shows the success SCHC ACK format, i.e., w <artwork name="" type="" align="left" alt=""><![CDATA[
hen all fragments have been correctly received (C=1), as defined in <xref target |--- SCHC ACK Header ---|
="RFC8724"/>. </t> | |--T-|--M--| 1 |
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
<t><figure title="SCHC Success ACK message format, as defined in RFC8724" anchor | RuleID |DTag| W |C=1| padding as needed
="success-ack-1byte"><artwork><![CDATA[ +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
]]></artwork>
|-- SCHC ACK Header --| </figure>
|--T-|---M--| 1 | <t>In case SCHC Fragment losses are found in any of the windows of the S
+--------+----+------+---+~~~~~~~~~~~~~~~~~~ CHC Packet, the SCHC Compound ACK <bcp14>MAY</bcp14> be used.
| RuleID |DTag| W |C=1| padding as needed The SCHC Compound ACK message format is shown in Figures <xref target="compound-
+--------+----+------+---+~~~~~~~~~~~~~~~~~~ ack-1byte" format="counter"/> and <xref target="compound-ack-less-M-padding" for
mat="counter"/>.
]]></artwork></figure></t>
<t>In case SCHC Fragment losses are found in any of the windows of the SCHC Pack
et, the SCHC Compound ACK MAY be used.
The SCHC Compound ACK message format is shown in <xref target="compound-ack-1byt
e"/> and <xref target="compound-ack-less-M-padding"/>.
</t> </t>
<t><figure title="SCHC Compound ACK message format" anchor="compound-ack-1byte"> <figure anchor="compound-ack-1byte">
<artwork><![CDATA[ <name>SCHC Compound ACK Message Format. Losses are found in windows W
= w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.
</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- 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 ->|
]]></artwork>
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi </figure>
<t>The SCHC Compound ACK groups the window number (W) with its correspon
]]></artwork></figure></t> ding bitmap.
Window numbers do not need to be contiguous. However, the window numbers and the
<t>The SCHC Compound ACK groups the window number (W) with its corresponding bit ir corresponding bitmaps included in the SCHC Compound ACK message <bcp14>MUST</
map. bcp14> be ordered from the lowest-numbered to the highest-numbered window.
Window numbers do not need to be contiguous. However, the window numbers and its Hence, if the bitmap of window number zero is present in the SCHC Compound ACK m
corresponding bitmaps included in the SCHC Compound ACK message MUST be ordered essage, it <bcp14>MUST</bcp14> always be the first one in order and its window n
from the lowest-numbered to the highest-numbered window. umber <bcp14>MUST</bcp14> be placed in the SCHC ACK Header.</t>
Hence, if the bitmap of window number zero is present in the SCHC Compound ACK m <t>If M or more padding bits would be needed after the last bitmap in th
essage, it MUST always be the first one in order and its W number MUST be placed e message to fill the last layer two (L2) Word, M bits at 0 <bcp14>MUST</bcp14>
in the SCHC ACK Header.</t> be appended after the last bitmap, and then padding is applied as needed (see <x
ref target="compound-ack-1byte"/>).
<t>If M or more padding bits would be needed after the last bitmap in the messag Since window number 0 (if present in the message) is placed as w1, the M bits se
e to fill the last L2 Word, M bits at 0 MUST be appended after the last bitmap, t to zero can't be confused with window number 0;
and then padding is applied as needed (see <xref target="compound-ack-1byte"/>). therefore, they signal the end of the SCHC Compound ACK message.
<!-- The M bits with 0 value signal the end of the SCHC Compound ACK.
To avoid confusing the M '0s' padding bits with Window number 0, if present in t
he SCHC Compound ACK, Window number 0 MUST be placed as w1. -->
Since window number 0, if present in the message, is placed as w1, the M bits se
t to zero can't be confused with window number 0,
and therefore they signal the end of the SCHC Compound ACK message.
<!-- The RECOMMENDED value for the padding bits is 0. -->
</t> </t>
<t> <xref target="compound-ack-less-M-padding"/> shows the case when the
<t> <xref target="compound-ack-less-M-padding"/> shows the case when the require required padding bits are strictly less than M bits.
d padding bits are strictly less than M bits. In this case, the L2 Maximum Transmission Unit (MTU) does not leave room for
In this case, the layer-2 MTU (Maximum Transmission Unit) does not leave roo any extra window value, let alone any bitmap,
m for any extra window value, let alone any bitmap,
thereby signaling the end of the SCHC Compound ACK message. thereby signaling the end of the SCHC Compound ACK message.
<!-- The RECOMMENDED padding value is 0. -->
</t> </t>
<figure anchor="compound-ack-less-M-padding">
<t><figure title="SCHC Compound ACK message format with less than M padding bits <name>SCHC Compound ACK Message Format with Less than M Padding Bits.
" anchor="compound-ack-less-M-padding"><artwork><![CDATA[ Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</n
ame>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- 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 ]]></artwork>
</figure>
]]></artwork></figure></t> <t>The SCHC Compound ACK <bcp14>MUST NOT</bcp14> use the Compressed Bitm
ap format for intermediate windows/bitmaps (i.e., bitmaps that are not the last
<t>The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for intermedi one of the SCHC Compound ACK message); therefore, intermediate bitmap fields <bc
ate windows/bitmaps (i.e., bitmaps that are not the last one of the SCHC Compoun p14>MUST</bcp14> be of size WINDOW_SIZE.
d ACK message), and Hence, the SCHC Compound ACK <bcp14>MAY</bcp14> use a Compressed Bitmap format o
therefore intermediate bitmaps fields MUST be of size WINDOW_SIZE. nly for the last bitmap in the message.
Hence, the SCHC Compound ACK MAY use a Compressed Bitmap format only for the The optional usage of this Compressed Bitmap for the last bitmap <bcp14>MUST</bc
last bitmap in the message. p14> be specified by the technology-specific SCHC Profile.</t>
The optional usage of this Compressed Bitmap for the last bitmap MUST be specifi
ed by the SCHC technology-specific profile.</t>
<t> The case where the last bitmap is effectively compressed corresponds to <xre
f target="compound-ack-less-M-padding"/>,
with the last bitmap ending, by construction, on an L2 Word boundary, theref
ore resulting in no padding at all.</t>
<t><xref target="compound-ack-compressed-bitmap-1"/> illustrates a bitmap compre <t> The case where the last bitmap is effectively compressed corresponds
ssion example of a SCHC Compound ACK, to <xref target="compound-ack-less-M-padding"/>,
with the last bitmap ending (by construction) on an L2 Word boundary, theref
ore resulting in no padding at all.</t>
<t><xref target="compound-ack-compressed-bitmap-1"/> illustrates a bitma
p compression example of a SCHC Compound ACK,
where the bitmap of the last window (wi) indicates that the first tile has n ot been correctly where the bitmap of the last window (wi) indicates that the first tile has n ot been correctly
received. received.
Because the compression algorithm resulted in effective compression, no padd ing is needed. Because the compression algorithm resulted in effective compression, no padd ing is needed.
</t> </t>
<figure anchor="compound-ack-compressed-bitmap-1">
<t><figure title="SCHC Compound ACK message format with compressed bitmap" ancho <name>SCHC Compound ACK Message Format with Compressed Bitmap and No P
r="compound-ack-compressed-bitmap-1"><artwork><![CDATA[ adding Added. Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;..
.&lt; wi.</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- 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
]]></artwork>
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi </figure>
<t><xref target="compound-ack-compressed-bitmap"/> illustrates another bi
]]></artwork></figure></t> tmap compression example of a SCHC Compound ACK,
where the bitmap of the last window (wi) indicates that the second and the f
<t><xref target="compound-ack-compressed-bitmap"/> illustrates another bitmap co ourth tiles have not been correctly
mpression example of a SCHC Compound ACK,
where the bitmap of the last window (wi) indicates that the second and the f
ourth tile have not been correctly
received. received.
In this example, the compression algorithm does not result in effective comp ression of the last bitmap. In this example, the compression algorithm does not result in effective comp ression of the last bitmap.
Besides, because more than M bits of padding would be needed to fill the las t L2 Word, M bits at 0 are appended to the message before padding is applied. Besides, because more than M bits of padding would be needed to fill the las t L2 Word, M bits at 0 are appended to the message before padding is applied.
</t> </t>
<t><figure title="SCHC Compound ACK message format with compressed bitmap" ancho <figure anchor="compound-ack-compressed-bitmap">
r="compound-ack-compressed-bitmap"><artwork><![CDATA[ <name>SCHC Compound ACK Message Format with Compressed Bitmap and Padd
ing Added to Reach the L2 Boundary. Losses are found in windows W = w1,...,wi, w
here w1 &lt; w2 &lt;...&lt;wi.</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- 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
]]></artwork></figure></t>
<t>If a SCHC sender gets a SCHC Compound ACK with invalid W's, such as duplicate
W values or W values not sent yet, it MUST discard the whole
SCHC Compound ACK message.</t>
<t>Note: because it has a C bit reset to 0, the SCHC Compound ACK is distinguish
able from the Receiver-Abort message <xref target="RFC8724"/>, which has a C bit
set to 1.</t>
</section> Transmitted SCHC Compound ACK
]]></artwork>
<section anchor="schc-compound-ack-behaviour" title="SCHC Compound ACK Behaviour </figure>
"> <t>If a SCHC sender gets a SCHC Compound ACK with invalid window numbers
, such as duplicate W values or W values not sent yet, it <bcp14>MUST</bcp14> di
<t>The SCHC ACK-on-Error behaviour is described in section 8.4.3 of <xref target scard the whole
="RFC8724"/>. The present document slightly modifies this behaviour, SCHC Compound ACK message.</t>
since in the baseline SCHC specification a SCHC ACK reports only one bitmap for <aside><t>Note that SCHC Compound ACKs are distinguishable from the Rece
the reception of exactly one window of tiles. The present SCHC iver-Abort message in the same way that regular SCHC ACKs are distinguishable, s
Compound ACK specification extends the SCHC ACK message format so that it can co ince the Receiver-Abort pattern never occurs in a legitimate SCHC Compound ACK <
ntain several bitmaps, each bitmap being identified by its corresponding xref target="RFC8724"/>.</t></aside>
</section>
<section anchor="schc-compound-ack-behavior">
<name>SCHC Compound ACK Behavior</name>
<t>The SCHC ACK-on-Error behavior is described in <xref target="RFC8724"
section="8.4.3" sectionFormat="of" />. The present document slightly modifies t
his behavior. In the baseline SCHC specification, a SCHC ACK reports only one b
itmap for the reception of exactly one window of tiles. The present SCHC
Compound ACK specification extends the SCHC ACK message format so that it can co
ntain several bitmaps, with each bitmap being identified by its corresponding
window number.</t> window number.</t>
<t>The SCHC ACK format, as presented in <xref target="RFC8724"/>, can be conside <t>As presented in <xref target="RFC8724"/>, the SCHC ACK format can be
red a special SCHC Compound ACK case, in which it reports only the tiles of one considered a special SCHC Compound ACK case in which it reports only the tiles o
window. Therefore, the SCHC Compound ACK is backwards compatible with the SCHC A f one window. Therefore, the SCHC Compound ACK is backwards compatible with the
CK format presented in <xref target="RFC8724"/>. SCHC ACK format presented in <xref target="RFC8724"/>.
The receiver can suspect if the sender does not support the SCHC Compound ACK, i The receiver can assume that the sender does not support the SCHC Compound ACK i
f the sender does not resend any tiles from windows that are not the first one i f, although the SCHC Compound ACK sent by the receiver reports losses in more th
n the SCHC Compound ACK and more ACKs are needed. In that case, the receiver can an one window, the sender does not resend any tiles from windows other than the
send SCHC Compound ACKs with only one window of tiles.</t> first window reported in the SCHC Compound ACK. In that case, the receiver can s
<t>Also, some flexibility is introduced with respect to <xref target="RFC8724"/> end SCHC Compound ACKs with only one window of tiles.</t>
, in that the receiver has the capability to respond to the All-0 with <t>Also, some flexibility is introduced with respect to <xref target="RF
a SCHC Compound ACK or not, depending on certain parameters, like network condit C8724"/> in that the receiver has the capability to respond (or not) to the All-
ions, sender buffer/chache size, supported application delay. Note that even tho 0 with a SCHC Compound ACK, depending on certain parameters, like network condit
ugh the protocol allows for such flexibility, the ions, sender buffer/cache size, and supported application delay. Note that even
actual decision criteria is not specified in this document. The application MUST though the protocol allows for such flexibility, the
set expiration timer values according to when the feedback is expected to be re actual decision criteria is not specified in this document. The application <bcp
ceived, e.g., after the All-0 or after the All-1.</t> 14>MUST</bcp14> set expiration timer values according to when the feedback is ex
pected to be received, e.g., after the All-0 or after the All-1.</t>
<t>The following <xref target="ACK-on-Error-subsection"/> (and its subsections) <t><xref target="ACK-on-Error-subsection"/> (and its subsections) replac
replaces the complete sections 8.4.3 (and its subsections) of RFC 8724. es the complete Section <xref target="RFC8724" section="8.4.3" sectionFormat="ba
<!--For the convenience of the reader, the added text to the original RFC 8724 i re"/> (and its subsections) of <xref target="RFC8724"/>.
s highlighted with *** NEW TEXT *** and the deleted text from RFC 8724 is delimi
ted by &#45;&#45; OLD TEXT &#45;&#45;.-->
</t> </t>
<!--<t>The following sections describe the differences between the baseline SCHC <section anchor="ACK-on-Error-subsection">
specification and the present SCHC protocol extension specification.--> <name>ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)</name>
<!--New text is between ** NEW TEXT **. Old text is &#45;&#45; OLD TEXT &#45;&#4 <t>The ACK-on-Error mode supports L2 technologies that have variable M
5;. New text replaces old text.--> TU and out-of-order delivery.
<!--</t>-->
<section anchor="ACK-on-Error-subsection" numbered="true" toc="includ
e" removeInRFC="false" pn="section-8.4.3">
<name slugifiedName="name-ack-on-error-mode">ACK-on-Error Mode</name>
<t pn="section-8.4.3-1">The ACK-on-Error mode supports L2 technologies
that have variable MTU and out-of-order delivery.
It requires an L2 that provides a feedback path from the reassembler to the frag menter. It requires an L2 that provides a feedback path from the reassembler to the frag menter.
See Appendix F for a discussion on using ACK-on-Error mode on quasi-bidirectiona See Appendix <xref target="RFC8724" section="F" sectionFormat="bare"/> for a dis
l links.</t> cussion on using ACK-on-Error mode on quasi-bidirectional links.</t>
<t pn="section-8.4.3-2">In ACK-on-Error mode, windows are used.</t> <t>In ACK-on-Error mode, windows are used.</t>
<t pn="section-8.4.3-3">All tiles except the last one and the penultim <t>All tiles except the last one and the penultimate one <bcp14>MUST</
ate one <bcp14>MUST</bcp14> be of equal size, hereafter called "regular". bcp14> be of equal size, hereafter called "regular".
The size of the last tile <bcp14>MUST</bcp14> be smaller than or equal to the re gular tile size. The size of the last tile <bcp14>MUST</bcp14> be smaller than or equal to the re gular tile size.
Regarding the penultimate tile, a Profile <bcp14>MUST</bcp14> pick one of the fo llowing two options:</t> Regarding the penultimate tile, a Profile <bcp14>MUST</bcp14> pick one of the fo llowing two options:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-4"> <ul spacing="normal">
<li pn="section-8.4.3-4.1">The penultimate tile size <bcp14>MUST</bc <li>The penultimate tile size <bcp14>MUST</bcp14> be the regular til
p14> be the regular tile size, or</li> e size, or</li>
<li pn="section-8.4.3-4.2">the penultimate tile size <bcp14>MUST</bc <li>the penultimate tile size <bcp14>MUST</bcp14> be either the regu
p14> be either the regular tile size or the regular tile size minus one L2 Word. lar tile size or the regular tile size minus one L2 Word.</li>
</li>
</ul> </ul>
<t pn="section-8.4.3-5">A SCHC Fragment message carries one or several contiguous tiles, which may span multiple windows. <t>A SCHC Fragment message carries one or several contiguous tiles, wh ich may span multiple windows.
A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number. A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number.
</t> </t>
<t pn="section-8.4.3-6">See <xref target="Fig-TilesACKonError" format= <t>See <xref target="Fig-TilesACKonError"/> (see <eref target="https:/
"default" sectionFormat="of" derivedContent="Figure 23"/> for an example.</t> /www.rfc-editor.org/rfc/rfc8724.html#figure-23">Figure 23 of RFC 8724</eref>) fo
<figure anchor="Fig-TilesACKonError" align="left" suppress-title="fals r an example.</t>
e" pn="figure-23"> <figure anchor="Fig-TilesACKonError">
<name slugifiedName="name-schc-packet-fragmented-in-til">SCHC Packet <name>SCHC Packet Fragmented in Tiles, ACK-on-Error Mode (Figure 23
Fragmented in Tiles, ACK-on-Error Mode</name> in RFC 8724)</name>
<artwork name="" type="" align="left" alt="" pn="section-8.4.3-7.1"> <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------...-----------+ +---------------------------------------------...-----------+
| 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 |-----------|</artwork> SCHC Fragment msg |-----------|
]]></artwork>
</figure> </figure>
<t pn="section-8.4.3-8">The W field is wide enough that it unambiguous ly represents an absolute window number. <t>The W field is wide enough that it unambiguously represents an abso lute window number.
The fragment receiver sends SCHC Compound ACKs to the fragment sender about wind ows for which tiles are missing. The fragment receiver sends SCHC Compound ACKs to the fragment sender about wind ows for which tiles are missing.
No SCHC Compound ACK is sent by the fragment receiver for windows that it knows have been fully received.</t> No SCHC Compound ACK is sent by the fragment receiver for windows that it knows have been fully received.</t>
<t pn="section-8.4.3-9">The fragment sender retransmits SCHC Fragments for tiles that are reported missing. <t>The fragment sender retransmits SCHC Fragments for tiles that are r eported missing.
It can advance to next windows even before it has ascertained that all tiles bel onging to previous windows have been correctly received, It can advance to next windows even before it has ascertained that all tiles bel onging to previous windows have been correctly received,
and it can still later retransmit SCHC Fragments with tiles belonging to previou s windows. and it can still later retransmit SCHC Fragments with tiles belonging to previou s windows.
Therefore, the sender and the receiver may operate in a decoupled fashion. Therefore, the sender and the receiver may operate in a decoupled fashion.
The fragmented SCHC Packet transmission concludes when:</t> The fragmented SCHC Packet transmission concludes when:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-10"> <ul spacing="normal">
<li pn="section-8.4.3-10.1">integrity checking shows that the fragme <li>integrity checking shows that the fragmented SCHC Packet has bee
nted SCHC Packet has been correctly reassembled at the receive end, n correctly reassembled at the receive end,
and this information has been conveyed back to the sender, or</li> and this information has been conveyed back to the sender,</li>
<li pn="section-8.4.3-10.2">too many retransmission attempts were ma <li>too many retransmission attempts have been made, or</li>
de, or</li> <li>the receiver determines that the transmission of this fragmented
<li pn="section-8.4.3-10.3">the receiver determines that the transmi SCHC Packet has been inactive for too long.</li>
ssion of this fragmented SCHC Packet has been inactive for too long.</li>
</ul> </ul>
<t pn="section-8.4.3-11">Each Profile <bcp14>MUST</bcp14> specify whic <t>Each Profile <bcp14>MUST</bcp14> specify which RuleID value(s) corr
h RuleID value(s) corresponds to SCHC F/R messages operating in this mode.</t> esponds to SCHC F/R messages operating in this mode.</t>
<t pn="section-8.4.3-12">The W field <bcp14>MUST</bcp14> be present in <t>The W field <bcp14>MUST</bcp14> be present in the SCHC F/R messages
the SCHC F/R messages.</t> .</t>
<t pn="section-8.4.3-13">Each Profile, for each RuleID value, <bcp14>M <t>Each Profile, for each RuleID value, <bcp14>MUST</bcp14> define:</t
UST</bcp14> define:</t> >
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-14"> <ul spacing="normal">
<li pn="section-8.4.3-14.1">the tile size (a tile does not need to b <li>the tile size (a tile does not need to be a duplicate of an L2 W
e multiple of an L2 Word, but it <bcp14>MUST</bcp14> be at least the size of an ord, but it <bcp14>MUST</bcp14> be at least the size of an L2 Word),</li>
L2 Word),</li> <li>the value of M,</li>
<li pn="section-8.4.3-14.2">the value of M,</li> <li>the value of N,</li>
<li pn="section-8.4.3-14.3">the value of N,</li> <li>the value of WINDOW_SIZE, which <bcp14>MUST</bcp14> be strictly
<li pn="section-8.4.3-14.4">the value of WINDOW_SIZE, which <bcp14>M less than 2<sup>N</sup>,</li>
UST</bcp14> be strictly less than 2^N,</li> <li>the size and algorithm for the RCS field,</li>
<li pn="section-8.4.3-14.5">the size and algorithm for the RCS field <li>the value of T,</li>
,</li> <li>the value of MAX_ACK_REQUESTS,</li>
<li pn="section-8.4.3-14.6">the value of T,</li> <li>the expiration time of the Retransmission Timer,</li>
<li pn="section-8.4.3-14.7">the value of MAX_ACK_REQUESTS,</li> <li>the expiration time of the Inactivity Timer,</li>
<li pn="section-8.4.3-14.8">the expiration time of the Retransmissio <li>if the last tile is carried in a Regular SCHC Fragment or an All
n Timer,</li> -1 SCHC Fragment (see <xref target="ACK-on-Error-sender"/> (Section <xref target
<li pn="section-8.4.3-14.9">the expiration time of the Inactivity Ti ="RFC8724" sectionFormat="bare" section="8.4.3.1"/> in <xref target="RFC8724"/>)
mer,</li> ,</li>
<li pn="section-8.4.3-14.10">if the last tile is carried in a Regula <li>if the penultimate tile <bcp14>MAY</bcp14> be one L2 Word smalle
r SCHC Fragment or an All-1 SCHC Fragment (see Section 8.4.3.1), and</li> r than the regular tile size (in this case, the regular tile size <bcp14>MUST</b
<li pn="section-8.4.3-14.11">if the penultimate tile <bcp14>MAY</bcp cp14> be at least twice the L2 Word size),</li>
14> be one L2 Word smaller than the regular tile size. In this case, the regular <li>usage or not of the SCHC Compound ACK message, and</li>
tile size <bcp14>MUST</bcp14> be at least twice the L2 Word size.</li> <li>usage or not of the Compressed Bitmap format in the last window
<!-- <li pn="section-8.4.3-14.12">if the SCHC Compound ACK is used. of the SCHC Compound ACK message.</li>
</li>-->
<li pn="section-8.4.3-14.12">Usage or not of the SCHC Compound ACK
message.</li>
<li pn="section-8.4.3-14.13">Usage or not of the compressed bitmap
format in the last window of the SCHC Compound ACK message.</li>
</ul> </ul>
<t pn="section-8.4.3-15">For each active pair of RuleID and DTag value <t>For each active pair of RuleID and DTag values, the sender <bcp14>M
s, the sender <bcp14>MUST</bcp14> maintain:</t> UST</bcp14> maintain:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-16"> <ul spacing="normal">
<li pn="section-8.4.3-16.1">one Attempts counter, and</li> <li>one Attempts counter and</li>
<li pn="section-8.4.3-16.2">one Retransmission Timer.</li> <li>one Retransmission Timer.</li>
</ul> </ul>
<t pn="section-8.4.3-17">For each active pair of RuleID and DTag value <t>For each active pair of RuleID and DTag values, the receiver <bcp14
s, the receiver <bcp14>MUST</bcp14> maintain:</t> >MUST</bcp14> maintain:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-18"> <ul spacing="normal">
<li pn="section-8.4.3-18.1">one Inactivity Timer, and</li> <li>one Attempts counter and</li>
<li pn="section-8.4.3-18.2">one Attempts counter.</li> <li>one Inactivity Timer.</li>
</ul> </ul>
<section anchor="ACK-on-Error-sender" numbered="true" toc="exclude" re <section anchor="ACK-on-Error-sender">
moveInRFC="false" pn="section-8.4.3.1"> <name>Sender Behavior (Replaces Section 8.4.3.1, RFC 8724)</name>
<name slugifiedName="name-sender-behavior-3">Sender Behavior</name> <t>At the beginning of the fragmentation of a new SCHC Packet:</t>
<t pn="section-8.4.3.1-1">At the beginning of the fragmentation of a <ul spacing="normal">
new SCHC Packet:</t> <li>the fragment sender <bcp14>MUST</bcp14> select a RuleID and DT
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- ag value pair for this SCHC Packet.
2"> A Rule <bcp14>MUST NOT</bcp14> be selected if the values of M and WINDOW_SIZE fo
<li pn="section-8.4.3.1-2.1">the fragment sender <bcp14>MUST</bcp1 r that Rule are such that the SCHC Packet cannot be fragmented in (2<sup>M</sup>
4> select a RuleID and DTag value pair for this SCHC Packet. ) * WINDOW_SIZE tiles or less.</li>
A Rule <bcp14>MUST NOT</bcp14> be selected if the values of M and WINDOW_SIZE fo <li>the fragment sender <bcp14>MUST</bcp14> initialize the Attempt
r that Rule are such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW s counter to 0 for that RuleID and DTag value pair.</li>
_SIZE tiles or less.</li>
<li pn="section-8.4.3.1-2.2">the fragment sender <bcp14>MUST</bcp1
4> initialize the Attempts counter to 0 for that RuleID and DTag value pair.</li
>
</ul> </ul>
<t pn="section-8.4.3.1-3">A Regular SCHC Fragment message carries in its payload one or more tiles. <t>A Regular SCHC Fragment message carries in its payload one or mor e tiles.
If more than one tile is carried in one Regular SCHC Fragment:</t> If more than one tile is carried in one Regular SCHC Fragment:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
4"> <li>the selected tiles <bcp14>MUST</bcp14> be contiguous in the or
<li pn="section-8.4.3.1-4.1">the selected tiles <bcp14>MUST</bcp14 iginal SCHC Packet, and</li>
> be contiguous in the original SCHC Packet, and</li> <li>they <bcp14>MUST</bcp14> be placed in the SCHC Fragment Payloa
<li pn="section-8.4.3.1-4.2">they <bcp14>MUST</bcp14> be placed in d adjacent to one another, in the order they appear in the SCHC Packet, from the
the SCHC Fragment Payload adjacent to one another, in the order they appear in start of the SCHC Packet toward its end.</li>
the SCHC Packet, from the start of the SCHC Packet toward its end.</li>
</ul> </ul>
<t pn="section-8.4.3.1-5">Tiles that are not the last one <bcp14>MUS T</bcp14> be sent in Regular SCHC Fragments specified in Section 8.3.1.1. <t>Tiles that are not the last one <bcp14>MUST</bcp14> be sent in Re gular SCHC Fragments as specified in Section <xref target="RFC8724" section="8.3 .1.1" sectionFormat="bare"/>.
The FCN field <bcp14>MUST</bcp14> contain the tile index of the first tile sent in that SCHC Fragment.</t> The FCN field <bcp14>MUST</bcp14> contain the tile index of the first tile sent in that SCHC Fragment.</t>
<t pn="section-8.4.3.1-6">In a Regular SCHC Fragment message, the se <t>In a Regular SCHC Fragment message, the sender <bcp14>MUST</bcp14
nder <bcp14>MUST</bcp14> fill the W field with the window number of the first ti > fill the W field with the window number of the first tile sent in that SCHC Fr
le sent in that SCHC Fragment.</t> agment.</t>
<t pn="section-8.4.3.1-7">A Profile <bcp14>MUST</bcp14> define if th <t>A Profile <bcp14>MUST</bcp14> define if the last tile of a SCHC P
e last tile of a SCHC Packet is sent:</t> acket is sent:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
8"> <li>in a Regular SCHC Fragment, alone or as part of a multi-tiles
<li pn="section-8.4.3.1-8.1">in a Regular SCHC Fragment, alone or Payload,</li>
as part of a multi-tiles Payload,</li> <li>alone in an All-1 SCHC Fragment, or</li>
<li pn="section-8.4.3.1-8.2">alone in an All-1 SCHC Fragment, or</ <li>with either one of the above two methods.</li>
li>
<li pn="section-8.4.3.1-8.3">with any of the above two methods.</l
i>
</ul> </ul>
<t pn="section-8.4.3.1-9">In an All-1 SCHC Fragment message, the sen <t>In an All-1 SCHC Fragment message, the sender <bcp14>MUST</bcp14>
der <bcp14>MUST</bcp14> fill the W field with the window number of the last tile fill the W field with the window number of the last tile of the SCHC Packet.</t
of the SCHC Packet.</t> >
<t pn="section-8.4.3.1-10">The fragment sender <bcp14>MUST</bcp14> s <t>The fragment sender <bcp14>MUST</bcp14> send SCHC Fragments such
end SCHC Fragments such that, all together, they contain all the tiles of the fr that, all together, they contain all the tiles of the fragmented SCHC Packet.</t
agmented SCHC Packet.</t> >
<t pn="section-8.4.3.1-11">The fragment sender <bcp14>MUST</bcp14> s <t>The fragment sender <bcp14>MUST</bcp14> send at least one All-1 S
end at least one All-1 SCHC Fragment.</t> CHC Fragment.</t>
<t pn="section-8.4.3.1-12">In doing the two items above, the sender <t>In doing the two items above, the sender <bcp14>MUST</bcp14> asce
<bcp14>MUST</bcp14> ascertain that the receiver will not receive the last tile t rtain that the receiver will not receive the last tile through both a Regular SC
hrough both a Regular SCHC Fragment and an All-1 SCHC Fragment.</t> HC Fragment and an All-1 SCHC Fragment.</t>
<t pn="section-8.4.3.1-13">The fragment sender <bcp14>MUST</bcp14> l <t>The fragment sender <bcp14>MUST</bcp14> listen for SCHC Compound
isten for SCHC Compound ACK messages after having sent:</t> ACK messages after having sent:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
14"> <li>an All-1 SCHC Fragment or</li>
<li pn="section-8.4.3.1-14.1">an All-1 SCHC Fragment, or</li> <li>a SCHC ACK REQ.</li>
<li pn="section-8.4.3.1-14.2">a SCHC ACK REQ.</li>
</ul> </ul>
<t pn="section-8.4.3.1-15">A Profile <bcp14>MAY</bcp14> specify othe r times at which the fragment sender <bcp14>MUST</bcp14> listen for SCHC Compoun d ACK messages. <t>A Profile <bcp14>MAY</bcp14> specify other times at which the fra gment sender <bcp14>MUST</bcp14> listen for SCHC Compound ACK messages.
For example, this could be after sending a complete window of tiles.</t> For example, this could be after sending a complete window of tiles.</t>
<t pn="section-8.4.3.1-16">Each time a fragment sender sends an All- <t>Each time a fragment sender sends an All-1 SCHC Fragment or a SCH
1 SCHC Fragment or a SCHC ACK REQ:</t> C ACK REQ:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
17"> <li>it <bcp14>MUST</bcp14> increment the Attempts counter, and</li
<li pn="section-8.4.3.1-17.1">it <bcp14>MUST</bcp14> increment the >
Attempts counter, and</li> <li>it <bcp14>MUST</bcp14> reset the Retransmission Timer.</li>
<li pn="section-8.4.3.1-17.2">it <bcp14>MUST</bcp14> reset the Ret
ransmission Timer.</li>
</ul> </ul>
<t pn="section-8.4.3.1-18">On Retransmission Timer expiration:</t> <t>On Retransmission Timer expiration:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
19"> <li>if the Attempts counter is strictly less than MAX_ACK_REQUESTS
<li pn="section-8.4.3.1-19.1">if the Attempts counter is strictly ,
less than MAX_ACK_REQUESTS,
the fragment sender <bcp14>MUST</bcp14> send the fragment sender <bcp14>MUST</bcp14> send
either the All-1 SCHC Fragment or either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window,</li> a SCHC ACK REQ with the W field corresponding to the last window,</li>
<li pn="section-8.4.3.1-19.2">otherwise, the fragment sender <bcp1 4>MUST</bcp14> send a SCHC Sender-Abort, and <li>otherwise, the fragment sender <bcp14>MUST</bcp14> send a SCHC Sender-Abort, and
it <bcp14>MAY</bcp14> exit with an error condition.</li> it <bcp14>MAY</bcp14> exit with an error condition.</li>
</ul> </ul>
<t pn="section-8.4.3.1-20">All message receptions being discussed in the rest of this section are to be understood as <t>All message receptions being discussed in the rest of this sectio n are to be understood as
"matching the RuleID and DTag pair being processed", even if not spelled out, fo r brevity.</t> "matching the RuleID and DTag pair being processed", even if not spelled out, fo r brevity.</t>
<t pn="section-8.4.3.1-21">On receiving a SCHC Compound ACK:</t> <t>On receiving a SCHC Compound ACK:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1- <ul spacing="normal">
22"> <li>
<li pn="section-8.4.3.1-22.1"> <t>if one of the W fields in the SCHC Compound ACK corresponds t
<t pn="section-8.4.3.1-22.1.1">if one of the W field in the SCHC o the last window of the SCHC Packet:</t>
Compound ACK corresponds to the last window of the SCHC Packet:</t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn="section-8.4. <li>if the C bit is set, the sender <bcp14>MAY</bcp14> exit su
3.1-22.1.2"> ccessfully.</li>
<li pn="section-8.4.3.1-22.1.2.1">if the C bit is set, the sen <li>
der <bcp14>MAY</bcp14> exit successfully.</li> <t>otherwise: </t>
<li pn="section-8.4.3.1-22.1.2.2"> <ul spacing="normal">
<t pn="section-8.4.3.1-22.1.2.2.1">otherwise: </t> <li>
<ul spacing="normal" bare="false" empty="false" pn="section- <t>if the Profile mandates that the last tile be sent in
8.4.3.1-22.1.2.2.2"> an All-1 SCHC Fragment:</t>
<li pn="section-8.4.3.1-22.1.2.2.2.1"> <ul spacing="normal">
<t pn="section-8.4.3.1-22.1.2.2.2.1.1">if the Profile ma <li>
ndates that the last tile be sent in an All-1 SCHC Fragment:</t> <t>if the SCHC Compound ACK shows no missing tile at
<ul spacing="normal" bare="false" empty="false" pn="sect the receiver, the sender:</t>
ion-8.4.3.1-22.1.2.2.2.1.2"> <ul spacing="normal">
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.1"> <li>
<t pn="section-8.4.3.1-22.1.2.2.2.1.2.1.1">if the SC <bcp14>MUST</bcp14> send a SCHC Sender-Abort and
HC Compound ACK shows no missing tile at the receiver, the sender:</t> </li>
<ul spacing="normal" bare="false" empty="false" pn=" <li>
section-8.4.3.1-22.1.2.2.2.1.2.1.2">
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.1.2.1">
<bcp14>MUST</bcp14> send a SCHC Sender-Abort, an
d</li>
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.1.2.2">
<bcp14>MAY</bcp14> exit with an error condition. </li> <bcp14>MAY</bcp14> exit with an error condition. </li>
</ul> </ul>
</li> </li>
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.2"> <li>
<t pn="section-8.4.3.1-22.1.2.2.2.1.2.2.1">otherwise <t>otherwise:</t>
:</t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn=" <li>the fragment sender <bcp14>MUST</bcp14> send S
section-8.4.3.1-22.1.2.2.2.1.2.2.2"> CHC Fragment messages containing all the tiles of all the windows that are repor
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.1">the ted missing in the SCHC Compound ACK.</li>
fragment sender <bcp14>MUST</bcp14> send SCHC Fragment messages containing all t <li>if the last of these SCHC Fragment messages is
he tiles of all the windows that are reported missing in the SCHC Compound ACK.< not an All-1 SCHC Fragment, then the fragment sender <bcp14>MAY</bcp14> either
/li> send, in addition, a SCHC ACK REQ with the W field corresponding to the last win
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.2">if t dow or repeat the All-1 SCHC Fragment to ask the receiver to confirm that all ti
he last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the les have been correctly received.
fragment sender MAY either send in addition a SCHC ACK REQ with the W field corr
esponding to the last window, or repeat the All-1 SCHC Fragment to ask the recei
ver confirmation that all tiles have been correctly received.
</li> </li>
<li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.3">in d oing the two items above, the sender <bcp14>MUST</bcp14> ascertain that the rece iver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.</li> <li>in doing the two items above, the sender <bcp1 4>MUST</bcp14> ascertain that the receiver will not receive the last tile throug h both a Regular SCHC Fragment and an All-1 SCHC Fragment.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li pn="section-8.4.3.1-22.1.2.2.2.2"> <li>
<t pn="section-8.4.3.1-22.1.2.2.2.2.1">otherwise:</t> <t>otherwise:</t>
<ul spacing="normal" bare="false" empty="false" pn="sect <ul spacing="normal">
ion-8.4.3.1-22.1.2.2.2.2.2"> <li>if the SCHC Compound ACK shows no missing tile at
<li pn="section-8.4.3.1-22.1.2.2.2.2.2.1">if the SCHC the receiver, the sender
Compound ACK shows no missing tile at the receiver, the sender
<bcp14>MUST</bcp14> send the All-1 SCHC Fragment</li> <bcp14>MUST</bcp14> send the All-1 SCHC Fragment</li>
<li pn="section-8.4.3.1-22.1.2.2.2.2.2.2"> <li>
<t pn="section-8.4.3.1-22.1.2.2.2.2.2.2.1">otherwise <t>otherwise:</t>
:</t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn=" <li>the fragment sender <bcp14>MUST</bcp14> send S
section-8.4.3.1-22.1.2.2.2.2.2.2.2"> CHC Fragment messages containing all the tiles that are reported missing in the
<li pn="section-8.4.3.1-22.1.2.2.2.2.2.2.2.1">the SCHC Compound ACK.</li>
fragment sender <bcp14>MUST</bcp14> send SCHC Fragment messages containing all t <li>the fragment sender <bcp14>MUST</bcp14> then s
he tiles that are reported missing in the SCHC Compound ACK.</li> end
<li pn="section-8.4.3.1-22.1.2.2.2.2.2.2.2.2">the
fragment sender <bcp14>MUST</bcp14> then send
either the All-1 SCHC Fragment or either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window.</li> a SCHC ACK REQ with the W field corresponding to the last window.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li pn="section-8.4.3.1-22.2"> <li>
<t pn="section-8.4.3.1-22.2.1">otherwise, the fragment sender:</ <t>otherwise, the fragment sender:</t>
t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn="section-8.4. <li>
3.1-22.2.2">
<li pn="section-8.4.3.1-22.2.2.1">
<bcp14>MUST</bcp14> send SCHC Fragment messages containing t he tiles that are reported missing in the SCHC Compound ACK.</li> <bcp14>MUST</bcp14> send SCHC Fragment messages containing t he tiles that are reported missing in the SCHC Compound ACK.</li>
<li pn="section-8.4.3.1-22.2.2.2">then, it <bcp14>MAY</bcp14> send a SCHC ACK REQ with the W field corresponding to the last window.</li> <li>then, it <bcp14>MAY</bcp14> send a SCHC ACK REQ with the W field corresponding to the last window.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t pn="section-8.4.3.1-23">See Figure 43/> for one among several pos sible examples of a Finite State Machine implementing a sender behavior obeying this specification.</t> <t>See <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#fig ure-43">Figure 43</eref> for one among several possible examples of a Finite Sta te Machine implementing a sender behavior obeying this specification.</t>
</section> </section>
<section anchor="ACK-on-Error-receiver" numbered="true" toc="exclude" <section anchor="ACK-on-Error-receiver">
removeInRFC="false" pn="section-8.4.3.2"> <name>Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724)</name>
<name slugifiedName="name-receiver-behavior-3">Receiver Behavior</na <t>On receiving a SCHC Fragment with a RuleID and DTag pair not bein
me> g processed at that time:</t>
<t pn="section-8.4.3.2-1">On receiving a SCHC Fragment with a RuleID <ul spacing="normal">
and DTag pair not being processed at that time:</t> <li>the receiver <bcp14>SHOULD</bcp14> check that the DTag value h
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2- as not recently been used for that RuleID value,
2">
<li pn="section-8.4.3.2-2.1">the receiver <bcp14>SHOULD</bcp14> ch
eck if the DTag value has not recently been used for that RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission. thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the <bcp14>RECOMMENDED</bcp14> life time for the DTag value at the receiver. The initial value of the Inactivity Timer is the <bcp14>RECOMMENDED</bcp14> life time for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver <bcp14>MAY </bcp14> silently ignore it and discard it.</li> If the SCHC Fragment is determined to be such a remnant, the receiver <bcp14>MAY </bcp14> silently ignore it and discard it.</li>
<li pn="section-8.4.3.2-2.2">the receiver <bcp14>MUST</bcp14> star t a process to assemble a new SCHC Packet with that RuleID and DTag value pair. <li>the receiver <bcp14>MUST</bcp14> start a process to assemble a new SCHC Packet with that RuleID and DTag value pair.
The receiver <bcp14>MUST</bcp14> start an Inactivity Timer for that RuleID and D Tag value pair. The receiver <bcp14>MUST</bcp14> start an Inactivity Timer for that RuleID and D Tag value pair.
It <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and D Tag value pair. It <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and D Tag value pair.
If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> respond to the sender with a SCHC Receiver-Abort.</li> If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> respond to the sender with a SCHC Receiver-Abort.</li>
</ul> </ul>
<t pn="section-8.4.3.2-3">On reception of any SCHC F/R message for t <t>On reception of any SCHC F/R message for the RuleID and DTag pair
he RuleID and DTag pair being processed, the receiver <bcp14>MUST</bcp14> reset being processed, the receiver <bcp14>MUST</bcp14> reset the Inactivity Timer pe
the Inactivity Timer pertaining to that RuleID and DTag pair.</t> rtaining to that RuleID and DTag pair.</t>
<t pn="section-8.4.3.2-4">All message receptions being discussed in <t>All message receptions being discussed in the rest of this sectio
the rest of this section are to be understood as n are to be understood as
"matching the RuleID and DTag pair being processed", even if not spelled out, fo r brevity.</t> "matching the RuleID and DTag pair being processed", even if not spelled out, fo r brevity.</t>
<t pn="section-8.4.3.2-5">On receiving a SCHC Fragment message, <t>On receiving a SCHC Fragment message,
the receiver determines what tiles were received, based on the payload length an d on the W and FCN fields of the SCHC Fragment.</t> the receiver determines what tiles were received, based on the payload length an d on the W and FCN fields of the SCHC Fragment.</t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2- <ul spacing="normal">
6"> <li>if the FCN is All-1 and if a Payload is present, the full SCHC
<li pn="section-8.4.3.2-6.1">if the FCN is All-1, if a Payload is Fragment Payload <bcp14>MUST</bcp14> be assembled including the padding bits.
present, the full SCHC Fragment Payload <bcp14>MUST</bcp14> be assembled includi
ng the padding bits.
This is because the size of the last tile is not known by the receiver; This is because the size of the last tile is not known by the receiver;
therefore, padding bits are indistinguishable from the tile data bits, at this s tage. therefore, padding bits are indistinguishable from the tile data bits, at this s tage.
They will be removed by the SCHC C/D sublayer. They will be removed by the SCHC C/D sublayer.
If the size of the SCHC Fragment Payload exceeds or equals If the size of the SCHC Fragment Payload exceeds or equals
the size of one regular tile plus the size of an L2 Word, this <bcp14>SHOULD</bc p14> raise an error flag.</li> the size of one regular tile plus the size of an L2 Word, this <bcp14>SHOULD</bc p14> raise an error flag.</li>
<li pn="section-8.4.3.2-6.2"> <li>
<t pn="section-8.4.3.2-6.2.1">otherwise, tiles <bcp14>MUST</bcp1 <t>otherwise, tiles <bcp14>MUST</bcp14> be assembled based on th
4> be assembled based on the a priori known tile size. e a priori known tile size.
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4. <ul spacing="normal">
3.2-6.2.2"> <li>If allowed by the Profile, the end of the payload <bcp14>M
<li pn="section-8.4.3.2-6.2.2.1">If allowed by the Profile, th AY</bcp14> contain the last tile, which may be shorter. Padding bits are indisti
e end of the payload <bcp14>MAY</bcp14> contain the last tile, which may be shor nguishable from the tile data bits, at this stage.</li>
ter. Padding bits are indistinguishable from the tile data bits, at this stage.< <li>The payload may contain the penultimate tile that, if allo
/li> wed by the Profile, <bcp14>MAY</bcp14> be exactly one L2 Word shorter than the r
<li pn="section-8.4.3.2-6.2.2.2">The payload may contain the p egular tile size.</li>
enultimate tile that, if allowed by the Profile, <bcp14>MAY</bcp14> be exactly o <li>
ne L2 Word shorter than the regular tile size.</li> <t>Otherwise, padding bits <bcp14>MUST</bcp14> be discarded.
<li pn="section-8.4.3.2-6.2.2.3">
<t pn="section-8.4.3.2-6.2.2.3.1">Otherwise, padding bits <b
cp14>MUST</bcp14> be discarded.
This is possible because:</t> This is possible because:</t>
<ul spacing="normal" bare="false" empty="false" pn="section- <ul spacing="normal">
8.4.3.2-6.2.2.3.2"> <li>the size of the tiles is known a priori,</li>
<li pn="section-8.4.3.2-6.2.2.3.2.1">the size of the tiles <li>tiles are larger than an L2 Word, and</li>
is known a priori,</li> <li>padding bits are always strictly less than an L2 Word.
<li pn="section-8.4.3.2-6.2.2.3.2.2">tiles are larger than </li>
an L2 Word, and</li>
<li pn="section-8.4.3.2-6.2.2.3.2.3">padding bits are alwa
ys strictly less than an L2 Word.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t pn="section-8.4.3.2-7">On receiving a SCHC All-0 SCHC Fragment:</ <t>On receiving a SCHC All-0 SCHC Fragment:</t>
t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3. <li>if the receiver knows of any windows with missing tiles for th
2-8"> e packet being reassembled (and depending on certain parameters, like network co
<li pn="section-8.4.3.2-8.1">if the receiver knows of any wind nditions, sender buffer/cache size, and supported application delay, among other
ows with missing tiles for the packet being reassembled (and depending on certai s), it <bcp14>MAY</bcp14> return a SCHC Compound ACK for the missing tiles, star
n parameters, like network conditions, sender buffer/chache size, supported appl ting from the lowest-numbered window.
ication delay, among others), it MAY return a SCHC Compound ACK for the missing
tiles, starting from the lowest-numbered window.
</li> </li>
</ul> </ul>
<t pn="section-8.4.3.2-9">On receiving a SCHC ACK REQ or an All-1 SC <t>On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>
HC Fragment:</t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2- <li>if the receiver knows of any windows with missing tiles for th
10"> e packet being reassembled, it
<li pn="section-8.4.3.2-10.1">if the receiver knows of any windows
with missing tiles for the packet being reassembled, it
<bcp14>MUST</bcp14> return a SCHC Compound ACK for the missing tiles, starting f rom the lowest-numbered window.</li> <bcp14>MUST</bcp14> return a SCHC Compound ACK for the missing tiles, starting f rom the lowest-numbered window.</li>
<li pn="section-8.4.3.2-10.2"> <li>
<t pn="section-8.4.3.2-10.2.1">otherwise: <t>otherwise:
</t> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-8.4. <ul spacing="normal">
3.2-10.2.2"> <li>if it has received at least one tile, it <bcp14>MUST</bcp1
<li pn="section-8.4.3.2-10.2.2.1">if it has received at least 4> return a SCHC Compound ACK for the highest-numbered window it currently has t
one tile, it <bcp14>MUST</bcp14> return a SCHC Compound ACK for the highest-numb iles for,</li>
ered window it currently has tiles for,</li> <li>otherwise, it <bcp14>MUST</bcp14> return a SCHC Compound A
<li pn="section-8.4.3.2-10.2.2.2">otherwise, it <bcp14>MUST</b CK for window number 0.</li>
cp14> return a SCHC Compound ACK for window numbered 0.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t pn="section-8.4.3.2-11">A Profile <bcp14>MAY</bcp14> specify othe <t>A Profile <bcp14>MAY</bcp14> specify other times and circumstance
r times and circumstances at which s at which
a receiver sends a SCHC Compound ACK, a receiver sends a SCHC Compound ACK
and which window the SCHC Compound ACK reports about in these circumstances.</t> and which window the SCHC Compound ACK reports about in these circumstances.</t>
<t pn="section-8.4.3.2-12">Upon sending a SCHC Compound ACK, the rec <t>Upon sending a SCHC Compound ACK, the receiver <bcp14>MUST</bcp14
eiver <bcp14>MUST</bcp14> increase the Attempts counter.</t> > increase the Attempts counter.</t>
<t pn="section-8.4.3.2-13">After receiving an All-1 SCHC Fragment, <t>After receiving an All-1 SCHC Fragment,
a receiver <bcp14>MUST</bcp14> check the integrity of the reassembled SCHC Packe t at least every time a receiver <bcp14>MUST</bcp14> check the integrity of the reassembled SCHC Packe t at least every time
it prepares for sending a SCHC Compound ACK for the last window.</t> it prepares to send a SCHC Compound ACK for the last window.</t>
<t pn="section-8.4.3.2-14">Upon receiving a SCHC Sender-Abort, <t>Upon receiving a SCHC Sender-Abort,
the receiver <bcp14>MAY</bcp14> exit with an error condition.</t> the receiver <bcp14>MAY</bcp14> exit with an error condition.</t>
<t pn="section-8.4.3.2-15">Upon expiration of the Inactivity Timer, <t>Upon expiration of the Inactivity Timer,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort, the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t> and it <bcp14>MAY</bcp14> exit with an error condition.</t>
<t pn="section-8.4.3.2-16">On the Attempts counter exceeding MAX_ACK _REQUESTS, <t>On the Attempts counter exceeding MAX_ACK_REQUESTS,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort, the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t> and it <bcp14>MAY</bcp14> exit with an error condition.</t>
<t pn="section-8.4.3.2-17">Reassembly of the SCHC Packet concludes w <t>Reassembly of the SCHC Packet concludes when:</t>
hen:</t> <ul spacing="normal">
<ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2- <li>a Sender-Abort has been received,</li>
18"> <li>the Inactivity Timer has expired,</li>
<li pn="section-8.4.3.2-18.1">a Sender-Abort has been received, or <li>the Attempts counter has exceeded MAX_ACK_REQUESTS, or</li>
</li> <li>at least an All-1 SCHC Fragment has been received and integrit
<li pn="section-8.4.3.2-18.2">the Inactivity Timer has expired, or y checking of the reassembled SCHC Packet is successful.</li>
</li>
<li pn="section-8.4.3.2-18.3">the Attempts counter has exceeded MA
X_ACK_REQUESTS, or</li>
<li pn="section-8.4.3.2-18.4">at least an All-1 SCHC Fragment has
been received and integrity checking of the reassembled SCHC Packet is successfu
l.</li>
</ul> </ul>
<t pn="section-8.4.3.2-19">See Figure 44 for one among several possi ble examples of a Finite State Machine implementing a receiver behavior obeying this specification. The example provided is meant to match the sender Finite Sta te Machine of Figure 43.</t> <t>See <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#fig ure-44">Figure 44</eref> for one among several possible examples of a Finite Sta te Machine implementing a receiver behavior obeying this specification. The exam ple provided is meant to match the sender Finite State Machine of <eref target=" https://www.rfc-editor.org/rfc/rfc8724.html#figure-43">Figure 43</eref>.</t>
</section> </section>
</section> </section>
</section> </section>
<!--<section anchor="sender-behaviour" title="Sender Behaviour">-->
<!--<t>OLD TEXT (<xref target="RFC8724"/>, section 8.4.3.1) - On receiving a SCH
C ACK:</t>-->
<!--<t><list style="symbols">-->
<!--<t>(...)</t>-->
<!--<t>the fragment sender MUST send SCHC Fragment messages containing all the t
iles that are reported missing in the SCHC ACK.</t>-->
<!--<t>if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment
, then the fragment sender MUST in addition send-->
<!--after it a SCHC ACK REQ with the W field corresponding to the last window.</
t>-->
<!--</list></t>-->
<!--<t>NEW TEXT - On receiving a SCHC Compound ACK:</t>-->
<!--<t><list style="symbols">-->
<!--<t>(...)</t>-->
<!--<t>the fragment sender MUST send SCHC Fragment messages containing all the t
iles of all the windows that are reported missing in the-->
<!--SCHC Compound ACK.</t>-->
<!--<t>if the last of these SCHC Fragment messages reported missing is not an Al
l-1 SCHC Fragment, then the fragment sender MAY either,-->
<!--send in addition a SCHC ACK REQ with the W field corresponding to the last w
indow, 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.</t>-->
<!--</list></t>-->
<!--</section>-->
<!--<section anchor="receiver-behaviour" title="Receiver Behaviour">-->
<!--<t>OLD TEXT (<xref target="RFC8724"/>, section 8.4.3.2) - On receiving a SCH
C ACK REQ or an All-1 SCHC Fragment:</t>-->
<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet be
ing reassembled, it MUST return a SCHC ACK for the-->
<!--lowest-numbered such window.</t>-->
<!--</list></t>-->
<!--<t>NEW TEXT: On receiving an All-0 SCHC Fragment:</t>-->
<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet be
ing reassembled (and if network conditions are known to be conducive),-->
<!--it MAY return a SCHC Compound ACK for the missing tiles, starting from the l
owest-numbered window.</t>-->
<!--</list></t>-->
<!--<t>NEW TEXT: On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>-->
<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet be
ing reassembled, it MUST return a SCHC Compound ACK for the missing tiles, start
ing from the lowest-numbered window.</t>-->
<!--</list></t>-->
<!--</section>-->
</section> </section>
<section anchor="schc-compound-ack-examples">
<section anchor="schc-compound-ack-examples" title="SCHC Compound ACK Example"> <name>SCHC Compound ACK Example</name>
<t><xref target="compound-ack-ex-ex"/> shows an example transmission of a
<t><xref target="compound-ack-ex-ex"/> shows an example transmission of a SCHC P SCHC Packet in ACK-on-Error mode using the SCHC Compound ACK.
acket in ACK-on-Error mode using the SCHC Compound ACK. In the example, the SCHC Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE
In the example, the SCHC Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE =7, M=2, and two lost SCHC fragments.
=7, M=2 and two lost SCHC fragments. Only 1 SCHC Compound ACK is generated.</t>
Only 1 compound SCHC ACK is generated.</t> <figure anchor="compound-ack-ex-ex">
<name>SCHC Compound ACK Message Sequence Example</name>
<t><figure title="SCHC Compound ACK message sequence example" anchor="compound-a <artwork name="" type="" align="left" alt=""><![CDATA[
ck-ex-ex"><artwork><![CDATA[
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)
|-----W=1, FCN=6 ----->| |-----W=1, FCN=6 ----->|
skipping to change at line 678 skipping to change at line 589
|-----W=1, FCN=4 ----->| |-----W=1, FCN=4 ----->|
|-----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)
]]></artwork></figure></t> ]]></artwork>
</figure>
<t><figure title="SCHC Compound ACK message format example: Losses are found in <figure anchor="compound-ack-fmt-ex">
windows 00 and 01" anchor="compound-ack-fmt-ex"><artwork><![CDATA[ <name>SCHC Compound ACK Message Format Example: Losses are Found in Wind
ows 00 and 01</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- 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 ->|
]]></artwork>
]]></artwork></figure></t> </figure>
</section>
</section> <section anchor="schc-compound-ack-yang-model">
<name>SCHC Compound ACK YANG Data Model</name>
<section anchor="schc-compound-ack-yang-model" title="SCHC Compound ACK YANG Dat <t>This document also extends the SCHC YANG data model defined in <xref ta
a Model"> rget="RFC9363"/> by including
<t>The present document also extends the SCHC YANG data model defined in <xref t
arget="RFC9363"/> by including
a new leaf in the Ack-on-Error fragmentation mode to describe both the option to use the SCHC Compound ACK, as well as its bitmap format. </t> a new leaf in the Ack-on-Error fragmentation mode to describe both the option to use the SCHC Compound ACK, as well as its bitmap format. </t>
<section anchor="yang-model">
<section anchor="yang-model" title="SCHC YANG Data Model Extension"> <name>SCHC YANG Data Model Extension</name>
<figure anchor="schc-data-model">
<t><figure title="SCHC YANG Data Model - Compound ACK extension" anchor="schc-da <name>SCHC YANG Data Model - Compound ACK Extension</name>
ta-model"><artwork><![CDATA[ <sourcecode markers="true" name="ietf-schc-compound-ack@2023-07-22.yan
g" type="yang"><![CDATA[
<CODE BEGINS> file "ietf-lpwan-schc-compound-ack@2023-03-16.yang" module ietf-schc-compound-ack {
module ietf-lpwan-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 line 738 skipping to change at line 645
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.";
} }
} }
]]></sourcecode>
<CODE ENDS> </figure>
</section>
]]></artwork></figure></t> <section anchor="yang-tree">
<name>SCHC YANG Tree Extension</name>
</section> <figure anchor="schc-data-tree">
<name>Tree Diagram - Compound ACK Extension</name>
<section anchor="yang-tree" title="SCHC YANG Tree Extension"> <sourcecode type="yangtree"><![CDATA[
module: ietf-schc-compound-ack
<t><figure title="Tree Diagram - Compound ACK extension" anchor="schc-data-tree" augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
><artwork><![CDATA[ schc:mode/schc:ack-on-error:
+--rw bitmap-format? schc-compound-ack:bitmap-format-type
module: ietf-lpwan-schc-compound-ack +--rw last-bitmap-compression? boolean
augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/ ]]></sourcecode>
schc:mode/schc:ack-on-error: </figure>
+--rw bitmap-format? schc-compound-ack:bitmap-format-type </section>
+--rw last-bitmap-compression? boolean </section>
<section anchor="schc-compound-ack-parameters">
]]></artwork></figure></t> <name>SCHC Compound ACK Parameters</name>
<t>This section lists the parameters related to the SCHC Compound ACK usag
</section> e that need to be defined in the Profile.
This list <bcp14>MUST</bcp14> be appended to the list of SCHC parameters und
</section> er "Decision to use SCHC fragmentation mechanism or not. If yes, the document mu
st describe:" as defined in Appendix <xref target="RFC8724" sectionFormat="bare"
<!--</section>--> section="D"/> of <xref target="RFC8724"/>.
<section anchor="schc-compound-ack-parameters" title="SCHC Compound ACK Paramete
rs">
<t>This section lists the parameters related to the SCHC Compound ACK usage that
need to be defined in the Profile.
This list MUST be appended to the list of SCHC parameters under "Decision to
use SCHC fragmentation mechanism or not. If yes, the document must describe:" i
n Annex D of <xref target="RFC8724"/>.
</t> </t>
<ul spacing="normal">
<t><list style="symbols"> <li>whether the SCHC Compound ACK message is used or not, and</li>
<t>Usage or not of the SCHC Compound ACK message.</t> <li>whether the compressed bitmap format in the last window of the SCHC
<t>Usage or not of the compressed bitmap format in the last window of the SCHC C Compound ACK message is used or not.</li>
ompound ACK message.</t> </ul>
</list></t> </section>
<section anchor="security-considerations">
</section> <name>Security Considerations</name>
<t>This document specifies a message format extension for SCHC.
<section anchor="security-considerations" title="Security considerations"> Hence, the same security considerations defined in <xref target="RFC8724"/>
and <xref target="RFC9363"/> apply.</t>
<t>The current document specifies a message format extension for SCHC. <t>The YANG module specified in this document defines a schema for data th
Hence, the same Security Considerations defined in <xref target="RFC8724"/> at is designed to be accessed via network management protocols such as NETCONF <
and in <xref target="RFC9363"/> apply.</t> xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The lowest NETCONF
<t>There are a number of data nodes defined in this YANG module that are layer is the secure transport layer, and the mandatory-to-implement secure tran
sport is Secure Shell (SSH) <xref target="RFC6242"/>. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="R
FC8446"/>.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC
8341"/> provides the means to restrict access for particular NETCONF or RESTCONF
users to a preconfigured subset of all available NETCONF or RESTCONF protocol o
perations and content.</t>
<t>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:</t>
<dl newline="true" spacing="normal">
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-err <dt>/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-
or: error:</dt>
All the data nodes may be modified. The Rule contains sensitive information, <dd>All the data nodes may be modified. The Rule contains sensitive informatio
such n, such
as the SCHC F/R mode configuration and usage and configuration of the SCHC C as the SCHC F/R mode configuration and usage and SCHC Compound ACK configura
ompound ACK. tion.
An attacker may try to modify other devices' Rules by changing the F/R mode or the An attacker may try to modify other devices' Rules by changing the F/R mode or the
usage of the SCHC Compound ACK and may block communication or create extra A CKs. usage of the SCHC Compound ACK and may block communication or create extra A CKs.
Therefore, a device must be allowed to modify only Therefore, a device must be allowed to modify only
its own rules on the remote SCHC instance. The identity of the its own Rules on the remote SCHC instance. The identity of the
requester must be validated. This can be done through requester must be validated. This can be done through
certificates or access lists. certificates or access lists.</dd>
</dl>
Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-err <dt>/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-
or: error:</dt>
By reading this module, an attacker may learn the F/R mode used by the devic <dd>By reading this module, an attacker may learn the F/R mode used by the dev
e ice,
and how the device manage the bitmap creation and also learn the buffer size how the device manages the bitmap creation, the buffer sizes, and when the d
s and when the device will request an ACK. evice will request an ACK.</dd>
</dl>
</t> </section>
<section anchor="ianaconsiderations">
</section> <name>IANA Considerations</name>
<section anchor="ianaconsiderations" title="IANA Considerations"> <t> This document registers one URI and one YANG data model.</t>
<t> This document registers one URI and one YANG data model.</t> <section anchor="uri_registration">
<section anchor="uri_registration" title="URI Registration"> <name>URI Registration</name>
<t> <t>
IANA registered the following URI in the "IETF XML Registry" IANA registered the following URI in the "IETF XML Registry"
<xref target="RFC3688"/>: <xref target="RFC3688"/>:
</t> </t>
<dl newline="false">
<t><list> <dt>URI:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack<
<t>URI: urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack</t> /dd>
<t>Registrant Contact: The IESG.</t> <dt>Registrant Contact:</dt> <dd>The IESG.</dd>
<t>XML: N/A; the requested URI is an XML namespace.</t> <dt>XML:</dt> <dd>N/A; the requested URI is an XML namespace.</dd>
</list></t> </dl>
</section>
</section> <section anchor="module_name_registration">
<section anchor="module_name_registration" title="YANG Module Name Registrat <name>YANG Module Name Registration</name>
ion">
<t> IANA has registered the following YANG data model in the "YANG Modul e <t> IANA has registered the following YANG data model in the "YANG Modul e
Names" registry <xref target="RFC6020"/>.</t> Names" registry <xref target="RFC6020"/>.</t>
<t><list> <dl newline="false">
<t> name: ietf-lpwan-schc-compound-ack</t> <dt>name:</dt> <dd>ietf-schc-compound-ack</dd>
<t>namespace: urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack</t> <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-schc-compound
<t>prefix: schc-compound-ack</t> -ack</dd>
<t>reference: RFC </t> <dt>prefix:</dt> <dd>schc-compound-ack</dd>
</list></t> <dt>reference:</dt> <dd>RFC 9441</dd>
</dl>
</section>
</section> </section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>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/50
1100011033), and by Secretaria
d'Universitats i Recerca del Departament d'Empresa i Coneixement de
la Generalitat de Catalunya 2017 through grant SGR 376.</t>
<t>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).</t>
<t>Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Re
gular 1201893 and Basal Project FB0008.</t>
<t>Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201
893.</t>
<t>The authors would like to thank Rafael Vidal, Julien Boite, Renaud Marty, Ant
onis Platis, Dominique Barthel and Pascal Thubert for their
very useful comments, reviews and implementation design considerations.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<references title='Normative References'> <name>References</name>
<references>
<?rfc include='reference.RFC.2119'?> <name>Normative References</name>
<?rfc include='reference.RFC.8174'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<?rfc include='reference.RFC.8724'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.9363'?> 174.xml"/>
<?rfc include='reference.RFC.3688'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.6020'?> 724.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
363.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
41.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
376.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<references title='Informative References'> <name>Acknowledgements</name>
<?rfc include='reference.RFC.8376'?> <t><contact fullname="Carles Gomez"/> has been funded in part by the Spani
</references> sh 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 003
30.</t>
<t><contact fullname="Sergio Aguilar"/> has been funded by the ERDF and th
e Spanish Government through project TEC2016-79988-P and project PID2019-106808R
A-I00,
AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).</t>
<t><contact fullname="Sandra Cespedes"/> has been funded in part by the AN
ID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
<t><contact fullname="Diego Wistuba"/> has been funded by the ANID Chile P
roject FONDECYT Regular 1201893.</t>
<t>The authors would like to thank <contact fullname="Rafael Vidal"/>, <co
ntact fullname="Julien Boite"/>, <contact fullname="Renaud Marty"/>, <contact fu
llname="Antonis Platis"/>, <contact fullname="Dominique Barthel"/>, and <contact
fullname="Pascal Thubert"/> for their
very useful comments, reviews, and implementation design considerations.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 127 change blocks. 
861 lines changed or deleted 713 lines changed or added

This html diff was produced by rfcdiff 1.48.