Subject: Re: [manet] Default metric in OLSRv2

From: "Tan, Chiang Kang " <[email-masked]>
Date: Thu, 15 Oct 2009 12:14:23 +0100

>Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a 
>conference about military communications. There were a couple of
presentations 
>which used OLSR as a mesh net protocol and they can be summarized as: "OLSR

>does not work well". When I tried to get some more facts about this I
quickly 
>recognized that all of them used hopcount metrics "because it's the default

>described in the RFC".

Many apologies if my question is a bit off from your original post. So
happened that I'm seeing this I believe a hop count related problem in the
OLSR protocol I'm using in my testbed environment. My observation in one
scenario is a source node uses a forward path that is different from a
return path from a destination node, both paths 3 hops apart. So my question
is does this commonly happen using OLSR with hop count as a metric?

I'm not absolutely certain if this is giving me the problem I'm
experiencing, but I'm interested to know if this is also one of those "does
not work well" points presented to you recently.

Thank you.

Regards,

Chiang 

****************************************************************************
Please consider the environment before printing this email.
****************************************************************************
Thales Research and Technology (UK) Limited DISCLAIMER:  The information
contained in this e-mail is confidential.  It may also be legally
privileged.  It is intended only for the stated addressee(s) and access to
it by any other person is unauthorised.  If you are not an addressee, you
must not disclose, copy, circulate or in any other way use or rely on the
information contained herein.  Such unauthorised use may be unlawful.  We
may monitor all e-mail communications through our networks.  If you have
received this e-mail in error, please inform us immediately on +44 (0)1293
575987 and delete it and all copies from your system.  We accept no
responsibility for changes to any e-mail which occur after it has been sent.
Attachments to this e-mail may contain software viruses which could damage
your system.  We therefore recommend you virus-check all attachments before
opening.  The registered office of Thales Research and Technology (UK)
Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX.  Registered in England No. 774298.
****************************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Oct 2009 10:40:44 +0100

> My observation in one

Yes.

Let's consider the simplest interesting network, one with four nodes
in a square, with no diagonal connections, ABCD round the square.
I'm going to discuss two hop paths, obviously this generalises to
more than two hops.

Actually any node can send information "left" or "right" to its
opposite node, because it can use two hop information directly
without considering MPRs. But use of MPRs is preferred by RFC
3626 (and in OLSRv2) so we'll assume that.

What that means is that if A is routing to C it will choose
B as a preferred route if it has a B to C link in its Topology Set,
i.e. (assuming only MPR selectors are advertised in TC messages)
if C selected B as an MPR. A will choose D as a preferred route
if C selected D as an MPR. C must choose one or the other. It may
choose both if there is more to this network, in which case A has
a choice, rather than its choice being dictated by C.

But in general that means choices. Choices can't be avoided (with
extra nodes hanging off B and D, C must choose both as MPRs).
Sometimes those choices are made (in this case) by A, sometimes
by C, sometiimes (in more complicated cases) by A and C and by
other nodes on the path between them.

Going back to the square, we can in that case make consistent
choices (other than by extra signalling, which rather defeats
the object of the OLSR exercise) only by consistent MPR
selection. In general that's not possible. In the square case
it's not impossible, some coordination can be done. But without
coordination everyone might pick MPRs such that all traffic
flow over two hops is, say, clockwise.

There's also a question as to whether this matters, and if so
why. But if that is a desirable feature then you need either
a significant modification of OLSR (and not having considered
it I don't know how easy it would be, but my guess is that it
would be tricky with limited topology, easier with fuller
topology) or a new routing algorithm. (And how maintainable
it is in the face of dynamism would be another question.)

And finally, if a wide range of metrics is used, and metrics
are the same in both directions, then this gets less likely
with metrics (as it requires what becomes more of a coincidence
of there being equal length routes). But with unidirectional
metrics (as we intend to add) it becomes quite likely with
metrics also.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************