Subject: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt

From: JP Vasseur <[email-masked]>
Date: Mon, 29 Jun 2009 06:48:47 +0200

Here you are.

Thanks.

JP.

Begin forwarded message:

> From: [email-masked]
> Date: June 29, 2009 1:15:01 AM CEDT
> To: [email-masked]
> Subject: I-D Action:draft-dt-roll-rpl-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : RPL: Routing Protocol for Low Power and Lossy  
> Networks
> 	Author(s)       : T. Winter, R. Team
> 	Filename        : draft-dt-roll-rpl-00.txt
> 	Pages           : 60
> 	Date            : 2009-06-28
>
> This document specifies the Routing Protocol for Low Power and Lossy
> Networks (RPL), in accordance with the requirements described in
> [I-D.ietf-roll-building-routing-reqs],
> [I-D.ietf-roll-home-routing-reqs],
> [I-D.ietf-roll-indus-routing-reqs], and [RFC5548].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-dt-roll-rpl-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2009 12:59:02 +0200

Thanks!

Just a quick note on the abbreviation RPL.

RPL: Rendez-vouz Point Link RFC5015 and more
RPL: PDAD-RREP-with-Location-information
      draft-jeong-autoconf-pdad-on-demand-01
RPL: Remote Program Load, IBM 1984

Maybe a better abbreviation could be suggested.

Alex

JP Vasseur a écrit :
> Here you are.
> 
> Thanks.
> 
> JP.
> 
> Begin forwarded message:
> 
>> *From: [email-masked] <mailto:[email-masked]>
>> *Date: *June 29, 2009 1:15:01 AM CEDT
>> *To: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D Action:draft-dt-roll-rpl-00.txt *
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
>> Title           : RPL: Routing Protocol for Low Power and Lossy Networks
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
> 
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Mon, 29 Jun 2009 17:59:22 +0200

Hi Alex,

We tried many acronyms ... ideas welcome ! And more importantly  
comments too.

Thanks.

JP.

On Jun 29, 2009, at 12:59 PM, Alexandru Petrescu wrote:

>>> *Reply-To: [email-masked] <mailto:[email-masked] 
>>> >
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2009 18:15:43 +0200

> We tried many acronyms ... ideas welcome ! And more importantly

Could be ROLL... Something like:

       Routing Protocol for Low Power and Lossy Networks (ROLL)

Or other inspiring acronyms. (I find ROLL inspiring).

I did a review of the document.  I am not sure whether I should send the
comments now or later when more people report more.  There are a few
eyebrow-raising aspects, like a Directed Acyclic Graph without arrows,
or a node with multiple interfaces, which I don't understand.

I am not sure whether it's worth reporting the rest now...

Thanks for the comprehensive document and let's see comments,

Alex

>> RPL: Rendez-vouz Point Link RFC5015 and more RPL:
>> PDAD-RREP-with-Location-information 
>> draft-jeong-autoconf-pdad-on-demand-01 RPL: Remote Program Load,
>> IBM 1984
>> 
>>> Here you are. Thanks. JP. Begin forwarded message:
>>>> *From: [email-masked]
>>>> <mailto:[email-masked]> *Date: *June 29, 2009 1:15:01
>>>> AM CEDT *To: [email-masked]
>>>> <mailto:[email-masked]> *Subject: **I-D
>>>> Action:draft-dt-roll-rpl-00.txt * *Reply-To:
>>>> [email-masked] <mailto:[email-masked]>
>>>> 
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories.
>>>> 
>>>>  Networks Author(s)       : T. Winter, R. Team Filename
>>>> : draft-dt-roll-rpl-00.txt Pages           : 60 Date
>>>> : 2009-06-28
>>>> 
>>>> This document specifies the Routing Protocol for Low Power and
>>>> Lossy Networks (RPL), in accordance with the requirements
>>>> described in [I-D.ietf-roll-building-routing-reqs], 
>>>> Below is the data which will enable a MIME compliant mail
>>>> reader implementation to automatically retrieve the ASCII
>>>> version of the Internet-Draft.
>>>> _______________________________________________ I-D-Announce
>>>> mailing list [email-masked] 
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>  _______________________________________________ Roll mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>> 
>> 
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 29 Jun 2009 18:32:17 +0200

Hi Alex,

Please send your comments.

Thanks.

JP.

On Jun 29, 2009, at 6:15 PM, Alexandru Petrescu wrote:

>>> PDAD-RREP-with-Location-information draft-jeong-autoconf-pdad-on- 
>>> demand-01 RPL: Remote Program Load,
>>> IBM 1984
>>>>> described in [I-D.ietf-roll-building-routing-reqs], [I-D.ietf- 
>>>>> roll-home-routing-reqs], [I-D.ietf-roll-indus-routing-reqs], and  
>>>>> [RFC5548].
>>>>> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dt-roll-rpl-00.txt
>>>>> Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
>>>>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/i-d-announce

---

From: "Goindi, Manhar" <[email-masked]>
Date: Tue, 30 Jun 2009 19:15:04 +1000

Hi JP,

Thanks a lot for sharing this draft as it proved very informative & I
thoroughly enjoyed reading it.

I have the following queries:

1.       How does a node know that DIO it has received from a node
should be taken as a Parent or a Sibling with reference to Example in
section 3.3.1.4.1?  I mean how would it decide its own depth.

2.       In Section 3.3.4.4 - why doesn't node 51 reattach itself as a
child to node 53 instead of making node 52 as its parent?  Is it that
node 51 cannot hear node 53 directly so it has to go through node 52?

3.       Can siblings hear each other as it is not evident from Figure
2:  Example DAG?

4.       In section 3.3.4.1:  Moving Down a DAG - it is mentioned that
there is little change for a loop and node 56 may reattach to DAG with
parents 43 & 55.  How is the formation or non-formation of this loop
detected?  What is the mechanism for that?

Would someone like to see if there is an answer to them?

Thanks & Best Regards,

Manhar Goindi

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur
Sent: Monday, June 29, 2009 10:19 AM
To: ROLL WG
Subject: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt

Here you are.

Thanks.

JP.

Begin forwarded message:

            Title           : RPL: Routing Protocol for Low Power and
Lossy Networks
            Author(s)       : T. Winter, R. Team
            Filename        : draft-dt-roll-rpl-00.txt
            Pages           : 60
            Date            : 2009-06-28

Manhar Goindi
Technical Expert
Landis+Gyr
Phone: +91 120 3352149
[email-masked]
http://www.landisgyr.com/

Manage Energy Better

PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jun 2009 15:49:49 +0200

1. How does a node know that DIO it has received from a node should be taken as a Parent or a Sibling with reference to Example in section 3.3.1.4.1?  I mean how would it decide its own depth.

Hi Manhar:

The component that makes that resolution is out of scope. That component, that I call plugin for the lack of a better term,  depends on the metrics which in turn depend on the link type (like RSSI) and the use case (like battery). Because the plugin depends on the metrics, it makes more sense to specify reference examples using those metrics in the current metrics drafts. Other drafts might follow for more specific use cases, and you might even find RA extensions and plugins that are completely proprietary. 

The plugin component is very loosely constrained. It selects an ordered set of preferred parents and from then generic RPL takes over. RPL will use for this node a depth that is incremented from the depth of the deepest parent. The resulting depth enables an abstraction of feasible successors in the same DAG, some parents (least depth) some siblings (same depth). Loop avoidance is guaranteed by construction when packets are passed to parents. It is attempted on a per packet basis when forwarding via siblings.

Note that the plugin might not be use the depth as primary selector for the choice of the preferred parent. For instance that a node sees 2 routers, one at depth 1 with a poor signal indicator and one at depth 2 with a very good signal. The plugin should prefer the second router. 

The resulting graph might depend a lot on how greedy the plugins are.  If you consider that a node is richer when it has a higher number of feasible successors, what society are we trying to build? Let me give you an example. We have a triangle, A, B, C. A is  a root and B and C dynamically appear. Once things settle, you could end up with a situation like:  

 +--->A<---+        +--->A<---+        +--->A<---+        +--->A<---+

 |         |        |         |        |         |        |         |

 |         |        |+--->---+|        |         |        |         |

 B-------->C        B|       |C        B         C        B<------->C

                     +---<---+

   Case 1             Case 2             Case 3             Case 4

Case 1: B is a scrooge. If it comes up after C it sees A  and C and tries to optimize locally its number of parents. If C comes later, B detaches from A and reattaches to again get 2 parents. The resulting depths are A:0, C:1 and B:2 . Drawback: C is always deprived from an alternate forwarding solution. Greediness is discouraged unless the node has a very good reason like critical + low battery but draft 00 lacks any clear cut constraint about that.

Case 2:  C is also greedy. So when B attaches to C as before, C will detach from A to reattach to B and C, and we are in a loop till maximum depth. At which point the looser will attach to A only and we start over the count to infinity. This is definitively broken. A simple tie break is to ignore RAs from deeper, and this is MUSTed in section 5.4 at the end of item 5. So, case 2 is actually impossible with the current spec.

Case 3. B & C are both genuinely altruistic, so anxious of the benefit of others that they wouldn't dare get deeper than they could. So they end up at depth 1 with only one feasible successor, A. The result is in fact even worse than case 1 because neither B nor C can benefit from the other.

Case 4. Same as case 3 with a new rule of allowing sibling forwarding. In that case, B and C are still both depth 1, but they can use one another as alternate (backup) feasible successors. Because the sibling hops do not belong to the DAG, they are not loopless by construction and additional measures must be taken like always prefer a real parent, do not give a packet back to a sibling, decrement hop limit faster, that sort of thing.

The spec is very open but case 4 might be often desirable but for specific nodes that really need to be greedier than average. One way of doing this is to select only ONE preferred parent (then again not necessarily the shallowest one) and orient its vector in the gradient towards that guy. If we do that, the depth will really represent the hops over the preferred and most probable path as opposed to the worst path within selected parents.

My take is that we should SHOULD that behavior. What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Goindi, Manhar

Sent: mardi 30 juin 2009 11:15

To: JP Vasseur (jvasseur); ROLL WG

Subject: Re: [Roll] Fwd: I-D Action:draft-dt-roll-rpl-00.txt

Hi JP,

Thanks a lot for sharing this draft as it proved very informative & I thoroughly enjoyed reading it.

2. How does a node know that DIO it has received from a node should be taken as a Parent or a Sibling with reference to Example in section 3.3.1.4.1?  I mean how would it decide its own depth.

3. In Section 3.3.4.4 – why doesn’t node 51 reattach itself as a child to node 53 instead of making node 52 as its parent?  Is it that node 51 cannot hear node 53 directly so it has to go through node 52?

4. Can siblings hear each other as it is not evident from Figure 2:  Example DAG?

5. In section 3.3.4.1:  Moving Down a DAG – it is mentioned that there is little change for a loop and node 56 may reattach to DAG with parents 43 & 55.  How is the formation or non-formation of this loop detected?  What is the mechanism for that?

 

Thanks & Best Regards,

Manhar Goindi

Manhar Goindi

Technical Expert

Landis+Gyr        

Phone: +91 120 3352149

www.landisgyr.com

manage energy better

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur

To: ROLL WG

Here you are.

Thanks.

JP.

Begin forwarded message:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

            Pages           : 60

            Date            : 2009-06-28

Internet-Draft.

 PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jun 2009 18:16:11 +0200

Hi again Manhar

Q: In Section 3.3.4.4 – why doesn’t node 51 reattach itself as a child to node 53 instead of making node 52 as its parent?  Is it that node 51 cannot hear node 53 directly so it has to go through node 52?

R: That's correct. If it could hear both 51 would join 53 at the same time as 52. But here, bad luck, it will hear of the DAG only when 52 advertises it. The harm a dag hop timer of 7*DAGDelay and jump.

Q: Can siblings hear each other as it is not evident from Figure 2:  Example DAG?

R: Figure 1 represents connectivity and you can see siblings hearing each other. Figure 2 represents the DAG so it does not include the sibling links. Sibling links are bidirectional at the graph level though unidirectional for a given packet. We're missing the term to indicate the DAG+sibling_links. Gradient is fine when you talk about pointing to the preferred parent, but this is also a term that was overloaded in the past. What else?

Q: In section 3.3.4.1:  Moving Down a DAG – it is mentioned that there is little change for a loop and node 56 may reattach to DAG with parents 43 & 55.  How is the formation or non-formation of this loop detected?  What is the mechanism for that?

R: Behavior in 3.3.4.1 is greedy  and I would not recommend it in the general case. It is not strictly speaking unlawful since we only MUST ignore RAs from deeper. In this case it deprives 55 from a sibling that might have been useful. It would also cause any child attach to 56 to either lose that parent or follow it out of the DAG. 

So what happens is. A node detaches and advertises a new DAG for which it is root. Then it sends an RA advertising that new floating DAG. Children that have other parents will probably prefer to stay in the DAG and will just lose that parent. Nodes in the subDAG that have no more alternate will follow it in its fall and inherit directly from the parent graph. Recursively, the frozen subDAG is painted as nodes belonging to the new DAGID and thus gine from the main DAG. After some time (time for multiple trickled RA flows AND for DAG hop timer to elapse) it is expected that all nodes in the frozen part know about it and advertise the new DAGID. It is thus safe to attach to a node that advertizes the main DAGID. Trouble will occur if multiple RAs are lost. The sequence number clears that issue completely but requires a DAG-wide heartbeat mechanism, which will probably be a discussed issue against the draft.

Thanks a bunch for your interest,

Pascal

Hi JP,

1. How does a node know that DIO it has received from a node should be taken as a Parent or a Sibling with reference to Example in section 3.3.1.4.1?  I mean how would it decide its own depth.
2. In Section 3.3.4.4 – why doesn’t node 51 reattach itself as a child to node 53 instead of making node 52 as its parent?  Is it that node 51 cannot hear node 53 directly so it has to go through node 52?
3. Can siblings hear each other as it is not evident from Figure 2:  Example DAG?
4. In section 3.3.4.1:  Moving Down a DAG – it is mentioned that there is little change for a loop and node 56 may reattach to DAG with parents 43 & 55.  How is the formation or non-formation of this loop detected?  What is the mechanism for that?

Thanks & Best Regards,
Manhar Goindi

Manhar Goindi
Technical Expert
Landis+Gyr        
Phone: +91 120 3352149

manage energy better

Here you are.

Thanks.

JP.

Begin forwarded message: