[manet] OLSRv2 futures

Christopher Dearlove <christopher.dearlove@gmail.com> Wed, 08 November 2023 12:55 UTC

Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id ADAD3C16F404 for <manet@ietfa.amsl.com>; Wed, 8 Nov 2023 04:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wzyTSEhNuiV5 for <manet@ietfa.amsl.com>; Wed, 8 Nov 2023 04:55:43 -0800 (PST)
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 E3F04C16F408 for <manet@ietf.org>; Wed, 8 Nov 2023 04:55:43 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40806e4106dso4763555e9.1 for <manet@ietf.org>; Wed, 08 Nov 2023 04:55:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699448142; x=1700052942; darn=ietf.org; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=bNmY/GoZGaiBF6UaulPtZyi7eMVr2zX03I4r2wxAYFI=; b=NGNKzyB18Zt+Ql43IJJszO8NGU6mse2cIThxk2Vzo1kvoq1kWIbkOfHetKd0jqMp54 dQ4lCxJ62R/Fw7ly/GYJv5zopVBEdcvKZlbKplKtmdbmrN4GnNG0X26bCfiuPRPwYpgp 5cVH3ufATx+VVXi9vVuPEQyYsEfttTTGHT3YScLA0YVcRzO7WDeUs7omCmYlTzRE3c39 M9HnYQ2xjAsvzV589BsigVNPd3ftYA5B929G/P0rH/1APaC0BZT7VQaTIGkqR4pY3NFF 2WIZW3sObgtunj7rmXRzd3VDTwW8+Bp99aXRJ4nF/G8nzk7WTkBydfecff48s0ct2xhV KEbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699448142; x=1700052942; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bNmY/GoZGaiBF6UaulPtZyi7eMVr2zX03I4r2wxAYFI=; b=Gcu+xxfweRIvvPE+/1lZ+ihDRcGhoL4Sp2+xdZQUxNRMm6MWznZ8GQwKYnBb+EbhCY YUqViT4FNmxEc+7jfrnBQjYKUNl4WI5y6DrMmjlcmAvkYhRkM2GvLcM1U5IQ37mCqj0r oPD6B2bI7bcQJyoMBzn4DmwnCoKwXRDvGEmoA69LxkARSan/82eI+ZriZSuFEvX42tLB eyqVuS+CLSh89/5KV1iv5/LuYylzzvPayGugYlETyVEnXoB2g4H7RJG27ZwS38qj8nW/ 8gO5GqYUVOykaPHCAp1ehRZ3GfrQagKwEwcDtzX3JlGGPlQouNFrWuWYeDCFvfZD3IOc xR8w==
X-Gm-Message-State: AOJu0Yw4j9WW43TX/Ndn6zsVyR00dXq0wUgosFAhxCAQtCExVmEnH1aj slqDiCsM5SHm60e6NfM2Xwr3rH/0Ceo=
X-Google-Smtp-Source: AGHT+IG+N5a0nRUBX5oS2VobukrscrrQZbZsMXV/WJlRgWbFM3R9VKUmWbJzluZsITDJgeQbQtKn2w==
X-Received: by 2002:a05:600c:3104:b0:407:3e94:bcca with SMTP id g4-20020a05600c310400b004073e94bccamr2205943wmo.1.1699448141442; Wed, 08 Nov 2023 04:55:41 -0800 (PST)
Received: from smtpclient.apple (82-132-224-241.dab.02.net. []) by smtp.gmail.com with ESMTPSA id f21-20020a7bcc15000000b0040773c69fc0sm18787698wmh.11.2023. for <manet@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2023 04:55:40 -0800 (PST)
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.\))
Message-Id: <2DF36343-1777-49D2-92B5-DECA6EE87F8F@gmail.com>
Date: Wed, 08 Nov 2023 12:55:23 +0000
To: MANET IETF <manet@ietf.org>
X-Mailer: Apple Mail (2.3774.
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/3gLPwmqkwB8zzDcXZ-jSAO2klaI>
Subject: [manet] OLSRv2 futures
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2023 12:55:45 -0000

To summarise where I think things are with regard to OLSRv2, starting from the easiest - not necessarily the most important (if anything is).

- A simple standards track document that adds permission to for a router to send one or more unscheduled TC messages (probably changing schedule) on learning of a new router in the network (on adding an entry to the Advertising Router Set). However, a complication is that the motivation for this is based on the next item, so how to package the two would be an issue, as there’s a standards track/informative mismatch. Probably end up repeating some material.

- An informative document that explains how OLSRv2 (including NHDP) can be used in ways that allow more efficient use in some scenarios. I have notes somewhere that can expand on some of this. It could be considered as rationale for many of the design decisions. A possibly non-exhaustive list of these features and use is:
  + The ability to work responsively, only sending messages when the situation changes. (This might need the first point above for ideal use.) Assumes a stable network, other than joiners/leavers and the changes they offer/require, and the ability to recognise local changes. (Or continue to use NHDP as usual.)
+ The ability to change parameters dynamically. Enables features such as exponential backoff in stable circumstances, with reversion when changes occur. Similar to the above in some regards.
+ Different parameters on different routers and different interfaces. The former is potentially useful when e.g. some routers are moving rapidly. Ideally some modelling would support this.
+ The ability to set multiple TC interval times at different distances, implementing the concept of fisheye/HSLS routing. Requires some, not easily defined, network properties to be suitable (density largely).

From this point down, there needs to be real motivation to consider them. (Also true above, but I think that might exist.)

- A mechanism to allow a forgetful router to rejoin a network without waiting for timeout of its previous messages. Ranked lower than the above because it’s a change, and compatibility has to be considered.

- A mechanism to allow a router to dump its topology information to a new neighbour for fast full joining. There are lots of questions here - solicited or unsolicited, message format (and how to make 5444 compatible when it expresses the relationship between two addresses, not a characteristic of one address), in HELLO message?

And a long way down, and I don’t think there’s enough commitment from the WG, or even real use cases openly demonstrated:

- Adding reactive features (RREQ/RREP messages) to OLSRv2. In principle this wants a reactive protocol, but as so much would need re-engineering, knowledge of AODV/AODVv2/LOADng might suffice. Although the technical problems with AODVv2 remain issues to be solved here. The basic concept is routers not prepared to do what’s needed proactively (though this has more than one level) but prepared to do some or all of the work reactively (also more than one level). The full generalisation is a form of policy-based routing.

- Adding DTN features, with message store and forwarding. (I’m aware of some IPR here.)

- Routing confidentiality. (I’m aware of some IPR here too.)