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

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Wed, 06 June 2012 08:42 UTC

Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: coma@ietfa.amsl.com
Delivered-To: coma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2F21F86AD for <coma@ietfa.amsl.com>; Wed, 6 Jun 2012 01:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byUlflpc9ZLx for <coma@ietfa.amsl.com>; Wed, 6 Jun 2012 01:42:20 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBD21F86AA for <coma@ietf.org>; Wed, 6 Jun 2012 01:42:20 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q568gF59026770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <coma@ietf.org>; Wed, 6 Jun 2012 10:42:15 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q568gFt0020568 for <coma@ietf.org>; Wed, 6 Jun 2012 10:42:15 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jun 2012 10:42:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 6 Jun 2012 10:42:13 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403DFB0D5@DEMUEXC006.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Constrained Device Classes 0, 1 and 2 and their need for Management
Thread-Index: Ac1DwEUD8febgWegSgq+hs2ifloHKA==
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: <coma@ietf.org>
X-OriginalArrivalTime: 06 Jun 2012 08:42:14.0955 (UTC) FILETIME=[45ECEFB0:01CD43C0]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2591
X-purgate-ID: 151667::1338972136-00003CDD-95223929/0-0/0-0
Subject: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management
X-BeenThere: coma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coma>, <mailto:coma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coma>
List-Post: <mailto:coma@ietf.org>
List-Help: <mailto:coma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coma>, <mailto:coma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2012 08:42:21 -0000

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