[Lwip] WG proposal

Jari Arkko <jari.arkko@piuha.net> Mon, 10 January 2011 21:16 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: lwip@core3.amsl.com
Delivered-To: lwip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62123A67F7 for <lwip@core3.amsl.com>; Mon, 10 Jan 2011 13:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level:
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 plDKn8Vrxs2u for <lwip@core3.amsl.com>; Mon, 10 Jan 2011 13:16:09 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0358F3A67ED for <lwip@ietf.org>; Mon, 10 Jan 2011 13:16:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 106852CC31 for <lwip@ietf.org>; Mon, 10 Jan 2011 23:18:23 +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 K+2VauhAEMZc for <lwip@ietf.org>; Mon, 10 Jan 2011 23:18:22 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2940D2CC2D for <lwip@ietf.org>; Mon, 10 Jan 2011 23:18:22 +0200 (EET)
Message-ID: <4D2B779D.5060705@piuha.net>
Date: Mon, 10 Jan 2011 23:18:21 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: lwip@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Lwip] WG proposal
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lwip>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2011 21:16:11 -0000

All,

After thinking about the results of the LWIP BOF for a while and talking 
to various people, my proposal is to create a focused working group to 
produce an implementation guidance document. The key to the success of 
this effort is recruiting the smart guys who have actually built some of 
the existing implementations. We are in talks with several such experts, 
though our exact recruitment ability is yet to be seen. Here's a 
proposed charter. Comments appreciated.

If you are interested in this effort and have built a small TCP/IP 
implementation, talk to me, Bob, and Cao about your participation in the 
effort.

Jari
-----

Light-Weight Implementation Guidance (LWIG)

Current Status: Proposed

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. 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, and 
associated 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.

Generic hardware design advice and software implementation techniques 
are outside the scope of this work, as such expertise is not 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.

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:

February 2011   Design team of experts and a document editor recruited
March 2011       Working group chartered
August 2011       First version of the implementation guidance document 
submitted
March 2012      Submit the implementation guidance document to the IESG 
for publication as an Informational RFC