Re: [6lo] [lp-wan] "Dev" and "App" terms and peer-to-peer 802.15.4 networks

[Laurent Toutain <[e-mail]>]

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 <
[e-mail]> wrote:

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