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

From: Ana Minaburo <[email-masked]>
Date: Sun, 11 Feb 2018 21:41:15 +0100

Hello

I've created a ticket (#14) in order to discuss this possibility.

I would like to conserve the idea that the Rule ID is free to the
implementation to know which rule is which one. If we introduce the concept
about that we reserve this number or another to some objectives we will not
finish defining all the reserved Rule ID needed for some cases.

Nevertheless, I agree to introduce a paragraph for Legacy devices.

Ana

On Fri, Feb 9, 2018 at 5:43 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 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.
>
> 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] <[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 :
>
>
>
> 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]> wrote:
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
>