Subject: [lp-wan] Ticket #20 Byte Boundary

From: ana minaburo <[email-masked]>
Date: Tue, 19 Jun 2018 17:07:01 +0200

Interim 13/06/2018

The term |<------ byte boundary ------->|
will be replaced with:

Option 1
|         next byte boundary ->|

Option 2
| L2 Word ->|

   - ML consensus is for Option 2

Now all the figures and in the text, we have changed to L2 Word (the most
relevant are:)

Terminology

   - L2 Word: this is the minimum subdivision of payload data that the L2
   will carry. In most L2 technologies, the L2 Word is an octet. In
   bit-oriented radio technologies, the L2 Word might be a single bit. The L2
   Word size is assumed to be constant over time for each device.

Fragmentation Overview
SCHC F/R uses the knowledge of the L2 Word size (see {{Term}}) to encode
some messages. Therefore, SCHC MUST know the L2 Word size. SCHC F/R
generates SCHC Fragments and SCHC ACKs that are, for most of them,
multiples of L2 Words. The padding overhead is kept to the absolute
minimum. See {{Padding}}.

Fragmentation Formats (Different places on this section)
The total size of the fragment header is not necessarily a multiple of the
L2 Word size. To build the fragment payload, SCHC F/R MUST take from the
SCHC Packet a number of bits that makes the SCHC Fragment an exact multiple
of L2 Words. As a consequence, no padding bit is used for these fragments.
...
The size of the All-0 fragment header is generally not a multiple of the L2
Word size. Therefore, an All-0 empty fragment generally needs padding bits.
The padding bits are always less than an L2 Word.

Since an All-0 payload MUST be at least the size of an L2 Word, a receiver
can distinguish an All-0 empty fragment from a regular All-0 fragment, even
in the presence of padding.
...

The total size of the All-1 SCHC Fragment header is generally not a
multiple of the L2 Word size. The All-1 fragment being the last one of the
SCHC Packet, SCHC F/R cannot freely choose the payload size to align the
fragment to an L2 Word. Therefore, padding bits are generally appended to
the All-1 fragment to make it a multiple of L2 Words in size.

The MIC MUST be computed on the payload and the padding bits. The rationale
is that the SCHC Reassembler needs to check the correctness of the
reassembled SCHC packet but has no way of knowing where the payload ends.
Indeed, the latter requires decompressing the SCHC Packet.

An All-1 fragment payload MUST be at least the size of an L2 Word. The
rationale is that the All-1 empty fragment (see {{All1Empty}}) needs to be
distinguishable from the All-1 fragment, even in the presence of padding.
This may entail saving an L2 Word from the previous fragment payload to
make the payload of this All-1 fragment big enough.

The values for N, T and the length of MIC are not specified in this
document and SHOULD be determined in other documents (e.g.
technology-specific profile documents).

The length of the MIC MUST be at least an L2 Word size. The rationale is to
be able to distinguish a Sender-Abort (see {{Aborts}}) from an All-1
Fragment, even in the presence of padding.
...

The size of the All-1 empty fragment header is generally not a multiple of
the L2 Word size. Therefore, an All-1 empty fragment generally needs
padding bits. The padding bits are always less than an L2 Word.

Since an All-1 payload MUST be at least the size of an L2 Word, a receiver
can distinguish an All-1 empty fragment from a regular All-1 fragment, even
in the presence of padding.

...
Bitmap Encoding {#Bitmapopt}
The SCHC ACK that is transmitted is truncated by applying the following
algorithm: the longest contiguous sequence of bits that starts at an L2
Word boundary of the SCHC ACK, where the bits of that sequence are all set
to 1, are all part of the Bitmap and finish exactly at the end of the
Bitmap, if one such sequence exists, MUST NOT be transmitted. Because the
SCHC Fragment sender knows the actual Bitmap size, it can reconstruct the
original Bitmap from the shortened bitmap.

When shortening effectively takes place, the SCHC ACK is a multiple of L2
Words, and padding MUST NOT be appended. When shortening does not happen,
padding bits MUST be appended as needed to fill up the last L2 Word.

{{Fig-Localbitmap}} shows an example where L2 Words are actually bytes and
where the original Bitmap contains 17 bits, the last 15 of which are all
set to 1.
SCHC ACK Header --Bitmap --------|

| Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|

next L2 Word boundary ->| next L2 Word | next L2 Word |

{: #Fig-Localbitmap title='A non-encoded Bitmap'}

{{Fig-transmittedbitmap}} shows that the last 14 bits are not sent.
T --|1|

+---- ... --+- ... -+-+-+-+-+
| Rule ID | DTag |W|1|0|1|
+---- ... --+- ... -+-+-+-+-+

next L2 Word boundary ->|

{: #Fig-transmittedbitmap title='Optimized Bitmap format'}

{{Fig-Bitmap-Win}} shows an example of an SCHC ACK with FCN ranging from 6
down to 0, where the Bitmap indicates that the second and the fifth SCHC
Fragments have not been correctly received.

6 5 4 3 2 1 0 (*)

T --|1|
+-----------+-------+-+-+-+-+-+-+-+-+
| Rule ID | DTag |W|1|0|1|1|0|1|1| Bitmap before tx
+-----------+-------+-+-+-+-+-+-+-+-+
next L2 Word boundary ->|<-- L2 Word -->|

(*)=(FCN values)

+-----------+-------+-+-+-+-+-+-+-+-+~+
| Rule ID | DTag |W|1|0|1|1|0|1|1|Pad| Encoded Bitmap
+-----------+-------+-+-+-+-+-+-+-+-+~+
next L2 Word boundary ->|<-- L2 Word -->|

{: #Fig-Bitmap-Win title='Example of a Bitmap before transmission, and the
transmitted one, for a window that is not the last one'}

{{Fig-Bitmap-lastWin}} shows an example of an SCHC ACK with FCN ranging
from 6 down to 0, where MIC check has failed but the Bitmap indicates that
there is no missing SCHC Fragment.
Fragmentation Header-|6 5 4 3 2 1 7 (*) T --|1|

| Rule ID | DTag |W|0|1|1|1|1|1|1|1| Bitmap before tx

next L2 Word boundary ->|<-- L2 Word -->|

C

+---- ... --+- ... -+-+-+-+
| Rule ID | DTag |W|0|1| Encoded Bitmap
+---- ... --+- ... -+-+-+-+

next L2 Word boundary ->|

(*) = (FCN values indicating the order)

{: #Fig-Bitmap-lastWin title='Example of the Bitmap in ACK-Always or
ACK-on-Error for the last window'}

...

The size of the Sender-Abort header is generally not a multiple of the L2
Word size. Therefore, a Sender-Abort generally needs padding bits.

Since an All-1 fragment MIC MUST be at least the size of an L2 Word, a
receiver can distinguish a Sender-Abort from an All-1 fragment, even in the
presence of padding.

When an SCHC Fragment receiver needs to abort the on-going SCHC fragmented
packet transmission, it transmits a Receiver-Abort. The Receiver-Abort
format is a variation on the SCHC ACK format, creating an exception in the
encoded Bitmap algorithm. As shown in {{Fig-ACKabort}}, a Receiver-Abort is
coded as an SCHC ACK message with a shortened Bitmap set to 1 up to the
first L2 Word boundary, followed by an extra L2 Word full of 1's. Such a
message never occurs in a regular acknowledgment and is detected as a
Receiver-Abort.

The Rule ID and Dtag values in the Receive-Abort message MUST be identical
to the ones used in the fragments of the SCHC Packet the transmission of
which is being aborted.

A Receiver-Abort is aligned to L2 Words, by design. Therefore, padding MUST
not be appended.