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

["Pascal Thubert (pthubert)" <[e-mail]>]

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
From: [e-mail] [mailto:[e-mail]] 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.

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

Manhar Goindi
Technical Expert
Landis+Gyr        
Phone: [phone]
[e-mail]
www.landisgyr.com

manage energy better
From: [e-mail] [mailto:[e-mail]] 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:

From: [e-mail]
Date: June 29, 2009 1:15:01 AM CEDT
To: [e-mail]
Subject: I-D Action:draft-dt-roll-rpl-00.txt 
Reply-To: [e-mail]

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.

 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.