diff options
Diffstat (limited to 'doc/rfc/rfc9441.txt')
| -rw-r--r-- | doc/rfc/rfc9441.txt | 1120 |
1 files changed, 1120 insertions, 0 deletions
diff --git a/doc/rfc/rfc9441.txt b/doc/rfc/rfc9441.txt new file mode 100644 index 0000000..11ee2f3 --- /dev/null +++ b/doc/rfc/rfc9441.txt @@ -0,0 +1,1120 @@ + + + + +Internet Engineering Task Force (IETF) JC. Zúñiga +Request for Comments: 9441 Cisco +Updates: 8724, 9363 C. Gomez +Category: Standards Track S. Aguilar +ISSN: 2070-1721 Universitat Politècnica de Catalunya + L. Toutain + IMT-Atlantique + S. Céspedes + Concordia University + D. Wistuba + NIC Labs, Universidad de Chile + July 2023 + + +Static Context Header Compression (SCHC) Compound Acknowledgement (ACK) + +Abstract + + This document updates the Static Context Header Compression (SCHC) + and fragmentation protocol (RFC 8724) and the corresponding YANG + module (RFC 9363). It defines a SCHC Compound Acknowledgement (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 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) technologies defined in RFC 8376, which are Sigfox, Long + Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB- + IoT), and IEEE 802.15.4w. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9441. + +Copyright Notice + + Copyright (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. Terminology + 3. SCHC Compound ACK + 3.1. SCHC Compound ACK Message Format + 3.2. SCHC Compound ACK Behavior + 3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724) + 4. SCHC Compound ACK Example + 5. SCHC Compound ACK YANG Data Model + 5.1. SCHC YANG Data Model Extension + 5.2. SCHC YANG Tree Extension + 6. SCHC Compound ACK Parameters + 7. Security Considerations + 8. IANA Considerations + 8.1. URI Registration + 8.2. YANG Module Name Registration + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + The Generic Framework for Static Context Header Compression (SCHC) + and Fragmentation 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 Low-Power Wide Area Networks (LPWANs) + listed in [RFC8376], which are Sigfox, LoRaWAN, NB-IoT, and IEEE + 802.15.4w. These LPWANs have similar characteristics, such as star- + oriented topologies, network architecture, and connected devices with + built-in applications. + + 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, 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. + + In ACK-on-Error mode in [RFC8724], the SCHC Packet is fragmented into + pieces called tiles, where all tiles are the same size except for the + last one, which can be smaller. Successive tiles are grouped in + windows of fixed size. A SCHC Fragment carries one or several + contiguous tiles, which may span multiple windows. When sending all + tiles from all windows, the last tile is sent in an All-1 SCHC + Fragment. The SCHC receiver will send a SCHC ACK reporting on the + reception of exactly one window of tiles after receiving the All-1 + SCHC Fragment. In case of SCHC Fragment losses, a bitmap is added to + the failure SCHC ACK, where each bit in the bitmap corresponds to a + tile in the window. If SCHC Fragment losses span multiple windows, + the SCHC receiver will send one failure SCHC ACK per window with + losses. + + This document updates the SCHC protocol for frame fragmentation and + 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 the ACK-on-Error mode of SCHC. The SCHC + Compound ACK extends the failure SCHC ACK message format so that it + can contain several bitmaps, with each bitmap being identified by its + corresponding window number. The SCHC Compound ACK is backwards + compatible with the SCHC ACK as defined in [RFC8724], and introduces + flexibility, as the receiver has the capability to respond to the + All-0 SCHC Fragment, providing more Downlink opportunities and + therefore adjusting to the delay requirements of the application. + +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 [RFC8724]. + +3. SCHC Compound ACK + + The SCHC Compound ACK is a failure SCHC ACK message that can contain + several bitmaps, with each bitmap being identified by its + corresponding window number. In [RFC8724], the failure SCHC ACK + message only contains one bitmap corresponding to one window. The + SCHC Compound ACK extends this format, allowing more windows to be + acknowledged in a single ACK and reducing the total number of failure + SCHC ACK messages, especially when fragment losses are present in + intermediate windows. + + 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; otherwise, the SCHC Compound ACK MUST NOT be used. + + 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 SCHC Compound 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. + +3.1. SCHC Compound ACK Message Format + + Figure 1 shows the success SCHC ACK format, i.e., 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 RFC 8724 + + 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 Figures 2 and 3. + + |--- 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 ->| + + Figure 2: SCHC Compound ACK Message Format. Losses are found in + windows W = w1,...,wi, where w1 < w2 <...< wi. + + The SCHC Compound ACK groups the window number (W) with its + corresponding bitmap. Window numbers do not need to be contiguous. + However, the window numbers and their 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 window number MUST be + placed in the SCHC ACK Header. + + If M or more padding bits would be needed after the last bitmap in + the message to fill the last layer two (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; therefore, they signal the end of the SCHC Compound ACK + message. + + Figure 3 shows the case when the required padding bits are strictly + less than M bits. In this case, the L2 Maximum Transmission Unit + (MTU) does not leave room for any extra window value, let alone any + bitmap, thereby signaling 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 |pad| + +------+----+------+---+--------+...+------+--------+~~~+ + next L2 Word boundary ->| + + Figure 3: SCHC Compound ACK Message Format with Less than M + Padding Bits. Losses are found in windows W = w1,...,wi, where + w1 < w2 <...< wi. + + The SCHC Compound ACK MUST NOT use the Compressed Bitmap format for + intermediate windows/bitmaps (i.e., bitmaps that are not the last one + of the SCHC Compound ACK message); therefore, intermediate bitmap + 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 technology-specific SCHC 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 with Compressed Bitmap + + Figure 4: SCHC Compound ACK Message Format with Compressed Bitmap + and No Padding Added. Losses are found in windows W = w1,...,wi, + where w1 < w2 <...< wi. + + Figure 5 illustrates another bitmap compression example of a SCHC + Compound ACK, where the bitmap of the last window (wi) indicates that + the second and the fourth tiles 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 + + Figure 5: SCHC Compound ACK Message Format with Compressed Bitmap + and Padding Added to Reach the L2 Boundary. Losses are found in + windows W = w1,...,wi, where w1 < w2 <...<wi. + + If a SCHC sender gets a SCHC Compound ACK with invalid window + numbers, such as duplicate W values or W values not sent yet, it MUST + discard the whole SCHC Compound ACK message. + + | Note that SCHC Compound ACKs are distinguishable from the + | Receiver-Abort message in the same way that regular SCHC ACKs + | are distinguishable, since the Receiver-Abort pattern never + | occurs in a legitimate SCHC Compound ACK [RFC8724]. + +3.2. SCHC Compound ACK Behavior + + The SCHC ACK-on-Error behavior is described in Section 8.4.3 of + [RFC8724]. The present document slightly modifies this behavior. 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, with each bitmap being + identified by its corresponding window number. + + As presented in [RFC8724], the SCHC ACK format can be considered a + special SCHC Compound ACK case in which it reports only the tiles of + one window. Therefore, the SCHC Compound ACK is backwards compatible + with the SCHC ACK format presented in [RFC8724]. The receiver can + assume that the sender does not support the SCHC Compound ACK if, + although the SCHC Compound ACK sent by the receiver reports losses in + more than one window, the sender does not resend any tiles from + windows other than the first window reported in the SCHC Compound + ACK. In that case, the receiver can send SCHC Compound ACKs with + only one window of tiles. + + Also, some flexibility is introduced with respect to [RFC8724] in + that the receiver has the capability to respond (or not) to the All-0 + with a SCHC Compound ACK, depending on certain parameters, like + network conditions, sender buffer/cache size, and supported + application delay. Note that even though the protocol allows for + such flexibility, the actual decision criteria is not specified in + this document. The application MUST set expiration timer values + according to when the feedback is expected to be received, e.g., + after the All-0 or after the All-1. + + Section 3.2.1 (and its subsections) replaces the complete + Section 8.4.3 (and its subsections) of [RFC8724]. + +3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724) + + The ACK-on-Error mode supports L2 technologies that have variable MTU + 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 one window of tiles or several windows of tiles, each + one identified by its window number. + + See Figure 6 (see Figure 23 of RFC 8724 (https://www.rfc- + editor.org/rfc/rfc8724.html#figure-23)) for an example. + + +---------------------------------------------...-----------+ + | 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 6: SCHC Packet Fragmented in Tiles, ACK-on-Error Mode + (Figure 23 in RFC 8724) + + The W field is wide enough that it unambiguously represents an + 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, + + * too many retransmission attempts have been 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 a duplicate of an L2 + Word, but it MUST be at least the size of an L2 Word), + + * the value of M, + + * the value of N, + + * 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 (see Section 3.2.1.1 (Section 8.4.3.1 in [RFC8724]), + + * if the penultimate tile MAY be one L2 Word smaller than the + regular tile size (in this case, the regular tile size MUST be at + least twice the L2 Word size), + + * usage or not of the SCHC Compound ACK message, and + + * usage or not of the Compressed Bitmap format in the last window of + the SCHC Compound ACK message. + + 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 Attempts counter and + + * one Inactivity Timer. + +3.2.1.1. Sender Behavior (Replaces Section 8.4.3.1, RFC 8724) + + At the beginning of the fragmentation of a new SCHC Packet: + + * 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. + + 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 as 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 either one 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. + + 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 fields 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. + + * if the last of these SCHC Fragment messages is not an + All-1 SCHC Fragment, then the fragment sender 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 to confirm + 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 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43) + for one among several possible examples of a Finite State Machine + implementing a sender behavior obeying this specification. + +3.2.1.2. Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724) + + On receiving a SCHC Fragment with a RuleID and DTag pair not being + processed at that time: + + * the receiver SHOULD check that 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 and 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. + + - 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 depending on certain parameters, + like network conditions, sender buffer/cache size, and supported + application delay, among others), 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. + + * 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 number + 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 to send 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. + + 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, + + * the Inactivity Timer has expired, + + * 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 (https://www.rfc-editor.org/rfc/rfc8724.html#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 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43). + +4. SCHC Compound ACK Example + + 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 SCHC Compound 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) + + 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 + + This document also extends the SCHC YANG data model defined in + [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. + +5.1. SCHC YANG Data Model Extension + + <CODE BEGINS> file "ietf-schc-compound-ack@2023-07-26.yang" + module ietf-schc-compound-ack { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-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> + Editor: Sergio Aguilar + <mailto:sergio.aguilar.romero@upc.edu>"; + description + "Copyright (c) 2023 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 + the license terms contained in, the Revised 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 9363 + (https://www.rfc-editor.org/info/rfc9363); see the RFC itself + for full legal notices. + *************************************************************** + Generic data model for the Static Context Header Compression + Rule for SCHC, based on RFCs 8724 and 8824. Including + compression, no-compression, and fragmentation Rules."; + + revision 2023-07-26 { + description + "Initial version for RFC 9441."; + reference + "RFC 9441 Static Context Header Compression (SCHC) Compound + Acknowledgement (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 RFC 8724."; + reference + "RFC 8724 SCHC: Generic Framework for Static Context Header + Compression and Fragmentation"; + } + + identity bitmap-compound-ack { + base bitmap-format-base-type; + description + "Compound ACK allows several bitmaps in an ACK message."; + } + + typedef bitmap-format-type { + type identityref { + base bitmap-format-base-type; + } + description + "Type of bitmap used in Rules."; + } + + augment "/schc:schc/schc:rule/schc:nature/" + + "schc:fragmentation/schc:mode/schc:ack-on-error" { + leaf bitmap-format { + when "derived-from-or-self(../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-or-self(../schc:fragmentation-mode, + 'schc:fragmentation-mode-ack-on-error')"; + type boolean; + default "true"; + description + "When true, the ultimate bitmap in the SCHC ACK message + can be compressed. Default behavior from RFC 8724."; + reference + "RFC 8724 SCHC: Generic Framework for Static Context Header + Compression and Fragmentation"; + } + description + "Augment the SCHC Rules to manage Compound ACK."; + } + } + <CODE ENDS> + + Figure 9: SCHC YANG Data Model - Compound ACK Extension + +5.2. SCHC YANG Tree Extension + + module: ietf-schc-compound-ack + augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/ + schc:mode/schc:ack-on-error: + +--rw bitmap-format? schc-compound-ack:bitmap-format-type + +--rw last-bitmap-compression? boolean + + Figure 10: Tree Diagram - Compound ACK Extension + +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. 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:" + as defined in Appendix D of [RFC8724]. + + * whether the SCHC Compound ACK message is used or not, and + + * whether the compressed bitmap format in the last window of the + SCHC Compound ACK message is used or not. + +7. Security Considerations + + This document specifies a message format extension for SCHC. Hence, + the same security considerations defined in [RFC8724] and [RFC9363] + apply. + + The YANG module specified in this document defines a schema for data + that is designed to be accessed via network management protocols such + as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer + is the secure transport layer, and the mandatory-to-implement secure + transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer + is HTTPS, and the mandatory-to-implement secure transport is TLS + [RFC8446]. + + The Network Configuration Access Control Model (NACM) [RFC8341] + provides the means to restrict access for particular NETCONF or + RESTCONF users to a preconfigured subset of all available NETCONF or + RESTCONF protocol operations and content. + + There are a number of data nodes defined in this YANG module that are + writable/creatable/deletable (i.e., config true, which is the + default). These data nodes may be considered sensitive or vulnerable + in some network environments. Write operations (e.g., edit-config) + to these data nodes without proper protection can have a negative + effect on network operations. These are the subtrees and data nodes + and their sensitivity/vulnerability: + + /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ + schc:ack-on-error: + All the data nodes may be modified. The Rule contains sensitive + information, such as the SCHC F/R mode configuration and usage and + SCHC Compound ACK configuration. 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 + ACKs. Therefore, a device must be allowed to modify only its own + Rules on the remote SCHC instance. The identity of the requester + must be validated. This can be done through certificates or + access lists. + + Some of the readable data nodes in this YANG module may be considered + sensitive or vulnerable in some network environments. It is thus + important to control read access (e.g., via get, get-config, or + notification) to these data nodes. These are the subtrees and data + nodes and their sensitivity/vulnerability: + + /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/ + schc:ack-on-error: + By reading this module, an attacker may learn the F/R mode used by + the device, how the device manages the bitmap creation, the buffer + sizes, and when the device will request an ACK. + +8. IANA Considerations + + This document registers one URI and one YANG data model. + +8.1. URI Registration + + IANA registered the following URI in the "IETF XML Registry" + [RFC3688]: + + URI: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack + + Registrant Contact: The IESG. + + XML: N/A; the requested URI is an XML namespace. + +8.2. YANG Module Name Registration + + IANA has registered the following YANG data model in the "YANG Module + Names" registry [RFC6020]. + + name: ietf-schc-compound-ack + + namespace: urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack + + prefix: schc-compound-ack + + reference: RFC 9441 + +9. References + +9.1. Normative References + + [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>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + <https://www.rfc-editor.org/info/rfc6020>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + <https://www.rfc-editor.org/info/rfc6242>. + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + <https://www.rfc-editor.org/info/rfc8040>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + <https://www.rfc-editor.org/info/rfc8341>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. + 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>. + + [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static + Context Header Compression (SCHC)", RFC 9363, + DOI 10.17487/RFC9363, March 2023, + <https://www.rfc-editor.org/info/rfc9363>. + +9.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>. + +Acknowledgements + + Carles Gomez has been funded in part by the Spanish Government + through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant + (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria + d'Universitats i Recerca del Departament d'Empresa i Coneixement de + la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant + SGR 00330. + + Sergio Aguilar has been funded by the ERDF and the Spanish Government + through project TEC2016-79988-P and project PID2019-106808RA-I00, + AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033). + + Sandra Cespedes has been funded in part by the ANID Chile Project + FONDECYT Regular 1201893 and Basal Project FB0008. + + Diego Wistuba has been funded by the ANID Chile Project FONDECYT + Regular 1201893. + + The authors would like to thank Rafael Vidal, Julien Boite, Renaud + Marty, Antonis Platis, Dominique Barthel, and Pascal Thubert for + their very useful comments, reviews, and implementation design + considerations. + +Authors' Addresses + + Juan Carlos Zúñiga + Cisco + Montreal QC + Canada + Email: juzuniga@cisco.com + + + Carles Gomez + Universitat Politècnica de Catalunya + C/Esteve Terradas, 7 + 08860 Castelldefels + Spain + Email: carles.gomez@upc.edu + + + Sergio Aguilar + Universitat Politècnica 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 Céspedes + 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: research@witu.cl |