Subject: [6lo] "Dev" and "App" terms and peer-to-peer 802.15.4 networks

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 18 Feb 2022 17:42:39 +0100

Dear all,

RFC 8376 (LPWAN Overview) introduces the terms "Dev" and "App". RFC 8724
(the base SCHC specification) reuses and expands a little bit the
definition of these terms.

"Dev" refers to a constrained device (e.g. sensor, actuator, etc.),
whereas "App" refers to a network-side, less constrained element that is a
communication endpoint for Devs.

These terms ("Dev", "App") are exploited in RFC 8724 as an optimization
for SCHC header compression of IPv6 addresses and UDP ports, in order to
allow the same Rule to be used for compression/decompression (C/D) for
both directions.

However, if we try to use SCHC in a different scenario, the same model may
not always be a good fit.

For example, in draft-gomez-6lo-schc-15dot4-01 we are defining how SCHC
can be used for C/D in 802.15.4 networks.

If the 802.15.4 network follows the star topology and the constrained
devices communicate with some network-side element, the terms "Dev" and
"App" apply as well as in the original, LPWAN context.

However, if we consider a mesh 802.15.4 network, where any two peers may
be the communicating endpoints, it is less clear what role would
correspond to a specific device. By "nature", all the constrained devices
could be "Dev".

In such a peer-to-peer scenario, if we want to reuse the "Dev" and "App"
terms, perhaps the only way to do so might be to provide additional
context to each device indicating what role corresponds to device A when
talking to device B, and when talking to any other device. This seems
quite complex, and opens some further questions...

Another approach is using the position of IPv6 addresses or UDP ports
(i.e. use "Source" and "Destination" fields) in packet headers for C/D. In
this case, there is no need to be limited by the "Dev" and "App" terms for
C/D. In this case, however, one Rule is needed for each direction.

Another detail is that the "Uplink" and "Downlink" terms are defined in
RFC 8724 as a function of "Dev" and "App". Therefore, if "Dev" and "App"
are not applicable, Uplink/Downlink are not applicable either. Or they may
have a "local" meaning only for each specific pair of endpoints...

Should we then need to consider other terms like just "Transmit" and
"Receive"?  (This is relevant for C/D of CoAP header fields...)

What are your thoughts?

@LPWAN chairs: since this topic may be related with the LPWAN architecture
effort, I'd be happy to discuss the topic with some slides in the next
interim (next Tuesday), if there is room in the agenda.

Thanks,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 24 Feb 2022 16:59:55 +0100

Dear all,

Last Tuesday, in the LPWAN interim, we discussed the topic of "Dev" and
"App" roles for SCHC header compression in peer-to-peer 802.15.4 networks
(please find it below).

There are two main options:

- Option A: each device needs to know whether it will be Dev or App for each
            possible endpoint it communicates with.

- Option B: allow using "source" and "destination" in the C/D Rules (will
            roughly duplicate the number of Rules).

In the interim, there was a quite common preference for Option A. This
option opens further questions.

Option A may require some sort of negotiation between two endpoints to
determine who is "Dev" and who is "App".

Another question is whether all devices in the mesh share the same set of
Rules (used by/for all nodes in the network) or one Rule concerning two
endpoints is only shared by those two endpoints.

Thoughts?

Thanks!

Carles

PS: some pointers from the last interim are the following:

Minutes:
https://datatracker.ietf.org/meeting/interim-2022-lpwan-04/materials/minutes-interim-2022-lpwan-04-202202221600-01

The materials from the interim, including slides:
https://datatracker.ietf.org/meeting/interim-2022-lpwan-04/session/lpwan

---

From: Laurent Toutain <[email-masked]>
Date: Mon, 28 Feb 2022 18:25:21 +0100

Hi Carles,

I think is it good to keep App and Dev since they are hardcoded in the
Field ID. The goal will be to determine who's up and down. In openschc we
have a tunnel mode and the SCHC packet is sent over an UDP tunnel. This
allows fast prototyping. In the core side, when an IPv6 packet arrives, the
Rule Manager look for a validate rule among all the rules of all he
devices. If a rule matches, the RM returns the Device ID that could be a
LPWAN id (such as lorawan:1234567812345678) or the UDP tunnel (udp:
123.234.123.234:8888) and the packet is sent to the other end.

The other end receives the packet and looks in its own rule manager to find
the reverse rule. Since the rules are the same on both end, the ID
associated to the rule is of course the one of the device.

When the device answer, we can generalize the previous behavior. If the
answer matches a rule and the ID of the rule is the own device, then the
SCHC packet has to be sent to the core (which is identified in case of
Lora, send the SCHC packet on the Lora interface, and in case of UDP to the
IP address of the core learnt in the previous exchange).  I don't say that
it will work in mesh network, since we still consider a single core.
If the matching rule has an id different from the device, then the SCHC
packet is sent to that ID has for the core.

Another remark is that we can break symmetry in the rule. In the example we
gave, for APP* and DEV* Field ID we have always a BI direction. If for
instance, we give DOWN to a DEV* and APP* pair then it will correspond to
the source and destination addresses.

My 2 cents

Laurent

On Thu, Feb 24, 2022 at 5:00 PM Carles Gomez Montenegro <
[email-masked]> wrote:

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