Subject: [lp-wan] Ticket #11 ACK Format

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 15:56:54 +0200

Does Padding is needed for ACK?

Ana: Yes because RuleID and bitmap are not always multiple of 8 bits
comment:1 <https://trac.ietf.org/trac/lpwan/ticket/11#comment:1>Changed 5
weeks ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-02-26T13%3A05%3A18-08%3A00&precision=second>
 by ana@…

#11 <https://trac.ietf.org/trac/lpwan/ticket/11> padding in ACK? Laurent

Edgar: comment about the whole padding thing. NB-IOT does not need byte
alignement of the payload. There is padding a Layer 2 anyway. Does padding
need to be here, or should be left to the technology dcument?
JCZ: agree to remove it from the general SCHC document, and leave it to the
technology documents.
Ana: several months ago, decided that padding was best put at the end.
Edgar: padding here is to achieve byte alignement. Also filling a transport
block. leave the latter to the L2. The former may not be needed on some
technologies.
Carles: the SCHC doc could mention the two options (padding between header
and payload or at the end). Leave to the tech document to select.
Edgar: rather have only one specified, and activate it or not. Otherwise
interop will be hard, especially multi-RAT networks.
Laurent: in LoRa? <https://trac.ietf.org/trac/lpwan/wiki/LoRa>, we
(Acklio?) use the FPort byte to carry the Rule ID, in one full byte. Some
form of padding!
Laurent:
Ana: suggests to have a DEFAULT specification in the SCHC document, and
leave it to the technology document to specify differently if it wants!

comment:2 <https://trac.ietf.org/trac/lpwan/ticket/11#comment:2>Changed 4
minutes ago
<https://trac.ietf.org/trac/lpwan/timeline?from=2018-04-03T06%3A46%3A37-07%3A00&precision=second>
 by ana@…
------------------------------

IETF 101

In the new section, we have added that ACK also may use padding.

   1. Padding management

Default padding is defined for the L2 frame with a variable length of
bytes. Padding is done twice, after compression and in the all-1
fragmentation.

In compression, the rule and the compression residues are not aligned on a
byte, but payload following the residue is always a multiple of 8 bits. In
that case, padding bits can be added after the payload to reach the
first-byte boundary. Since the rule and the residue give the length of the
SCHC header and payload is always a multiple of 8 bits, the receiver can
without ambiguity remove the padding bits which never excide 7 bits.

SCHC fragmentation works on a byte aligned (i.e. padded SCHC packet).
Fragmentation header may not be aligned on the byte boundary, but each
fragment except the last one (All-1 fragment) must send the maximum bits as
possible. Only the last fragment need to introduce padding to reach the
next boundary limit. Since the SCHC is known to be a multiple of 8 bits,
the receiver can remove the extra bit to reach this limit.

Default padding mechanism does not need to send the padding length and can
lead to a maximum of 14 bits of padding.

In the section 7.4.3 ACK format
The ACK format includes the encoded Bitmap that will be padded if needed.

7.4.3.1. Bitmap Encoding

The Bitmap is transmitted by a receiver as part of the ACK format.
An ACK message MAY include padding at the end to align its number of
transmitted bits to a multiple of 8 bits.