Subject: Re: [Lwip] Discussion about IoT Device Classes

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 1 Feb 2017 10:57:12 +0100

Hi Carsten,

thanks for the initiative. I support it!

Coarsly, from the software perspective, there are 3 classes of devices:

- "motes" with fixed, simplistic functionality in software, on which
resources are so constrained that an operating system and (secure) software
updates do not make sense.

- "low-end IoT devices" with more resources and more functionalities in
software, which run an OS but cannot run generic operating systems such as
Linux or equivalents/derivatives, and hence run IoT-specific operating
systems such as RIOT, Contiki etc.

- "high-end IoT devices" which have enough resources so that they can run
generic operating systems such as Linux or equivalents/derivatives.

Each category presents specific challenges, but the "low-end IoT device"
category is the one where the most fundamental progress is expected, and
achievable.
By that I mean that we can hope to transform low-end IoT devices into
"standard" Internet citizens if we do things right.
On that level, there is no hope for motes and, on the other hand, high-end
IoT devices are already Internet citizens.

>From that perspective, I'm not sure defining a "Class 7" would be useful.
I'm not even sure if defining a "Class 0" is so useful either in the end --
if we have no hope that such devices will become "standard" Internet
citizens.

Best,

Emmanuel

On Wed, Feb 1, 2017 at 4:01 AM, Christian Groves <[email-masked]>
wrote:

> 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
>
>
>
>
> On 26/01/2017 6:57 PM, Carsten Bormann wrote:
>
>> On 26 Jan 2017, at 00:38, Carsten Bormann <[email-masked]> wrote:
>>
>>> Sure.  We started that discussion a few IETFs ago and have a bis draft
>>> out at
>>> 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/CONTRIBUT
>> ING.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
>>
>> _______________________________________________
>> Lwip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lwip
>>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 1 Feb 2017 15:05:41 +0100

Hi Carsten and Co-Authors,

thanks for working on the document.

What I am missing is a discussion (which does not need to end in the
final version of the document) on what functionality you consider to be
included in, for example, the class 1 device.

I agree with Emmanuel regarding the difference between the device that
run a RTOS (or special IoT-designed OS) and the devices that run a
general purpose OS, like Linux. This is also a differentiation we make,
as you know.

Ciao
Hannes

PS: I am not sure about the "motes". Are you talking about BLE beacons?

On 02/01/2017 10:57 AM, Emmanuel Baccelli wrote:
> resources are so constrained that an operating system and (secure)
> software updates do not make sense.
> 
> software, which run an OS but cannot run generic operating systems such
> as Linux or equivalents/derivatives, and hence run IoT-specific
> operating systems such as RIOT, Contiki etc.
> 
> - "high-end IoT devices" which have enough resources so that they can
> run generic operating systems such as Linux or equivalents/derivatives.
> 
> On that level, there is no hope for motes and, on the other hand,
> high-end IoT devices are already Internet citizens.
> 
> I'm not even sure if defining a "Class 0" is so useful either in the end
> -- if we have no hope that such devices will become "standard" Internet
> citizens.
> 
> Best,
> 
> Emmanuel
> 
> 
> On Wed, Feb 1, 2017 at 4:01 AM, Christian Groves <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     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.
> 
>     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
> 
> 
> 
> 
>         On 26 Jan 2017, at 00:38, Carsten Bormann <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Sure.  We started that discussion a few IETFs ago and have a
>             bis draft out at
>         <https://github.com/lwig-wg/terminology>
>         and
>         <https://lwig-wg.github.io/terminology/>
> 
>         (Please see
>         https://github.com/lwig-wg/terminology/blob/master/CONTRIBUTING.md
>         <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
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/lwip>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lwip>
> 
> 
> 
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 1 Feb 2017 16:48:21 +0100

Hi Hannes,

concerning "motes", "class 0", or whatever we want to call such devices:
indeed, not sure how we should relate with such devices in the document.

Do we care to define a "new" category of devices on which no protocol
will run that we IETFers specify (e.g. BLE beacons)?

I'd say: no, unless it is deemed useful to distinguish from other types of
devices
that are expected to run IETF protocols in practice.

Emmanuel

On Wed, Feb 1, 2017 at 3:05 PM, Hannes Tschofenig <[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Feb 2017 13:32:11 -0500

> general purpose OS, like Linux. This is also a differentiation we make,

And there is also some sub-classes of "Linux" that are relevant.

    > PS: I am not sure about the "motes". Are you talking about BLE beacons?

It's a good example. But really anything that basically can never be field
upgraded.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 1 Feb 2017 19:54:03 +0100

Hi Michael,

> And there is also some sub-classes of "Linux" that are relevant.

I personally care less about those sub-categories since I can map these
class 1 devices to Cortex M class processors and class 2 devices to
Cortex A class processors. For Intel, there are similar categories.

> It's a good example. But really anything that basically can never be field

I guess I am fine calling them class 0 devices that are basically
outside our scope since they do not run IP.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Feb 2017 09:57:18 -0500

> I'd say: no, unless it is deemed useful to distinguish from other
    > types of devices

I say, "yes".

It's useful to be able to say, "dude, that's a class 0 device! You can't make
IPv6 work there, stop trying: you are breaking important functionality"

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Feb 2017 10:04:19 -0500

> Cortex A class processors. For Intel, there are similar categories.

I'm not sure I understand how ARM or Intel classifications help us
communicate across product lines.

There are systems with <4M of flash and 2M of ram running a Linux kernel,
and some application specific /sbin/init-equivalent.  If you think about the
capablities of these system, they are basically early 386-class machines.
Many of these systems wind up being non-field upgradeable due to lack of
space.  While if they were running a smaller RTOS, they would be very well
provisioned, but they'd have no MMU protection.  Some run VxWorks kernels
with MMU protection enabled.  There are several generations of home routers
which fit into this size category, btw.
Adding a new security feature (or algorithm) to the above systems can be very
difficult.

Then there are the somewhat large openwrt-class devices which are just a bit
bigger.  They often have shells, interpreters and sophisticated (and sadly
insecure) mechanisms.  4M of flash and 8M of ram seems to be a lower
threshold to make this work.  It can still be very hard to field upgrade
such small systems, but it is often possible.
Adding a new security feature (or algorithm) to the above systems can be
quiet easy.

---

From: Oliver Hahm <[email-masked]>
Date: Fri, 3 Feb 2017 12:35:09 +0100

Hi Hannes!

> outside our scope since they do not run IP.

I'm not so sure we should discard these devices so hasty. Sure, with just some
tens of bytes of RAM, you won't be able to implement 6lowpan-HC or DTLS. But
as soon as we have some kilobytes of RAM (let's say 5kB as on some MSP430
motes), simple IPv6 connectivity is possible, if its functionality is well
defined. As far as I know, current IPv6/6lo specifications do not consider
unidirectional devices, but is there anything wrong in a simple sensor that
just broadcasts (multicasts) its sensor values to a hardwired IPv6 address
(e.g., ff02::2)?

Cheers,
Oleg

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Feb 2017 12:44:25 +0100

Class 0 devices cannot very well be full citizens of the Internet (at least we tried to define the class so this is approximately true), but they indeed can have some connectedness to them.
IPv6 beacons are one such example, but also maybe devices with local interconnects that talk to an IP node.  Section 5.2 has class I0 for the latter.  I0 devices may still terminate application protocols such as CoAP and security protocols (e.g., DCAF was designed so this is possible).

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 3 Feb 2017 15:41:36 +0100

Hi Oliver,

your remark illustrates the need to discuss what functionality we
expected to be implemented on these devices.

Without a list of specs the RAM/flash size indication is not terribly
meaningful.

Ciao
Hannes