Subject: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood

From: Aurélien Ribon <[email-masked]>
Date: Fri, 15 May 2009 10:40:38 +0200

Hello,

I am currently writing a full hardware implementation of OLSR v1 on a FPGA.
Everything is going well but there is one point that is not totally clear in
my mind.

When the draft says (for TC, MID and HNA message processing) :

     1    If the sender interface (NB: not originator) of this message
          is not in the symmetric 1-hop neighborhood of this node, the
          message MUST be discarded.

Does it mean :

Look in the Link Set and see if there is a tuple where

L_neighbor_iface_addr == sender iface addr
AND
L_SYM_time >= currentTime

?

Thanks,
Aurélien Ribon

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 15 May 2009 16:55:42 +0100

Two points:
 
I think the L_neighbor_iface_addr condition should also include
that L_local_iface_addr (of the same tuple) is the local interface
address on which the message (packet) was received.

Agreed that may not be exactly what it says, but as you say, it's
not quite clear. But I think that's theoretically better. But in
almost all cases it's not going to make much difference, and in most
cases none at all.
 
I also think your >= should be >.
 
OK, in practice that may make little or no difference. But for expiry times
you want to remove at the time (removing "at the first time after that time"
is not well-defined) and you want to do the same for other timers for
consistency I think.
 
Now I have to admit I haven't checked the second point with RFC 3626. I am
fairly sure OLSRv2 adopts the above approach (but OLSRv2 is in general tighter
on these sorts of things - on link quality thresholds for example). It also
handles the first point subtly differently too.

--
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aurélien Ribon
Sent: 15 May 2009 09:41
To: [email-masked]
Subject: [manet] OLSR v1 - Question about the symmetric 1-hop neighborhood

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Hello,

I am currently writing a full hardware implementation of OLSR v1 on a FPGA.
Everything is going well but there is one point that is not totally clear in my mind.

Does it mean :

?

Thanks,
Aurélien Ribon

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

---

From: Bruce Simpson <[email-masked]>
Date: Tue, 19 May 2009 10:58:43 +0100

>           message MUST be discarded.
Look here in method  TopologyManager::event_receive_tc() :-
http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/topology.cc?rev=1.5

and look here in method Neighborhood::is_sym_neighbor_addr() :-
http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/contrib/olsr/neighborhood.cc?rev=1.4

Of course, that lookup could probably get speeded up if the interface ID 
where the message was received is known.

cheers,
BMS

---

From: Aurélien Ribon <[email-masked]>
Date: Tue, 19 May 2009 14:09:06 +0200

Thank you all for your answers. But that leave me with one more question.

Chris, you said :
*
*

> * I think the L_neighbor_iface_addr condition should also include*
> * that L_local_iface_addr (of the same tuple) is the local interface*
> * address on which the message (packet) was received.*
>
> * Agreed that may not be exactly what it says, but as you say, it's*
> * not quite clear. But I think that's theoretically better. But in*
> * almost all cases it's not going to make much difference, and in most*
> * cases none at all.*
>

I agree with you, but Bruce said :

*Look here in method  TopologyManager::event_**receive_tc() :-*
> *
> *
> * and look here in method Neighborhood::is_sym_neighbor_**addr() :-*
> *
> *

So, that means that we should test the neighbor tuple and not the link
tuple. But the draft do mention that :

Wouldn't the "not originator" expression mean that we only do care about the
connectivity of only one interface ?
Looking at the neighbor tuple is the same as evaluating all the interfaces
at the same time, since a neighbor tuple is updated on every associated link
tuple update/record, am I wrong ?

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 May 2009 09:46:26 +0100

>  So, that means that we should test the neighbor tuple and not the link tuple. But the draft do mention that :
> 
> Wouldn't the "not originator" expression mean that we only do care
> about the connectivity of only one interface ?

The "not originator" refers to something else - to that when a message
goes from A to B to C its originator is A, but C cares about B, not A.
That doesn't make the conclusion above right or wrong.

> Looking at the neighbor tuple is the same as evaluating all the
> interfaces at the same time, since a neighbor tuple is updated
> on every associated link tuple update/record, am I wrong ?

The Neighbour Tuple is updated each time. (The very precise details
I'd have to check up on, as it's OLSRv2's behaviour that I'm now most
familiar with.) But the subtlety happens in cases such as the following.

(a) A has interfaces A1, A2, B has interfaces B1, B2. There's a symmetric
link from A1 to B1 and an asymmetric link from A2 to B2. You receive a
TC message at B2 from A2, should you discard it?

(b) A has interfaces A1, A2, B has interface B1. There's a symmetric
link from A1 to B1 and an asymmetric link from A2 to B1. You receive a
TC message at B1 from A2, should you discard it?

(c) A has interface A1, B has interfaces B1, B2. There's a symmetric
link from A1 to B1 and an asymmetric link from A1 to B2. You receive a
TC message at B2 from A1, should you discard it?

I wouldn't incidentally rely on any specific implementation as defining
the right answer, although of course it can be useful.