Re: [smartpowerdir] Fwd: LWIG WG proposal

Jari Arkko <jari.arkko@piuha.net> Sun, 23 January 2011 19:59 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142743A6932 for <smartpowerdir@core3.amsl.com>; Sun, 23 Jan 2011 11:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level:
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9FAFauCbDDF for <smartpowerdir@core3.amsl.com>; Sun, 23 Jan 2011 11:58:58 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D832E3A6949 for <smartpowerdir@ietf.org>; Sun, 23 Jan 2011 11:58:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BE3FE2CC3A; Sun, 23 Jan 2011 22:01:49 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9wp4X7yWEZ0; Sun, 23 Jan 2011 22:01:49 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 245272CC2D; Sun, 23 Jan 2011 22:01:48 +0200 (EET)
Message-ID: <4D3C892B.3090908@piuha.net>
Date: Sun, 23 Jan 2011 22:01:47 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
References: <4D2A4844.9020301@piuha.net> <45CA4DDE-356C-41A2-88C5-BA33DDB5FB14@vigilsec.com> <80A0822C5E9A4440A5117C2F4CD36A64017726BB@DEMUEXC006.nsn-intra.net>
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64017726BB@DEMUEXC006.nsn-intra.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: Re: [smartpowerdir] Fwd: LWIG WG proposal
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2011 19:59:00 -0000

Thanks for your comments, Mehmet.

> I believe this work is valuable and different IETF WGs can benefit from
> the results. However, ...
>
> although IETF working groups often report from implementation and
> interoperability experiences it is not very common to develop a document
> on "implementation techniques". I think the charter text should make it
> clear why the development of such a document should be done at an SDO
> like IETF.
>   

Strictly speaking the general purpose implementation techniques (like 
how to do efficient memory management) are outside the scope. However, I 
think the IETF is a good place to write documents that talk about 
protocol-related implementation issues, such as what parts of an 
implementation are necessary if, say, you only need one client-side TCP 
connection.

> People who propose this WG do not seem to be the main contributors and
> we need to find some smart guys first with LW implementation experience.
> I would like to see more willing contributors with experience before we
> start the work.
>   

I do have a number of willing contributors, some which I would classify 
as major experts in writing small TCP/IP implementations. I have not 
publicly broadcasted the set of the willing experts. But Adam Dunkels, 
Margaret Wasserman,

> It would be also interesting if the charter mentions 6LoWPAN (e.g.
> "associated protocols such as 6LoWPAN").
>   

I have been asked to be more specific in this text. 6LOWPAN *is* 
included in the latest version. See below. Comments appreciated, this is 
not set in stone.

Jari


Light-Weight Implementation Guidance (lwig)
-------------------------------------------
Current Status: Proposed Working Group

Chairs:
TBD

Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.com>
Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:
Jari Arkko <jari.arkko@piuha.net>

Transport Area Advisor:
TBD

Mailing Lists:
General Discussion: lwip@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/lwip
Archive: http://www.ietf.org/mail-archive/web/lwip

Description of Working Group:

Communications technology is being embedded into our environment. 
Different types of devices in our buildings, vehicles, equipment and 
other objects have a need to communicate. It is expected that most of 
these devices employ the Internet Protocol suite. However, there is a 
lot of variation in the capabilities between different types of devices, 
and it is not always easy to embed all the necessary features. The 
Light-Weight Implementation Guidance (LWIG) Working Group focuses on 
helping the implementors of the smallest devices. The goal is to be able 
to build minimal yet interoperable IP-capable devices for the most 
constrained environments.

Building a small implementation does not have to be hard. Many small 
devices use stripped down versions of general purpose operating systems 
and their TCP/IP stacks. However, there are implementations that go even 
further in minimization and can exist in as few as a couple of kilobytes 
of code, as on some devices this level of optimization is necessary. 
Technical and cost considerations may limit the computing power, battery 
capacity, available memory, or communications bandwidth that can be 
provided. To overcome these limitations the implementors have to employ 
the right hardware and software mechanisms. For instance, certain types 
of memory management or even fixed memory allocation may be required. It 
is also useful to understand what is necessary from the point of view of 
the communications protocols and the application employing them. For 
instance, a device that only acts as a client or only requires one 
connection can simplify its TCP implementation.

The purpose of the LWIG working group is to collect experiences from 
existing small IP stacks with regards to protocol implementation 
techniques and other details that have been useful in deployments. The 
group shall focus only on techniques that have been used in actual 
implementations and do not impact interoperability with other devices. 
The techniques shall also not affect conformance to the relevant 
specifications. The output of this work is a document that describes 
implementation techniques for reducing complexity, memory footprint, or 
power usage. The main focus is in the IPv4, IPv6, UDP, TCP, ICMPv4/v6, 
MLD/IGMP, ND, DHCPv4/v6, IPsec, 6LOWPAN, and RPL protocols. This 
document would be helpful for the implementors of new devices or for the 
implementors of new general-purpose small IP stacks. It is also expected 
that the document increases our knowledge of what existing small 
implementations do, and helps in the further optimization of the 
existing implementations. On areas where the considerations for small 
implementations have already been documented the group shall make an 
effort to refer to those documents instead of developing its own.

Generic hardware design advice and software implementation techniques 
are outside the scope of this work, as such expertise is not within the 
IETF domain. Protocol implementation experience, however, is within the 
IETF domain. The group shall also not develop any new protocols or 
protocol behavior modifications beyond what is already allowed by 
existing RFCs, because it is important to ensure that different types of 
devices can work together. The group shall not develop assumptions or 
profiles about the operating environment of the devices, because, in 
general, it is not possible to guarantee any special configuration. 
Finally, while implementation techniques relating to security mechanisms 
are within scope, mere removal of security functionality from a protocol 
is not an acceptable recommendation.

Given that the group works on both IP and transport layer protocols it 
is necessary to ensure that expertise in both aspects is present in the 
group. Participation from the implementors of existing small IP stacks 
is also required.

Milestones:

Feb 2011 Design team of experts and a document editor recruited
Aug 2011 First version of the implementation guidance document submitted
Mar 2012 Submit the implementation guidance document to the IESG for 
publication as an Informational RFC