Hi all,
summarizing my thoughts:
1 about sleepy nodes
MAC layer approaches such as sampled listening (wise MAC...) or
centralized (TSMP...) ensure that packets are received, multicasts or
unicasts, if they need to, with very low duty cycles (~0.1%).
If we assume that packets are very frequently lost (at IP layer) because
nodes are sleeping, then most IP protocols will break.
If we assume this only for multicasts, RPL for instance will have
trouble
If we assume this also for unicasts, there will be problems to reach the
white board for NUD. Then if we manage to reach it, the application will
have trouble to reach the neighbor.
2 about the superiority of a unicast approach compared to a multicast
one with regards to power consumption (expressed in terms of nodes
needing to wake up)
- sample network topology 1 (L2):
5 hops tree (2 childs per parent), 1+2+4+8+16+32 nodes. average number
of neighbors is around 3. average number of hops to sink is around 4.
multicast NS needs 4 nodes awake (1 sender + 3 receivers) for one packet
transmission
unicast NS needs 2 nodes awake for 4 packet transmissions = 8
Hence it seems that in this topology (one of the target scenarios i
guess), multicast uses less power than unicast
- generally the number of nodes that need to wake up for a mcast NS is 1
+ average number of neighbors
number of nodes that need to wake up for unicast is 2 x average number
of hops
There are probably topolgies where the unicast is superior, but in the
general case it is not clear.
Am I missing something?
3 about changing ND for specific links
- It is clearly acceptable in the general case (Carsten quotes from
4861). It does not mean that it is a must, and reusability is clearly
also an advantage. hence I am ok to revise ND if there is a clear need
(see below why I think there is not except for DAD)
- RFC3122 (inverse ND) is an extension to ND, not a redesign
4 about layer 3 addresses and layer 2
I do not think it is reasonable to allow disabling address resolution (I
know nd-06 is more flexible). I think it should be mandatory for all
nodes to do address resolution. If the L2 address is deducted from L3,
what is the use of a L2 address? The layering is not respected, and i do
not think there are enough reasons to do so.
5 what needs to be fixed in my opinion
considering 1 and 2, non transitivity is the only issue I am convinced
about with 15.4. I guess only DAD needs to be fixed in these
environments with possible changes to ND. the rest should remain
optional in my opinion, or be part of an ND update/deprecation in 6man
Best,
Julien
________________________________
From: [email protected] [mailto:[email protected]]
On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 13 octobre 2009 14:53
To: Mathilde Durvy (mdurvy); 6lowpan
Cc: Patrick Wetterwald (pwetterw)
Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND
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
