Re: [manet] Problems not reports (was Re: AODVv2 implementation)

Abdussalam Baryun <> Sun, 28 January 2024 23:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0582FC14F5E8 for <>; Sun, 28 Jan 2024 15:14:22 -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 JyB6GFvUaxX8 for <>; Sun, 28 Jan 2024 15:14:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::436]) (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 30B24C14F5E3 for <>; Sun, 28 Jan 2024 15:14:21 -0800 (PST)
Received: by with SMTP id ffacd0b85a97d-33ae3cc8a70so1038454f8f.0 for <>; Sun, 28 Jan 2024 15:14:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706483659; x=1707088459;; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=P8+5yzihy5soral2ySIfTE3KnrPkiwqDAreDlXSEkfc=; b=IR7MvXm/1uxEbgZAQ5wrNsrTOfqh79pbwwg6AGJG+QY+pE2gkhMppIdTiWsIDKy923 hh9F/j6ONNa/gtTgnA0Wd09DMeH9wQShhWxtC1rwOnU9ljBQ9f16c6XR8p2lIdQzVLym Ke00DVVCEMoDMKuwkXu+Qed7f5eggJ2grYtvu2Gb8IjCcoV/YXG19v9agcfnzgHRkVpV JSoVuXi1msyyiqmJX2TTHhH/7YcNzOUpo3j42qLeuElKl/Q/azMDspGV8X9LZPZlfnTe k7RLe2vVdn9ybXFtHEgf4BxmNVj/6U8ZuklhzfFMGO9ZjE/Mf94fE6RwPYtm/BhgGIEh Qznw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706483659; x=1707088459; h=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=P8+5yzihy5soral2ySIfTE3KnrPkiwqDAreDlXSEkfc=; b=BuX6uXIFxobFNLek2uqpm/iz83R3yYV8PDRhZh0zuFSugbG/XZ1xp9DCYEr7RRCPHm Q9A2DeZK89y16w6O+cxx+QYBcul2lWjZlt6uRbdg2Exik6dewdi+nVYLgJMsPPJiGbBg MyTCZarCW2TDwY01zsBSYVE727Tq2UsMSCsWurpMx+bfrcdjrzeUd7yRvQ5+iVCw2yR2 jSs+eTQ51BsMjW0h+vx5pynpMzgss5friiu5eeI9y231S86WQj1Ur5D+94m0o+n1knzx N+CiO5pft5kuaWxBygsZh4b7jHA1Xqn+jyDbFMSKGDzIOrC/eNCXgK1sWksXuBZKcaTC Nk0w==
X-Gm-Message-State: AOJu0YwxeJLyG6zP0tMYDY36kQbNpl3ZSo4pIOvf1GuFx+G8ovosLWoP tJlOezm8H05qMStDKv4mMHJdaxz+ojGVBMrviAO4kmW3LE7D5OjC2F8dbi7ux328+SBsPecRYcp S3hLn7KYlmwlGRANPCoZpNRIj+DEdkIOeObKk/A==
X-Google-Smtp-Source: AGHT+IHZzZPqsSc9fcCRWlYMV6gW52X/+rgpP79tvtrNQJ0YDb33+nBR3cX1epekhViA889xJOSu/BWcSkPOHDVvwew=
X-Received: by 2002:adf:ff82:0:b0:33a:e555:192b with SMTP id j2-20020adfff82000000b0033ae555192bmr2871417wrr.40.1706483658821; Sun, 28 Jan 2024 15:14:18 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Mon, 29 Jan 2024 01:11:49 +0200
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="0000000000004c95d7061009b03f"
Archived-At: <>
Subject: Re: [manet] Problems not reports (was Re: 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 23:14:22 -0000

Hi Brian,

>> 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.
Did you implement AODV RFC3561 or AODVv2_lastest draft, please details?
Also are you reporting a problem? please mention with clarification and
reference to specification related?

> 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.
We need to separate multicast routing from unicast routing, the AODV is
about unicast routing and not multicast,

> 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.
Does AODV refer to nrlsmf within the specification or not?

>>> 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.
Are we mixing both RFC6621 and RFC3561, because I don't think it was
specified in this IETF WG? if it was then please refer me to reference of
While reporting any problem please refer to RFCs or specifications that was
agreed on for such IETF WG or any other Known Group in the World. I will
never discuss about implementation only after knowing references to which
specifications and which known body or practical software known.

>>> 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).
This is multicast problems so I see it not for AODV, please report it as
RFC6621 problems so we can discuss without mixing specifications. Or you
may suggest the use of RFC6621 for some routing/forwarding techniques and
how to use such multicast techniques. However, the last meeting had input
of that Multicast is not a good idea for MANET, so we need NOT to mix
between AODV and Multicast.

> 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.
Again that is for SMF or RFC6621 only or does it require for AODV
specifications, so the example is not understood the relationship with AODV
Secondly, Linux is an Open Source software, and well known which we
can discuss, but does it have AODV implementation or does any one report
arror while using Linux and AODV RFC3561?

Please specify requirements of such software or requirements of such RFC?

Best Regards