 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Roger,The spec is exactly along the lines of what you wrote: intermediate nodes can store routes of course, and RPL does not mandate to store route at the DAG only. Some networks will exclusively use hop by hop routing with route storage at each hop, others won't, others will have a mixed of nodes and RPL
does support them all. Cheers. JP. On Nov 17, 2009, at 12:42 AM, Roger Alexander wrote:
Sorry for the earlier transmission of the incomplete email...(moving vehicle)...final thoughts completed below.Thanks. RogerOn Nov 16, 2009, at 3:33 PM, Roger Alexander <roger.alexander at ekasystems.com > wrote:It seems that the intermediate nodes that do maintain DAOs can limit overhead by avoiding the need for all changes in node connectivity to the DAG from having to always go all the way to the root to provide for maintaining an outward path. Furthermore if only the root stores DAOs the RPL reduces to a source routing protocol which may be an issue.On Nov 13, 2009, at 6:44 PM, Michael Richardson <mcr at sandelman.ca> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1mcr> I guess it might be enough to have a bit that gets turned by the"Richard" == Richard Kelsey <richard.kelsey at ember.com> writes:mcr> first non-root node that stores DAOs.Richard> I think you need two bits. One is turned on by the root ifRichard> it stores DAOs and the other is turned on by any Richard> intermediate node that stores them. I didn't realize that the root could *not* store DAOs...! I'm trying to imagine how that works. I can perhaps see how this might be the case with an ungrounded DAG, where some random DAO-incapable node decides to become the new root.mcr> If I understand correctly, if the intermediate nodes do not store mcr> DAOs, then they won't have a routing table to other peers, so p2pmcr> traffic will have to travel all the way up to the root and out mcr> again. Richard> Yes. On the other hand, the DAG formation mechanism works Richard> to maximize downward fanout, which in turn maximizes the Richard> number of P2P routes that go through the root even if all Richard> nodes store DAOs. For example, if the root has N childrenRichard> with roughly equal subgraphs, then each node can reach onlyRichard> 1/N of the network without through the root.Yeah, I can see how a relatively uniformly distributed DAG would have this property. I can also see where this would not be the case, such as a long linear network, such as a series of lampposts or utility polesalong a rural road... where the grounded node is at one of the road.It seemed to me like a compromise that the root had to be able to create source routes so that weaker intermediate nodes could avoid storing the DAOs. That this wasn't the ideal situation, but was a compromise. What happens if we insist all nodes store DAOs? (is it simpler?)Richard> That uses too much RAM for us to require it. Yes, I understand why we can not do it. You see, I'm asking what the real tradeoff is about this. If ram and CPU was free, but network bandwidth was not, would we decide to force all nodes to store DAOs? JP has suggested that it helps.It does help when intermediate nodes store DAOs since DAO information should only need to be passed further up towards the root when the info represents a change in outward (to leaves) connectivity. That is, if a node changes parent and reattaches to a new branch that information only needs to travel inward towards the root to the point in the tree that held an outward table containing the given node. Granted it may be in some cases that point is at the root itself. However, in the absence of DAO storage at intermediate nodes a node's change of parent must always be conveyed all the way to the root so that outward connectivity (via source routing) can be supported. For nodes not maintaining state, the change of parent information must always flow back to the root or otherwise to the first DAO storing node (which may then need to update it's parent(s) if the stateless node was not previuosly reachable via the stateful node).I can see with a linear network where there is traffic up and down the line, that without DAO storing nodes in the middle, traffic has to goall the way to the end and back.What happens if we insist that no nodes store DAOs? (is it simpler?)Richard> Do you mean no nodes at all, or no nodes other than the Richard> root? No nodes other than the root.... Nothing would work if nobody knew the routes, right. Richard> If only the root stores DAOs, then most of the P2P traffic Richard> will go through the root. As I said above, this is oftenRichard> the case even if all node's store DAOs. I think this wouldRichard> be OK. Even without intermediate DAO storage, routing Richard> packets directly to neighbors will reduce the P2P messages Richard> traveling through the root. Devices that require more Richard> bandwidth (in or out) can become roots of their own DAGs, Richard> as long as the number of such devices is limited. To summarize, forbidding intermediate nodes to store DAOs: - causes a loss in quality for p2p traffic for some topologies,It also creates additional routing traffic towards the root which is needed so that the reverse path information from the root to the node can be conveyed to the root for subsequent outward routing.but for many topologies has a neglible effect - causes no change for m2p - massively reduces traffic when there is a new parent chosen - simplifies the protocol (no need to record who records DAOs)Not clear why there is a need to know who records DAOs. In response to a new child a parent that does maintain state will add itself to the path information from the child and pass that information to it's parent. That information will pass inward towards the root until a node is encountered that can store the path information and previously supported connectivity to the node at the same cost.- removes the need for code to do different things depending upon whether there are DAO storing nodes above, when changing parents.The nodes that do not store DAOs can have a consistent behavior while those that do can similarly also be consistent.Or to be it another way, capable nodes that have the ram to store DAOsare causing load on less capable nodes. They aren't being very helpful.- --] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | device driver[ Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE >then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSv4ZbYCLcPvd0N1lAQLyNQf+JhBgKbIXe/Fj9knKJwWuflxOwDndPzHF AiZIszE8gxjHKUyd7UPC/b7Mf/kQvIO9v05inqaUazjK4a1n9aY6J4/dKONGzpNl p+DO9LkBo5j9wnSdc6KU3YIgv2apznSxX6Q/FTIh6Jt9yPUcq9wyFUKAETrIqw67 WGxqhkHq58xBWJD5SPfvvun2dnZMXWMOrQ1lICWFO3B14Z0F42wMAr06ZmcNk7ko xup7hh8HDe2QqJ504PKP9S9C5KrJpHWjEPmLvvJbqUumNnHPOkc5R39XKRNjH1bF YbuW4YqEixUrTooNjYRZ2s7M+Sv2rDbR4Vur+zXimFthXnWj3fsiKg== =slpm -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll at ietf.org https://www.ietf.org/mailman/listinfo/roll_______________________________________________ Roll mailing list Roll at ietf.org https://www.ietf.org/mailman/listinfo/roll_______________________________________________ Roll mailing list Roll at ietf.org https://www.ietf.org/mailman/listinfo/roll