On Oct 14, 2009, at 18:05 , Julien Abeille (jabeille) wrote:
Hi Carsten,
I got the mesh under point.
Do we agree that
- in route over
- considering duty cycled nodes with efficient duty cycling techniques
(smapled listening, centralized scheduling)
(RFC4861) AR works (I can resolve addresses of one hop neighbors), NUD
works,
AR and NUD initiated by an RFC4861 interface on an Edge Router will
fail in route-over configurations for any destinations outside of
radio range. This is the result of the non-transient link:
ER ---- A ---- B ----- C
++++++
As you concluded, NS/NA is only useful within radio range. Let's
assume ER and A are within radio range. ER attempts to send to C. What
happens to the NS? Fails. This is why I don't see RFC4861 without any
adaptation as a solution on a LoWPAN interface. It expects that NS/NA
messages reach the whole subset of nodes on the link, but that is not
the case.
This is the reason why we have a whiteboard with entries for all
LoWPAN nodes (A, B, C). For all AR, NUD and DAD requests coming from
the ER side it is able to answer them immediately (without any
overhead to the LoWPAN!). The whiteboard also enables DAD for NRs
coming from the LoWPAN side.
I agree that within the LoWPAN some kind of 1-hop NUD may be useful,
and that should be discussed.
Zach
router and prefix discovery... Work
DAD fails
In other terms features related to reachability of one hop neighbors,
resolution of their address, router/parameter/prefix discovery work?
Addressing related features fail?
Julien
-----Original Message-----
From: Carsten Bormann [mailto:[email protected]]
Sent: mercredi 14 octobre 2009 16:50
To: Julien Abeille (jabeille)
Cc: 6lowpan
Subject: Re: [6lowpan] Fundamental assumptions of
6lowpan-nd-06: (1) Addressresolution is a waste of energy
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.
Got it.
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.)
I'll stop on semantics
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
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
