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.
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.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
