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
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
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
> 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
