Subject: [Lwip] Discussion about IoT Device Classes

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jan 2017 23:12:06 +0100

Hi all,

https://tools.ietf.org/html/rfc7228#section-3 defines these three
classes of IoT devices:

     +-------------+-----------------------+-------------------------+
     | Name        | data size (e.g., RAM) | code size (e.g., Flash) |
     +-------------+-----------------------+-------------------------+
     | Class 0, C0 | << 10 KiB             | << 100 KiB              |
     |             |                       |                         |
     | Class 1, C1 | ~ 10 KiB              | ~ 100 KiB               |
     |             |                       |                         |
     | Class 2, C2 | ~ 50 KiB              | ~ 250 KiB               |
     +-------------+-----------------------+-------------------------+

Is there an interest to get together at the next IETF meeting and to
talk about re-working on these classes and to provide more details about
the functionality that is included in this calculation based on ongoing
implementation work?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2017 00:38:49 +0100

Sure.  We started that discussion a few IETFs ago and have a bis draft out at
draft-bormann-lwig-7228bis.

(I’m not sure that I will be in Chicago, but I could join from remote.)

One thing that needs to be added before even discussing these device classes is the difference between micro controllers (which you have been calling M-class) and general purpose computing platforms (A-class).  Proposed text for that should be in the next version of 7228bis.

Grüße, Carsten

> On 25 Jan 2017, at 23:12, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Zhen Cao <[email-masked]>
Date: Thu, 26 Jan 2017 14:19:02 +0800

Hi Hannes,

Definitely an interesting topic.  We had some brief discussion at
IETF96, and now we need some concrete items to kickoff.

Anyway, I will add a slot on the next meeting.

Best regards,
Zhen

---

From: Zhen Cao <[email-masked]>
Date: Thu, 26 Jan 2017 14:32:12 +0800

> One thing that needs to be added before even discussing these device classes is the difference between micro controllers (which you have been calling M-class) and general purpose computing platform…

If I get it right, the M-class and A-class are mirroring to the modem-
and application- core.  But I am not sure what are the major
difference in implementing an IP layer stack on the two different
architectures. (that's something possible of interest to a larger
audience)

Best regards,
Zhen

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2017 08:09:09 +0100

> architectures. (that's something possible of interest to a larger

(I always read “M-class” as “Microcontroller-class”.)

A-class processors, even if used in the embedded space, have protection (kernel and user mode) and an operating system such as Linux, so they typically have considerable RAM and Flash resources (separate chips, in the multi-megabyte range).  M-class processors run real-time operating systems such as RIOT, and can get by with much lower resources (in particular, energy usage); often, they are fully integrated on one chip (a separate serial flash chip is popular in some applications).  As their frugality with resources allows M-class processors to be used in much larger numbers, one would also expect that in the long tun the majority of IoT devices will be based on M-class processors.  The RFC 7228 system of device classes was meant to apply to M-class processors.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Jan 2017 08:57:44 +0100

> draft-bormann-lwig-7228bis.

… and the editors’ draft is now at:

https://github.com/lwig-wg/terminology
and
https://lwig-wg.github.io/terminology/

Issues and pull requests are welcome.
(Please see https://github.com/lwig-wg/terminology/blob/master/CONTRIBUTING.md ).

(The proposed bis document is an individual submission at this point; we still put it up under the “lwig-wg” organization as there appears to be some interest.)

Grüße, Carsten

---

From: Renzo Navas <[email-masked]>
Date: Thu, 26 Jan 2017 10:33:07 +0100

Hello Hannes, Carsten, Zhen, and LWIG!

Thank you Carsten for starting the 7228bis initiative;

I am also interested on making explicit the "time awareness"
constraints for devices. As we discussed before (on ACE and Clock
design team): RealTimeChip or not; possibility of synchronized time or
not (absolute or relative), etc.
e.g: Raspberry Pi (Class 2), Arduino Mega (C1), do not have a RTC.

So the 7228bis might be a great place to put this in.

Regards,

Renzo

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Jan 2017 08:53:34 -0500

I think that we need some additional dimensions (yes, time awareness is one).
I'd like to also add something about field upgrade constraints.

I'd like to have a class 3 defined: I'm thinking about the endless devices
which we have come to hate with about 4M of hard to upgrade flash (sometimes
execute in place), a *nix kernel, and a single useful process running in
addition to the unwanted telnetd with stock password.

I'd like to have a class defined (8? 9?) that matches what we see in
current mobile phones.  And another that matches what we see in current
(router) control plane CPUs (very similar to class 3 above, btw)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Groves <[email-masked]>
Date: Wed, 1 Feb 2017 14:01:46 +1100

I did a quick read of the draft and to me its not clear what the goal of 
clause 5.2 "Class of Internet Integration" is.

The table talks about internet technologies, the text makes reference to 
communications patterns (e.g. device-to-cloud) whereas the section is on 
integration. It also lists I9 which seems to suggest there will be 
"degrees" on classes of integration between I1 and I9.

So is the aim to only have 3 types? e.g.

Device Internal IP usage - IP Interoperability not an issue.

Device to Provider Server - IP Interoperability within a service provider.

Device to Any - IP interoperability required between multiple service 
providers.

Or to have something more specific to IP listing what parts of the IP 
suite are supported?

Regards, Christian