Subject: [lp-wan] FW: SCHC

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Feb 2018 16:44:24 +0000

With Nicolas’ agreement, cc’ing the list, and sorry for the French.

In short, Nicolas asks whether it is possible to have a LoRa Frame encapsulated in IPv6/UDP/CoAP even if there is no rule ID at all, e.g. for devices that are not SCHC-aware.
My take is that it should be possible, that was something we discussed early in the process. There should be a default rule that does not expect a ruleID in the LPWAN data. I could not find where that is specified in the document; since the spec is for the air protocol, it can be OK that it is not even mentioned, but I’d rather it be. When we talk data model for the rules, we’ll have to be able to configure a default ruleID for a device in any case.

Also, Nicolas indicates that rules must be based on DevEUI not DevAddr, and appears to have an issue with the timers we put in place for the fragmentation process, maybe use the frameCounter, to be discussed.

Additional notes from a F2F talk we had:

-         CoAP rules should be able to place into the CoAP payload information from the NS (e.g. link quality) as well as information from the end device.

-         Rules should have rewritable fields (e.g. a DNS name or an address), and methods to rewrite them may be triggered by either a management console or the end device itself.

I’ll let the authors comment on Nicolas’ points in more details.

Cheers,

Pascal

From: Nicolas Sornin [mailto:[email-masked]]
Sent: vendredi 2 février 2018 16:53
To: Pascal Thubert (pthubert) <[email-masked]>
Subject: SCHC

Bonjour Pascal.
Dans le train j’ai eu le temps de lire le dernier doc sur la compression SCHC

C’est tres clair.
J’aime bien la methode de fragmentation qui ne devrait pas créer trop d’overhead.
D’apres ce que je comprends il n’est pas possible de reduire l’overhead IP a vraiment zero ?
Il faut au minimum envoyer le « RuleID » qui va etre codé sur 4bits pour pouvoir remplacer le header IP meme statique ?
Dans les faits en supposant un device ultra bete qui transmet toujours vers la meme URL/Port , quel est l’overhead final de la couche IP +UDP + COAP ?

Les devices LoRaWAN ont un addresse (devAddr) sur 4 bytes, mais comme plusieurs devices peuvent avoir le meme devAddr, on utilise le devEUI (8 bytes) pour identifier de manière unique un device.
Si plusieurs devEUI peuvent correspondrent au meme devAddr (plusieurs device ont la meme devAddr sur le reseau) on utilse la signature du paquet (MIC) pour les differencier. Cela est possible car tous les devices ont de clées differentes.

Donc on peut vramient considerer le devEUI comme une addresse MAC et l’utiliser pour reconstruire  DEViid
En gros ce que j’essaye de faire passer c’est qu’il faut surtout pas utiliser devAddr dans les rules, mais devEUI (qui est lui-même derivé de devAddr une fois le check du MIC effectué)

JE suis ok pour participer a un document decrivant les particularités de SCHC over LoRaWAN.
En particulier je pense qu’il faut abandonner le concept de timer dans la fragmentation , et utiliser le frameCounter a la place.

Super boulot !

A tres bientôt.

Nicolas.

---

From: Ivaylo Petrov <[email-masked]>
Date: Wed, 7 Feb 2018 10:11:00 +0100

Hello everyone,

I agree that it would be nice to explicitly state how default ruleIDs are
handled. My reading of the SCHC draft is - the ruleID could be of any size
- even 0, which is exactly the same as having a default rule.

I don't see anywhere in the draft DevAddr or DevEUI mentioned as they are
LoRaWAN specific. I found "LPWAN address" for referring to this, which
might be misleading, but my reading of it is - the device unique
identifier, which for LoRaWAN is the DevEUI.

Just my two cents.

Cheers,

Ivaylo Petrov
Chief Architect
ivaylo at ackl.io

www.ackl.io

2 bis rue de la Châtaigneraie,
35510 Cesson Sévigné
FRANCE

Phone: +33 (0)2.99.12.24.14

2018-02-06 17:44 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]>:

> In short, Nicolas asks whether it is possible to have a LoRa Frame
> encapsulated in IPv6/UDP/CoAP even if there is no rule ID at all, e.g. for
> devices that are not SCHC-aware.
>
> My take is that it should be possible, that was something we discussed
> early in the process. There should be a default rule that does not expect a
> ruleID in the LPWAN data. I could not find where that is specified in the
> document; since the spec is for the air protocol, it can be OK that it is
> not even mentioned, but I’d rather it be. When we talk data model for the
> rules, we’ll have to be able to configure a default ruleID for a device in
> any case.
>
>
>
> Also, Nicolas indicates that rules must be based on DevEUI not DevAddr,
> and appears to have an issue with the timers we put in place for the
> fragmentation process, maybe use the frameCounter, to be discussed.
>
>
>
> -         CoAP rules should be able to place into the CoAP payload
> information from the NS (e.g. link quality) as well as information from the
> end device.
>
> -         Rules should have rewritable fields (e.g. a DNS name or an
> address), and methods to rewrite them may be triggered by either a
> management console or the end device itself.
>
>
>
> *From:* Nicolas Sornin [mailto:[email-masked]]
> *Sent:* vendredi 2 février 2018 16:53
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Subject:* SCHC
>
>
>
> Bonjour Pascal.
>
> Il faut au minimum envoyer le « RuleID » qui va etre codé sur 4bits pour
> pouvoir remplacer le header IP meme statique ?
>
> Dans les faits en supposant un device ultra bete qui transmet toujours
> vers la meme URL/Port , quel est l’overhead final de la couche IP +UDP +
> COAP ?
>
>
>
> Les devices LoRaWAN ont un addresse (devAddr) sur 4 bytes, mais comme
> plusieurs devices peuvent avoir le meme devAddr, on utilise le devEUI (8
> bytes) pour identifier de manière unique un device.
>
> Si plusieurs devEUI peuvent correspondrent au meme devAddr (plusieurs
> device ont la meme devAddr sur le reseau) on utilse la signature du paquet
> (MIC) pour les differencier. Cela est possible car tous les devices ont de
> clées differentes.
>
>
>
> En gros ce que j’essaye de faire passer c’est qu’il faut surtout pas
> utiliser devAddr dans les rules, mais devEUI (qui est lui-même derivé de
> devAddr une fois le check du MIC effectué)
>
>
>
> En particulier je pense qu’il faut abandonner le concept de timer dans la
> fragmentation , et utiliser le frameCounter a la place.
>
>
>
> Super boulot !
>
>
>
> A tres bientôt.
>
>
>
> Nicolas.
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: Ana Minaburo <[email-masked]>
Date: Wed, 7 Feb 2018 15:31:00 +0100

Hello Pascal and all,

The SCHC draft must stay as open as necessary for any LPWAN technology. The
case for LORA where the DeviiD may be the DevEUI or timers may be the frame
counters must be part of the corresponding technology document and not part
of SCHC.

Good that Lora can have unique device identifiers, this will be useful to
make compression/decompression.
When a device does not implement SCHC the SCHC-compression is not used and
the packet is sent as it is, fragmentation will only be used when the size
of the L2 PDU is smaller than the IPv6/UDP/CoAP/payload packet. This is the
actual state of the draft.

Ana

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Feb 2018 12:56:56 +0000

Hello Ana :

When a device does not implement SCHC the SCHC-compression is not used and the packet is sent as it is, fragmentation will only be used when the size of the L2 PDU is smaller than the IPv6/UDP/CoAP/payload packet. This is the actual state of the draft.

We add a use case for that whereby the C/D function in the network could still inserts IPv6/UDP and even CoAP based on static rules that could depend for instance on application octets in the payload, or be a fully constant insertion. Basically no rule in the payload, but we can still do something. This could be useful for legacy devices. I have not seen that we abandoned that use case, nor that SCHC cannot serve it. It’s probably a matter of a sentence or 2 describing the use case. Why not do it?

Take care,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ana Minaburo
Sent: mercredi 7 février 2018 15:31
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: Re: [lp-wan] FW: SCHC

Hello Pascal and all,

The SCHC draft must stay as open as necessary for any LPWAN technology. The case for LORA where the DeviiD may be the DevEUI or timers may be the frame counters must be part of the corresponding technology document and not part of SCHC.

Good that Lora can have unique device identifiers, this will be useful to make compression/decompression.
When a device does not implement SCHC the SCHC-compression is not used and the packet is sent as it is, fragmentation will only be used when the size of the L2 PDU is smaller than the IPv6/UDP/CoAP/payload packet. This is the actual state of the draft.

Ana

On Tue, Feb 6, 2018 at 5:44 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
With Nicolas’ agreement, cc’ing the list, and sorry for the French.

Cheers,

Pascal

From: Nicolas Sornin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: vendredi 2 février 2018 16:53
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Subject: SCHC

Bonjour Pascal.

C’est tres clair.

Super boulot !

A tres bientôt.

Nicolas.

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Nicolas Sornin <[email-masked]>
Date: Thu, 8 Feb 2018 14:16:29 +0000

Dear all.
I am very new to that discussion so please excuse my boldness, but here is a naïve proposal that would not disrupt the current spec.
You have already defined a set of rules, rules are identified by a ruleID.
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)
Those rules would never be called in the compressed payload. But if they exist they would be executed by the decompressor.

That allows to easily prepend or append stuff to a legacy device’s payload that isn’t even SCHC enabled as pascal mentionned.

Regards.

Nicolas.

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 08 February 2018 13:57
To: Ana Minaburo
Cc: lp-wan
Subject: Re: [lp-wan] FW: SCHC

The e-mail below was received from outside Semtech, exercise caution
________________________________
Hello Ana :

Take care,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Ana Minaburo
Sent: mercredi 7 février 2018 15:31
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lp-wan] FW: SCHC

Hello Pascal and all,

Ana

Cheers,

Pascal

Bonjour Pascal.

C’est tres clair.

Super boulot !

A tres bientôt.

Nicolas.

---

From: Ana Minaburo <[email-masked]>
Date: Thu, 8 Feb 2018 15:20:52 +0100

Hello,

Yes, we can do it, I can add this use case in the document, Laurent has
already present this at one of the IETF meetings, so we only need to
include this part,

I agree
Ana

On Thu, Feb 8, 2018 at 1:56 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> We add a use case for that whereby the C/D function in the network could
> still inserts IPv6/UDP and even CoAP based on static rules that could
> depend for instance on application octets in the payload, or be a fully
> constant insertion. Basically no rule in the payload, but we can still do
> something. This could be useful for legacy devices. I have not seen that we
> abandoned that use case, nor that SCHC cannot serve it. It’s probably a
> matter of a sentence or 2 describing the use case. Why not do it?
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Ana Minaburo
> *Sent:* mercredi 7 février 2018 15:31
> *Cc:* lp-wan <[email-masked]>
> *Subject:* Re: [lp-wan] FW: SCHC
>
>
>
> Hello Pascal and all,
>
>
>
> The SCHC draft must stay as open as necessary for any LPWAN technology.
> The case for LORA where the DeviiD may be the DevEUI or timers may be the
> frame counters must be part of the corresponding technology document and
> not part of SCHC.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Feb 2018 16:43:41 +0000

This is a great idea, Nicolas,  I really like your formulation. This does not chance the spec, just reserves a rule 0 and a rule -1…
Cheers;
Pascal

From: Nicolas Sornin [mailto:[email-masked]]
Sent: jeudi 8 février 2018 15:16
To: Pascal Thubert (pthubert) <[email-masked]>; Ana Minaburo <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: RE: [lp-wan] FW: SCHC

Dear all.

Regards.

Nicolas.

Take care,

Pascal

Hello Pascal and all,

Ana

Cheers,

Pascal

Bonjour Pascal.

C’est tres clair.

Super boulot !

A tres bientôt.

Nicolas.