Subject: [lp-wan] Ticket #17: Compression Terminology

From: Ana Minaburo <[email-masked]>
Date: Mon, 26 Feb 2018 21:47:09 +0100

<DB> suggest using terms that may be more easily understandable to define
the compressed header fields and the description of the Rule
------------------------------

<SCHC-Authors>
In section 3. Terminology, we have added:
* Compress Residue. The bytes that need to be sent after applying the SCHC
compression over each header field
* Field Description. A line in the Rule Table.

In section 4.3. Packet processing
Compression Rule selection: The goal is to identify which Rule(s) to use to
compress the packet's headers. When doing compression, the Rule will be
selected matching the Field Description to the IPv6 packet header as
described below, when the selection of a Rule is done, the Rule-ID is used
to compress the header.
When doing decompression, in the network side the SCHC C/D needs to find
the correct Rule based on the L2 PDU and in this way, finds the Dev-ID and
the Rule-ID. In the Dev, only the Rule ID is needed to identify the correct
Rule since Dev only holds rules that apply to itself.
The detailed steps for Compression Rule selection are the following:
* The first step is to choose the Fields Description by their direction,
using the direction indicator (DI), so the Fields Descriptions that do not
correspond to the appropriate DI will be ignored, if all the fields do not
have a Field Description with the correct DI the Rule is discarded and SCHC
C/D proceeds to explore the next Rule.
* When the DI has matched, then the next step is to identify the fields
according to field position (FP). If the field position does not
correspond, then the Rule is not used and the SCHC proceeds to consider the
next Rule.
* Once the DI and the FP correspond to the header information, each field's
value is then compared to the corresponding target value (TV) stored in the
Rule for that specific field using the matching operator (MO).
* If all the fields in the packet's header satisfy all the matching
operators (MO) of a Rule (i.e. all results are True), the fields of the
header are then compressed according to the Compression/Decompression
<https://trac.ietf.org/trac/lpwan/wiki/Compression/Decompression> Actions
(CDAs) and a compression residue header may be obtained. Otherwise, the
next rule is tested.

If no eligible Rule is found, then the header must be sent without
compression, in which case the fragmentation process may be required.