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

From: Ana Minaburo <[email-masked]>
Date: Tue, 27 Mar 2018 17:09:46 +0200

On Mon, Feb 26, 2018 at 9:47 PM, Ana Minaburo <[email-masked]> wrote:

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

SCHC Packet

|  Rule ID   +   Comp.  Residue   |
+-----------------------------------------+---------------------+
|        Compressed Header          |      Payload       |
+-----------------------------------------+---------------------+

SCHC Fragment

| Rule ID + DTAG + W + FCN [+ MIC ] |  Comp. Header | Payload |
+-------------------------------------------------+---------
--------------------------+
|                 Fragment Header               |              Fragment
          |
+-------------------------------------------------+---------
--------------------------+

SCHC ACK
<-----ACK Header----->
                     <- T -> 1
+---- ... ---+---... ---+----+-------- ... ---------+
| Rule ID  |  DTag  | W | encoded Bitmap|
+---- ... ---+---... ---+----+-------- ... ---------+

Field Description

Rule 0
+----------------+---+---+--+--------+---------+--------------------+
|     Field        |FL|FP|DI| Value | Match  | Comp Decomp|
|                     |    |     |   |           | Opera. | Action
    |
+----------------+---+---+--+--------+---------+--------------------+
|IPv6 version |  4 | 1 |Bi|   6       | equal  |  not-sent          |