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

From: Charlie Perkins <[email-masked]>
Date: Wed, 8 Jun 2016 21:51:10 -0700

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.

---

From: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" <[email-masked]>
Date: Mon, 13 Jun 2016 14:14:52 +0000

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?
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:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Wed, 15 Jun 2016 06:46:25 +0000

Hello Rahul,

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

With Regards,
Satish
> From: Roll [mailto:[email-masked]] On Behalf Of Rahul Arvind
> Jadhav (Rahul Arvind Jadhav, 2012 Labs)
> Sent: 2016年6月13日 22:15
> Subject: Re: [Roll] AODV-RPL (draft-satish-roll-aodv-rpl-00.txt)
> 
> Dear Authors,
> 
> 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."