Subject: [Roll] Triggering a new DODAG iteration

From: Robert Assimiti <[email-masked]>
Date: Thu, 18 Mar 2010 16:24:28 -0400

As you can imagine, triggering a new DODAG iteration in a wireless subnet that scales to thousands of wireless nodes can be quite disruptive to the operation of the subnet.

The criteria that will trigger a new DODAG iteration should (in my opinion) be left to the implementation.
The decision of triggering a new DODAG iteration lies with the root.
A well informed root can make better decisions than an un-informed root.

Hence I propose that we discuss additional standardized error messages reported by the routers.
At this point nodes can flag rank and forwarding errors through the usage of the 'R' and 'F' bits present in the flow label.

In my opinion, this is a very limited set of error messages.
Since we are seeking interoperability,  we should define a new ICMPv6 error message that allows the nodes to report various DODAG inconsistencies and discrepancies with more details and precision than the 'R' and 'F' bits.
Some suggestions for potential reported errors:

1.       Preferred parent not reachable

2.       Parent not reachable

3.       Parent set nears depletion
Etc ....etc

Armed with this information (sent in an interoperable manner) the root is now capable of making a more informed decision when to trigger a new DODAG iteration.

Any thoughts? Suggestions?

Robert Assimiti
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]<mailto:[email-masked]>

________________________________
This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.

---

From: Kris Pister <[email-masked]>
Date: Tue, 23 Mar 2010 13:14:24 -0700

I'm a big fan of having error messages as well as status/summary 
messages reported to the DAG root.
Status is one of the important tools for detecting insider attacks on 
the network.  Having a regular summary of what each node is hearing from 
its neighbors about rank, etc., would help catch attacks as well as 
bugs, and help with your iteration trigger.

ksjp

Robert Assimiti wrote:
>
> As you can imagine, triggering a new DODAG iteration in a wireless 
> subnet that scales to thousands of wireless nodes can be quite 
> disruptive to the operation of the subnet.
>
>  
>
> At this point nodes can flag rank and forwarding errors through the 
> usage of the 'R' and 'F' bits present in the flow label.
>
>  
>
> Since we are seeking interoperability,  we should define a new ICMPv6 
> error message that allows the nodes to report various DODAG 
> inconsistencies and discrepancies with more details and precision than 
> the 'R' and 'F' bits.
>
> Armed with this information (sent in an interoperable manner) the root 
> is now capable of making a more informed decision when to trigger a 
> new DODAG iteration.
>
>  
>
> *Robert Assimiti*
> *Office: [678]-202-6859*
> *Mobile: [404]-578-0205*
> [email-masked] <mailto:[email-masked]>*
>
>  
>
>
> ------------------------------------------------------------------------
> This e-mail (including any attachments to it) is confidential, 
> proprietary, legally privileged, subject to copyright and is sent for 
> the personal attention of the intended recipient only. If you have 
> received this e-mail in error, please reply to advise us immediately, 
> delete it and destroy any printed copies of it. You are notified that 
> reading, disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited. 
> No employee is authorized to conclude any binding agreement on behalf 
> of NIVIS LLC with another party by e-mail without express written 
> confirmation by an officer of the company. Although we have taken 
> reasonable precautions to ensure no viruses are present in this 
> e-mail, we cannot accept responsibility for any loss or damage arising 
> from the viruses in this e-mail or attachments.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>