Re: [Roll] AODV-RPL (draft-satish-roll-aodv-rpl-00.txt)

Hello Rahul,

Thank you for your comments. Please, see my response in "[SA]".

With Regards,
Satish
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind
> Jadhav (Rahul Arvind Jadhav, 2012 Labs)
> Sent: 2016年6月13日 22:15
> To: Routing Over Low power and Lossy networks
> Cc: Dongxin Liu
> Subject: Re: [Roll] AODV-RPL (draft-satish-roll-aodv-rpl-00.txt)
> 
> Dear Authors,
> 
> Thanks for the draft. IMO, P2P traffic in RPL is an important work and
> a weak-point of RPL.
> 
> One comment regarding link asymmetry and how the draft takes care of
> it..
> The draft talks about sending route control messages (RREQ-instance
> message) from OrigNode to TargNode to enable data transmission from
> TargNode to OrigNode (section 4) i.e. send message downstream to
> identify upstream path, like the way RPL DIO msg flows downstream to
> identify upstream path.
> Isn't this orthogonal to the requirements of asymmetric link detection?
> Can a node make a reachability assumption towards an upstream peer on
> receiving msg from that upstream peer?

[SA]
For AODV-RPL, how to exactly check the link reliability is out the scope of the document. 

Assume the link reliability (Bi-directional Symmetric or Bi-directional Asymmetric) is known, the operation of AODV-RPL at nodeB is explained below. 

             OrigNode-------nodeB-------TargNode

             Figure.1. Sample AODV-RPL topology

Case 1: If the link from OrigNode->nodeB(Downstream) and nodeB->OrignNode(upstream) is reliable at nodeB then "S" bit is remains to 1 (Symmetric).

Case 2: If the link from OrigNode->nodeB(Downstream) is not reliable and nodeB->OrigNode(upstream) is reliable at nodeB then "S" bit is set to "0"(Asymmetric).

Case 3: If the link from OrigNode ->nodeB(Downstream) is reliable and the link from nodeB->OrignNode (upstream) is not reliable then nodeB won't multicast the control messages. With this case, data transmission for RREQ-Instance from TargNode to OrgNode is not possible.

Once the TargNode receive the RREQ-Instance with “S=1” then RREP-Instance is unicast back to OrigNode in symmetrical links. 

When the “S” bit is set to “0” by any intermediate node during RREQ-Instance then it can’t be changed to “1” by another intermediate node on the way towards Destination. Hence, TargNode will initiate another RREQ-Instance multicast towards OrgNode for S=0. 

Currently, RPL[RFC6550] use the Rank (ETX) in Objective Function Zero (OF-0) to check the bi-directional symmetric link reliability during network formation. The ETX functionality could be revised to check for both Symmetric(S=0) and Asymmetric(S=1) link reliability. Furthermore, EAR [On Accurate and Asymmetry-aware Measurement of Link Quality in Wireless Mesh Networks] metric can also be used to check for uni-directional and bi-directional link reliability. Performance of EAR is tested in both simulations (Ns-2) and Linux-based testbed.
[SA]

> In case of P2P-RPL (RFC 6997), there is a clear assumption about
> bidirectional reachability. To quote, "Since the links in the
> discovered route have bidirectional reachability (Section 7), the
> Target may use the discovered route to reach the Origin."
> How does the draft address this problem and handle asymmetric
> bidirectional routes?
> 
> Thanks,
> Rahul
> 
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Charlie Perkins
> Sent: 09 June 2016 AM 10:21
> To: Routing Over Low power and Lossy networks
> Cc: Dongxin Liu
> Subject: [Roll] AODV-RPL (draft-satish-roll-aodv-rpl-00.txt)
> 
> 
> Hello folks,
> 
> We have submitted AODV-RPL for consideration in the [roll] WG. AODV-RPL
> borrows some ideas from AODV and also handles asymmetric bidirectional
> routes.  Comments and suggestions will be appreciated!
> 
> Regards,
> Charlie P.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll