Behcet,
Just to be clear - the future is now. We have and others have
implemented IPv6 on 802.15.4 - it works and is deployed. Our stack is
not yet 6lowpan compliant in that our frame format is not the same as
6lowpan but this is a small tweak.
geoff
On Wed, 2006-07-19 at 20:10 -0700, Behcet Sarikaya wrote:
> I agree with Phil, I think we should have his consideration considered
> seriously.
> Regarding his question, in the format draft, 802.15.4 MAC layer is
> assumed and the frame sizes are from IEEE standard. This WG assumes
> that even the light sensors support 802.15.4 MAC (kind of like Telos
> motes). In that sense this WG is addressing futuristic sensor nodes on
> which IP stack can be implemented. How close that future be, we do not
> know.
>
> Regards,
>
> Behcet
>
> ----- Original Message ----
> From: Philip Levis <[EMAIL PROTECTED]>
> To: Geoff Mulligan <[EMAIL PROTECTED]>
> Cc: 6lowpan <[email protected]>
> Sent: Wednesday, July 19, 2006 5:34:17 PM
> Subject: Re: [6lowpan] WG Last call on Problem Statement Document
>
> On Jul 19, 2006, at 2:29 PM, Geoff Mulligan wrote:
>
> > Folks,
> > This note formally starts the WG Last Call for comments on
> > draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions,
> > Problem Statement and Goals".
> >
> > The document can be found at:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt
> >
> > The document is intended to be submitted by this Working Group to
> the
> > IESG for publication as an Informational Document.
> >
> > Please review the document carefully (one last time), and send your
> > comments to the 6lowpan list. Please also indicate in your response
> > whether or not you think this document is ready to go to the IESG.
>
> One consideration and one question about an implication. Both stem
> from the scarcity of storage (RAM or non-volatile) on many of these
> devices, due to power and cost considerations.
>
> Consideration: the draft acknowledges that LowPAN devices may be
> deployed in large numbers (possibly in high density) but require low-
> state/low-overhead protocols. It might be useful to make this
> statement a little stronger, and comment that protocols which
> require
> state for every "neighbor" (whatever that means) are not feasible.
> Rather, protocols which can scale to different degrees of accuracy
> (e.g., I can store 10% of the neighbors, vs. 50%) are preferred.
> Otherwise, you have a box with 10,000 nodes in it and the protocols
> collapse.
>
> Question: The requirement for fragmentation and assembly below IP,
> given the minimum packet size of 1280 octets, seems to preclude most
> devices that have, e.g., 2K of RAM and no other feasible storage
> medium. I don't mean to suggest that this limitation on scope or
> statement of requirements is a problem: you have to cut the line
> somewhere. Rather, would making this explicit be helpful?
>
> Phil
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
