Subject: Re: [manet] OLSR questions

From: [email-masked] (Ioannis C Avramopoulos)
Date: Tue, 12 Mar 2002 15:20:24 -0500 (EST)

Dear Laurent,

thank you for your clarifications. I still have some questions. See below.

Ioannis
 
>> - What are the advantages of having a LOST_LINK type over having no
>>such type (version 4 for example did not have such link type)?

>It allows quicker update of one hop and especially two hop
>neighborhood. A node announcing a neighbor loss allows its neighbors
>to remove the link (without waiting for expiration) from their 2-hop
>neighbor set.

Lets assume that initially nodes A and B have a bidirectional link and at
some time the link becomes unidirectional from A to B (A->B). After the
timeout of A expires and A has not received any HELLO from B, A may instead
of listing B with link type LOST_LINK may not list B at all. We can simply
add a rule in B to consider the link with A unidirectional if B is not
listed in A's HELLO (instead of considering A as a unidirectional link if B
is listed as LOST_LINK) and therefore we don't have to wait for the
timeout.

Similarly if we have another node C that is a neighbor of A and a 2-hop
neighbor of B (C-A-B) when the topology becomes C-A->B if B is not listed
in A's HELLO we may simply add a rule in C that purges B from the 2-hop
neighborhood.

If the aforementioned rule is added I still don't see why a LOST_LINK type
is beneficial.

>> - Why should a node have multiple interfaces all running the OLSR
>>protocol?

>several radio interfaces with directional antennas (and possibly same
>radio channel).

>> - Does the IEEE 802.11 specification make any provision for the
>>scenario of a node possessing multiple interfaces?

>No. It is in charge of the routing layer.

If you have several interfaces with directional antennas then it is
possible that they overlap. Packets that are transmitted over all
interfaces simultaneously will collide at nodes that are within the
overlap. Since IEEE 802.11 does not arbitrate access to the broadcast
channel and it is the responsibility of the routing layer then the routing
layer should deal with such cases.

I have one more general remark. I believe that considering multiple
interfaces makes the presentation of neighbor sensing not very
straightforward (in version 4 for example where multiple interfaces are not
considered the presentation is straighforward). Maybe you could consider
presenting neighbor sensing separately for the cases of single and multiple
interfaces and more clearly state the objectives and assumptions of
multiple interfaces. But this is just my opinion...

Thanks again
Ioannis

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Laurent Viennot <[email-masked]>
Date: Mon, 18 Mar 2002 10:19:03 +0100

Dear Ioannis,

Some clarifications to your second mail... 

laurent

 > is listed as LOST_LINK) and therefore we don't have to wait for the

Be carafull, Hellos are partial. This means that not being listed in one
Hello does not mean you won't be listed in another. This means that
the rate of Hellos is independent from how often a neighbor interface
is advertised.

An important reason for using partial Hellos is to avoid splitting
Hello messages in several MAC packets: this would increase the
probability of loosing Hello messages (if one MAC packet is lost, then
the whole message is lost even if you have received parts of it).

 > layer should deal with such cases.

I mean that the network layer is in charge of connectivity between the
interfaces. The IEEE 802.11 specification will treat them as if they
were on different nodes, thus providing some medium access arbitration.

 > multiple interfaces. But this is just my opinion...

You are right, multiple interfaces makes neighbor sensing more complex
but we are writing a specification supporting multiple
interfaces. Some ambiguity could arise in a document that would
present twice neighbor sensing. However, we have tried to introduce
concepts in a pedagogic order for readability but the priority is the
clarity of the specification.  If you want some material about
understanding OLSR design, take a look at
http://hipercom.inria.fr/olsr/

Notice some weird situations that may occur with multiple interfaces
as discussed in other mails on the list.

If you still have questions, we are pleased to answer them.

laurent

---

From: Laurent Viennot <[email-masked]>
Date: Mon, 18 Mar 2002 10:19:03 +0100

Dear Ioannis,

laurent

laurent