Re: [manet] OLSRv2 futures

Abdussalam Baryun <> Wed, 08 November 2023 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA1A9C170613 for <>; Wed, 8 Nov 2023 05:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Status: No, score=-7.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z-pyiY5EVEYI for <>; Wed, 8 Nov 2023 05:08:43 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (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 (Postfix) with ESMTPS id 19686C17C890 for <>; Wed, 8 Nov 2023 05:08:43 -0800 (PST)
Received: by with SMTP id 38308e7fff4ca-2c5039d4e88so93890651fa.3 for <>; Wed, 08 Nov 2023 05:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699448921; x=1700053721;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+WjUl/f78/prPOAs66Kuuy3lD0M2dR7wWOPyl/nt1pM=; b=jtp9lG1TiBACDoSYxBdXpEATyIY9GU+9+uv3qQ36HiQ4gONNCbGjr3f5bdXLHQeguS WeH/T7zOjPVFN0HSJidXCMSZ61n44xMPinvhX3ylLZ1y/HNRkwox+FucmQ+PFPEENjrc WChgqlfPBcxlSwq0Xx/pKWMTRdKWOFLbtJD27y9h/E1ZX9MmFUONkOa8gi0CaqwOX1j/ X97KikKweHSrljz0gPIyLYaECB06+5PHpcVoRl1xRHKgg0DttdsiWuFqy2FoP/bYxiL6 fuvqr0E5m1wCf1nTXYC/eH6rvVqYP1fjRv4+/+WL6hDYzeCTXBTXOkw79eCTaLDZFGde SOaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699448921; x=1700053721; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+WjUl/f78/prPOAs66Kuuy3lD0M2dR7wWOPyl/nt1pM=; b=Nfdb0rghTD+aFCR3+VQI8Vi7qiq7lYCKvmVrBVNy4tHJdsaQJIgWwzK0REcAMIesFq L2D4BGVY8E/kQ3DKIFIwe29Pk4WheMceoSjsS62O4qN5FmjgkGOKYiZrRkSpUmFXtHdh VX34ET0R0S9LOq9Wm6qeWJacQQuxSUV8rZ/MNXzQPlS8MgHyjmrxskqqJv7v7bKgXM2F +ljRbukeoI5WqqkNjXMjvTL5ZjGYZVPmMP7UQl01u45M5zicjGeabkkhBcrz7Lpi/8wV dm1UHEFxohnDHfvzksu71X1sS7ru7v4dD5WnSy5LbWHZ07s29ACCEtJol9BL3J53SnqF IdkQ==
X-Gm-Message-State: AOJu0YzswMWfEvlz7oLFupWIvKGnC0uIELyvE+9PLeegW4NDXL3Vfc5l 0GkS52mAJ26jvjw0fRLKlYoHfIQ6P6HxtFWY26S5zafW
X-Google-Smtp-Source: AGHT+IGWNP/9JWlgNTUcQco7nXL17nlvyKIHmrIlXzs8n4rtI4d2wOqDU0R6voHc73RGxa7nMcWYTUUDSZ8DM7qhrWM=
X-Received: by 2002:a2e:a312:0:b0:2c5:1542:6147 with SMTP id l18-20020a2ea312000000b002c515426147mr1745147lje.15.1699448920800; Wed, 08 Nov 2023 05:08:40 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Wed, 08 Nov 2023 14:56:47 +0200
Message-ID: <>
To: Christopher Dearlove <>
Content-Type: multipart/alternative; boundary="0000000000003d04b50609a3c915"
Archived-At: <>
Subject: Re: [manet] OLSRv2 futures
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Nov 2023 13:08:43 -0000

On Wed, Nov 8, 2023 at 2:55 PM Christopher Dearlove <> wrote:

> 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.

I think the AODV algorithm is same for all just few functional changes
among those versions, however, DLEP can help to trigger routers to do what
is needed.