Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency

[Stephen Dawson-Haggerty <stevedh at eecs.berkeley.edu>]

On Thu, Nov 5, 2009 at 9:53 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Nov 5, 2009, at 12:17 PM, Stephen Dawson-Haggerty wrote:
>
>>
>> Also, we lost some of the text explaining why you might want to
>> increment the dag sequence number (it's split between 5.4.3, 5.3.3,
>> and 5.3.1).  I would have appreciated a sentence towards the beginning
>> something like "The effect of incrementing the DAG sequence number is
>> to trigger additional DIO transmissions.  This serves as an
>> implementation-controlled mechanism to rebuild forwarding tables among
>> members of a DAG instance".
>
> The term used is "global repair." I might be OK saying "this can serve as an
> implementation-controlled mechanism," but stating the total purpose of a
> mechanism is problematic. If someone later down the line starts using it for
> something else... does that make sense.

Point taken, although your text is fairly clear here.  If I hear a DIO
with a new sequence number from a neighbor, I MUST update his
information in my table.  Furthermore, I MUST only keep parents with
the same instance ID in my feasible parents set, so I must either
remove the guy with the new sequence number from the set or else
remove everyone else (at least until they too update their sequence
number).  At some point, I switch over to the new sequence number;
when I do, I will have heard a updated DIO message from each of the
guys in the new candidate parent set.  For this reason, I think it
would be fair to say that the effect of incrementing the sequence
number at the root is to force a refresh of all candidate parent sets
within the dag-- doesn't seem up for interpretation.

Also, in 5.3.1, #3 and #6 seem more-or-less redundant-- if I must
advertise my parent's sequence number, it will not be higher then any
number I have heard.

Thanks.
Steve

>
>> Neither document does a great job of explaining the role of the
>> neighbor set in forwarding, in particular I couldn't find a place
>> where it said that you might try multiple parents for the same packet.
>
> Agreed. I didn't get to forwarding yet. Clearly it needs to be there. The
> text would be simple: you forward packets to your parent, which MUST be a
> member of the candidate parent set. A node MAY change which element of its
> candidate parent set is its parent at any time. A given implementation might
> apply certain heuristics (e.g., for stability), but we don't want to
> constrain the parent selection process. We do want to constrain the set of
> nodes that can be candidate parents.
>
> Phil
>
>



-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720