Subject: [Roll] Mixed mode operation

From: Mukul Goyal <[email-masked]>
Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT)

Hi all

I was wondering if there was ever a discussion on the mailing list or else where regarding why is it difficult to support mixed mode operation. We know from the WG meeting at Anaheim that mixed mode operation is difficult to support but it is not clear why. 

Not supporting mixed mode operation is a major climb down for RPL. This means that the introduction of even a single non-storing router can turn a hitherto storing LLN into a non-storing one thereby causing a major upheaval in the network as all the DAOs now have to reach the root.

Thanks
Mukul

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 29 Mar 2010 07:29:41 -0400

> Date: Sun, 28 Mar 2010 23:57:29 -0500 (CDT)
> From: Mukul Goyal <[email-masked]>
> 
> I was wondering if there was ever a discussion on the mailing list or
> else where regarding why is it difficult to support mixed mode
> operation. We know from the WG meeting at Anaheim that mixed mode
> operation is difficult to support but it is not clear why.

Speaking for myself, supporting mixed mode is both complex
and can use up a lot of bandwidth.  Numerous people have
commented that RPL is too complicated, and much of the
complexity comes from attempting to handle mixed-mode DODAGs
efficiently.

A key issue is the response to a change in parents.  With
caching, a node with a new parent sends a (potentially)
large amount of data, its cache, one hop to the new parent.
The parent in turn only forwards up those DAOs that are new
to it.  Without caching the node can send a small amount of
data, its new parent, a (potentially) long distance.  In a
mixed network you get the worst of both.  Because there may
be a cache, the entire sub-DAGs worth of DAOs must be sent
to the new parent, and non-caching nodes have to elicit and
forward all of these DAOs, whether or not they are
redundant.

> Not supporting mixed mode operation is a major climb down for
> RPL.

In what way?  It would definitely be nice to have, but there
is no requirement for it.  At least at Anaheim, there was a
sense that no mixed-mode style of networks exist today.

> This means that the introduction of even a single non-storing
> router can turn a hitherto storing LLN into a non-storing one thereby
> causing a major upheaval in the network as all the DAOs now have to
> reach the root.

My understanding is that a non-storing router can only join
a storing DODAG as a host, the same as a router that does
not understand the metric in use in the DODAG.  There is no
mechanism for changing a storing DODAG into a non-storing one.

                                    -Richard Kelsey

---

From: [email-masked]
Date: Mon, 29 Mar 2010 09:39:52 -0500

Richard,

In Anaheim, we touched on the issue
where a storing node has reached its storing capacity.  However, I
don't believe we resolved the issue; that being if a node has max'd out
its storage, is the node now considered a 'non-storing' node and
hence has to retreat to life as a leaf node?  I wouldn't think so,
especially if the node is spatially defined in the middle of the DAG.

I think that with the limited RAM available
on these devices, running out of routing table space will be a frequent
issue that we must consider.

Jerry

From:

Richard Kelsey <[email-masked]>

To:

Mukul Goyal <[email-masked]>

Cc:

[email-masked]

Date:

03/29/2010 06:33 AM

Subject:

Re: [Roll] Mixed mode operation

efficiently.

redundant.

-Richard Kelsey

_______________________________________________

Roll mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/roll

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 29 Mar 2010 07:53:13 -0700

On Mar 28, 2010, at 9:57 PM, Mukul Goyal wrote:

> I was wondering if there was ever a discussion on the mailing list  
> or else where regarding why is it difficult to support mixed mode  

Yes, we've had discussions on this mailing list explaining the  
asymptotic analysis of the currently proposed mechanism.

I think it is more beneficial to ask the question from a different  
angle:  Is there a mechanism to support mixed mode operation that is  
both well understood and widely deployed in LLNs today?  This isn't  
the first time we've asked this question and we have yet to see a  
better proposal than what exists today.

> Not supporting mixed mode operation is a major climb down for RPL.  
> This means that the introduction of even a single non-storing router  
> can turn a hitherto storing LLN into a non-storing one thereby  

Not supporting mixed-mode operation would be on-par with the industry  
today (which, for me, is a major goal).  The point is that the LLN  
solutions that are shipping today assume either fully non-storing or  
fully storing.  Any issues around that are being addressed without  
having to resort to mixed mode operation.

A single non-storing router attaching to a storing LLN simply attaches  
as a host - any attempt to change the state of the entire network  
would not scale well.

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Mar 2010 08:08:58 -0700

On Mar 29, 2010, at 7:39 AM, [email-masked] wrote:

> 
> 
> Richard, 
> 
> In Anaheim, we touched on the issue where a storing node has reached its storing capacity.  However, I don't believe we resolved the issue; that being if a node has max'd out  its storage, is the node now considered a 'non-storing' node and hence has to retreat to life as a leaf node?  I wouldn't think so, especially if the node is spatially defined in the middle of the DAG.   
> 
> I think that with the limited RAM available on these devices, running out of routing table space will be a frequent issue that we must consider. 
> 
> Jerry 

Jerry,

As far as I know, there is no routing protocol today which resolves this issue (RIP, OSPF, BGP, IS-IS, AODV, DSDV, DSR, DYMO, OLSR, Srcr, CTP....?). It therefore seems like a (challenging) research problem: we really should not put it on the critical path for specifying a standard.

Phil

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Mar 2010 08:15:54 -0700

> I was wondering if there was ever a discussion on the mailing list or else where regarding why is it difficult to support mixed mode operation. We know from the WG meeting at Anaheim that mixed mod…

The simplest version of one of the problems is this:

A -> ... -> B -> C -> ... -> Root

B's sub-DAG is non-storing. C is storing. B changes its parent set such that it has a new preferred parent D that is a storing node:

A -> ... -> B -> D -> .... -> Root

B now must request DAOs (and source routes) from its entire sub-DAG, so they can be stored in D. D must also issue a new DAO to advertise these prefixes.

There might be cute and elegant solutions to these kinds of problems, but I think Jonathan's point still holds: there are no networks today which support this mode of operation. This means that 1) it's not a critical requirement and 2) there are not well-understood solutions that we can standardize and feel confident in.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Mar 2010 17:35:45 +0200

Another angle is to ask ourselves what we can do simpler if we have the
assumption that there is no mixed mode.

I think that one such thing is illustrated by Richard's proposal in a
parallel thread "Proposal for DAOs in non-caching DODAGs".

Before (in 07) we had the complex S flag mechanism to sometimes save the
costly cache repopulation that Phil depicts below. Implicitly, 07 also
implied a tree so that when we are in non-caching world, and B
advertises a SR path via D, the root knows that C->B is broken and
recomputes D-> B-> A to reach A.

After (with Richard's new proposal) a node can advertise multiple
parents to the root, and in particular if C->B still works, B can
advertise both C and D as DAO parents. 

Suppressing the mixed mode operation enables us to support DAGs with no
fan outs, and simplifies the protocol by removing the S-flag thing.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Philip Levis
> Sent: Monday, March 29, 2010 5:16 PM
> To: Mukul Goyal
> Cc: roll
> Subject: Re: [Roll] Mixed mode operation
> 
> 
or else
> where regarding why is it difficult to support mixed mode operation.
We
> know from the WG meeting at Anaheim that mixed mode operation is
> difficult to support but it is not clear why.
> 
> B's sub-DAG is non-storing. C is storing. B changes its parent set
such that it
> has a new preferred parent D that is a storing node:
> 
> B now must request DAOs (and source routes) from its entire sub-DAG,
so
> they can be stored in D. D must also issue a new DAO to advertise
these
> prefixes.
> 
> There might be cute and elegant solutions to these kinds of problems,
but I
> think Jonathan's point still holds: there are no networks today which
support
> this mode of operation. This means that 1) it's not a critical
requirement and
> 2) there are not well-understood solutions that we can standardize and
feel
> confident in.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 12:12:55 -0400

>>>>> "Jonathan" == Jonathan Hui <[email-masked]> writes:
    Jonathan> Not supporting mixed-mode operation would be on-par with
    Jonathan> the industry  today (which, for me, is a major goal).  The
    Jonathan> point is that the LLN  solutions that are shipping today
    Jonathan> assume either fully non-storing or  fully storing.  Any
    Jonathan> issues around that are being addressed without  having to
    Jonathan> resort to mixed mode operation.

What do deployed storing solutions do when the node runs out of space?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 12:46:32 -0400

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> In Anaheim, we touched on the issue where a storing node has
    Jerald> reached its storing capacity.  However, I don't believe we
    Jerald> resolved the issue; 
    Jerald> that being if a node has max'd out  its storage, is the node
    Jerald> now considered a 'non-storing' node and hence has to retreat
    Jerald> to life as a leaf node?  I wouldn't think so, especially if
    Jerald> the node is spatially defined in the middle of the DAG.

I was an advocate of not dealing with mix storing/non-storing.

If we have an efficient solution for the storing/non-storing, then we
could say that a storing node that is full becomes non-storing.

If we do not have such a solution, then it seems that when a node
becomes full in an all-storing network, then yes, it has to become a
leaf.

I think it was clear from the beginning that all-storing networks have
the downside that all storing nodes have to have enough capacity at
every intermediate node.  And that this is a natural limit to scaling of
the network.

If we get the set of MUSTs and MAYs correct, then all-storing networks
should always be able to operate as non-storing networks (at least for
some DODAGs!), so I see this as less of a serious issue.  

I think we should maintain the mixed-mode flag bits in the headers, but
define the value to be non-mixed for now.  This leaves us the ability to
signal a mixed-DAG for those that want to experiment.  

I think that the better p2p algorithms will come out this experimentation. 

- --

---

From: [email-masked]
Date: Mon, 29 Mar 2010 11:55:54 -0500

Phil,

I'm only trying to be pragmatic.  If
nodes are holding state for other nodes in the DAG, then I would think
that depending on the node's relative rank in the DAG; nodes higher (i.e.
closer to the LBR) in the DAG would be required to hold more state. That
is, nodes would need to hold state for all nodes 'below' them in the DAG.
Since rank is a function of spatial placement, this means that a
node cannot a priori set aside a fixed set of RAM for routing tables.  That
said, I would think filling up the routing table would be quite common.

What I'm asking is what should a node
do when its table fills?  Should it not accept new requests? Drop
the Least Recently Used? Drop the first entry? the last entry?  I
think this needs to be documented for interoperability.  What table
management policy would have the least impact on node-to-node connectivity?

Jerry

From:

Philip Levis <[email-masked]>

To:

[email-masked]

Cc:

Richard Kelsey <[email-masked]>,
[email-masked], [email-masked]

Date:

03/29/2010 10:09 AM

Subject:

On Mar 29, 2010, at 7:39 AM, [email-masked]
wrote:

Richard,

In Anaheim, we touched on the issue where a storing node has reached its
storing capacity.  However, I don't believe we resolved the issue;
that being if a node has max'd out  its storage, is the node now considered
a 'non-storing' node and hence has to retreat to life as a leaf node?  I
wouldn't think so, especially if the node is spatially defined in the middle
of the DAG.

I think that with the limited RAM available on these devices, running out
of routing table space will be a frequent issue that we must consider.

Jerry

Jerry,

As far as I know, there is no routing protocol today which
resolves this issue (RIP, OSPF, BGP, IS-IS, AODV, DSDV, DSR, DYMO, OLSR,
Srcr, CTP....?). It therefore seems like a (challenging) research problem:
we really should not put it on the critical path for specifying a standard.

Phil

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 29 Mar 2010 10:08:47 -0700

Storing devices that are out of resources to store either need to become
non-storing (if that is legal in the DAG they are a member) or must become
leaf devices.  I don't see any other alternative.

Internally, they can do some table management/freeing of resources but I
would not expect to see that in the specification.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Richardson
Sent: Monday, March 29, 2010 9:13 AM
To: roll
Subject: Re: [Roll] Mixed mode operation

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 14:37:15 -0400

>>>>> "Don" == Don Sturek <[email-masked]> writes:
    Don> Storing devices that are out of resources to store either need
    Don> to become non-storing (if that is legal in the DAG they are a
    Don> member) or must become 
    Don> leaf devices.  I don't see any other alternative.

I wasn't asking about RPL.
I was asking about current (proprietary) deployed solutions.

There is a belief that the mixed mode has never been deployed in any
proprietary solution.  Given that, in networks with storing nodes, when
the node gets full, what happens?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 14:48:31 -0400

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald>    Phil, I'm only trying to be pragmatic.  If nodes are
    Jerald> holding state for other nodes in the DAG, then I would think
    Jerald> that depending on the node's relative rank in the DAG; nodes
    Jerald> higher (i.e. closer to the LBR) in the DAG would be required
    Jerald> to hold more state. That is, nodes would need to hold state
    Jerald> for all nodes 'below' them in the DAG.

And, since the network is self-organizing,  we may not know apriori
which nodes are closer to the LBR, and which are not (and how this
changes when nodes fail, batteries run down, etc.) so in fact, we can't
really guess which nodes need more storage than others.
(I imagine that there could be quite an on-site industry to optimize
such networks given some actual data)

    Jerald> Since rank is a
    Jerald> function of spatial placement, this means that a node cannot
    Jerald> a priori set aside a fixed set of RAM for routing tables.

    Jerald> That said, I would think filling up the routing table would
    Jerald> be quite common.  What I'm asking is what should a node do
    Jerald> when its table fills?  Should it not accept new requests? 
    Jerald> Drop the Least Recently Used? Drop the first entry? the last
    Jerald> entry?  I think this needs to be documented for
    Jerald> interoperability.  What table management policy would have
    Jerald> the least impact on node-to-node connectivity?  Jerry

Let me rewrite your options, because I agree the question is very
important, and has not been addressed.  (Can we open an issue for this?)

1) Drop the Least Recently Used? 

   LRU here means that we've relayed traffic to this node.

   If the node is in fact active, but not through this node, this is
   appealing because it might be that in fact the layers above this node
   have already decided that our node is not in the path. 

   I have major concerns that this mechanism is too traffic dependant
   to properly analyze in a simulation.

2) Drop the first entry?

   This entry would be the oldest, and therefore we might never hear
   from this node again.  

   The major concern I have is that it will lead to a kind of race where
   nodes work for awhile, and then we can't talk to them again as the
   network grows.  

   However, when we hear from this node again, it displaces another
   node. This is LRU, but now not based upon traffic to the node, but 
   rather based upon hearing DIOs from it.

3) Drop the last entry?  

   This might be a compelling mechanism.  When the table is full, it's full. 
   No churn.  No needless processing.  This might be the lowest power
   mechanism for some architectures.
   This does create a different kind of race -- first nodes to boot and
   network win.  But, if you have a stable network, it likely STAYS that
   way.

- --

---

From: [email-masked]
Date: Mon, 29 Mar 2010 14:11:15 -0500

Hi Don,

Don't you think it's scary for a node
to just down-shift to being a leaf node if it's out of resources?  In
our implementations, nodes closest to the LBR tend to have the most traffic.
The traffic level diminishes as the node is placed farther from the
LBR.  Since we can't control node placement in a jobsite, it's likely
that all the LBR neighbors will run our of memory first.  If they
drop down to 'leafs', that renders the whole DAG beneath them unusable.
That would not be a good thing!  somehow, we need to manage
the routing table resource.

Jerry

From:

"Don Sturek" <[email-masked]>

To:

"'Michael Richardson'" <[email-masked]>,
"'roll'" <[email-masked]>

Date:

03/29/2010 12:09 PM

Subject:

Storing devices that are out of resources to store
either need to become

Internally, they can do some table management/freeing of resources but
I

Don

-----Original Message-----

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

Michael Richardson

To: roll

>>>>> "Jonathan" == Jonathan Hui <[email-masked]>
writes:

Jonathan> Not supporting mixed-mode operation would be
on-par with

Jonathan> the industry  today (which, for me, is
a major goal).  The

Jonathan> point is that the LLN  solutions that are
shipping today

Jonathan> assume either fully non-storing or  fully
storing.  Any

Jonathan> issues around that are being addressed without
having to

--

]       He who is tired of Weird Al is tired of life!
|  firewalls

[

]   Michael Richardson, Sandelman Software Works, Ottawa, ON
|net

architect[

] [email-masked] http://www.sandelman.ottawa.on.ca/
|device

driver[

then sign the petition.

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Mar 2010 12:50:38 -0700

> the node gets full, what happens?

Jonathan mentioned this in his presentation at Anaheim: you provision/design your network so this doesn't happen. 

Phil

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 29 Mar 2010 15:01:40 -0700

Hi Jerry,

I think the table sizes need to be configured to meet the worst case
placement of the device in the network.    If you make the tables too small
for wherever the device may be deployed in an operational environment then I
don't see how the specification or protocol is going to make up for that.

Don

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 12:11 PM
To: [email-masked]
Cc: 'Michael Richardson'; 'roll'; [email-masked]
Subject: Re: [Roll] Mixed mode operation

Hi Don, 

Don't you think it's scary for a node to just down-shift to being a leaf
node if it's out of resources?  In our implementations, nodes closest to the
LBR tend to have the most traffic.  The traffic level diminishes as the node
is placed farther from the LBR.  Since we can't control node placement in a
jobsite, it's likely that all the LBR neighbors will run our of memory
first.  If they drop down to 'leafs', that renders the whole DAG beneath
them unusable.  That would not be a good thing!  somehow, we need to manage
the routing table resource. 

Jerry 

From: 

To: 

"'Michael Richardson'" <[email-masked]>, "'roll'" <[email-masked]> 

Date: 

03/29/2010 12:09 PM 

Subject: 

  _____  

Don

-----Original Message-----
From: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of
Michael Richardson
Sent: Monday, March 29, 2010 9:13 AM
To: roll
Subject: Re: [Roll] Mixed mode operation

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked]  <http://www.sandelman.ottawa.on.ca/>
http://www.sandelman.ottawa.on.ca/ |device
driver[
  Kyoto Plus: watch the video < <http://www.youtube.com/watch?v=kzx1ycLXQSE>
http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition. 
_______________________________________________
Roll mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

---

From: "Roger Alexander" <[email-masked]>
Date: Mon, 29 Mar 2010 18:04:27 -0400

Hi Richard, Mukul,

> Richard Kelsey
> Sent: Monday, March 29, 2010 7:30 AM
> To: Mukul Goyal
> Cc: [email-masked]

I do concur here. Though with caching-only nodes there is an opportunity, in
conjunction with acknowledged exchanges, to introduce further scalability
optimizations that can include performing just incremental updates when
refreshing DAO sub-DAG destination addresses. This does require some
additional enhancement to the current DAO specification but can be
introduced as part of a caching-only mode operation.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 18:10:05 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Don> Storing devices that are out of resources to store either need
    Don> to become non-storing (if that is legal in the DAG they are a
    Don> member) or must become leaf devices.  I don't see any other
    Don> alternative.

    >> I wasn't asking about RPL.  I was asking about current
    >> (proprietary) deployed solutions.
    >> 
    >> There is a belief that the mixed mode has never been deployed in
    >> any proprietary solution.  Given that, in networks with storing
    >> nodes, when the node gets full, what happens?

    Philip> Jonathan mentioned this in his presentation at Anaheim: you
    Philip> provision/design your network so this doesn't happen.

Okay, but that's not an answer.

Do you provision it so that every node can hold enough routes for any
topology, or just for the topology that you care about?

If, when I've provisioned the network, I'm WRONG and for some reason
there are additional nodes, what does this mean?  What policy is used to
select which ones fit?

Answers to the above question is important from a security design point
of view: if an attacker can cause the topology to change through
creative use of active (or even passive) repeaters, then it could
overwhelm an "interior" node's capacity.   What happens then?

- --

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 29 Mar 2010 15:11:14 -0700

For the solutions that I am familiar with (which use a variation of AODV),
we only have recommended practices on retiring or removing route table
entries.

Many of these implementations do some route table management when the
routing table is full.  However, these actions (in the proprietary solutions
I am familiar with) come at a cost of flooding the network when the removed
route table entry is re-established.  If you make your route table entries
too small to support the size of network you are deploying then I don't see
route table maintenance itself solving the problem.

Don

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 19:09:21 -0400

>>>>> "Don" == Don Sturek <[email-masked]> writes:
    Don> Many of these implementations do some route table management
    Don> when the routing table is full.  However, these actions (in the
    Don> proprietary solutions I am familiar with) come at a cost of
    Don> flooding the network when the removed route table entry is
    Don> re-established.  If you make your route table entries too small
    Don> to support the size of network you are deploying then I don't
    Don> see route table maintenance itself solving the problem.

I certainly won't disagree with that statement.

The situation I want to think about is what happens when there are n+1
entries needed, and only n available.  Not 2n, or 10n.

So in AODV and other situations, the network falls back to network
flooding to get packets through, when it can't find an entry.  So that's
what happens if an attacker manages to push an important node out.

What I'm trying to determine if there is any determinism in which entry
is pushed out that the attacker can exploit.

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 29 Mar 2010 17:42:26 -0700

Hi Michael,

It would make sense to recommend to vendors they implement a route entry
management solution and to even provide a best practices.

On the point below on hacker exploitation, mesh routing relies on
distributed routing.  I think all router devices need to be authenticated
before being allowed to participate.  For any mesh routing solution
(distance vector, source routing, link state) it would be easy to could come
up with ways for a malicious router to disrupt routing (eg, depleting route
table entries in distance vector routing, extending route records in source
routing to deplete packet header field support, etc.)

Don

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Mar 2010 21:26:17 -0400

>>>>> "Don" == Don Sturek <[email-masked]> writes:
    Don> It would make sense to recommend to vendors they implement a
    Don> route entry management solution and to even provide a best
    Don> practices.

    Don> On the point below on hacker exploitation, mesh routing relies
    Don> on distributed routing.  I think all router devices need to be
    Don> authenticated before being allowed to participate.  For any

Authentication may not solve anything if it does not include
non-spoofable replay protection.  My experience with L2-"security" is
that it does not provide this.

Consider that one can record and replay packets.
An attacker can record packets in one part of the network and replay 
them back in another part of the network.    Think of someone with a
tape recorder recording your voice in your house, and then playing it
back in your office, to make someone believe you are in the office.
This works even if you speak in code.  

This is not an active mitm attack, because no packets are actually
removed or intercepted. 

This is a VERY HARD problem to solve, because really, if the attacker
just installed a high-gain antenna in one part of the building, a coax
cable, and another antenna in another part of the building, it's really
the same thing!  The difference is perhaps that the totally passive
system will relay packets usefully. 

So, again my situation is:

mcr> The situation I want to think about is what happens when there
mcr> are n+1 entries needed, and only n available.  Not 2n, or 10n.

If I make a particular node think it's adjacent now to n+1 nodes, which
routing entry is flushed out?

- --

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Mar 2010 19:27:03 -0700

On Mar 29, 2010, at 6:26 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

This came up in Anaheim; one approach to defending from this is  
requiring a node to respond to a nonce before handling its packets  
(e.g., inserting a routing table entry). There are of course  
timeliness issues, etc.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Mar 2010 08:35:58 +0200

Hi:

As Phil said the anti-replay came up in Anaheim. This piece is to be
covered in the security analysis. So I think we should only consider the
saturation of routing tables in this thread.

Also I do not believe in churn in routing tables to address capacity
overload. We've seen in ND that a cache that's not dimensioned
appropriately (too small) just  causes permanent look ups that multiply
the traffic in the network, loss and latency.

In classical mesh networking, what you do when the network gets fully
busy is that you add another root. Capacity management becomes a
deployment issue. Usually what we address there is the bandwidth
capacity on the root radio space. In this thread, the problem is a bit
different and the routing table overload might occur one or more hops
away from the root. Still, the solution to increase capacity needs is
probably divide and conquer, and nothing will replace a proper capacity
planning overall.

RPL enables DAGs that are made of multiple DODAGs. RPL enables the radio
roots to be connected to a backbone, with a super-root there if you want
a single DODAG. RPL dynamically adapts to the addition or the removal of
a root in an instance so adapting the capacity to new requirements has
only a local impact on the network. It also adapts dynamically to the
addition of a parent in the DODAG to share the load close to the root.
So we can do divide and conquer dynamically.

If there are enough parents and still one parent is overloaded
somewhere, then we might have an issue with the parent selection. At the
moment, a parent cannot indicate the capacity of its routing table, so a
node might attach to parent that has no room for it. Also, one of the
reasons for a DAO ack is for a parent to reject a DAO for lack of
capacity. 

If there are enough roots and still one DODAG is overloaded somewhere,
then we might have an issue with the DODAG selection. We need is to push
nodes on the ridge between DADOGs to jump onto the other DODAG in order
to balance the load between DODAGs. To do that, we need a pushback
mechanism from the nodes where the capacity is reached to the nodes on
the ridge that can jump elsewhere.

I'm not saying that this is easy, but I think it can be done.

Pascal

Of
> Philip Levis
> Sent: Tuesday, March 30, 2010 4:27 AM
> To: Michael Richardson
> Cc: 'roll'
> > cable, and another antenna in another part of the building, it's
> > really the same thing!  The difference is perhaps that the totally
> > passive system will relay packets usefully.
> 
requiring a
> node to respond to a nonce before handling its packets (e.g.,
inserting a
> routing table entry). There are of course timeliness issues, etc.
> 
> Phil
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Mar 2010 10:23:49 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> As Phil said the anti-replay came up in Anaheim. This piece
    Pascal> is to be covered in the security analysis. So I think we
    Pascal> should only consider the saturation of routing tables in
    Pascal> this thread.

okay.

    Pascal> If there are enough roots and still one DODAG is overloaded
    Pascal> somewhere, then we might have an issue with the DODAG
    Pascal> selection. We need is to push nodes on the ridge between
    Pascal> DADOGs to jump onto the other DODAG in order to balance the
    Pascal> load between DODAGs. To do that, we need a pushback
    Pascal> mechanism from the nodes where the capacity is reached to
    Pascal> the nodes on the ridge that can jump elsewhere.

I think this is the most important part.
Nodes have to agree to be parents.

I think that this also makes the security arrangements easier.

Do they need to do it with an individual ACK, or are there ways to
accumulate this into a single message... I note that the intermediate
node has to inform it's parent who it's children are (in the DIO), so
that message could also be sent to the children!
I think that in many layer-2s, that the children will see the DIO to the
parent anyway.

However, if the children include a nonce which the parent must return
inorder to ack, then the DIO might grow too much.

- -- 

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Hi:

    Pascal> As Phil said the anti-replay came up in Anaheim. This piece
    Pascal> is to be covered in the security analysis. So I think we
    Pascal> should only consider the saturation of routing tables in
    Pascal> this thread.

    Pascal> Also I do not believe in churn in routing tables to address
    Pascal> capacity overload. We've seen in ND that a cache that's not
    Pascal> dimensioned appropriately (too small) just causes permanent
    Pascal> look ups that multiply the traffic in the network, loss and
    Pascal> latency.

    Pascal> In classical mesh networking, what you do when the network
    Pascal> gets fully busy is that you add another root. Capacity
    Pascal> management becomes a deployment issue. Usually what we
    Pascal> address there is the bandwidth capacity on the root radio
    Pascal> space. In this thread, the problem is a bit different and
    Pascal> the routing table overload might occur one or more hops away
    Pascal> from the root. Still, the solution to increase capacity
    Pascal> needs is probably divide and conquer, and nothing will
    Pascal> replace a proper capacity planning overall.

    Pascal> RPL enables DAGs that are made of multiple DODAGs. RPL
    Pascal> enables the radio roots to be connected to a backbone, with
    Pascal> a super-root there if you want a single DODAG. RPL
    Pascal> dynamically adapts to the addition or the removal of a root
    Pascal> in an instance so adapting the capacity to new requirements
    Pascal> has only a local impact on the network. It also adapts
    Pascal> dynamically to the addition of a parent in the DODAG to
    Pascal> share the load close to the root.  So we can do divide and
    Pascal> conquer dynamically.

    Pascal> If there are enough parents and still one parent is
    Pascal> overloaded somewhere, then we might have an issue with the
    Pascal> parent selection. At the moment, a parent cannot indicate
    Pascal> the capacity of its routing table, so a node might attach to
    Pascal> parent that has no room for it. Also, one of the reasons for
    Pascal> a DAO ack is for a parent to reject a DAO for lack of
    Pascal> capacity.

    Pascal> If there are enough roots and still one DODAG is overloaded
    Pascal> somewhere, then we might have an issue with the DODAG
    Pascal> selection. We need is to push nodes on the ridge between
    Pascal> DADOGs to jump onto the other DODAG in order to balance the
    Pascal> load between DODAGs. To do that, we need a pushback
    Pascal> mechanism from the nodes where the capacity is reached to
    Pascal> the nodes on the ridge that can jump elsewhere.

    Pascal> I'm not saying that this is easy, but I think it can be
    Pascal> done.

    Pascal> Pascal

    >> -----Original Message----- From: [email-masked]
    >> [mailto:[email-masked]] On Behalf
    Pascal> Of
    >> Philip Levis Sent: Tuesday, March 30, 2010 4:27 AM To: Michael
    >> Richardson Cc: 'roll' Subject: Re: [Roll] Mixed mode operation
    >> 
    >> 
    >> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
    >> >
    >> >
    >> >>>>>> "Don" == Don Sturek <[email-masked]> writes: > Don> It
    >> would make sense to recommend to vendors they implement
    Pascal> a
    >> > Don> On the point below on hacker exploitation, mesh routing >
    >> relies > Don> on distributed routing.  I think all router devices
    >> need to > be > Don> authenticated before being allowed to
    >> participate.  For any
    >> >
    >> > Authentication may not solve anything if it does not include >
    >> non-spoofable replay protection.  My experience with
    >> L2-"security"
    Pascal> is
    >> > Consider that one can record and replay packets.  > An attacker
    >> can record packets in one part of the network and replay > them
    >> back in another part of the network.  Think of someone with a >
    >> tape recorder recording your voice in your house, and then
    >> playing
    Pascal> it
    >> > back in your office, to make someone believe you are in the
    >> office.  > This works even if you speak in code.
    >> >
    >> > This is not an active mitm attack, because no packets are
    >> actually > removed or intercepted.
    >> >
    >> > This is a VERY HARD problem to solve, because really, if the
    Pascal> attacker
    >> > just installed a high-gain antenna in one part of the building,
    >> a
    Pascal> coax
    >> > cable, and another antenna in another part of the building,
    >> it's > really the same thing!  The difference is perhaps that the
    >> totally > passive system will relay packets usefully.
    >> 
    Pascal> requiring a
    >> node to respond to a nonce before handling its packets (e.g.,
    Pascal> inserting a
    >> _______________________________________________ Roll mailing list
    >> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Tue, 30 Mar 2010 10:03:12 -0700

> I'm not saying that this is easy, but I think it can be done.

I really think this is outside the protocol specification and is a non-issue. Does any other routing protocol specify what happens when there is insufficient space in a routing table? It's an implementation-specific decision. At the very least, it should be outside the core specification. 

It's an operational/administrative issue: if the network's routing tables are overloaded, add another root. Rank and incrementing DODAG sequence numbers are a perfectly reasonable way to achieve this. We don't need additional complexity.

Phil

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Tue, 30 Mar 2010 10:28:51 -0700

+1 

-John

> It's an operational/administrative issue: if the network's routing tables are overloaded, add another root. Rank and incrementing DODAG sequence numbers are a perfectly reasonable way to achieve th…

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Mar 2010 20:32:15 +0200

On Mar 30, 2010, at 7:03 PM, Philip Levis wrote:

> I really think this is outside the protocol specification and is a  
> non-issue. Does any other routing protocol specify what happens when  
> there is insufficient space in a routing table? It's an  
> implementation-specific decision. At the very least, it should be  
> outside the core specification.

Yes I do agree. This is either an implementation specific issue or  
even more likely a deployment issue.

>
> It's an operational/administrative issue: if the network's routing  
> tables are overloaded, add another root. Rank and incrementing DODAG  
> sequence numbers are a perfectly reasonable way to achieve this. We  
> don't need additional complexity.

Definitely.

Thanks.

JP.

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 30 Mar 2010 23:15:44 +0200

JP and Phil,

	Umm, are you sure it's a good idea to punt on this issue?  Limited 
memory and interoperability has been stressed so much on this mailing 
list.  I would hate to be the poor guy trying to debug a network where 
the devices came from different vendors and each had a different table 
eviction policy.  Are you going to at least specify some sort of a 
standard error message to send back to the root in this situation?

BTW, I support the proposal to just not add new entries if the table is 
full, rather than try to evict different entries.  It's simpler to 
understand, and requires less debating on this mailing list (since the 
focus is on other issues right now).  It makes sense to revisit the 
issues Pascal brought up later.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

---

From: Philip Levis <[email-masked]>
Date: Tue, 30 Mar 2010 14:37:02 -0700

On Mar 30, 2010, at 2:15 PM, Phoebus Chen wrote:

> JP and Phil,
> 
> 	Umm, are you sure it's a good idea to punt on this issue?  Limited memory and interoperability has been stressed so much on this mailing list.  I would hate to be the poor guy trying to debug a network where the devices came from different vendors and each had a different table eviction policy.  Are you going to at least specify some sort of a standard error message to send back to the root in this situation?

I don't think the question is whether to punt; it's whether it's in the core spec. Please, someone correct me if I'm wrong, but *no routing protocol today* deals with this issue. Putting a research question on the critical path seems like a bad idea to me. I mean, I suppose we could make something up and convince ourselves it's reasonable, but the history of wireless protocol design has shown us the success of such ventures. :)

Keep in mind the situation here: someone has greatly underprovisioned their network. How would this manifest? A good implementation is going to limit the amount of energy it spends on route discovery. If there's routing table churn beyond this budget, then there won't be routes: ICMPv6 code 1. Getting a report of this to a management layer lies above RPL. But I think that's where the answer lies. E.g., in a home automation network, nodes report what their general routing state is. If it starts to look cramped, then the home automation network can initialize another node to be a DODAG root.

> 
> BTW, I support the proposal to just not add new entries if the table is full, rather than try to evict different entries.  It's simpler to understand, and requires less debating on this mailing list (since the focus is on other issues right now).  It makes sense to revisit the issues Pascal brought up later.

Let's get back to the basic requirement Anders keeps on reiterating: if I flick a light switch, the light should turn on. What happens if routing table entries are full?

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 31 Mar 2010 11:28:09 +0200

Hi Phil:

I do not think that we can live without enough capacity, trying to fix
that is a nightmare. I just wish that a network with enough capacity
works, and that is not obvious today. On the contrary, I'm afraid that
if we do nothing, a well dimensioned network will randomly expose
routing table capacity issues that will be difficult to justify.

We seem to agree that the problem is mostly a deployment problem, add a
root, right? That's certainly fine with the usual mesh problem when the
weak link is the bandwidth at the root. That's probably failing short
when the capacity problem is the routing table in a node hops away from
the root.

With the current spec, all the nodes around could select a same parent
and overload it while alternates exist with plenty of room. This might
push the capacity problem hops away from the root. If a candidate parent
can hint that it is loaded and not willing to accept much more, then the
parent selection in the children can load balance with other parents. So
the problem is again pushed back to the root and we're safe again.

If a parent can reject a DAO with a negative ack, then the child can
select an alternate parent for that DAO and the light will come up. This
is the bare minimum we can do. We already have an issue on this and I'm
asking support on the proposal.

Pascal

> From: Philip Levis [mailto:[email-masked]]
> Sent: Tuesday, March 30, 2010 7:03 PM
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; roll
> > covered in the security analysis. So I think we should only consider
> > the saturation of routing tables in this thread.
> >
> > appropriately (too small) just  causes permanent look ups that
> > multiply the traffic in the network, loss and latency.
> >
> > probably divide and conquer, and nothing will replace a proper
> > capacity planning overall.
> >
> > RPL enables DAGs that are made of multiple DODAGs. RPL enables the
> > radio roots to be connected to a backbone, with a super-root there
if
> > you want a single DODAG. RPL dynamically adapts to the addition or
the
> > removal of a root in an instance so adapting the capacity to new
> > requirements has only a local impact on the network. It also adapts
> > dynamically to the addition of a parent in the DODAG to share the
load
> close to the root.
> > somewhere, then we might have an issue with the parent selection. At
> > the moment, a parent cannot indicate the capacity of its routing
> > table, so a node might attach to parent that has no room for it.
Also,
> > one of the reasons for a DAO ack is for a parent to reject a DAO for
> > lack of capacity.
> >
> > then we might have an issue with the DODAG selection. We need is to
> > push nodes on the ridge between DADOGs to jump onto the other DODAG
> in
> > order to balance the load between DODAGs. To do that, we need a
> > pushback mechanism from the nodes where the capacity is reached to
the
> > nodes on the ridge that can jump elsewhere.
> >
non-issue. Does
> any other routing protocol specify what happens when there is
insufficient
> space in a routing table? It's an implementation-specific decision. At
the very
> least, it should be outside the core specification.
> 
tables are
> overloaded, add another root. Rank and incrementing DODAG sequence
> numbers are a perfectly reasonable way to achieve this. We don't need
> additional complexity.
> 
> Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Mar 2010 16:08:29 +0200

Agreeing on all points mentioned here.

One more comment though (in line)

On Mar 30, 2010, at 11:37 PM, Philip Levis wrote:

>> memory and interoperability has been stressed so much on this  
>> mailing list.  I would hate to be the poor guy trying to debug a  
>> network where the devices came from different vendors and each had  
>> a different table eviction policy.  Are you going to at least  
>> specify some sort of a standard error message to send back to the  
>> root in this situation?

The answer to this question is "yes", this will go in the  
manageability section of the I-D (I'll open a ticket for this), good  
point.

>
> I don't think the question is whether to punt; it's whether it's in  
> the core spec. Please, someone correct me if I'm wrong, but *no  
> routing protocol today* deals with this issue. Putting a research  
> question on the critical path seems like a bad idea to me. I mean, I  
> suppose we could make something up and convince ourselves it's  
> reasonable, but the history of wireless protocol design has shown us  
> the success of such ventures. :)
>
> Keep in mind the situation here: someone has greatly  
> underprovisioned their network. How would this manifest? A good  
> implementation is going to limit the amount of energy it spends on  
> route discovery. If there's routing table churn beyond this budget,  
> then there won't be routes: ICMPv6 code 1. Getting a report of this  
> to a management layer lies above RPL. But I think that's where the  
> answer lies. E.g., in a home automation network, nodes report what  
> their general routing state is. If it starts to look cramped, then  
> the home automation network can initialize another node to be a  
> DODAG root.
>
>>
>> BTW, I support the proposal to just not add new entries if the  
>> table is full, rather than try to evict different entries.  It's  
>> simpler to understand, and requires less debating on this mailing  
>> list (since the focus is on other issues right now).  It makes  
>> sense to revisit the issues Pascal brought up later.
>
> Let's get back to the basic requirement Anders keeps on reiterating:  
> if I flick a light switch, the light should turn on. What happens if  
> routing table entries are full?
>
> Phil

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 11:34:32 -0500 (CDT)

Catching up on this thread. 

My main concern was what happens in a storing LLN when a parent can not store the child's DAO. I thought it has to become a leaf. This has consequences in terms of what happens to its children and the fact that it could snowball into a catastrophe:

node A becomes a leaf node => reachability information stored in node A now needs to be stored in other nodes (say B and C) and these nodes also dont have memory to store this additional information => nodes B and C become leaf nodes => .... => the network as a whole goes down.

But what Pascal is saying is that this is not going to happen because I as a parent can always refuse to accept a child's DAO and still stay a storing router. The child simply finds another parent to store its DAO. The problem occurs only when it cant find another parent to store its DAO or all its parents refuse to store its DAO.

Please let me know if this understanding is not correct.

Thanks
Mukul

----- Forwarded Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Philip Levis" <[email-masked]>, "Michael Richardson" <[email-masked]>
Cc: "roll" <[email-masked]>
Sent: Tuesday, March 30, 2010 1:35:58 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Mixed mode operation

Hi:

Pascal

Of
> > This is a VERY HARD problem to solve, because really, if the
attacker
requiring a
inserting a

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 12:10:54 -0500 (CDT)

Pascal,

I totally support the negative DAO ack. I think it is critical.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Philip Levis" <[email-masked]>
Cc: "roll" <[email-masked]>
Sent: Wednesday, March 31, 2010 4:28:09 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Mixed mode operation

Hi Phil:

Pascal

if
the
load
Also,
the
non-issue. Does
insufficient
the very
tables are

---

From: Kris Pister <[email-masked]>
Date: Wed, 31 Mar 2010 10:57:28 -0700

Don Sturek wrote:
> [...] mesh routing relies on
> distributed routing.  
Hmm.  There are some very nice centralized approaches that work just 
fine. :)

All of wirelessHART and ISA100.11A use centralized route computation.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Wed, 31 Mar 2010 11:05:00 -0700

> that it does not provide this.
For those using TSCH (802.15.4E), there's built-in replay protection 
because all nodes in the network share a common sense of time.  Absolute 
Slot Number is a monotonic representation of time, and acts like a nonce 
in the MIC calculation, so replaying a packet in a different time slot 
doesn't work.
> system will relay packets usefully. 
This is a nice example, in that it's akin to the sort of weird RF 
behavior that occurs naturally.  Nodes far apart in the network suddenly 
hear each other quite well for some period of time, and then just as 
mysteriously don't hear each other anymore.  RPL had better be able to 
deal with this, or we're in deep trouble.

ksjp
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBS7FTNYCLcPvd0N1lAQLeowgAn2043p/1x9+TmWB09nJAHPvGVdHpBASJ
> fZRnHjnOjrv5H/lIe+FHC8iQUae/1+Orjyii4ev4nB3pD1alJy31pylM02bhWS9t
> lFBozHKBH3GlIq6Bh8RRyRrzE0WVdQFlvQaRcqcvhfvTxc/knc5aoEos5zMX1nx3
> aNDA55wTsWapuue8+T1Py4L6O/aOBHJQcOfHhHFdgX8R8ITM9N8wb1Jaoa3yVcXd
> tAVhB42NmP9l+Bn+pZJlstK1BrYTe/RuP2jQUjGwMqfhjfwXjD6KTKmCBmr+b8xP
> Ztmla/UjKwrXoACEhavCF7sJnHkmJxtdwfwLsjLz7md9PvQJLWP2UA==
> =0QxQ
> -----END PGP SIGNATURE-----

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Mar 2010 14:42:45 -0400

>>>>> "Kris" == Kris Pister <[email-masked]> writes:
    Kris> For those using TSCH (802.15.4E), there's built-in replay
    Kris> protection because all nodes in the network share a common
    Kris> sense of time.  Absolute Slot Number is a monotonic
    Kris> representation of time, and acts like a nonce in the MIC
    Kris> calculation, so replaying a packet in a different time slot
    Kris> doesn't work.

Thanks, that's good to know.
How long is the time slot?

---

From: Owen Kirby <[email-masked]>
Date: Wed, 31 Mar 2010 12:40:09 -0700

Mukul, Pascal,

Please correct me if I'm wrong, but are we really sure a *negative* ack 
is what we need in this case?

It seems to me that if the root needs to send a negative ack because the 
routing tables are full, then the root could be in a state where it's 
unable to route the NACK to the node that sent the DAO in the first 
place. In which case, the node never gets a NACK and will assume that 
the reverse route is being stored on the root.

To illustrate how this might happen on a non-caching network:

A -> B -> C -> ...   -> Root

1) C sends a DAO, and fills up the routing table on the DAG root so it 
can't accept any more DAOs.
2) B sends a DAO to the root. The root can route a NACK back because it 
knows how to route to C, and the parent set in B's DAO contains C.
3) A sends a DAO to the root, but the root doesn't have a route to B and 
thus can't find a route back to A.

It seems to me that a positive ack would be more appropriate in this 
case. This would also prevent inconsistencies if the DAO or NACK gets 
lost due to interference.

Thanks,
Owen

Mukul Goyal wrote:
>>> In classical mesh networking, what you do when the network gets
>>>       
> fully
>   
>>> capacity on the root radio space. In this thread, the problem is a
>>>       
> bit
>   
>>> different and the routing table overload might occur one or more
>>>       
> hops
>   
>>> away from the root. Still, the solution to increase capacity needs
>>>       
> is
>   
>>> If there are enough roots and still one DODAG is overloaded
>>>       
> somewhere,
>

---

From: Kris Pister <[email-masked]>
Date: Wed, 31 Mar 2010 15:26:04 -0700

> How long is the time slot?
It's configurable, but for a full 127B 15.4 packet plus secure ACK you 
can get the slot down to under 6ms.
HART uses 10ms because they wanted to make sure that people could do it 
with existing off-the-shelf chips.

ksjp

---

From: Philip Levis <[email-masked]>
Date: Wed, 31 Mar 2010 19:28:16 -0700

On Mar 31, 2010, at 11:05 AM, Kris Pister wrote:

> For those using TSCH (802.15.4E), there's built-in replay protection because all nodes in the network share a common sense of time.  Absolute Slot Number is a monotonic representation of time, and acts like a nonce in the MIC calculation, so replaying a packet in a different time slot doesn't work.

Unfortunately we can't assume 802.15.4E. :(

> This is a nice example, in that it's akin to the sort of weird RF behavior that occurs naturally.  Nodes far apart in the network suddenly hear each other quite well for some period of time, and then just as mysteriously don't hear each other anymore.  RPL had better be able to deal with this, or we're in deep trouble.

It does not seem an undue burden to me for a node to send a request/response that demonstrates another node's real presence before making that node its preferred parent. Or are there simpler mechanisms?

Phil