SCHC Compound ACK
draft-ietf-lpwan-schc-compound-ack-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9441.
|
|
|---|---|---|---|
| Authors | Juan-Carlos Zúñiga , Carles Gomez , Sergio Aguilar , Laurent Toutain , Sandra Cespedes , Diego S. Wistuba La Torre | ||
| Last updated | 2023-02-13 (Latest revision 2023-01-19) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
TSVART Last Call review
(of
-14)
by Wesley Eddy
Ready w/nits
YANGDOCTORS Early review
(of
-14)
by Ebben Aries
On the Right Track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Alexander Pelov | ||
| Shepherd write-up | Show Last changed 2023-01-26 | ||
| IESG | IESG state | Became RFC 9441 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Éric Vyncke | ||
| Send notices to | pthubert@cisco.com, a@ackl.io |
draft-ietf-lpwan-schc-compound-ack-10
lpwan Working Group JC. Zuniga
Internet-Draft Cisco
Updates: 8724 (if approved) C. Gomez
Intended status: Standards Track S. Aguilar
Expires: 23 July 2023 Universitat Politecnica de Catalunya
L. Toutain
IMT-Atlantique
S. Cespedes
Concordia University
D. Wistuba
NIC Labs, Universidad de Chile
19 January 2023
SCHC Compound ACK
draft-ietf-lpwan-schc-compound-ack-10
Abstract
The present document describes an extension to the SCHC (Static
Context Header Compression and fragmentation) protocol RFC8724. It
defines a SCHC Compound ACK message format and procedure, which are
intended to reduce the number of response transmissions (i.e., SCHC
ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several
windows in a single SCHC message (i.e., the SCHC Compound ACK).
Both message format and procedure are generic, so they can be used,
for instance, by any of the four LWPAN technologies defined in
RFC8376, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 July 2023.
Zuniga, et al. Expires 23 July 2023 [Page 1]
Internet-Draft SCHC Compound ACK January 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SCHC Compound ACK . . . . . . . . . . . . . . . . . . . . . . 3
3.1. SCHC Compound ACK Message Format . . . . . . . . . . . . 4
3.2. SCHC Compound ACK Behaviour . . . . . . . . . . . . . . . 6
8.4.3. ACK-on-Error Mode . . . . . . . . . . . . . . . . . . 7
4. SCHC Compound ACK Examples . . . . . . . . . . . . . . . . . 15
5. SCHC Compound ACK YANG Data Model . . . . . . . . . . . . . . 16
5.1. SCHC YANG Data Model Extension . . . . . . . . . . . . . 16
5.2. SCHC YANG Tree Extension . . . . . . . . . . . . . . . . 18
6. SCHC Compound ACK Parameters . . . . . . . . . . . . . . . . 19
7. Security considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Generic Framework for Static Context Header Compression and
Fragmentation (SCHC) specification [RFC8724] describes two
mechanisms: i) a protocol header compression scheme, and ii) a frame
fragmentation and loss recovery functionality. Either can be used on
top of radio technologies such as the four LWPAN defined in
[RFC8376], being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. These
LPWANs have similar characteristics such as star-oriented topologies,
network architecture, connected devices with built-in applications,
etc.
Zuniga, et al. Expires 23 July 2023 [Page 2]
Internet-Draft SCHC Compound ACK January 2023
SCHC offers a great level of flexibility to accommodate all these
LPWAN technologies. Even though there are a great number of
similarities between them, some differences exist with respect to the
transmission characteristics, payload sizes, etc. Hence, there are
optimal parameters and modes of operation that can be used when SCHC
is used on top of a specific LPWAN technology.
The present document describes an extension to the SCHC protocol for
frame fragmentation and loss recovery. It defines a SCHC Compound
ACK format and procedure, which is intended to reduce the number of
response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of
SCHC. The SCHC Compound ACK extends the SCHC ACK message format so
that it can contain several bitmaps, each bitmap being identified by
its corresponding window number.
The SCHC Compound ACK:
* provides feedback only for windows with fragment losses,
* has a variable size that depends on the number of windows with
fragment losses being reported in the single Compound SCHC ACK,
* includes the window number (i.e., W) of each bitmap,
* might not cover all windows with fragment losses of a SCHC Packet,
* and is distinguishable from the SCHC Receiver-Abort.
2. Terminology
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
It is assumed that the reader is familiar with the terms and
mechanisms defined in [RFC8376] and in [RFC8724].
3. SCHC Compound ACK
The SCHC Compound ACK is a SCHC ACK message that can contain several
bitmaps, each bitmap being identified by its corresponding window
number.
The SCHC Compound ACK MAY be used in fragmentation modes that use
windows and that allow reporting the bitmaps of multiple windows at
the same time, and MUST NOT be used otherwise.
Zuniga, et al. Expires 23 July 2023 [Page 3]
Internet-Draft SCHC Compound ACK January 2023
The SCHC Compound ACK groups the window number (W) with its
corresponding bitmap. Windows do not need to be contiguous.
However, the window numbers and corresponding bitmaps included in the
SCHC Compound ACK message MUST be ordered from the lowest-numbered to
the highest-numbered window. Hence, if the bitmap of window number
zero is present in the SCHC Compound ACK message, it MUST always be
the first one in order and its W number MUST be placed in the SCHC
ACK Header.
3.1. SCHC Compound ACK Message Format
Figure 1 shows the regular SCHC ACK format when all fragments have
been correctly received (C=1), as defined in [RFC8724].
|-- SCHC ACK Header --|
|--T-|-M-| 1 |
+--------+----+---+---+~~~~~~~~~~~~~~~~~~
| RuleID |DTag| W |C=1| padding as needed
+--------+----+---+---+~~~~~~~~~~~~~~~~~~
Figure 1: SCHC Success ACK message format, as defined in RFC8724
In case SCHC Fragment losses are found in any of the windows of the
SCHC Packet, the SCHC Compound ACK MAY be used. The SCHC Compound
ACK message format is shown in Figure 2 and Figure 3. If M or more
padding bits would be needed after the last bitmap in the message to
fill the last L2 Word, M bits at 0 MUST be appended after the last
bitmap, and then padding is applied as needed (see Figure 2). Since
window number 0, if present in the message, is placed as w1, the M
bits set to zero can’t be confused with window number 0, and
therefore they signal the end of the SCHC Compound ACK message.
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+------+-----+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
+------+----+------+---+--------+...+------+--------+------+-----+
next L2 Word boundary ->|<-- L2 Word ->|
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 2: SCHC Compound ACK message format
Figure 3 shows the case when the required padding bits are strictly
less than M bits. In this case, the length of the message learnt
from the underlying layer does not leave room for any extra window
value, let alone any bitmap, thereby signaling the end of the SCHC
Compound ACK message.
Zuniga, et al. Expires 23 July 2023 [Page 4]
Internet-Draft SCHC Compound ACK January 2023
|--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+--------+...+------+--------+---+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
+------+----+------+---+--------+...+------+--------+---+
next L2 Word boundary ->|
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 3: SCHC Compound ACK message format with less than M
padding bits
The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for
intermediate windows/bitmaps (i.e., bitmaps that are not the last one
of the SCHC Compound ACK message), and therefore intermediate bitmaps
fields MUST be of size WINDOW_SIZE. Hence, the SCHC Compound ACK MAY
use a Compressed Bitmap format only for the last bitmap in the
message. The optional usage of this Compressed Bitmap for the last
bitmap MUST be specified by the SCHC technology-specific profile.
The case where the last bitmap is effectively compressed corresponds
to Figure 3, with the last bitmap ending, by construction, on an L2
Word boundary, therefore resulting in no padding at all.
Figure 4 illustrates a bitmap compression example of a SCHC Compound
ACK, where the bitmap of the last window (wi) indicates that the
first tile has not been correctly received. Because the compression
algorithm resulted in effective compression, no padding is needed.
|--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
+------+----+------+---+--------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with uncompressed Bitmap
|--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+--------+...+------+---+
|RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
+------+----+------+---+--------+...+------+---+
next L2 Word boundary ->|
Transmitted SCHC Compound ACK
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 4: SCHC Compound ACK message format with compressed bitmap
Zuniga, et al. Expires 23 July 2023 [Page 5]
Internet-Draft SCHC Compound ACK January 2023
Figure 5 illustrates another bitmap compression example of a SCHC
Compound ACK, where the bitmap of the last window (wi) indicates that
the second and the fourth tile have not been correctly received. In
this example, the compression algorithm does not result in effective
compression of the last bitmap. Besides, because more than M bits of
padding would be needed to fill the last L2 Word, M bits at 0 are
appended to the message before padding is applied.
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--|
+------+----+------+---+------+...+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+...+------+--------------+
next L2 Word boundary ->|
SCHC Compound ACK with uncompressed Bitmap
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+------+...+------+--------------+------+---+
|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 ------>|
Transmitted SCHC Compound ACK
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi
Figure 5: SCHC Compound ACK message format with compressed bitmap
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.
Note: because it has a C bit reset to 0, the SCHC Compound ACK is
distinguishable from the Receiver-Abort message [RFC8724], which has
a C bit set to 1.
3.2. SCHC Compound ACK Behaviour
The SCHC ACK-on-Error behaviour is described in section 8.4.3 of
[RFC8724]. The present document slightly modifies this behaviour,
since in the baseline SCHC specification a SCHC ACK reports only one
bitmap for the reception of exactly one window of tiles. The present
SCHC Compound ACK specification extends the SCHC ACK message format
so that it can contain several bitmaps, each bitmap being identified
by its corresponding window number.
Zuniga, et al. Expires 23 July 2023 [Page 6]
Internet-Draft SCHC Compound ACK January 2023
The SCHC ACK format, as presented in [RFC8724], can be considered a
special SCHC Compound ACK case, in which it reports only the tiles of
one window. Therefore, the SCHC Compound ACK is backwards compatible
with the SCHC ACK format presented in [RFC8724].
Also, some flexibility is introduced with respect to [RFC8724], in
that the receiver has the capability to respond to the All-0 with a
SCHC Compound ACK or not, depending on certain parameters, like
network conditions. Note that even though the protocol allows for
such flexibility, the actual decision criteria is not specified in
this document.
The following sections describe the differences between the baseline
SCHC specification and the present SCHC protocol extension
specification. New text is between ** NEW TEXT **. Old text is --
OLD TEXT --. New text replaces old text.
8.4.3. ACK-on-Error Mode
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 fragmenter. See Appendix F
for a discussion on using ACK-on-Error mode on quasi-bidirectional
links.
In ACK-on-Error mode, windows are used.
All tiles except the last one and the penultimate one MUST be of
equal size, hereafter called "regular". The size of the last tile
MUST be smaller than or equal to the regular tile size. Regarding
the penultimate tile, a Profile MUST pick one of the following two
options:
* The penultimate tile size MUST be the regular tile size, or
* the penultimate tile size MUST be either the regular tile size or
the regular tile size minus one L2 Word.
A SCHC Fragment message carries one or several contiguous tiles,
which may span multiple windows. A SCHC **Compound** ACK reports on
the reception of --exactly-- one window of tiles ** or several
windows of tiles, each one identified by its window number**.
See Figure 23 for an example.
Zuniga, et al. Expires 23 July 2023 [Page 7]
Internet-Draft SCHC Compound ACK January 2023
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------|
Figure 23: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode
The W field is wide enough that it unambiguously represents an
absolute window number. The fragment receiver sends SCHC
**Compound** ACKs to the fragment sender about windows for which
tiles are missing. No SCHC **Compound** ACK is sent by the fragment
receiver for windows that it knows have been fully received.
The fragment sender retransmits SCHC Fragments for tiles that are
reported missing. It can advance to next windows even before it has
ascertained that all tiles belonging to previous windows have been
correctly received, and it can still later retransmit SCHC Fragments
with tiles belonging to previous windows. Therefore, the sender and
the receiver may operate in a decoupled fashion. The fragmented SCHC
Packet transmission concludes when:
* integrity checking shows that the fragmented SCHC Packet has been
correctly reassembled at the receive end, and this information has
been conveyed back to the sender, or
* too many retransmission attempts were made, or
* the receiver determines that the transmission of this fragmented
SCHC Packet has been inactive for too long.
Each Profile MUST specify which RuleID value(s) corresponds to SCHC
F/R messages operating in this mode.
The W field MUST be present in the SCHC F/R messages.
Each Profile, for each RuleID value, MUST define:
* the tile size (a tile does not need to be multiple of an L2 Word,
but it MUST be at least the size of an L2 Word),
* the value of M,
* the value of N,
Zuniga, et al. Expires 23 July 2023 [Page 8]
Internet-Draft SCHC Compound ACK January 2023
* the value of WINDOW_SIZE, which MUST be strictly less than 2^N,
* the size and algorithm for the RCS field,
* the value of T,
* the value of MAX_ACK_REQUESTS,
* the expiration time of the Retransmission Timer,
* the expiration time of the Inactivity Timer,
* if the last tile is carried in a Regular SCHC Fragment or an All-1
SCHC Fragment Section 8.4.3.1), and
* if the penultimate tile MAY be one L2 Word smaller than the
regular tile size. In this case, the regular tile size MUST be at
least twice the L2 Word size.
* **if the SCHC Compound ACK is used.**
For each active pair of RuleID and DTag values, the sender MUST
maintain:
* one Attempts counter, and
* one Retransmission Timer.
For each active pair of RuleID and DTag values, the receiver MUST
maintain:
* one Inactivity Timer, and
* one Attempts counter.
8.4.3.1. Sender Behavior
At the beginning of the fragmentation of a new SCHC Packet:
* the fragment sender MUST select a RuleID and DTag value pair for
this SCHC Packet. A Rule MUST NOT be selected if the values of M
and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot
be fragmented in (2^M) * WINDOW_SIZE tiles or less.
* the fragment sender MUST initialize the Attempts counter to 0 for
that RuleID and DTag value pair.
Zuniga, et al. Expires 23 July 2023 [Page 9]
Internet-Draft SCHC Compound ACK January 2023
A Regular SCHC Fragment message carries in its payload one or more
tiles. If more than one tile is carried in one Regular SCHC
Fragment:
* the selected tiles MUST be contiguous in the original SCHC Packet,
and
* they MUST be placed in the SCHC Fragment Payload adjacent to one
another, in the order they appear in the SCHC Packet, from the
start of the SCHC Packet toward its end.
Tiles that are not the last one MUST be sent in Regular SCHC
Fragments specified in Section 8.3.1.1. The FCN field MUST contain
the tile index of the first tile sent in that SCHC Fragment.
In a Regular SCHC Fragment message, the sender MUST fill the W field
with the window number of the first tile sent in that SCHC Fragment.
A Profile MUST define if the last tile of a SCHC Packet is sent:
* in a Regular SCHC Fragment, alone or as part of a multi-tiles
Payload,
* alone in an All-1 SCHC Fragment, or
* with any of the above two methods.
In an All-1 SCHC Fragment message, the sender MUST fill the W field
with the window number of the last tile of the SCHC Packet.
The fragment sender MUST send SCHC Fragments such that, all together,
they contain all the tiles of the fragmented SCHC Packet.
The fragment sender MUST send at least one All-1 SCHC Fragment.
In doing the two items above, the sender MUST ascertain that the
receiver will not receive the last tile through both a Regular SCHC
Fragment and an All-1 SCHC Fragment.
The fragment sender MUST listen for SCHC **Compound** ACK messages
after having sent:
* an All-1 SCHC Fragment, or
* a SCHC ACK REQ.
Zuniga, et al. Expires 23 July 2023 [Page 10]
Internet-Draft SCHC Compound ACK January 2023
A Profile MAY specify other times at which the fragment sender MUST
listen for SCHC **Compound** ACK messages. For example, this could
be after sending a complete window of tiles.
Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC
ACK REQ:
* it MUST increment the Attempts counter, and
* it MUST reset the Retransmission Timer.
On Retransmission Timer expiration:
* if the Attempts counter is strictly less than MAX_ACK_REQUESTS,
the fragment sender MUST send either the All-1 SCHC Fragment or a
SCHC ACK REQ with the W field corresponding to the last window,
* otherwise, the fragment sender MUST send a SCHC Sender-Abort, and
it MAY exit with an error condition.
All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
On receiving a SCHC **Compound** ACK:
* if **one of** the W field in the SCHC **Compound** ACK corresponds
to the last window of the SCHC Packet:
- if the C bit is set, the sender MAY exit successfully.
- otherwise:
o if the Profile mandates that the last tile be sent in an
All-1 SCHC Fragment:
+ if the SCHC **Compound** ACK shows no missing tile at the
receiver, the sender:
* MUST send a SCHC Sender-Abort, and
* MAY exit with an error condition.
+ otherwise:
* the fragment sender MUST send SCHC Fragment messages
containing all the tiles **of all the windows** that
are reported missing in the SCHC **Compound** ACK.
Zuniga, et al. Expires 23 July 2023 [Page 11]
Internet-Draft SCHC Compound ACK January 2023
* 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.-- **MAY either
send in addition a SCHC ACK REQ with the W field
corresponding to the last window, or repeat the All-1
SCHC Fragment to ask the receiver confirmation that
all tiles have been correctly received.**
* in doing the two items above, the sender MUST
ascertain that the receiver will not receive the last
tile through both a Regular SCHC Fragment and an All-1
SCHC Fragment.
o otherwise:
+ if the SCHC **Compound** ACK shows no missing tile at the
receiver, the sender MUST send the All-1 SCHC Fragment
+ otherwise:
* the fragment sender MUST send SCHC Fragment messages
containing all the tiles that are reported missing in
the SCHC **Compound** ACK.
* the fragment sender MUST then send either the All-1
SCHC Fragment or a SCHC ACK REQ with the W field
corresponding to the last window.
* otherwise, the fragment sender:
- MUST send SCHC Fragment messages containing the tiles that are
reported missing in the SCHC **Compound** ACK.
- then, it MAY send a SCHC ACK REQ with the W field corresponding
to the last window.
See Figure 43/> for one among several possible examples of a Finite
State Machine implementing a sender behavior obeying this
specification.
8.4.3.2. Receiver Behavior
On receiving a SCHC Fragment with a RuleID and DTag pair not being
processed at that time:
Zuniga, et al. Expires 23 July 2023 [Page 12]
Internet-Draft SCHC Compound ACK January 2023
* the receiver SHOULD check 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 fragmented SCHC Packet
transmission. The initial value of the Inactivity Timer is the
RECOMMENDED lifetime for the DTag value at the receiver. If the
SCHC Fragment is determined to be such a remnant, the receiver MAY
silently ignore it and discard it.
* the receiver MUST start a process to assemble a new SCHC Packet
with that RuleID and DTag value pair. The receiver MUST start an
Inactivity Timer for that RuleID and DTag value pair. It MUST
initialize an Attempts counter to 0 for that RuleID and DTag value
pair. If the receiver is under-resourced to do this, it MUST
respond to the sender with a SCHC Receiver-Abort.
On reception of any SCHC F/R message for the RuleID and DTag pair
being processed, the receiver MUST reset the Inactivity Timer
pertaining to that RuleID and DTag pair.
All message receptions being discussed in the rest of this section
are to be understood as "matching the RuleID and DTag pair being
processed", even if not spelled out, for brevity.
On receiving a SCHC Fragment message, the receiver determines what
tiles were received, based on the payload length and on the W and FCN
fields of the SCHC Fragment.
* if the FCN is All-1, if a Payload is present, the full SCHC
Fragment Payload MUST be assembled including the padding bits.
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 stage. They will be removed by the SCHC
C/D sublayer. If the size of the SCHC Fragment Payload exceeds or
equals the size of one regular tile plus the size of an L2 Word,
this SHOULD raise an error flag.
* otherwise, tiles MUST be assembled based on the a priori known
tile size.
- If allowed by the Profile, the end of the payload MAY contain
the last tile, which may be shorter. Padding bits are
indistinguishable from the tile data bits, at this stage.
- The payload may contain the penultimate tile that, if allowed
by the Profile, MAY be exactly one L2 Word shorter than the
regular tile size.
Zuniga, et al. Expires 23 July 2023 [Page 13]
Internet-Draft SCHC Compound ACK January 2023
- Otherwise, padding bits MUST be discarded. This is possible
because:
o the size of the tiles is known a priori,
o tiles are larger than an L2 Word, and
o padding bits are always strictly less than an L2 Word.
**On receiving a SCHC All-0 SCHC Fragment:
* if the receiver knows of any windows with missing tiles for the
packet being reassembled (and if network conditions are known to
be conducive), it MAY return a SCHC Compound ACK for the missing
tiles, starting from the lowest-numbered window.**
On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:
* if the receiver knows of any windows with missing tiles for the
packet being reassembled, it MUST return a SCHC **Compound** ACK
for the **missing tiles, starting from the lowest-numbered
window.**--lowest-numbered such window:--
* otherwise:
- if it has received at least one tile, it MUST return a SCHC
**Compound** ACK for the highest-numbered window it currently
has tiles for,
- otherwise, it MUST return a SCHC **Compound** ACK for window
numbered 0.
A Profile MAY specify other times and circumstances at which a
receiver sends a SCHC **Compound** ACK, and which window the SCHC
**Compound** ACK reports about in these circumstances.
Upon sending a SCHC **Compound** ACK, the receiver MUST increase the
Attempts counter.
After receiving an All-1 SCHC Fragment, a receiver MUST check the
integrity of the reassembled SCHC Packet at least every time it
prepares for sending a SCHC **Compound** ACK for the last window.
Upon receiving a SCHC Sender-Abort, the receiver MAY exit with an
error condition.
Upon expiration of the Inactivity Timer, the receiver MUST send a
SCHC Receiver-Abort, and it MAY exit with an error condition.
Zuniga, et al. Expires 23 July 2023 [Page 14]
Internet-Draft SCHC Compound ACK January 2023
On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST
send a SCHC Receiver-Abort, and it MAY exit with an error condition.
Reassembly of the SCHC Packet concludes when:
* a Sender-Abort has been received, or
* the Inactivity Timer has expired, or
* the Attempts counter has exceeded MAX_ACK_REQUESTS, or
* at least an All-1 SCHC Fragment has been received and integrity
checking of the reassembled SCHC Packet is successful.
See Figure 44 for one among several possible examples of a Finite
State Machine implementing a receiver behavior obeying this
specification. The example provided is meant to match the sender
Finite State Machine of Figure 43.
4. SCHC Compound ACK Examples
Figure 7 shows an example transmission of a SCHC Packet in ACK-on-
Error mode using the SCHC Compound ACK. In the example, the SCHC
Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE=7, M=2 and
two lost SCHC fragments. Only 1 compound SCHC ACK is generated.
Sender Receiver
|-----W=0, FCN=6 ----->|
|-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 --X-->|
|-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->| Bitmap: 1111011
(no ACK)
|-----W=1, FCN=6 ----->|
|-----W=1, FCN=5 ----->|
|-----W=1, FCN=4 ----->|
|-----W=1, FCN=3 ----->|
|-----W=1, FCN=2 ----->|
|-----W=1, FCN=1 --X-->|
|-- W=1, FCN=7 + RCS ->| Integrity check: failure
|<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011,
|-----W=0, FCN=2 ----->| W=1 - Bitmap:1111101]
|-----W=1, FCN=1 ----->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1
(End)
Zuniga, et al. Expires 23 July 2023 [Page 15]
Internet-Draft SCHC Compound ACK January 2023
Figure 7: SCHC Compound ACK message sequence example
|--- SCHC ACK Header --|- W=00 --|----- W=01 -----|
|--T-|---M--|-1-| |---M--| |---M--|
+------+----+------+---+---------+------+---------+------+-----+
|RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 | 00 | pad |
+------+----+------+---+---------+------+---------+------+-----+
next L2 Word boundary ->|<-- L2 Word ->|
Figure 8: SCHC Compound ACK message format example: Losses are
found in windows 00 and 01
5. SCHC Compound ACK YANG Data Model
The present document also extends the SCHC YANG data model defined in
[I-D.ietf-lpwan-schc-yang-data-model] by including a new leaf in the
Ack-on-Error fragmentation mode to describe both the option to use
the SCHC Compound ACK, as well as its bitmap format.
5.1. SCHC YANG Data Model Extension
<CODE BEGINS> file "ietf-lpwan-schc-compound-ack@2022-12-02.yang"
module ietf-lpwan-schc-compound-ack {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:"
+"ietf-lpwan-schc-compound-ack";
prefix schc-compound-ack;
import ietf-schc {
prefix schc;
}
organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan)
working group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lpwan/about/>
WG List: <mailto:lp-wan@ietf.org>
Editor: Laurent Toutain
<mailto:laurent.toutain@imt-atlantique.fr>
Editor: Juan Carlos Zuniga
<mailto:j.c.zuniga@ieee.org>";
description
"
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
Zuniga, et al. Expires 23 July 2023 [Page 16]
Internet-Draft SCHC Compound ACK January 2023
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
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.
***************************************************************
This module extends the ietf-schc module to include the
Compound ACK behavior for ACK-on-Error as defined in RFC YYYY.
It introduces a new leaf for ACK-on-Error defining the format
of the SCHC Compound ACK, adding the possibility to send
several bitmaps in a single SCHC ACK message.";
revision 2022-12-02 {
description
"Initial version for RFC YYYY ";
reference
"RFC YYYY: SCHC Compound ACK";
}
identity bitmap-format-base-type {
description
"Define how the bitmap is formed in ACK messages.";
}
identity bitmap-RFC8724 {
base bitmap-format-base-type;
description
"Bitmap by default as defined in RFC8724.";
}
identity bitmap-compound-ack {
base bitmap-format-base-type;
description
"Compound ACK.";
}
typedef bitmap-format-type {
type identityref {
base bitmap-format-base-type;
Zuniga, et al. Expires 23 July 2023 [Page 17]
Internet-Draft SCHC Compound ACK January 2023
}
description
"type used in rules";
}
augment "/schc:schc/schc:rule/schc:nature/"
+"schc:fragmentation/schc:mode/schc:ack-on-error" {
leaf bitmap-format {
when "derived-from(../schc:fragmentation-mode,"
+" 'schc:fragmentation-mode-ack-on-error')";
type schc-compound-ack:bitmap-format-type;
default "schc-compound-ack:bitmap-RFC8724";
description
"How the bitmaps are included in the"
+" SCHC ACK message.";
}
leaf last-bitmap-compression {
when "derived-from(../schc:fragmentation-mode,"
+" 'schc:fragmentation-mode-ack-on-error')";
type boolean;
default true;
description
"when true ultimate bitmap in the SCHC ACK message
can be compressed";
}
description
"added to SCHC rules";
}
}
<CODE ENDS>
Figure 9: SCHC YANG Data Model - Compound ACK extension
5.2. SCHC YANG Tree Extension
augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
schc:mode/schc:ack-on-error:
+--rw bitmap-format? schc-compound-ack:bitmap-format-type
Figure 10: SCHC YANG Tree - Compound ACK extension
Zuniga, et al. Expires 23 July 2023 [Page 18]
Internet-Draft SCHC Compound ACK January 2023
6. SCHC Compound ACK Parameters
This section lists the parameters related to the SCHC Compound ACK
usage that need to be defined in the Profile, in addition to the ones
listed in Annex D of [RFC8724].
* Usage or not of the SCHC Compound ACK message.
* Usage or not of the compressed bitmap format in the last window of
the SCHC Compound ACK message.
7. Security considerations
The current document specifies a message format extension for SCHC.
Hence, the same Security Considerations defined in [RFC8724] apply.
8. IANA Considerations
This document has no IANA actions.
9. Acknowledgements
Carles Gomez has been funded in part by the Spanish Government
through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant
(funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria
d'Universitats i Recerca del Departament d'Empresa i Coneixement de
la Generalitat de Catalunya 2017 through grant SGR 376.
Sergio Aguilar has been funded by the ERDF and the Spanish Government
through project TEC2016-79988-P and project PID2019-106808RA-I00,
AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).
Sandra Cespedes has been funded in part by the ANID Chile Project
FONDECYT Regular 1201893 and Basal Project FB0008.
Diego Wistuba has been funded by the ANID Chile Project FONDECYT
Regular 1201893.
The authors would like to thank Rafael Vidal, Julien Boite, Renaud
Marty, Antonis Platis, Dominique Barthel and Pascal Thubert for their
very useful comments, reviews and implementation design
considerations.
10. References
10.1. Normative References
Zuniga, et al. Expires 23 July 2023 [Page 19]
Internet-Draft SCHC Compound ACK January 2023
[I-D.ietf-lpwan-schc-yang-data-model]
Minaburo, A. and L. Toutain, "Data Model for Static
Context Header Compression (SCHC)", Work in Progress,
Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-21,
February 2021, <http://www.ietf.org/internet-drafts/draft-
ietf-lpwan-schc-yang-data-model-14.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>.
10.2. Informative References
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
Authors' Addresses
Juan Carlos Zuniga
Cisco
Montreal QC
Canada
Email: juzuniga@cisco.com
Carles Gomez
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.edu
Zuniga, et al. Expires 23 July 2023 [Page 20]
Internet-Draft SCHC Compound ACK January 2023
Sergio Aguilar
Universitat Politecnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: sergio.aguilar.romero@upc.edu
Laurent Toutain
IMT-Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Sandra Cespedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC, H3G 1M8
Canada
Email: sandra.cespedes@concordia.ca
Diego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Email: wistuba@niclabs.cl
Zuniga, et al. Expires 23 July 2023 [Page 21]