RFC 9441

Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)

📅 published July 2023, from ietf

RFC 9441 💖 Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)

okay bestie, let's get into this one 🎀 It's an Internet Standards Track doc from the IETF, dated July 2023, with ISSN 2070-1721. It's by JC. Zúñiga (Cisco), C. Gomez and S. Aguilar (Universitat Politècnica de Catalunya), L. Toutain (IMT-Atlantique), S. Céspedes (Concordia University), and D. Wistuba (NIC Labs, Universidad de Chile) 🫶 It updates RFC 8724 (the SCHC and fragmentation protocol) and RFC 9363 (the YANG module for it). The header doesn't list anything it obsoletes.

Abstract

This doc updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the matching YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure 🔥 The goal is to cut down on how many response transmissions (aka SCHC ACKs) you need in the ACK-on-Error Mode. How? By stuffing bitmaps from several windows into one SCHC message, called the SCHC Compound ACK. It's giving efficiency ✨

The format and procedure are both generic, so they can be used by any of the four Low-Power Wide Area Network (LPWAN) technologies in RFC 8376: Sigfox, Long Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w. Every single one of them gets to play 🦋

Status of This Memo

This is an Internet Standards Track document 💅

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🌸

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9441.

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) as they stand on the publication date. Please actually read these, bestie, because they spell out your rights and restrictions for this doc. Any code components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 📜

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 spec [RFC8724] describes two mechanisms. First, there's a protocol header compression scheme. Second, there's frame fragmentation and loss recovery. Either one can run on top of radio technologies like the four LPWANs listed in [RFC8376]: Sigfox, LoRaWAN, NB-IoT, and IEEE 802.15.4w. These LPWANs have a lot in common, like star-oriented topologies, network architecture, and connected devices with built-in applications 🧚

SCHC is super flexible, so it can accommodate all of these LPWAN technologies 💜 Still, they're not identical. Transmission characteristics, payload sizes, and so on all differ. So there are optimal parameters and modes of operation for SCHC on each specific LPWAN technology.

Now, how ACK-on-Error mode works in [RFC8724] 👑 The SCHC Packet gets chopped into pieces called tiles. All the tiles are the same size except the last one, which can be smaller. Successive tiles are grouped into windows of fixed size. A SCHC Fragment carries one or several contiguous tiles, and those can span multiple windows. When every tile from every window has been sent, the last tile goes out in an All-1 SCHC Fragment. After the All-1 SCHC Fragment arrives, the SCHC receiver sends a SCHC ACK reporting on exactly one window of tiles. If any SCHC Fragments got lost, the failure SCHC ACK gets a bitmap, and each bit in that bitmap lines up with one tile in the window. If the losses span multiple windows, the SCHC receiver sends one failure SCHC ACK per window that has losses 😭

This doc updates the SCHC protocol for frame fragmentation and loss recovery. It defines a SCHC Compound ACK format and procedure, meant to cut down on response transmissions (aka SCHC ACKs) in SCHC's ACK-on-Error mode. The SCHC Compound ACK extends the failure SCHC ACK message format so it can hold several bitmaps, and each bitmap gets identified by its window number. It's backwards compatible with the SCHC ACK defined in [RFC8724]. It also adds flexibility, because the receiver can respond to the All-0 SCHC Fragment too. That means more Downlink opportunities, so the protocol can match 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's assumed that you're already familiar with the terms and mechanisms defined in [RFC8376] and [RFC8724]. No cap, if you're new to this, go read those first 🙈

3. SCHC Compound ACK

The SCHC Compound ACK is a failure SCHC ACK message that can hold several bitmaps, and each bitmap is identified by its window number. In [RFC8724], the failure SCHC ACK only carries one bitmap, for one window. The SCHC Compound ACK extends that format so more windows can be acknowledged in a single ACK. That cuts the total number of failure SCHC ACK messages, especially when fragment losses show up in the middle 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 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 ✨

okay so first up is the plain old success ACK 💖 Figure 1 shows the SCHC ACK when every fragment arrived intact, which is the C=1 case from [RFC8724]. bestie, it's giving simple and clean 🎀

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

okay now the fun part 🦋 if some SCHC Fragment losses show up in any of the windows of the SCHC Packet, you're allowed to send a SCHC Compound ACK. The SCHC Compound ACK MAY be used in that situation. Its format is 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.

so the SCHC Compound ACK pairs each window number (W) with its matching bitmap 🍓 the window numbers don't have to be contiguous, no cap. BUT the window numbers and their bitmaps MUST be ordered from the lowest-numbered window to the highest-numbered window. That's the rule, no exceptions 🙈 and if window number zero's bitmap is in the message, it MUST always come first, and its window number MUST be placed in the SCHC ACK Header. non-negotiable, bestie 👑

now the padding situation 🧚 if M or more padding bits would be needed after the last bitmap to fill the last layer two (L2) Word, then M bits set to 0 MUST be appended after that last bitmap. After that, padding gets applied as needed (see Figure 2). Here's why it's lowkey genius: window number 0 (if it's there) is always placed first as w1, so those zero M bits can't be mistaken for window number 0. They just mean "the message is over" ✨

Figure 3 is for when the padding needed is strictly less than M bits. In that case the L2 Maximum Transmission Unit (MTU) doesn't have room for any extra window value, let alone a bitmap, so the end of the SCHC Compound ACK message is signaled by that lack of room 🌸

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

now the compression drama 🎭 the SCHC Compound ACK MUST NOT use the Compressed Bitmap format for intermediate windows or bitmaps (basically, any bitmap that isn't the last one in the message). So intermediate bitmap fields MUST be of size WINDOW_SIZE. The only place compression is allowed is the last bitmap, and the SCHC Compound ACK MAY use a Compressed Bitmap format for that one. And the optional use of that Compressed Bitmap for the last bitmap MUST be specified by the technology-specific SCHC Profile. the profile gets the final say 💜

when the last bitmap is actually compressed, you end up in the Figure 3 situation, where the last bitmap lands exactly on an L2 Word boundary. result? zero padding at all 😭

Figure 4 shows a compression example. The bitmap of the last window (wi) says the first tile wasn't received correctly. Since the compression worked, 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 is another compression example 🦋 this time the last window's bitmap says the second and fourth tiles weren't received correctly. Here the compression doesn't actually help the last bitmap. Also, since more than M bits of padding would be needed to fill the last L2 Word, M bits set to 0 get appended to the message before padding is applied. So you still get the end-of-message signal, just the long way 🌈

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

last but definitely not least 👑 if a SCHC sender receives a SCHC Compound ACK with invalid window numbers (like duplicate W values, or W values it hasn't sent yet), it MUST discard the whole SCHC Compound ACK message. No partial credit, periodt 💀

✨ quick aside: SCHC Compound ACKs can be told apart from the Receiver-Abort message the same way regular SCHC ACKs can, because the Receiver-Abort pattern never shows up in a legit SCHC Compound ACK [RFC8724]. so no mix-ups, iykyk 🙈

3.2. SCHC Compound ACK Behavior 🌸

so the SCHC ACK-on-Error behavior is described in Section 8.4.3 of [RFC8724], and this doc tweaks it a little 💅 in the baseline SCHC spec, a SCHC ACK only reports one bitmap, for exactly one window of tiles. The SCHC Compound ACK extends the message format so it can hold several bitmaps, each one tagged with its own window number. main character glow-up 💖

Here's the best part: the regular SCHC ACK is basically a special case of the SCHC Compound ACK that only reports the tiles of one window. So the SCHC Compound ACK is backwards compatible with the SCHC ACK format from [RFC8724] 🦋 and the receiver can figure out the sender doesn't support SCHC Compound ACKs if, even though the receiver reported losses in more than one window, the sender only resends tiles from the first reported window. If that happens, the receiver can just send SCHC Compound ACKs with one window of tiles at a time 🫶

also, there's some flexibility compared to [RFC8724]: the receiver can choose whether or not to answer the All-0 with a SCHC Compound ACK, depending on things like network conditions, sender buffer/cache size, and supported application delay ✨ the protocol allows for that flexibility, but the actual decision criteria aren't specified in this document, so that's up to the implementation, bestie 🧚 and whatever the choice, 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]. so if you were reading the old section, that's the update, no cap 💜

3.2.1. ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724) ✨

okay so ACK-on-Error mode is built for L2 technologies with a variable MTU and out-of-order delivery 🦋 It needs an L2 that gives the reassembler a feedback path back to the fragmenter 💅 For the quasi-bidirectional links tea, check out Appendix F 🫶

In ACK-on-Error mode, windows are used 🎀

All tiles except the last one and the penultimate one MUST be of equal size, which we'll call "regular" 🌸 The last tile MUST be smaller than or equal to the regular tile size. For the penultimate tile, a Profile MUST pick one of these 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, and those tiles can span multiple windows 🧚 A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, and each window is identified by its window number 💜

Here's the example, see Figure 6 (see Figure 23 of RFC 8724 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-23))) 👑

        +---------------------------------------------...-----------+
        |                       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 to unambiguously represent an absolute window number 🍓 The fragment receiver sends SCHC Compound ACKs to the fragment sender about windows where tiles are missing. It does NOT send a SCHC Compound ACK for windows it already knows are fully received, so no spam there 🙈

Now the fragment sender retransmits SCHC Fragments for tiles that get reported missing. It can move on to the next windows even before it has confirmed that every tile in the previous windows arrived correctly, and it can still go back later and retransmit SCHC Fragments with tiles from previous windows 😭 So the sender and the receiver can operate in a decoupled way, and the fragmented SCHC Packet transmission wraps up 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) correspond 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 fragmenting 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 one or more tiles in its payload. If more than one tile rides 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 right next to one another, in the order they appear in the SCHC Packet, going 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 how the last tile of a SCHC Packet is sent:

  • in a Regular SCHC Fragment, alone or as part of a multi-tile 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.

While 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 discussed in the rest of this section are to be understood as "matching the RuleID and DTag pair being processed", even if that isn't spelled out, just to keep things brief 🧚

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:
      • 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.
          • while 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.
      • 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. 👑

For one of several possible examples of a Finite State Machine that implements sender behavior obeying this specification, see Figure 43 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-43) 🦋✨

3.2.1.2. Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724) 🦋

okay so the receiver side is where the real drama happens 😭 Let's go through it step by step.

When a SCHC Fragment shows up with a RuleID and DTag pair the receiver isn't already processing:

  • the receiver SHOULD check that the DTag value has not recently been used for that RuleID value, which makes sure the SCHC Fragment isn't a leftover from an earlier 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 turns out to be a leftover, 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 💅

Every SCHC F/R message for the RuleID and DTag pair being processed resets the receiver's Inactivity Timer for that pair. The receiver MUST reset the Inactivity Timer pertaining to that RuleID and DTag pair on each reception 🌸

Also, everything else in this section is read as "matching the RuleID and DTag pair being processed," even when that isn't spelled out, just to keep things short 🧚

When a SCHC Fragment message arrives, the receiver figures out which tiles it got, using the payload length and 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 receiver doesn't know the size of the last tile, so at this stage the padding bits look exactly like tile data bits. The SCHC C/D sublayer removes them later 🙈 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. At this stage, padding bits look the same as tile data bits.
    • 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 works because:
      • the size of the tiles is known a priori,
      • tiles are larger than an L2 Word, and
      • padding bits are always strictly less than an L2 Word.

When a SCHC All-0 SCHC Fragment comes in 🍓

  • 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.

When a SCHC ACK REQ or an All-1 SCHC Fragment comes in, things get serious 💀

  • 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, plus which window the SCHC Compound ACK reports about in those cases 🌈

Every time the receiver sends 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 🔍

When a SCHC Sender-Abort is received, the receiver MAY exit with an error condition 🛑

When the Inactivity Timer expires, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition 😤

When the Attempts counter goes over MAX_ACK_REQUESTS, the receiver MUST send a SCHC Receiver-Abort, and it MAY exit with an error condition 😤

Reassembly of the SCHC Packet wraps up when any of these happen:

  • 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.

For one of several possible examples of a Finite State Machine that implements receiver behavior following this specification, see Figure 44 (https://www.rfc-editor.org/rfc/rfc8724.html#figure-44). This example 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 this example, the SCHC Packet is split into 14 tiles, with N=3, WINDOW_SIZE=7, M=2, and two lost SCHC fragments. Only 1 SCHC Compound ACK gets 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 adding a new leaf in the Ack-on-Error fragmentation mode. It covers both the option to use the SCHC Compound ACK and 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 🎀

okay so this section is the checklist for anyone writing a Profile 💅 It lists the SCHC Compound ACK settings the Profile has to spell out. These items MUST be tacked onto the end of the SCHC list under "Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:" from Appendix D of [RFC8724]. Two things to define:

  • 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 🔐

bestie, this one's serious 😭 This document adds a message format extension to SCHC, so the same security considerations from [RFC8724] and [RFC9363] apply here too. No skipping them!

The YANG module in this document is a schema for data you reach through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. The bottom layer of NETCONF is a secure transport layer, and the mandatory-to-implement one is Secure Shell (SSH) [RFC6242]. The bottom layer of RESTCONF is HTTPS, and its mandatory-to-implement secure transport is TLS [RFC8446].

The Network Configuration Access Control Model (NACM) [RFC8341] is how you restrict particular NETCONF or RESTCONF users to a preset subset of protocol operations and content. It's giving access control ✨

There are a bunch of data nodes in this YANG module that you can write, create, or delete (that's config true, which is the default). These can be sensitive or vulnerable in some environments. Writing to them (for example with edit-config) without proper protection can badly mess with network operations. Here are the subtrees and data nodes, plus how sensitive they are:

/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error:

All the data nodes in there may be modified. The Rule holds sensitive stuff, like the SCHC F/R mode configuration and how SCHC Compound ACK is set up and used. An attacker could try to change other devices' Rules by messing with the F/R mode or the SCHC Compound ACK usage. That could block communication or create extra ACKs, which is so not it 💀 So a device must be allowed to modify only its own Rules on the remote SCHC instance. The identity of the requester must be validated, and that can be done through certificates or access lists.

Some of the readable data nodes in this YANG module can also be sensitive or vulnerable in some environments, so controlling read access (for example via get, get-config, or notification) to them matters a lot. Here are the subtrees and data nodes, plus their sensitivity:

/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/
schc:ack-on-error:

By reading this module, an attacker could learn the F/R mode the device uses, how the device handles bitmap creation, the buffer sizes, and when the device will ask for an ACK. Lowkey a whole blueprint 🙈

8. IANA Considerations 🌸

This document registers one URI and one YANG data model. Iconic, right? ✨

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. Main character energy for these legends 👑

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
📦 where this page comes from