3.2.1.2. Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724)
3.2.1.2. Receiver Behavior
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:
-
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 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 of RFC 8724 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.