Subject: [Roll] FW: New Version Notification for draft-thubert-roll-asymlink-00.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Oct 2011 12:33:37 +0200

Dear WG:

During the elaboration of RPL draft, RPL ticket #32 was opened to cover Asymmetric Links. Richard in particular suggested to "Add a flag to Routing Metric/Constraint to indicate whether the path metric represents the upward (flag = 0) or downward (flag = 1) metric.  The flag would only be meaningful for path metrics that are aggregations of potentially asymmetric link metrics, such as latency or link quality". 

The group did not express enough interest at the time to make that feature a core feature of the protocol. 

Still, there are specific cases of strongly asymmetrical links where an optimization would be useful when affordable. This popped up again recently during the bi-weekly discussion between the authors of the industrial applicability draft. So we decided that I should raise the question again to the group, as a new optimization. This draft suggested as we discussed long ago to make 2 DODAGs, one optimized for upwards traffic and one for downwards, and then couple them.

What do you think?

Pascal
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: lundi 17 octobre 2011 12:04
To: Pascal Thubert (pthubert)
Cc: Pascal Thubert (pthubert)
Subject: New Version Notification for draft-thubert-roll-asymlink-00.txt

A new version of I-D, draft-thubert-roll-asymlink-00.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Filename:	 draft-thubert-roll-asymlink
Revision:	 00
Title:		 RPL adaptation for asymmetrical links
Creation date:	 2011-10-17
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   The Routing Protocol for Low Power and Lossy Networks defines a
   generic Distance Vector protocol for Low Power and Lossy Networks,
   many of which exhibit strongly asymmetrical characteristics.  This
   draft proposes an extension for that optimizes RPL operations whereby
   upwards and downwards direction-optimized RPL instances are
   associated.

The IETF Secretariat

---

From: C Chauvenet <[email-masked]>
Date: Mon, 17 Oct 2011 05:29:37 -0700

Hi Pascal,

I agree that asymmetric links are challenging to establish a stable and optimal routing topology.

I strongly push the design of a mechanism that could enable to route in such conditions.

I think it is worth to flesh out a standard mechanism to address issues with asymmetrical links, as it is not really an exception in LLNs.

I'm sure many RPL implementations faced asymmetrical links, and each one has its own mechanism.
It may be great to gather our experiments and do it in a standard way.

BTW, it would also enable a safer and quicker behavior of parent selection, as DIO are not acknowledged (Link local multicast).

Your proposition seems good and simple because it just need a flag in the metric container.

I'm wondering about the overhead it would imply.
Would you need to manage 2 DAGs before coupling them ?

Cédric.

Le 17 oct. 2011 à 12:33, Pascal Thubert (pthubert) a écrit :

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Oct 2011 14:58:28 +0200

Hi Cedric:

Please see inline:

[Cedric >] Your proposition seems good and simple because it just need a flag in the metric container.

[Pascal >] Actually the proposed 'D' flag is in the DIO base object. The 'D' flag does not influence only the metric containers, but the OF as a whole. For instance that proposal enables existing OFs such as OF0 and MrHof to operate with asymmetrical links. The flag tells the OF whether to use an metric that accounts for both directions, or for only one direction.

[Cedric >] I'm wondering about the overhead it would imply. Would you need to manage 2 DAGs before coupling them ?

 [Pascal >] Yes, you end up with 2 instances, and probable one or more additional parents. So there is a cost associated to the benefits.  In the case of an industrial network, the operational network is often computed and optimized by and external Path Computation Engine. In that case, it is useful to have a third DAG that is computed by a more dynamic OF and that serves as a last resort when the forwarding along the optimum graph fails.

Cheers;

Pascal