Hi Carsten,
> -----Original Message-----
> From: Carsten Bormann [mailto:[email protected]]
> Sent: mercredi 14 octobre 2009 15:34
> To: Julien Abeille (jabeille)
> Cc: 6lowpan
> Subject: Re: [6lowpan] Fundamental assumptions of
> 6lowpan-nd-06: (1) Addressresolution is a waste of energy
>
> On Oct 14, 2009, at 14:54, Julien Abeille (jabeille) wrote:
>
> > redefine as little as we can
>
> Julien,
>
> discussing this in generalities doesn't help.
>
it does. We also need to understand, what IP advantages we keep with
6lowpan-ND, what we loose, in terms of reusability, simlicity, cost...
Asking questions solely in terms of protocol efficiency does not work,
as these are not the only parameters to take into account. If it was
only about protocol efficiency in the lowpan, I would personaly not use
IP at all.
So trying to detail both sides:
- In a number of scenarios, people are fine with mandating the IID to be
forged on the MAC
- not sending NS saves power
What we lose:
- complexity: we end up implementing one ND per link type
- reusability: we reevent protocols per link type. This one can get
important when it comes to education, network management...
We also have major disagreement on assumptions, which I try to
summarize:
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.
B. we agree on the non transitive aspect
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
D. we all agree we are considering a route over scenario
For those who think duty cycling solves the sleeping nodes issues:
- only DAD fails. Do we agree on this?
For those who sleeping nodes are a problem:
- AR, NUD, DAD fails
Is the summary fair?
Best,
Julien
> 4861-style address resolution does not work in a LoWPAN.
> So what do we do?
> "Redefine as little as we can" would clearly guide us to
> leave it out, because that's the minimum redesign.
> ("Design is done when there is nothing left to remove"...)
>
> But I'm not interested in design that is just based on
> general items of philosophy.
> I also care little about general points regarding what ATM
> did -- LoWPAN nodes are not $50k, but $.50 systems, so some
> tradeoffs are likely to be extremely different.
> These are resource-constrained systems, so we shouldn't
> design something new that just wastes resources.
>
> I want to know whether we *need* address resolution.
>
> Pascal gave one very good data point here: It's mostly not needed.
> I would like to know when it's still needed, and where the
> static IID- LLA mapping does not cover those needs.
>
> Once I know that, I'd like to know what are good, *working*
> (and reasonably efficient) ways of meeting those requirements.
> Hijacking messages from 4861 and giving them different
> semantics does not qualify; we should be upfront where we
> design new protocol (although we may be able to reuse
> formats, as we did in 6lowpan-ND-06).
>
> Gruesse, Carsten
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
