Re: [coman] Device Classes?

[Hannes Tschofenig <[e-mail]>]

Hi Anuj,

Thanks for the feedback. Your data confirmed my guess.

To me it would make sense to make different assumptions about end
devices and routers since they have different requirements. For a router
I might even be convinced that network management protocols are useful
but I am not at all convinced that end devices should run them.

Also, as I argued on other lists before I see a lot of overlap between

* network management when also used to retrieve the actual data of the
application (+ the management of the software)

* CoAP

(when a software update mechanism has to be implemented anyway).

If we ever want any interoperability then the approach of letting
thousand flowers bloom isn't going to work very well.

Sometimes saying "no" to some protocols is a good thing. (Btw, I am also
included to say no to all the IPsec/IKEv2 efforts for constrained devices.)

Ciao
Hannes

On 04/04/2014 11:55 AM, Sehgal, Anuj wrote:
> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/coman
>>>
>>
>> _______________________________________________
>> coman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/coman
>