Hi Carsten,
On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote: > Sure it would be nice if that "just worked", but it doesn't. As far as I see, among the procedures defined in 4861 (address resolution, NUD, router discovery, prefix discovery, redirect, next hop determination, parameter discovery, next hop determination, DAD) ony DAD fails. Just do proxy ND on each lowpan node and this is solved. <Pascal> Probably the main reason why the group went for the white board model was to avoid flooding over a potentially large network of potentially very battery-constrained nodes. Also I wouldn't simply proxy ND recursively without any structuring. If you could, there'd be no need for routing protocols or spanning tree and all that sort of things. You'll note that 6LoWPAN ND has only one backbone so the hierarchy for proxy ND is clear and loopless. Same goes for WIFI ESS. Within the LoWPAN we certainly do not proxy ND and we require a real routing protocol such as RPL within an edge LoWPAN or something OLSR/OSPF for a more core network such as FR/ATM. </Pascal> regarding the assumptions that you do not know whether your neighbors are sleepy and will receive an IP packet (this is the underlying assumption about failure of NS.., end of 1.2) - RPL will break with this assupmtion (many protocols will) - why do you though garantee that unicast will not? - for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are awake - if you cannot garantee that your neighbors are awake, how do you reach the white board? <Pascal> Synchronizing with one neighbor to forward unicast is a lot easier and economical than having to wake up all neighbors just to have them repeat multicast queries that no one is interested in. Some link layers synchronize time slots, while others use a preamble to wait for the next-hop to wake up. From L3, either way is certainly fine. What we care is for the operational cost on resources, in particular battery. And multicast is not your friend. Basically, we must avoid by design any situation where a node has to wake up just to listen to a packet and then drop it because it is not concerned after all. </Pascal> - once you confirmed reachability of a neigbor through white board, how do you know your app will manage to wake him up? for me this assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to provide very high reliability and very low duty cycle for years in real deployments. In these environments as I said 95% of 4861 ND works, only DAD fails and can be fixed trivialy. <Pascal> Wrong problem though. The problem is NOT to reuse 4861 at all cost. The problem is to find an ND solution for non-transitive links that fits within power and implementation size constraints, supports mobility (inherent to radio transmissions even for fixed nodes) and scales to the thousands over the said non-transitive links within the said power constraints. I am not in favor of adding an RFC 4861 solution that works only in specific configurations, and fits none of the requirements above. This can only increase the implementation cost and confuse the market. We discussed that at the meeting in Dublin and the approach that was followed since then is the one that got the WG consensus. What I think we agree upon though, is that the ND solution for 6LoWPAN should be one of much larger applicability than say, 802.15.4 for which the WG was initially created. The authors spent considerable efforts just to make it so and we think that the proposed approach is fit for non-transitive links in a way more general fashion. I think that we should concentrate our efforts in that direction, rather than looking behind at RFC 4861. </Pascal> Cheers, Pascal
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
