Re: [coman] Device Classes?

Hi,

I have on several occasions used Contiki to implement applications using some combination of the following stack on Class 1 devices (TelosB):

> I wonder whether someone has tried to implement a router with
> * an IPv6 stack
> * RPL
> * network management protocol (as Thomas was asking for)
> * CoAP
> * + the actual application

After fitting all this in, there really is no space left for security (DTLS, etc.). 

Fitting DNS should not be too complicated provided we knock off something from this list (either CoAP or network management protocol, SNMP in our case), but I say this based on experience with an mDNS implementation we did a few years ago that works on AVR Raven devices (closer to Class 2). 

In general, a basic Contiki 2.6 system (minus CoAP from above) takes up about 85% of Flash and statically allocated RAM on a TelosB (Class 1). Adding CoAP and a network management protocol will push this further, with nearly no space left. In fact, if the data model is too large or complicated for the network management protocol, then chances are that it too would not fit either. Similar constraints apply to CoAP as well. Working with CoAP up to Contiki 2.6, while using TelosB (Class 1), was also quite a struggle. At best we were able to work with a handful of resources, since the amount of memory left over was not too much.

I have not checked while writing this email, but at least in the past it was the RPL implementation that would take a significant amount of resources. This was largely due to non-storing mode not being implemented, but it would seem that Contiki 2.7 does have the option to enable non-storing mode. This might help reduce resource consumption further.

When we attempted an implementation of DTLS, we used the AVR Raven (Class 2) because TelosB (Class 1) did not have enough resources to function with it.

Regards,
Anuj

> On 04/04/2014 09:24 AM, Carsten Bormann wrote:
>> On 02 Apr 2014, at 09:43, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>> 
>>> IMHO these classes are about end devices rather than constrained routers
>>> and switches.
>> 
>> Actually, the device classes are about nodes in general (hosts and routers).  The document then goes on to say:
>> 
>>   (An alternative name, when the properties as a network node are not
>>   in focus, is "constrained device”.)
>> 
>> Protocols such as RPL take great care to enable the use of class-1 devices as routers (non-storing mode).
>> Constrained management will need to match that.
>> 
>> A more important dichotomy than host vs. router may be monitoring vs. configuration.
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> coman mailing list
>> coman@ietf.org
>> https://www.ietf.org/mailman/listinfo/coman
>> 
> 
> _______________________________________________
> coman mailing list
> coman@ietf.org
> https://www.ietf.org/mailman/listinfo/coman