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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Thu, 24 February 2022 16:00 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179473A0A87; Thu, 24 Feb 2022 08:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7lJvbQl86Hq; Thu, 24 Feb 2022 07:59:59 -0800 (PST)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0CD3A0A73; Thu, 24 Feb 2022 07:59:58 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 21OFxtH5010297; Thu, 24 Feb 2022 16:59:55 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 91B2E1D53C1; Thu, 24 Feb 2022 16:59:54 +0100 (CET)
Received: from 10.192.212.146 by webmail.entel.upc.edu with HTTP; Thu, 24 Feb 2022 16:59:55 +0100
Message-ID: <abe6f4c7a41473f210e18dcd5ea2352e.squirrel@webmail.entel.upc.edu>
In-Reply-To: <a9892ff8df546a562e213cffa6cd5877.squirrel@webmail.entel.upc.edu>
References: <a9892ff8df546a562e213cffa6cd5877.squirrel@webmail.entel.upc.edu>
Date: Thu, 24 Feb 2022 16:59:55 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: lp-wan@ietf.org, 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 24 Feb 2022 16:59:55 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/7Khs95JccHJTZu_g4FuGQu_MZz4>
Subject: Re: [6lo] [lp-wan] "Dev" and "App" terms and peer-to-peer 802.15.4 networks
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Feb 2022 16:00:04 -0000

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