Subject: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Jun 2012 10:42:13 +0200

Hi All,

following is an attempt to define the device classes in constrained
networks a bit more in detail. The text below follows the definition of
the three device classes provided by Carsten.

Class-0 (C0) devices are very constrained sensor-like motes. They will
most likely not have the possibility to have a direct communications
with the Internet in a secure manner. These class-0 devices will
participate in Internet communications with the help of larger devices
acting as proxy or gateways. 

Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and
roughly 100 Kbytes of code space (e.g. Flash). For example, this could
be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). Class-1
devices can't easily talk to other Internet nodes with a full protocol
stack using HTTP, TLS and related security protocols, and XML-based data
representations. However, they have enough power to use a reduced or
lightweight protocol stack (e.g. with CoAP and UDP) and participate in
meaningful conversations without the help of a gateway node. So they can
be integrated into the IoT network in one way or the other but need to
spare with memory for the protocol and application usage.

Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM
and maybe 250 Kbytes of code space and can support mostly the same
protocol stack as used on notebooks or servers. However, even these
devices can benefit from lightweight and energy-efficient protocols and
producing less bandwidth on air. Furthermore, using less network
resources would leave more resources available to applications. As such
using the same protocol stack on Class 1 and 2 devices might be
beneficial.

I assume we cannot do much for the management on C0 devices. They will
be most likely preconfigured and if ever will be reconfigured seldomly
with a very small data set.

For C1 devices it is indeed subject for discussion and to understand
what type of applications they could run and which management mechanisms
would be most suitable.
Even though they have some more functionality available we need to
assess C2 devices for the type of applications they will be running and
the management they would need. To be able to derive the requirements we
need to discuss the uses cases and how the devices are involved in the
management scenario. The use cases where C1 or C2 devices build a
cluster or are part of a hierarchy as well as the assumed degree of
automation might be essentially important.

Comments are welcome.

Cheers, 
Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jun 2012 11:22:17 +0200

> automation might be essentially important.

This classification is very rough since devices differ in their
architecture. For example, some devices can run their software right
out of flash memory and hence their RAM is really only used for the
storage of variables and the stack. Other devices have to copy the
machine code from flash to RAM before they can execute it. Such
devices have relatively large amounts of RAM but most of it is used to
store machine code.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Rares Ivan <[email-masked]>
Date: Wed, 6 Jun 2012 17:20:40 -0400

Hello,

In my opinion the classification should not be directly connected to the hardware capabilities of devices (like processing power, RAM, flash) just because same functional features can be supported on devices with very different hardware capabilities and architecture. There shouldn't be any mention of hardware resources.

The classification shall be based on various sets of features supported by a device. Therefore the complete list of features can be divided in subsets where Class-0 (C0) is the smallest set of supported features, Class-1 (C1) adds more features on top of C0, Class-2 (C2) adds more features on top of C1, and so on. A Class-2 device is implicitly compliant with Class-1 and Class-0, therefore a network manager that can manage Class-2 can also manage the lower classes; a manager that can only manage Class-1 devices could only manage Class-2 devices based on features specific to Class-1, which is the manager's limitation.

The higher the class, the more features a device supports, and based on this classification a manager would know what the capabilities of a device shall be. There wouldn't be any in-between classes specs allowed, and a device cannot be claimed as Class-2 compliant unless it supports ALL the features required by that category.

Regards,
  Rares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, June 06, 2012 5:22 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> networks a bit more in detail. The text below follows the definition 
> of the three device classes provided by Carsten.
> 
> be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). 
> Class-1 devices can't easily talk to other Internet nodes with a full 
> protocol stack using HTTP, TLS and related security protocols, and 
> XML-based data representations. However, they have enough power to use 
> a reduced or lightweight protocol stack (e.g. with CoAP and UDP) and 
> participate in meaningful conversations without the help of a gateway 
> node. So they can be integrated into the IoT network in one way or the 
> other but need to spare with memory for the protocol and application usage.
> 
> devices can benefit from lightweight and energy-efficient protocols 
> and producing less bandwidth on air. Furthermore, using less network 
> resources would leave more resources available to applications. As 
> such using the same protocol stack on Class 1 and 2 devices might be 
> beneficial.
> 
> what type of applications they could run and which management 
> mechanisms would be most suitable.
> assess C2 devices for the type of applications they will be running 
> and the management they would need. To be able to derive the 
> requirements we need to discuss the uses cases and how the devices are 
> involved in the management scenario. The use cases where C1 or C2 
> devices build a cluster or are part of a hierarchy as well as the 
> assumed degree of automation might be essentially important.
> 
> Comments are welcome.

This classification is very rough since devices differ in their architecture. For example, some devices can run their software right out of flash memory and hence their RAM is really only used for the storage of variables and the stack. Other devices have to copy the machine code from flash to RAM before they can execute it. Such devices have relatively large amounts of RAM but most of it is used to store machine code.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Coma mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/coma

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 8 Jun 2012 13:28:20 +0200

Hi Rares,

> Hello,
> 
> In my opinion the classification should not be directly connected to
the hardware
> capabilities of devices (like processing power, RAM, flash) just
because same functional
> features can be supported on devices with very different hardware
capabilities and
> architecture. There shouldn't be any mention of hardware resources.

We are interested to know which applications and features are possible
to run on different devices. However, the type of the application you
can run on a device is dependent on the available hardware capabilities.
So the device classes are used as a tool and will help us as a means to
an end. 
 
> The classification shall be based on various sets of features
supported by a device.
> Therefore the complete list of features can be divided in subsets
where Class-0 (C0) is
> the smallest set of supported features, Class-1 (C1) adds more
features on top of C0,
> Class-2 (C2) adds more features on top of C1, and so on. A Class-2
device is implicitly

I assume you mean "possible" features. E.g. based on the constrained
nature of resources, a device may support only a few of the features
(classified as C1) at a time.

> compliant with Class-1 and Class-0, therefore a network manager that
can manage
> Class-2 can also manage the lower classes; a manager that can only
manage Class-1
> devices could only manage Class-2 devices based on features specific
to Class-1, which
> is the manager's limitation.
> 
> The higher the class, the more features a device supports, and based
on this
> classification a manager would know what the capabilities of a device
shall be. There
> wouldn't be any in-between classes specs allowed, and a device cannot
be claimed as
> Class-2 compliant unless it supports ALL the features required by that
category.

Cheers,
Mehmet
 
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juergen
> Schoenwaelder
> Subject: Re: [Coma] Constrained Device Classes 0, 1 and 2 and their
need for
> Management
> 
> On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN -
DE/Munich)
> wrote:
architecture. For example,
> some devices can run their software right out of flash memory and
hence their RAM is
> really only used for the storage of variables and the stack. Other
devices have to copy
> the machine code from flash to RAM before they can execute it. Such
devices have
> relatively large amounts of RAM but most of it is used to store
machine code.