Re: OLSRv2 futures

On Wed, Nov 8, 2023 at 2:55 PM Christopher Dearlove <
[email protected]> 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.

AB

_______________________________________________
manet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/manet