[6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches

Carles Gomez Montenegro <carles.gomez@upc.edu> Thu, 13 July 2023 09:42 UTC

Return-Path: <carles.gomez@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 D8077C15109C for <6lo@ietfa.amsl.com>; Thu, 13 Jul 2023 02:42:08 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=upc-edu.20221208.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTBgsZO7ICRa for <6lo@ietfa.amsl.com>; Thu, 13 Jul 2023 02:42:07 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F40EC15108F for <6lo@ietf.org>; Thu, 13 Jul 2023 02:42:07 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3fc03aa6e04so4107745e9.2 for <6lo@ietf.org>; Thu, 13 Jul 2023 02:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20221208.gappssmtp.com; s=20221208; t=1689241326; x=1691833326; h=to:subject:message-id:date:from:reply-to:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=EMX8qbQyScuYfGDfgzORsyAGh/HDK/DRJeNrM8iggx0=; b=H1ZB73ighzsD/48ud/Z4FxJp8D9AjVeziTb0qLHzuKaoFsPVDCe7g/Q90i1OHWIh/0 KnJORg7seuv2A0UEyCXnqSXGTF7LFjFuLwqKssVhclpZ9u8St3W1Qi8+8MxUECp0CCSP WLjTRt3hq+0dUG2ZKx1O3bHfxRYPGKQbsxtDmxlY4StAHtM9u9Mz1C1tEgSholIb3uzz c1HJC3V6BUmSaAOvvmT4QTINU+5cpnzAfuj5ZLD9Hlp7iTdTEPDZ9EA/nbeHVawjLpni Y79Rr2p4vDtws9UZDQ2EeVfCViITS42+xAMF8LbPUU67UdPQh79t5td55hrXpLm+2Ny8 Z5oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689241326; x=1691833326; h=to:subject:message-id:date:from:reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EMX8qbQyScuYfGDfgzORsyAGh/HDK/DRJeNrM8iggx0=; b=FZreE3EnaSeVvhnk18jrjnl/fIHoFWmJ46K8KrJppyxX6d1me70uu2SArD7ptjUxtD 5RD7rjKWdDjAv7Vw8tV34RqTE8oFANSk5yQWQI1YNlOogIKb/XndXTP7vA50iWme6wK3 1Q48TYWRKdp5sgugApql+nc5Z2Fx4UyTYHm+2T9bkaqTSazihwdUgUWNbJ5fv0rH4Yvu my63gjsM1m/ie5/xHbF3PChe2Vk0e6hAC6I8y+T7/Of8d6Fpgq188Y4unI/n4vEmx4Ab YOCzG8uhv/jdIFqwF84QSU2KNn0R8czC7T7t7VeNWJZRomyUgy8PwYdlOr8XNUreZ0Pa tgFA==
X-Gm-Message-State: ABy/qLYDa6ojjFXCjM7xn+ho8zZBUMI91heLepVo/cXPsHph/G4XS1X0 nrwxLmonINtXDuuN2HF/EVLy2+cxiOniuUOsCz9+aq0+d6KqzL45Xuw=
X-Google-Smtp-Source: APBJJlFcrIezyvocjSynGquXniGq0xQ3uCCknFkaLrV4joYbhG3onWI9rbpK1mQDEku31rCcirMgogwx1NOZJVUrLF0=
X-Received: by 2002:a7b:c4d6:0:b0:3fb:ffef:d058 with SMTP id g22-20020a7bc4d6000000b003fbffefd058mr937920wmk.0.1689241325676; Thu, 13 Jul 2023 02:42:05 -0700 (PDT)
MIME-Version: 1.0
Reply-To: carles.gomez@upc.edu
From: Carles Gomez Montenegro <carles.gomez@upc.edu>
Date: Thu, 13 Jul 2023 11:41:54 +0200
Message-ID: <CAAUO2xxVKzXT0qneAQvkn71w=DSuv5HgFQW0Mo7Ksu4VqJ3RbQ@mail.gmail.com>
To: 6lo@ietf.org
Content-Type: multipart/alternative; boundary="000000000000284b3206005b25bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/-d6XC2VINVSMNXwZix-K4-OYpqE>
Subject: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Jul 2023 09:42:08 -0000

Dear 6lo WG,

As you may have noticed, there are currently 3 approaches to enable
route-over multihop in draft-ietf-6lo-schc-15dot4. A preliminary analysis
of pros and cons of each one is provided in Appendix B of the draft, in -02
[1].

Summarizing:

- “Straightforward Route-Over” incurs the lowest header overhead, as it
only requires the SCHC Dispatch (1 byte). However, it is the most demanding
approach in terms of memory usage, since all network nodes (including
intermediate nodes) need to store all the Rules in use in the network.
Therefore, it will be suitable for rather static, small networks and/or
where nodes have sufficient memory.

- “Tunneled, RPL-based Route-Over” incurs greater header overhead (with
some cases in the order of 12-16 bytes, although it may be more depending
on e.g. the number of hops), but only the endpoints need to store Rules,
and only those Rules used for the end-to-end communications such endpoints
are involved in. It requires the use of RPL, in its non-storing mode.

- “Pointer-based Route-Over approach” also only requires the endpoints to
store the Rules they will need to communicate with other endpoints. The
header overhead contains a fixed 3-byte part and a variable one. The latter
depends on the kind of interactions between endpoints: a) in special cases,
it could be even zero, b) in intranetwork communication it could be 2-8
bytes (depending on how IPv6 addresses are built) and c) if interactions
with various possible external networks it could be up to 16 bytes. This
approach does not require the use of RPL, and is also compatible with RPL
storing mode.

There may be further subtleties to consider.

A question that has been raised is whether we might want to keep all three
route-over approaches in the document or reduce the number of such
approaches. As authors we are in favor of enabling all of them, since they
may be complementary, and the most suitable one can be chosen for each
deployment.

Thoughts? Would you have any preference?

Thanks,

Carles and Ana (document authors)

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-schc-15dot4-02#name-analysis-of-route-over-mult