Subject: [Roll] AODV-RPL : unknown link state

From: LavanyaHM <[email-masked]>
Date: Tue, 18 Jul 2017 10:26:44 +0530

Dear AODV-RPL authors,

First of all I want to thank authors of this draft as it is useful in ad
hoc  and  on-demand  routing cases. 
I am implementing AODV-RPL in Contiki OS. During implementation, I am
facing a situation where a node
has no way of determining the bi-directional state of its peering link,
symmetric or  asymmetric, at the time of path establishment. The reason
being, there was no data transferred  earlier over the link between the
sender and receiver of RREQ message.
This is  especially true when the network has freshly come up and AODV-RPL
session was initiated, and the network is not sufficiently warmed up.

The question is, should we treat the lack of knowledge about the
bi-directional link state as symmetric or asymmetric ? When encountered
with this situation, the current implementation optimistically treats the
link
as symmetric, by default. But then, if the link actually turns out to
exhibit asymmetric behavior once the data
starts flowing, what should the protocol do ?

In the current specification, we don't have a provision for re-initiating
or modifying a P2P connection once it is set up. Let me know your thoughts
on this.

Any recommendation on assigning life time for routes?

Regards,
Lavanya H M

---

From: satish anamalamudi <[email-masked]>
Date: Tue, 18 Jul 2017 20:12:45 +0800

Hello Lavanya and all,

Please see my response in [SA].

Regards,
Satish

Sent from my iPhone

> On 18 Jul 2017, at 12:56 PM, LavanyaHM <[email-masked]> wrote:
> 
> Dear AODV-RPL authors,
> 
> starts flowing, what should the protocol do ?In the current specification, we don't have a provision for re-initiating or modifying a P2P connection once it is set up. Let me know your thoughts on this.

[SA] During the network bootup, we can assume the AODV-RPL protocol operation as bi-directional symmetric if there is no ETX statistics of default-RPL. Once, the data transmission occurs we can reconstruct the symmetric or asymmetric routes based on actual ETX statistics.
> Since DIO RREQ messages follow the operation of default RPL DIO trickle timer, we can expect that these messages continue to flow even after the RREP is received. Therefore, these messages act like probes to detect the presence of an asymmetric link. In fact, we are trying to reconstruct P2P connections all the time at the rate as dictated by the DIO RREQ trickle timer.  If the above explanation is fine, then we need to accordingly handle the existing
> instance. 
> 
> 
> 
> Any recommendation on assigning life time for routes ?

[SA] We will consider this issue in the next version of the draft.
> 
> Regards,
> Lavanya H M
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll