[6lo] "Dev" and "App" terms and peer-to-peer 802.15.4 networks
Carles Gomez Montenegro <carlesgo@entel.upc.edu> Fri, 18 February 2022 16:42 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 91CDE3A0997; Fri, 18 Feb 2022 08:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 5kMluXkrVYFB; Fri, 18 Feb 2022 08:42:43 -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 013443A005F; Fri, 18 Feb 2022 08:42:42 -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 21IGgcQM003794; Fri, 18 Feb 2022 17:42:38 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 5A8061D53C1; Fri, 18 Feb 2022 17:42:38 +0100 (CET)
Received: from 79.158.126.50 by webmail.entel.upc.edu with HTTP; Fri, 18 Feb 2022 17:42:39 +0100
Message-ID: <a9892ff8df546a562e213cffa6cd5877.squirrel@webmail.entel.upc.edu>
Date: Fri, 18 Feb 2022 17:42:39 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: lp-wan@ietf.org
Cc: 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]); Fri, 18 Feb 2022 17:42:38 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/F8j8wMDhxwE2P-lc8ENh9poqIjk>
Subject: [6lo] "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: Fri, 18 Feb 2022 16:42:49 -0000
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] "Dev" and "App" terms and peer-to-peer 802.… Carles Gomez Montenegro
- Re: [6lo] [lp-wan] "Dev" and "App" terms and peer… Carles Gomez Montenegro
- Re: [6lo] [lp-wan] "Dev" and "App" terms and peer… Laurent Toutain
- Re: [6lo] [lp-wan] "Dev" and "App" terms and peer… Carles Gomez Montenegro