On Oct 13, 2009, at 0:52 , Carsten Bormann wrote:
On Oct 12, 2009, at 23:30, Geoff Mulligan wrote:
On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote:
On Oct 12, 2009, at 21:01, JP Vasseur wrote:
I do not think that the issue is the code size itself but a change
in the architecture, thus
the reasonable question on whether we could find a simpler approach
compatible with
4861 to handle the case of non transitive links that preserves the
architecture.
6LoWPAN-ND is "compatible with 4861".
(BTW, the "architecture" of IPv6 is in 2460, and we are not
optimizing
that.)
Carsten,
Is this true? Could I have a 6lowpan node that implemented just
standard 4861
No.
That's not the meaning of "compatible" I meant.
Since 4861 never worked on 6lowpan (with the exception of 1) a two-
node 6lowpan, or 2) a fully transitive mesh-under with reasonably
reliable multicast delivery, yadda yadda), there is very little use
for that kind of compatibility.
It also works for the 2-node case only if those nodes are on all the
time. Sleeping nodes are a big problem also for a simple mesh-under
network. It basically looks like non-transivity.
ND is a link protocol, you need to run the same protocol on all
interfaces of the same link. If you really want to deploy a simple
LoWPAN with RFC4861 you can do that. Just make sure you run RFC4861 on
all interfaces. I'm not convinced of the value of even requiring that
they are mixed.
I think two-node 6lowpans and fully transitive mesh-unders are not
the main applications we have in mind.
(Yes, >2-node networks that happen to have full-mesh radio
connectivity also work, until they no longer happen to have it.
Given the vagaries of radio propagation, I don't think that's sound
design.)
Even if 4861 worked for more interesting cases, the simplifications
of 6lowpan-ND are a net win for constrained nodes.
The only nodes that need code for both 4861 and 6lowpan-ND are the
Edge Routers; of course the two protocols are similar enough that
most of this code will be shared.
The use case of "having my laptop in a 6lowpan" is probably best
solved by the driver adaptation/translation I described.
It is already possible to plug a simple device into a PC today and it
works with a standard IPv6 stack. Over the air we of course speak
6LoWPAN-ND. But to the IPv6 stack it is transparent. This I don't see
as an issue.
- Zach
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
