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

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 10:03:42 +0200

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

> ---Nicolas---
>
> 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.
>
> In short, Nicolas asks whether it is possible to have a LoRa?
> <https://trac.ietf.org/trac/lpwan/wiki/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.
>
>
> ---Pascal----
>
> Also, Nicolas indicates that rules must be based on DevEUI, not DevAddr?
> <https://trac.ietf.org/trac/lpwan/wiki/DevAddr>, and appears to have an
> issue with the timers we put in place for the fragmentation process, maybe
> use the frame-counter, 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.
>
>
> Ana: The draft- SCHC defines the way to compress/decompress the header and
> the fragmentation process. The Rule ID size is out of the scope of this
> document, and I think a new document with these ideas and with others may
> be written to complete the need to define the usage of Rule ID.
>
>
> ----------
> IETF 101
>
>
> The technology documents will describe if Rule ID is constrained by any
> alignment, SCHC itself is not aligned to any boundary but bits. The draft
> v-10 does not specify any numbering system, either for Rule ID or any other
> parameter in the header.
>
> A new section in v-10 has been included to describe when the Rule ID is
> needed, the size may be specified in the technology-documents or in a new
> document that needs to be created.
>
> For the moment Rule ID is needed for:
> - In the SCHC C/D context, to identify the compression rule
> - In SCHC Fragmentation to identify the specific modes and settings
> - In the case where SCHC C/D is not possible and SCHC fragmentation is not
> needed at least one Rule ID may be reserved
>
> The Rule ID space has a variable length and may be different from:
> - among Rule IDs
> - between SCHC C/D and SCHC fragmentation
> - among fragments
>
> The figures 9-23 where R is indicating the Fragmentation header size could
> give the idea of a fixed size, but the size of R is variable and can change
> from one packet to another. The size of R is not given because it depends
> on the size of Rule ID, DTag, and FCN.
>
> The idea is to delete R from the draft to be more clear about the size of
> the header. Do we delete this parameter from the draft? or you prefer to
> keep as it is?
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 3 Apr 2018 14:50:42 +0200

Hello Ana,

>> the header. Do we delete this parameter from the draft? or you prefer to

I agree with removing "R" from the draft, as it offers the highest level
of flexibility for handling Rule IDs.

Thanks,

Carles

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 3 Apr 2018 16:25:10 +0200

Me too, I think it will be more clear

Ana

On Tue, Apr 3, 2018 at 2:50 PM, Carles Gomez Montenegro <
[email-masked]> wrote:

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