On Thu, 2006-07-20 at 14:31 -0700, Philip Levis wrote: > 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.
We have the code currently running on a 64K flash part with 4K of ram. The biggest problem we are seeing with 16k flash parts is that they generally only have 2K (max) of ram. This is critically small for buffer space. > > > >> > >> 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). How does ip fragmentation "break" end-to-end? > > 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
