[Olsr-users] Question on multiple interfaces

Thijs van Veen (spam-protected)
Thu Aug 1 12:56:40 CEST 2013


I have a small question (based on the RFC
http://tools.ietf.org/html/rfc3626) regarding multiple interface nodes.

Given the following network with node A having 3 interfaces, 2 of which
are connected to B (single interface) and the other connected to C. B
and C are connected and all links are symmetric.

|       A         |
|  if.0 if.1 if.2 |
   \   /     / 
     B -- C  

Paths from A to B are:
A.if.0 -> B
A.if.1 -> B
A.if.2 -> C -> B

When considering the link A <-> B, will OLSR distinguish between the
links if.0 <-> B and if.1 <-> B?

To me the RFC suggests it only considers the faster link (judging from
HELLO processing on A): 

>From the RFC 3.4. Packet Processing and Message Flooding:
"3.1  if there exists a tuple in the duplicate set, where:

                             D_addr    == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then the message has already been completely processed
               and MUST not be processed again.
So only the first link is considered, because while received on
different interfaces, both messages have the same originator address and
sequence number causing the latter to be ignored;

Or, if the message is not ignored.

>From the RFC, 7.1. Populating the Link Set:
"1    Upon receiving a HELLO message, if there exists no link tuple

               L_neighbor_iface_addr == Source Address

          a new tuple is created with 

               L_neighbor_iface_addr = Source Address

               L_local_iface_addr    = Address of the interface
                                       which received the
                                       HELLO message

               L_SYM_time            = current time - 1 (expired)

               L_time                = current time + validity time

2   The tuple (existing or new) with:

               L_neighbor_iface_addr == Source Address

          is then modified as follows:

          2.1  L_ASYM_time = current time + validity time;

          2.2  if the node finds the address of the interface which
               received the HELLO message among the addresses listed in
               the link message then the tuple is modified as follows:

                    if Link Type is equal to LOST_LINK then

                         L_SYM_time = current time - 1 (i.e., expired)

                    else if Link Type is equal to SYM_LINK or ASYM_LINK

                         L_SYM_time = current time + validity time,

                         L_time     = L_SYM_time + NEIGHB_HOLD_TIME

          2.3  L_time = max(L_time, L_ASYM_time)
Only the first link is considered and for longer, because the latter
message (sent from same interface) has not been ignored and modifies the
time-outs of the first. This would cause the slower interface to be
added in the event the first interface had already been removed, but
this only reverses the problem. 

The other way around (processing on B), would work because the message
got sent from different interfaces.

  Thijs van Veen

http://www.fastmail.fm - One of many happy users:

More information about the Olsr-users mailing list