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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
