Re: [manet] AODVv2 implementation

Abdussalam Baryun <> Sun, 28 January 2024 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 385D0C18DB80 for <>; Sun, 28 Jan 2024 00:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.104
X-Spam-Status: No, score=-6.104 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, FREEMAIL_REPLY=1, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 z6R4qYONj-Jo for <>; Sun, 28 Jan 2024 00:15:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (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 E4DF5C14CE4D for <>; Sun, 28 Jan 2024 00:15:18 -0800 (PST)
Received: by with SMTP id ffacd0b85a97d-33aeb088324so146044f8f.2 for <>; Sun, 28 Jan 2024 00:15:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706429717; x=1707034517;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=megF5conLHjwSYXG6RYyWNaBEaDW9YaP976iKRoH8nE=; b=VwrJPUfYx8uk14sGSHD+rAaW4xy1oMBkgBmePU2BodlNP8TLy63essWOwWCTzNgbBY m1Cmn4/i1PSZ+IYMMuZ9jLIo/AY8yyI57ipaQF/JEyfvLIEW+sIwuPG6JHIBPO5eh8YE 2dzPAAZAsuKAUb4KOEbU7EW23vby0irygK0oYo5oJgccDqwBrqpK5s2dFYHbwhclNI1s 9fumgdZAfXiCf2JW7nky8M3YKgZEstA/3zahnXFYmce0tUBx01g/qWxuN1DH9fCF++Rp jPJGEIIKAJNO0O6kBqqZIFnSoqp8fIGjKNBs6TVrWUGxCf/DF7AzVbGlqwaajGiEIXhI E4BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706429717; x=1707034517; 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=megF5conLHjwSYXG6RYyWNaBEaDW9YaP976iKRoH8nE=; b=OtxmHN1v0MjdoakvAvDVgUAfVtoet1GMfX4ybTclIJMcajGhcS9FQuI222afNFhA6r 7Yj2FvZf0Iy2if6sHIRZhaXKOuLLzzf77sShNJqyXiTJDwk4zNPymElWn11rsZkrH0Tq 7lWzdq3kOy7Vf5E+eC9uzUMnXxsBkA41WCebYJr7MpEd41+ozHUUOBnqNgUDOgVHKtMG FrPmOVGadz1R5ARJPQOnzwtiVOIzTIgKc8ttFfQMiXtZW7rtW7AaLdDqH5qGdhrCIv+0 DiT8mBrOtCnpe5cXwxiz+vFG6i3JrkB0+l1tcy6ZHTP+Oh/f31fc4MQmtoeAEEM3LMOQ 2AAw==
X-Gm-Message-State: AOJu0YyipRrDHaJQH5oOtGNLYLI+BwnEYNptT/9CREOzObMin16Lh68p S/6WrYwz1tojSYC9xDnReTKb5rWifwKve7KfqlXfpqvueG3mKSvjgEhK3DbIgRzCrtdo82UUisa GdH03YFCR+/1HCcB5/JWzKBnBxciAXewTOiw=
X-Google-Smtp-Source: AGHT+IEX2mJDJ0VC2ApWrJzaQoUy0jdNy/+C7Fk+WiQ1SEPwefxJP75b7+NS7rz4UcfJtb2GNu+dHc/Y1U+s3037YGE=
X-Received: by 2002:a5d:6804:0:b0:336:905a:bf89 with SMTP id w4-20020a5d6804000000b00336905abf89mr2011114wru.57.1706429716569; Sun, 28 Jan 2024 00:15:16 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Sun, 28 Jan 2024 10:12:48 +0200
Message-ID: <>
To: Donald Eastlake <>
Cc: "" <>, Juliusz Chroboczek <>
Content-Type: multipart/alternative; boundary="00000000000017223f060ffd21e1"
Archived-At: <>
Subject: Re: [manet] AODVv2 implementation
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: Sun, 28 Jan 2024 08:15:21 -0000

Hi Donald,

Thank you for your suggestion but will some one willing to do this
I don't recommend adding AODVv2 implementation only if we adopt AODVv2
draft as standard work, the few participants that discussed the issue are
not willing to implement AODVv2 but if they say they are willing then yes
we can add as we have interest of implement. I suggested first we adopt
that individual work that management before deleted without I know the real
reason for that before.

Usually in IETF the interest of standard_implement comes after adopting
individual_work by some team or group, but I don't think we heard any
interest for implement of AODVv2_new_draft. My reply to the few inputs was
that there are many real implementations of AODV (well known MANET Reactive
Routing) and we not need to have at open sources so I suggested that
adopting is better way for progress as long as the few input are not
reporting any errors regarding RFC3561. If the WG wants to make it as
condition of any adopted work needs to be implemented in open source then
ok we don't object, but I object that few want no adoption until open
source implement which I don't think is the IETF practice (if I mistaken
please clarify).

Therefore, I suggest if no willing_showed_for_AODVv2_implement, or no
adoptation_agreed_on_aodvv2_individual_draft, or no consensus of WG on
adopting with conditions, then I suggest we add implementation of the
following MANET WG experimental RFCs which includes AODV:

RFC3561   (as you suggested)
RFC4728  ( I am interested to implement in Linux)
RFC6621 ( as there is interest for multicast or there was declare of
problems but not reported yet to this WG).

my addition reply comment below,

On Thu, Jan 25, 2024 at 8:07 AM Donald Eastlake <> wrote:

> I think that further exploration of AODVv2 and any AODV
> implementation problems would be useful topics for the MNET WG and that we
> should consider adding that to the Charter.

I will suggest exploration of implementation of OLSRv2 (RFC7181) which is
our proactive_routing_standard, as my last meeting input was that we
evaluate all our work while including different  mobility models (practical
scenarios or practical MANET use cases), and not evaluation general or
random models which are not realistic or which are never practical.

Finally, I will add that all our experimental RFCs are important and have
advantages and disadvantages while changing the mobility model or while
changing the use cases

Best Regards

> On Mon, Dec 4, 2023 at 8:42 AM Adamson, Robert B CIV USN NRL (5592)
> Washington DC (USA) <> wrote:
>> As Justin Dean mentioned, our nrlsmf code can act as tun/tap user-space
>> forwarding engine (and works on Linux (including Android ... although newer
>> Android policies have locked out use of some the the netlink APIs and I
>> haven't tested that in a while), OSX/BSD, and even Windows with use of
>> WinTAP (or whatever it's called).  We have done some stuff with that using
>> our own forwarding tables or with the OS tables but not yet for AODV.  For
>> AODV some sort of extra packet caching could be useful or do something
>> similar with what we do with the Elastic Multicast implementation to flood
>> until the "on demand" route is established.  Related to that the "nrlsmf"
>> code has support for some hybrid policies that can be set related to
>> flooding/forwarding such as token bucket limited forwarding rate until a
>> route is established or flooding a small number (e.g, burst) of packets
>> initially upon a new flow until a route is established.  With a little
>> tweaking, these could be extended a little bit to support other caching
>> strategies if desired.
>> Also, with the code, I have _slowly_ been refactoring code to keep the
>> forwarding plane aspects of the the nrlsmf "engine" distinct and separate
>> from the control plane aspects with the idea in mind to eventually have the
>> forwarding plane code be used independently in a kernel module (or
>> elsewhere) with the various forwarding plane features we see needed for
>> these sorts of protocols including duplicate packet detection, control
>> plane updates like mentioned for AODV2 below, per-flow forwarding state,
>> etc.  It's been _slow_ since my time to work on it is quite limited these
>> days.  Meanwhile, we do get pretty good performance with it in user space,
>> and I know there's improvements that could be made.
>> If the kernel forwarding table is used, there are ways (not pretty) to
>> update by using a pcap socket to monitor packets and do that independently
>> of the actual forwarding.  Again, not pretty or efficient, but a work
>> around until such features are resident in the forwarding engine.  That's
>> one of the things I see needed, including for the Elastic Multicast
>> protocol operation, to have the forwarding plane notify the control plane,
>> at least periodically and/or on an event-driven basis (e.g., new flow
>> detected).  On Linux, I think that ideally would be through a netlink
>> interface and my thought on encapsulating a forwarding mechanism like what
>> "nrlsmf" provides into a kernel module would include that interface.  For
>> example, to support the "per flow" packet processing and such
>> notifications, I created a "Flow Description" data structure that's also
>> used as an index on a modified Patricia Trie prefix-based radix tree (with
>> field wildcarding support) to detect, identify, and classify packet flows
>> for such purposes.
>> Cheers,
>> Brian
>> On 12/4/23, 9:04 AM, "manet on behalf of Henning Rogge" <
>> <> on behalf of
>> <>> wrote:
>> Hi,
>> I was thinking about how to implement AODV2 on a TUN but hit an
>> interesting issue when reading through the "Interaction with the
>> Forwarding Plane" chapter of AODVv2...
>> Chapter 6.4:
>> "AODVv2 needs to update the record of when a route was last used to
>> forward a packet".
>> Does this mean AODV cannot use the kernel routing forwarding system
>> and is expected to do everything in user space? I ask because the
>> "routing cache" (and its statistics for each route) were removed from
>> Linux in version 3.6.
>> Henning Rogge
>> _______________________________________________
>> manet mailing list
>> <>
>> <
>> _______________________________________________
>> manet mailing list
> _______________________________________________
> manet mailing list