Ron,
These are excellent points.
I would like to hear from other on the list about the idea of supporting
extremely small devices (4K) (smaller than the extremely small devices
that we have been targeting (32K)). I would not like to choose to miss
a potential market segment (potentially large market segment), but is it
reasonable to got after a 4k device which probably could not possibly
ever accept a 1280 byte (minimum size ipv6) packet.
I think question 2 is going to be critical as we move to the next phase
of this working group. Hopefully we will finish the format document and
start on rechartering. One of the top areas that I think we need to
look at is the idea of utilizing Manet and how the design will impact
6lowpan (memory, power, other costs). And whether or not we choose to
use the manet approach and protocols, should we down select to a single
protocol or some small set and if so what is the criteria for this
selection.
Please consider what criteria you think we should use to evaluate the
available mesh protocols.
While the IETF doesn't appear to embrace architecture docs, it is
critical for us to agree on some set of use-cases so that we can focus
our efforts on providing real solutions.
So again, please consider for our rechartering and new work items,
should we generate a set of use-cases? What is the format for this?
Should we support extremely small devices? And finally what criteria
should we use to determine the selection/evaluation of mesh routing
protocols (which probably begs for a use-case analysis.)
Folks, please start to participate in these discussions. It is only
with your input that we will have a successful working group and will
create a standard that is useful in the market.
geoff
On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:
> 1. Many sensor and control devices will be too small to support a full
> mesh/ip adaptation implementation. Some of these devices may be as small as
> 4K of flash and 100s of bytes of RAM and may only be used in a point to
> point (P2P), simple star, or very simple mesh implementation (please see the
> attached pdf drawing). Incorporation of these very small devices, I
> believe, is important to the broad adoption of 6lowpan.
>
> Should we consider how to support these extremely limited devices? Should
> we make it easy for these simple protocol implementations at this level to
> adapt to 6lowpan? If we want to include these small devices, should we
> consider a more constrained design (limited payload, P2P/star only) that
> would simplify the adaptation layer?
>
> 2. How will the group evaluate what mesh, P2P or star protocols should be
> supported? As David pointed out, we may not be allowing for future
> capabilities in the current structure of the adaptation layer should we want
> to support multiple types of L2 protocols.
>
> 3. Related to the pending mesh protocol evaluation, is the evaluation of any
> functionality related to the "cost" of those technical choices in terms of
> power, code size, complexity, RAM, instructions executed, etc?
>
> 4. As was mentioned on the list a while ago, neither the Problem Statement
> nor the Format documents discuss the overall 6LoWPAN architecture. As we
> move forward with our next working group items, shouldn't we create a
> document to describe the high level architecture which might well encompass
> the criteria for evaluation of the protocols and costs mentioned above?
>
> Ron Strich
> Mobile: 228.369.4332
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
