Subject: [lp-wan] Ticket #14 Legacy Devices

From: ana minaburo <[email-masked]>
Date: Tue, 17 Apr 2018 14:22:16 +0200

Hello,

Here you will find the link to the ticket:

https://trac.ietf.org/trac/lpwan/ticket/14

The question here is explicitly how to address legacy devices in the SCHC
sublayers. But this implies to give a solution for the Rule IDs question
that comes over again.

The draft version 11
--------------------------

Adds a complete general section 5 for Rule IDs, the Legacy devices are
implicitly added in the fourth bullet of section 5. :

5 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-11#section-5>.
Rule ID

   Rule ID are identifiers used to select either the correct context to
   be used for Compression/Decompression functionalities or for SCHC
   Fragmentation or after trying to do SCHC C/D and SCHC Fragmentation
   the packet is sent as is.  The size of the Rule ID is not specified
   in this document, as it is implementation-specific and can vary
   according to the LPWAN technology and the number of Rules, among
   others.

   The Rule IDs identifiers are used:

   o  In the SCHC C/D context to keep the Field Description of the
      header packet.

   o  In SCHC Fragmentation to identify the specific modes and settings.
      In bidirectional SCHC Fragmentation at least two Rules
      ID are needed.

   o  To identify the SCHC ACK in fragmentation

   o  And at least one Rule ID MAY be reserved to the case where no SCHC
      C/D nor SCHC Fragmentation were possible.

And then in SCHC Compression, section 6.2:

6.2 <https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-11#section-6.2>.
Rule ID for SCHC C/D

   Rule IDs are sent by the compression function in one side and are
   received for the decompression function in the other side.  In SCHC
   C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev
   instances MAY use the same Rule ID to define different header
   compression contexts.  To identify the correct Rule ID, the SCHC C/D
   needs to correlate the Rule ID with the Dev identifier to find the
   appropriate Rule to be applied.

And in SCHC Fragmentation, section 7.2 Fragmentation Tools

   o  Rule ID.  The Rule ID is present in the SCHC Fragment header and
      in the SCHC ACK header format.  The Rule ID in a SCHC fragment
      header is used to identify that a SCHC Fragment is being carried,
      which SCHC Fragmentation reliability mode is used and which window
      size is used.  The Rule ID in the SCHC Fragmentation header also
      allows interleaving non-fragmented
      packets and SCHC Fragments that carry other SCHC Packets.  The
      Rule ID in an SCHC ACK identifies the message as an SCHC ACK.

In the SCHC Fragmentation Formats we have deleted the R parameter, because
when reading the document, R gave the idea of fixed header length in SCHC
Fragmentation formats,  so the section 7.4 Fragments Format has been
changed. The R has been deleted and replaced by Fragmentation Header.

Do you have more inputs for legacy devices?

Ana

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 14:38:39 +0000

Hello all,

Looking at the ticket in the tracker, I quote Nicolas as saying
"We could very simply have a new rule type which is executed at the beginning of the processing of a frame(let’s call it an introduction rule) (if this rule exists in the device’s rule set)
And another rule type that may be executed every time the device’s over-the-air payload has been fully processed by the decompressor (a conclusion rule)"

Since he mentions introduction rule and conclusion rule, I'm assuming he envisages that the LPWAN payload does match a Rule, I.e. SCHC (C/)D is possible.
Therefore the proposed solution
    "the Legacy devices are implicitly added in the fourth bullet of section 5. :
    <snip>
    o  And at least one Rule ID MAY be reserved to the case where no SCHC
          C/D nor SCHC Fragmentation were possible."
Does not apply.

Comments? Nicolas, can you comment first hand about what you had in mind?

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 17 April 2018 14:22
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Ticket #14 Legacy Devices

Hello,

The question here is explicitly how to address legacy devices in the SCHC sublayers. But this implies to give a solution for the Rule IDs question that comes over again.

The draft version 11

Adds a complete general section 5 for Rule IDs, the Legacy devices are implicitly added in the fourth bullet of section 5. :

5<https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-11#section-5>.  Rule ID

6.2<https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-11#section-6.2>.  Rule ID for SCHC C/D

In the SCHC Fragmentation Formats we have deleted the R parameter, because when reading the document, R gave the idea of fixed header length in SCHC Fragmentation formats,  so the section 7.4 Fragments Format has been changed. The R has been deleted and replaced by Fragmentation Header.

Ana

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Nicolas Sornin <[email-masked]>
Date: Tue, 24 Apr 2018 14:59:03 +0000

Hi dominique, hi all !
Let me first try to explain exactly what I had in mind.
Although that is not the main goal of SCHC, I am planning to use SCHC compression/decompression to do a lot more than just UDP header compression.
Basically SCHC compression can also be applied to the payload (for exemple JSON) of the datagram , not just the header.
I think in many cases, we could by simply pre-pending and appending the correct text to the payload of the device , we can transform a legacy device packet into a usable COAP POST for example.
For this I need to be able to append arbitrary text/content before payload , and append arb text after the payload.
Therefore I propose to have a specific introduction/conclusion rule.
The way it works is as follow.
If an introduction rule is present, it is excuted before any other rule and before processing the first byte of the payload.
So the introduction rule is not matched to a ruleID in the payload, if it is present , then each time a payload is received then this rule is executed then the processing of the payload starts.

Same with the conclusion rule.
If the rule exists then once we reach the end of the payload (after matching the last ruleID), then the conclusion rule is executed.

I can present it a different way if you want.
If an introduction rule exists in the rule set, then think that the ruleID of the introduction rule is systematically pre-pended to the device’s payload (implicit)
Same for the conclusion rule.

Have I managed to convey it more clearly this time ?

Thanks !

From: lp-wan [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 24 April 2018 16:39
To: ana minaburo; [email-masked]
Subject: Re: [lp-wan] Ticket #14 Legacy Devices

Outside Email
________________________________
Hello all,

Dominique

Hello,

The draft version 11

   others.

      header packet.

      ID are needed.

Ana

Thank you.

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 16:32:31 +0000

Hi Nicolas,

Thanks for explaining the use case, this is much clearer.
I'm still trying to figure out the minimal deviation we need from the current generic SCHC C/D mechanism in order to make this work.
We ran experiments with a similar objective, albeit using what we called "custom CDAs".
Right now, when decompressing, there is only one rule applied per SCHC Packet. This rule inflates the Compression Residue into the reconstructed Packet with the help of Target Values stored into the rule (or  with the help of special CDAs like checksum, etc).
In our experiments, we had the legacy LoRaWAN payload match the decompression rule using a few bits/bytes (such as Fport and the first payload byte, typically) as the RuledID.
There is no such mechanism as reconstructing through successive passes of multiple rules. It seems that your proposal requires such mechanism.
Maybe some of the technology implementors will come up with a nice unifying model?
Anyway, we might be way outside the scope for this draft. Let's only make sure it does not preclude anything like what you need.
Best regards

Dominique

De : Nicolas Sornin <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 24 April 2018 16:59
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, ana minaburo <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : RE: [lp-wan] Ticket #14 Legacy Devices

Hi dominique, hi all !

Thanks !

From: lp-wan [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 24 April 2018 16:39
To: ana minaburo; [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] Ticket #14 Legacy Devices

Outside Email

Dominique

Hello,

The draft version 11

   others.

      header packet.

      ID are needed.

Ana

Thank you.