Hi Colin, the problem is that you do not only have IPv6 on your device but some application (+security) as well.
Your example with buffering frames does not really mean a lot with respect to the hardware requirements if do not also state the assumptions you make about the applications. Ciao Hannes On Jan 24, 2012, at 8:13 PM, Colin O'Flynn wrote: > Hello, > > There is a difference between Class 1 and Class 2, and not that much > difference below Class 1. > > Before I elaborate, let me explain where I'm getting my arguments from: I've > been involved in about four different main IPv6 stacks for low-power > devices, each stack on a different architecture. > > Around Class 1, you can do "real" IPv6. But you need to be careful: you've > got enough SRAM to buffer a few IPv6 frames, such as when you are doing ND. > But you won't get that much more, and you'll have to keep your neighbor > table small. For example such are the constraints Contiki's uipv6 is > originally built for (it can go a lot smaller even too). > > At Class 2, the extra 10K of breathing room means you can buffer several > frames along with having larger tables. This approach is taken in my own > IPv6 stack, (http://sourceforge.net/apps/trac/flexibleipfip/). The extra > code space gives you a lot more room for higher-level protocols, and > generally lets you do stuff that wastes a bit of code/SRAM but makes the > stack easier to work with. > > Much below Class 1 you start having to do "hacks" to get things working... > perhaps collapsing the 6LoWPAN layer and IPv6 layer, such as in > Atmel App-note AVR2070 (IIRC it has an option for a collapsed stack which > fits in 16K-FLASH 4K-SRAM parts, but I could be wrong). > > So I think the definitions are OK. What will happen is nobody will buy Class > 1 parts - already for example it's often cheaper buying a SoC than a > separate radio + micro. And most of the SoC have a lot of room in them... > > Warm Regards, > > -Colin > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Guillaume Fortaine > Sent: January 24, 2012 12:57 PM > To: Joe Touch > Cc: [email protected]; [email protected]; Antonio J. Jara > Subject: Re: [Lwip] Device Classification > > Hello, > > > On Tue, Jan 24, 2012 at 5:25 PM, Hannes Tschofenig > <[email protected]> wrote: >> Any thoughts about this classification? > > I have just asked the same question a few minutes ago :) > > > On Tue, Jan 24, 2012 at 5:34 PM, Joe Touch <[email protected]> wrote: >> I'm concerned that these ranges are too similar, and the distinction would >> be short-lived. >> >> I expect devices to persistently operate differently when their parameters >> are at least 2 order of magnitudes different. > > I totally agree and couldn't say better. > > On my side, I would replace Class 1 by Class 2. According to my > analysis, a good chip with the lowest common denominator features for > Internet of Things could be the STM32L Family (Ultra Low Power > Cortex-M3 32 bit, up to 48K SRAM/384K Flash, AES) : > > http://www.emcu.it/STM8L-STM32L-UltraLowPowerPlatform.html > > So, is there any need for 6LoWPAN or a "Lightweight IP Stack" ? Why > not to capitalize around the lwIP stack that, moreover, supports IPv6 > ? : > > http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG > > "2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt) > * nearly the whole stack: Finally, we got decent IPv6 support, big thanks > to > Ivan! (this is work in progress: we're just post release anyway :-)" > > > By the way, after that, there are the future chips around the > Cortex-A5 architecture : > > https://docs.google.com/viewer?a=v&q=cache:9DxfCwAl1JAJ:realview.com.cn/shop > pic/down/seminar/1011/Track%25201/Tech%2520Symposium%2520-%2520Cortex-A5.pdf > +Tech%2520Symposium%2520-%2520Cortex-A5.pdf&hl=fr&gl=fr&pid=bl&srcid=ADGEESj > TOGdalGDTg4lwwL-QM8rwVQi9ywlEvO_0aexJne-9lLDQooQzsi9LcFHNMFBm3bbbNT67qB8RURs > ATZ0TtqoeNsNWGVKk6fEeV_7SmMN_t-SAW4ZWRu30aZhjYkExu-DYJATS&sig=AHIEtbT8XrAlTv > _cpDxvNbaECQLwVpCN0Q > > > Best Regards, > > Guillaume FORTAINE > > > On Tue, Jan 24, 2012 at 5:34 PM, Joe Touch <[email protected]> wrote: >> I'm concerned that these ranges are too similar, and the distinction would >> be short-lived. >> >> I expect devices to persistently operate differently when their parameters >> are at least 2 order of magnitudes different. >> >> The numbers below are so close that they will change and thus likely > overlap >> over timescales that are too short, IMO, for the IETF to be concerned. >> >> (i.e., there was a time when the difference between 4KB and 8KB was >> important; now it's irrelevant) >> >> Joe >> >> >> On 1/24/2012 8:25 AM, Hannes Tschofenig wrote: >>> >>> Hey guys, >>> >>> after sending the workshop announcements to a few working groups I was >>> asked what I mean by "constrained" device. >>> >>> I responded with a pointer to the classification Carsten proposed in >>> http://tools.ietf.org/html/draft-bormann-lwig-guidance-00: >>> >>> +---------+-----------------------+-------------------------+ >>> | Name | data size (e.g., RAM) | code size (e.g., Flash) | >>> +---------+-----------------------+-------------------------+ >>> | Class 1 | ~ 10 KiB | ~ 100 KiB | >>> | | | | >>> | Class 2 | ~ 50 KiB | ~ 250 KiB | >>> +---------+-----------------------+-------------------------+ >>> >>> During the IAB technical plenary at the last IETF meeting Jari claimed >>> that we need to have a Class 0 here as well to cover his sensor >>> deployment. >>> >>> Any thoughts about this classification? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Lwip mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lwip >> >> _______________________________________________ >> Lwip mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lwip > _______________________________________________ > Lwip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lwip > > _______________________________________________ > Lwip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lwip _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
