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
