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

shows the regular SCHC ACK format when all fragments have been correctly received (C=1), as defined in .

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

|<-- L2 Word ->| Losses are found in windows W = w1,...,wi; where w1 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.

| Losses are found in windows W = w1,...,wi; where w1 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 , with the last bitmap ending, by construction, on an L2 Word boundary, therefore resulting in no padding at all. 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 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 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 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 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 , which has a C bit set to 1.

The SCHC ACK-on-Error behaviour is described in section 8.4.3 of . 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. The SCHC ACK format, as presented in , 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 . Also, some flexibility is introduced with respect to , 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.

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 for an example.

SCHC Packet Fragmented in Tiles, ACK-on-Error Mode +---------------------------------------------...-----------+ | 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 |-----------| 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,
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.

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.

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.

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

Receiver Behavior On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time:

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.
- Otherwise, padding bits MUST be discarded. This is possible 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.

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