Re: [6lowpan] Fundamental concerns about 6lowpan ND

["Pascal Thubert (pthubert)" <[e-mail]>]

Brian, Bob,

Needless to say, I completely agree with Carsten here. 

You might also want to talk to Samita who led the effort for using 4861
and is now a coauthor of the 6LoWPAN ND, and to Erik, of course.

Let me try to give you some additional background:

> ... RFC 2491 was written to capture those interfacing 
> functions needed to allow NDP and such to operate correctly.

RFC 2491 expects a MARS based service to enable a multicast emulation
for ND and present a common face to ND.

So we do something similar with a registrar of sorts, but a lot simpler
and more economical as it is integrated in ND.


>       Is it possible that standard IPv6 nodes could operate on a 
> 6lowpan network as well as a more traditional (e.g.,

Another question is whether that is desirable. There are assumptions
behind classical NDP as described in RFC 4861. The farther you go from
those assumption, the least NDP as its stands applies, and the more
costly the adaptation layer becomes. Classical NDP being optimized for
potentially large transitive networks with a high degree of trust and
few specific destination. It is based on assumptions like:

* reachability is Boolean, yes or no, whereas it is rather fuzzy in our
world. 

* CPU/NIC card time is cheap. Certainly not the case for us. Listening
costs as much battery as sending on most radios.

* links are transitive whereas the connectivity graph in our world is
not, but rather very dynamic and complex

* multicast and medium time are cheap, which is certainly not the case
for us. Yet, we have use case with 10K nodes in a single subnet. And a
node should never be awaken by a packet for which it is neither a router
or an end point.

* Multicast is easy. In NBMA, the air time of a multicast packets is
multiplied by the branches in the tree. When applied to radios,
multicast can become even more complex in that it can interfere with
itself as it gets propagated along the connectivity graph with such
effect as hidden terminal. The overall interference impacts
transmissions inside the graph for a lot longer than the transmission of
a packet.

* storing a packet during a reactive lookup is fine, which is certainly
wrong for a router that can only store one or 2 packets at the same
time. 

* The binding cache can be large enough and cheap to renew. Wrong again
for us, we have critically limited room and cannot afford the NS/NA
churn that results from a cache that's too small for the set of
neighbors. 

As you figure, in the rainbow of ways of doing ND, reactive discovery
using a global flooding and proactive discovery using a centralized
registry appear to be standing at the extremes. And our needs are a lot
better served by the other end.


> ethernet) one?  If so, this seems like a lot of complexity needed in 
> that device to determine the type of link it is operating on.

The 2 modes are not mutually exclusive. I'd say that 6LoWPAN-ND is
sufficient for a LoWPAN node, but that additional means such as RFC 3122
or RFC 4861 will provide other information and allow bypassing the
router when that's affordable.

Interestingly, the 6LoWPAN-ND method could be used in conjunction to
4861 on Ethernet as well, for the purpose of such operations as Source
Address Validation. There are things that the current work at SAVI
cannot do, for instance serving properly a multiply homed host that uses
an address from another interface. 


>> ...  Yet, IPv6 over 802.11 works relatively well.

Certainly not on flat 802.11 (aka adhoc mode).

RFC 4861 works on 802.11 infrastructure mode. Infra mode that is an
adaptation layer that that emulates Ethernet and does not exist in other
media that we serve- which include 802.11 adhoc mode, in particular Low
Power WI-FI though 802.15.4 dominates at this very moment. 

Interestingly, 6LoWPAN ND can very well be seen as an L3 generalization
of 802.11 infrastructure mode BSS (the edge router is a L3 access point
of sorts) and ESS (edge router proxy ND whereas APs proxy transparent
bridging), and coupled with RPL you can get a L3 generalization of
802.11S.

My conclusion:

Yes, we are definitely interested in bringing our NDP extension to a
larger audience because:

- a whole industry is waiting for us; that industry can hardly accept a
solution that would be constrained to a single type of interface
- we need a good story on how ND and (ROLL) RPL work together. That
story might be a lot different if this ND extension is adopted
- Classical NDP is reactive. It just makes sense to complement it with a
proactive option for cases where that applies better.
- The ND extension that we propose can actually cohabit and enable
interesting options on all sorts of media, though coming from the other
end of the rainbow, it is probably more adapted to NBMA than it is to
transit.

But we need you to consider the proposal in a very open minded way as
opposed to try to place 4861 there at all costs, that we already
determined that we could not afford. 

Cheers,

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf Of Carsten Bormann
>Sent: mercredi 14 octobre 2009 16:30
>To: Brian Haberman; [e-mail]
>Cc: 6lowpan
>Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND
>
>Brian, Bob,
>
>since JP dragged you in at this stage, let me try to summarize four
>years of discussion in one message (which probably won't work).
>
>6LoWPANs are non-transitive, but are quite different from 20th century
>NBMA links.
>We started out in 2006 by trying to modify ("optimize") 4861 to cope.
>That work led nowhere.
>At the Dublin IETF, 2008, we finally decided to address the issues in
>a more radical way, and we now have a spec that is close to completion.
>
>Some people came in later and now wonder why we abandoned the "minimum
>change" approach.
>Well, we didn't, but the minimum change is a bit different than we
>originally thought.
>
>>> Is an 802.15.4 network that much
>>> more of an onerous environment for the base IPv6 protocols
>>> (modulo some modifications/extensions)?
>
>802.15.4 networks are wireless.  Most nodes are extremely resource-
>constrained, see RFC 4919 and in particular
http://tools.ietf.org/html/draft-ietf-6lowpan-routing-
>requirements-04
>  for details.
>
>The main difference from 20c NBMAs (apart from the resource issue) is
>that, in a multi-hop wireless network based on low-power nodes, the
>definition of "neighbor" is much more tenuous than in ATM or FR.  So
>we arrived at a somewhat different model of links and address
>assignment.  This model is also motivated by the extremely small frame
>sizes of 802.15.4, which make header compression a core part of the
>architecture.
>
>>>      Is it possible that standard IPv6 nodes could operate
>>> on a 6lowpan network as well as a more traditional (e.g.,
>>> ethernet) one?
>
>Some are, we call these "edge routers" if they actually forward
>packets.  The large majority of nodes (hosts and routers) are 6lowpan-
>only (and these are typically the extremely resource constrained 8
>MHz, 10 kB $.50 SoCs).
>
>>> If so, this seems like a lot of complexity
>>> needed in that device to determine the type of link it is
>>> operating on.
>
>I don't follow -- a node would know whether one of its interfaces is
>on a LoWPAN or an Ethernet.
>
>More importantly, it is extremely unlikely that a LoWPAN is going to
>be set up for the same applications that we run over Ethernet today (.
>11 is much better for that purpose).
>
>>>      I agree that non-transitive links are an issue for more
>>> than just
>>> 802.15.4 networks.  The description given could be applied to
>>> 802.11 as well.  Yet, IPv6 over 802.11 works relatively well.
>
>For .11, we are talking about 2-3 orders of magnitude higher bit
>rates, 3 to 6 orders of magnitude more power (electrical), CPU speed,
>and memory per node, much more stable networks held together by
>relatively powerful access points mostly directly connected to even
>more stable Ethernet backbones etc.
>To a laptop, an 802.11 network is pretty much an Ethernet, so it's no
>surprise that 4861 works well.
>
>>>      It appears that a cross-WG review would be a good idea
>>> at this point.  I would like to see some 6MAN contributors
>>> comment on this work rather than waiting until a Last Call.
>
>
>I would love to have a Bar BOF/extended hallway meeting in Hiroshima
>about this.
>The 6lowpan WG meeting is currently scheduled at Monday morning; we
>are likely to spend some time on 6lowpan-ND there.
>If you think it's worth giving a summary presentation at 6man (Tuesday
>morning), that certainly can also be arranged.
>
>Gruesse, Carsten
>
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan