|
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
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
|
