it does. We also need to understand, what IP advantages we keep with
6lowpan-ND, what we loose, in terms of reusability, simlicity, cost...
There is no change to IP.
- reusability: we reevent protocols per link type. This one can get
important when it comes to education, network management...
It's much better to have a new protocol than to misuse an old protocol
in ways it never was designed for.
A. one camp assumes although nodes are sleeping, well known and
deployed
duty cycling techniques makes nodes appear always on. The other camp
thinks there are always nodes that cannot be reached 100% of the time.
I think 6lowpan-ND must cope with both kinds of nodes.
In general, that makes all protocol mechanisms that expect hosts to
react to unsolicited messages somewhat difficult.
C. one camp considers the link asymetric. IP applications will not
work
in this scenario either. I do not think we are in a UDLR environment
Well, there is no assurance of symmetry, but I'm not sure what you
mean here.
D. we all agree we are considering a route over scenario
I don't agree with that.
6lowpan-ND should work for mesh-under as well, and should not require
LoWPAN-wide multicast for that.
6lowpan-ND should also work in a minimal "star network".
For those who think duty cycling solves the sleeping nodes issues:
- only DAD fails. Do we agree on this?
4861 DAD (and everything else that would require multicasting NS
throughout a LoWPAN) fails independent of sleeping nodes.
For those who sleeping nodes are a problem:
- AR, NUD, DAD fails
4861 AR (and everything else that would require multicasting NS
throughout a LoWPAN) fails independent of sleeping nodes.
Wait, 4861 does not even *specify* AR for NBMAs, so nothing is
failing, it's just not there.
(To return to the subject of this thread: Losing AR apparently is not
a problem.)
NUD is interesting, because 4861 uses it for a number of things.
Maybe we can return to this later.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
