Re: [manet] AODVv2 implementation

Hi Henning,

I feel like I need to step into this discussion. First, I agree with you
that I would like to see an implementation of AODVv2. It is needed because
guidance is needed to steer the implementation, with example. Second.
Actually I would like to have access to a working implementation of AODV
(v1), but my team haven't found one (the existing one have degraded into
deprecation and non compilation so we are forced to use OLSRv1/2, (with
success)).
AODVv2 would be implementable should someone have the resources, desire and
skills for it.
I worked as an intern in Charlie's group 20+ years ago now at NRC, and at
the time, they had an AODVv6 implementation. That implementation was
promoted by Nokia's effort to drive IPv6 in general, with inputs from Bob
Hinden being part of the team as well. Me, at the time, while working as an
intern, also worked with HUT in Helsinki who in close collaboration with
Nokia and their IPv6 implementation tried to introduce some additional
research features. Some of this early work was adapted by Ryuji Wakikawa
(now Toyota) into NRCs AODVv6 IPv6 and then Nokia and Toyota NEMO work, and
on which me and Ryuji did some collaboration. As part of this work, I
forked AODV-UU into the IPv6 Usagi branch with those mentioned
research extensions. As for ICMPv6 "hacks", Ryuji and Charlie (and team)
worked quite a bit on that, and made some specific modifications and
submitted a couple of drafts to this group about that. It should be in the
archives. In addition, I know the guys at Ericsson in Stockholm (forgot the
names) were interested in this too. For Nokia, this was part of their core
efforts of Nokia breaking into cellular Networking, where IPv6 was a key
part of that strategy, including that AODVv6 implementation albeit somewhat
on the periphery.

 Anyway, fast forward to the future and about a year ago I was in need of
an ad hoc routing implementation in Linux, and for our use case, reactive
routing would make more sense in terms of topology changes. We couldn’t
find any compilable AODV implementations for Linux, with patches, hacks
etc. It was too far gone. We have instead versions of OLSR and OLSRv2
running in our prototypes, with some inadequacies I must say, but doing the
job just fine.  But sadly an AODV implementation is currently not
available, and neither anTo  AODVv2 implementation as per this thread, but
the feasibility should not be in doubt. But again, even pushing a sponsored
draft towards RFCx should have a current implementation. I am sorry to say
this, but even here you need a big car, and my Outback is not that kind of
car.

To get to the point, someone with muscle and money needs to step up.

Thanks,
Anders

On Mon, Nov 27, 2023 at 7:11 AM Henning Rogge <hrogge@gmail.com> wrote:

> On Sat, Nov 25, 2023 at 3:32 PM Juliusz Chroboczek <jch@irif.fr> wrote:
> >
> > Hi Charlie,
> >
> > > I do not have an implementation.
> >
> > It is my understanding that Henning has concerns about the
> implementability
> > of AODVv2.  Given Henning's track record, I recommend that we should not
> > dismiss his concerns.
>
> Hi Juliusz, hi Charlie,
>
> I would not say that AODV (v1 or v2) is impossible to implement (some
> people have done it), but it's much harder to do on most general
> purpose operation systems than OLSR(v1 or v2) because of its necessary
> interaction with the forwarding plane.
>
> I think I have seen three AODV (v1) implementations in my life, two of
> them NS-2 emulator patches (I don't trust NS-2 code at all, most
> routing implementations take a lot of liberties that cannot be done on
> real software/hardware)  and one of them Linux... the Linux one was a
> mess, completely with a Linux Kernel module for a kernel 5+ years old
> (which made it in fact unsable).
>
> It seems no one ever took the time to seem if there is a good way to
> write the "ICMP-trickery/route-status-monitoring" in a clean way,
> which is most likely also the reason why I never heard about an IPv6
> AODV implementation, which would need a different ICMPv6 based hack.
>
> That's why I would like to see a running implementation of AODVv2...
> it's the only way to validate that you can build interoperable
> implementations from the current draft. It's also the only way to test
> if the metric integration in AODVv2 is working reasonably well,
> because I don't think ANY routing protocol will do us good with
> hop-count metric on any wireless radio that supports multiple data
> rates.
>
> Henning Rogge
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>