On Jul 20, 2006, at 1:32 PM, Geoff Mulligan wrote:
On Thu, 2006-07-20 at 08:52 -0700, Philip Levis wrote:
On Jul 19, 2006, at 8:10 PM, 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.
You can totally write an IP stack -- even a TCP stack -- on sensor
nodes today, admittedly the ones that have the biggest
microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP
stack might not have a lot of RAM for windowing and high performance,
but that's rarely the goal. You can do it.
We have already built an 802.15.4MAC/AODVtiny/IPv6/UDP stack that will
run on a 64K part and, with some optimization in the MAC, should
run on
a 32K part. For a non-routing node (read RFD) it should run on a 16K
part! As Phil rightly points out, RAM is actually more of a
constraint.
16K RAM or program memory? If RAM, it sounds like you're talking
about an ARM or an MCU with an external memory attachment. The
largest microcontroller (not microprocessor) I know of is the
MSP430F1611, with 10K. Are there others? I'm sure you could easily do
all of those things in much less than 16K of RAM.
If you're talking about program memory, yeah, 32K sounds right, and
16K would be really squeaking it in.
I don't think the requirements the document implies are unrealistic
or onerous. As I said, you have to cut the line somewhere. My comment
was just that they *do* preclude smaller nodes whose storage cannot
hold a complete IPv6 packet, and it might be useful to note as such,
since the document is defining the problem statement, and therefore
the problem scope.
There certainly could be a problem for very small parts (ie those with
very limited RAM - 2k) where it could be nearly impossible for the
device to store a complete 1280 byte IPv6 packet, but I think with
some
judicious use of memory it might be doable even on a 2k ram device so
long as it isn't trying to maintain routing tables.
OK, we can quibble about where the line is (2K, 1K, 1.5K, 1529 bytes,
etc), but I think the point remains: there will be devices that
cannot receive complete IPv6 packets, and will therefore either be
precluded from interoperability or require breaking the end-to-end
argument by fragmenting and reassembly at the IP layer (not below, as
the draft mentions).
Anyways, I guess the question is whether the WG feels that mentioning
this constraint is important enough to include in the document.
Sounds like opinion is mixed. Given that it's such a minor point, I
don't think it's a big deal if it's not included; I just think its
presence would help define the problem space a little bit more
precisely.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
