Subject: RE: [manet] Default Forwarding Algorithm in OLSR

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 26 Jan 2005 15:26:06 +0000

> A question of interest is whether this can be weakened so that
> the third point becomes
>
> > - Only messages coming on symmetrical links are forwarded
>
> (Just for now let's ignore how we specify this in the set,
> although actually I think it's slightly easier than what is
> currently specified.)

I meant to say that the latter point assumes that I'll process
the first copy I get, symmetric or asymmetric. I'll forward as
currently. But is there a problem? (I might this way actually
process a message I current don't due to packet loss. But I
don't think that hurts.)

And sorry about the following, nothing I can do about it.

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

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

---

From: Cedric Adjih <[email-masked]>
Date: Thu, 27 Jan 2005 04:18:01 +0100 (CET)

Hello Chris,

> process a message I current don't due to packet loss. But I

I guess from a philosophical point of view, it's possible to process
messages from asymmetrical links, I would say:
- advantage: in case of motion, the TC/MID/HNA are still processed,
  before a symmetric link is re-established.
- drawback: in case of partitioned networks, if one node can hear
  a node from the other network (through asymmetric link), it
  would be a little strange, to have some (unused) information of
  the second network in the various sets. Pratical case: two OLSR
  networks running on contiguous wireless 802.11 channels ; from time
  to time, a broadcast could be received from the other, close, channel.
Overall, this looks like a good idea :-)  

Now from a pratical point of view, if TC/HNA/MID processing is 
changed to process asymmetric links, you still need to ensure the
invariant:
"A message has been processed if and only if there is a duplicate
 tuple for it in the duplicate set".
However this is a little technical:
- This shouldn't be implemented by removing the "symmetric
  interface test" of the default forwarding algorithm (i.e. section 3.4.1,
  step 1), and then calling it. This would break MPR flooding because
  of course, asymmetric links are not used for MPR calculation. And
  the message would not be forwarded: not now, and sometimes possibly,
  not later when a duplicate tuple would be created. The culprit is
  the bit: "The receiving interface (address) is added to D_iface_list"
- So probably one way is, in that case (asymmetric message):
  - if there is no duplicate tuple: create one with D_iface_list = empty
    It would be logical to do it right after processing (step 3.2)
  - don't use default forwarding algorithm (or let it stop at step 1).
  
As a side note, if you are to modify RFC3626 MPR flooding:
I see "4. Forwarding condition" could be stronger
(could be like step 2 of Default Forwarding Algorithm), but
anyway step 4.1 is redundant. Thus I think it can be entirely
removed, to simplify any further change :-)

Regards,
-- Cedric

Currently: [email-masked],
Laboratory of Pr. Mase, Information Network Research Group,
Dpt of Information Engineering, Niigata University, Japan