 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
On Nov 5, 2009, at 12:31 PM, Jonathan Hui wrote:
On Nov 5, 2009, at 11:24 AM, Philip Levis wrote:Here's my suggested rewrite for 5.2, 5.3, and 5.4. Would love to know if implementers feel this makes things clearer. In this text, the neighbor set is an unconstrained set of L2 neighbors, the parent set is a subset of the neighbor set and is the set of candidate parents, and the parent is the element of the parent set that is the current next hop towards the DAG root. Note that this text discards the sibling notion for the simpler notion of limited local repair.This text is definitely moving in the right direction.5.2 Neighbors, Parents, and Rank If Neighbor Unreachability Detection (NUD) determines that a neighbor is no longer reachable, then a RPL node MUST NOT consider this node a neighbor when calculating and advertising routes until the node determines it is reachable again. Unless it is a DAG root, a node MUST NOT advertise a DAG ID unless it has neighbors who have advertised that DAG ID. A RPL node that has issued a DIO for a DAGID I, DAG Instance N, and sequence number S MUST NOT consider neighbors for I,N whose last heard DIO for I,N had a sequence number < S.I'd change "MUST NOT consider neighbors" to "MUST NOT consider nodes as neighbors", or some other wording that cannot be misinterpreted as "MUST NOT process messages from neighbors".
I agree.
5.2.1 Parents By definition, DAG Roots do not have any DAG parents. RPL nodes that are not roots MAY maintain multiple candidate DAG parents for a single DAG Instance. The set of candidate DAG parents MUST be a subset of the set of neighbors. At any given moment, a node has a single DAG Parent, selected from the set of candidate DAG parents.Not sure why we have to single out THE DAG parent. The DAG is a DAG because a node can maintain more than one candidate parent. Choosing a candidate parent is what defines the forwarding (not routing) topology. More related to this subject below.
I agree. I was trying to distinguish the parent of the moment from the set of candidate parents. Does that make sense? Do you have a suggestion on how to reword this?
5.2.2 DAG Rank DAG Rank is not a cost metric, although its value is derived from and influenced by route cost metrics. Rank is used to avoid and detect loops. A node's Rank MUST be higher than the Rank of its DAG Parent. The exact calculation of the Rank may depend on the set of candidate DAG parents, link metrics, node configuration, and the DAG Instance OF.I'd say that the advertised Rank MUST be higher than the Rank of its candidate DAG parents, not just the a chosen DAG parent. We use the DAG to identify assign nodes relative position within the network. It doesn't make sense to have a candidate DAG parent that has a higher Rank.
Makes sense.
5.3. DAG Discovery and Maintenance DAG discovery forms a Directed Acyclic Graph towards a DAG Root by identifying a set of candidate DAG parents and selecting a member of the set as its DAG parent. DAG discovery also discovers neighbors, which may be used to provide additional path diversity when a node needs to move downward in the DAG. DAG discovery avoids loops by constraining when and how nodes can increase their Rank. RPL uses an IPv6 optional header in data packets to detect loops. 5.3.1. DAGs 1. A node MAY belong to multiple DAG Instances. 2. A DAGID, InstanceID, and DAGSequence number uniquely defines a DAG iteration. All of a node's candidate parents within a DAG instance MUST belong to the same DAG iteration: the last heard DIO from candidate parents must be for the same DAG iteration.Why not allow a node advertising DAG sequence N forward to a node with DAG sequence N+1? Communication delays means that we can't guarantee that this won't happen. So why restrict it even when we know this is true?
I don't think rule 2 restricts this -- rule 6 does. Let me explain where this rule was going -- it's trying to enforce that a node can't perpetually avoid incrementing its sequence number. The rule you suggested -- a node MUST NOT advertise a sequence number lower than all of its candidate parents -- can have issues when DIOs are lost. The goal of this rule is that a node can observe candidate parents increasing their sequence numbers, but continue to use ones that haven't. Then, at some point, it makes the decision to switch to the subset with the newer sequence number, and increments its own.
3. Within a given DAG instance, a node that is a not a root MUST NOT advertise a DAGSequenceNumber higher than the highest DAGSequenceNumber it has heard. 4. The DAGSequenceNumbers a node advertises for a DAG instance MUST monotonically increase, barring wrap-around as covered in X. 5. DAG Roots MAY increment the sequence number they advertise. 6. A node MUST advertise the same DAGSequenceNumber as its DAG Parent.Or at least what it thinks the DAGSequenceNumber is for its DAG Parent. This comes back to my previous point - when a new sequence number is propagating, nodes will (temporarily) have parents in one iteration, and others in another iteration. I don't think we should restrict implementations from waiting for some time to wait for its DAG parents to catch up to the current iteration - but I don't think we should recommend it either.
Yeah -- I think this text needs to distinguish "the last sequence number it heard from its a candidate parent" and "the candidate parent's sequence number."
Phil