Re: [manet] AODVv2 implementation

"Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <> Mon, 04 December 2023 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CB69C14F61B for <>; Mon, 4 Dec 2023 05:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 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, 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 7RqbsMZeNWv6 for <>; Mon, 4 Dec 2023 05:42:17 -0800 (PST)
Received: from ( [IPv6:2001:480:a0:f003::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78660C14F603 for <>; Mon, 4 Dec 2023 05:42:17 -0800 (PST)
Received: from pps.filterd ( []) by ( with ESMTP id 3B4DgFYh058959; Mon, 4 Dec 2023 13:42:15 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=s2.dkim; bh=/yaJF2wYVGwQDFmMm5ne5ryOfsUfhSpSNY1ynNRM0V8=; b=kj/F/tQ4e6HYGmD7DQuIW6sf+YpmsXLqm9bkGUD3FP+pggJznU9Hw5PyoIJDhaA2wDVS AftZJBMmA6IdDGMvNiWhDQJQBnD5rhuFURX/UGx519KRiqbtbvDtymMkuGgD9GM1SnLB U8/FNzmpvl1zGpYut1CnaNMHS1Ox7Q8dYva9GOWkvCjewCi2V6uT7w5GqvYtagt9Ttfl ibaAj3Rsyej263vI5/jUH7GVpV7blZa65oGCljil4Q12cGXmaaSTKddeYzlqrWlqtElY Tj+b5xvb/ZJOnrv4iQ/iU2L81ZuDXq9cTp9VJIzGT380yx/fY3QuENVe2NNa4FfKQ05o 7A==
Received: from pps.reinject (localhost []) by (PPS) with ESMTPS id 3uqun68tht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2023 13:42:15 +0000
Received: from ( []) by pps.reinject ( with ESMTP id 3B4DgETK058944; Mon, 4 Dec 2023 13:42:15 GMT
Received: from ( [IPv6:2001:480:20:404:0:0:25:114]) by (PPS) with ESMTPS id 3B4DgEiS058931 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2023 13:42:14 +0000
Received: from G1950SRVB2100.WDC.GEN.NRL.NAVY.MIL ( []) by (8.15.2/8.15.2) with ESMTPS id 3B4DgEAT012261 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Dec 2023 08:42:14 -0500
Received: from G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL (2001:480:20:2031:31::201) by G1950SRVB2100.WDC.GEN.NRL.NAVY.MIL (2001:480:20:2031:31::206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Dec 2023 08:42:13 -0500
Received: from G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL ([fe80::d1d8:a0fa:8863:95de]) by G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL ([fe80::d1d8:a0fa:8863:95de%7]) with mapi id 15.01.2507.035; Mon, 4 Dec 2023 08:42:13 -0500
From: "Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <>
To: Henning Rogge <>, Juliusz Chroboczek <>
CC: "" <>
Thread-Topic: [manet] AODVv2 implementation
Thread-Index: AQHaH2+6wC1aCLd9KkSB1PdGh++qn7CLbVqAgAKpUwCAAS/BgIAA49KAgAkMPYD///oBAA==
Date: Mon, 04 Dec 2023 13:42:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on
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: Mon, 04 Dec 2023 13:42:21 -0000

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.



On 12/4/23, 9:04 AM, "manet on behalf of Henning Rogge" < <> on behalf of <>> wrote:


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