Re: [Autoconf] updated draft on aspects of multi-hop wireless communication

"Charles E. Perkins" <charles.perkins@earthlink.net> Mon, 23 February 2009 18:20 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46AA3A67D7 for <autoconf@core3.amsl.com>; Mon, 23 Feb 2009 10:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 N6vBgw+CSE+I for <autoconf@core3.amsl.com>; Mon, 23 Feb 2009 10:20:49 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DA87D3A6784 for <autoconf@ietf.org>; Mon, 23 Feb 2009 10:20:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mGyGiZDtKYw5Gk72o3cZFd35xOSpWikkObcgm7ctMuvQtheneOJis3gZAKMnX4pp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1LbfQP-00057v-Ii; Mon, 23 Feb 2009 13:21:05 -0500
Message-ID: <49A2E90E.10808@earthlink.net>
Date: Mon, 23 Feb 2009 10:21:02 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Paul Lambert <paul@marvell.com>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52afc5e0f49191bc803abe662aea8393bb350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.129.145
Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 18:20:49 -0000

Hello Paul,

The document isn't intended to suggest a list of work
items for consideration by [autoconf].  Instead, it is just
a description of common properties of radio and other
wireless links.  These properties are not quite universal,
but they are widespread.  Some of them can be alleviated
a bit by mechanisms below the network protocol level.

So we are not suggesting requirements or work items.
Instead, we simply wanted to make as clear as possible
some of the characteristics of the transmission media
whose widespread availability is motivating the work
of [autoconf].

Your list of issues would, I think, all fit best in a
requirements document.  I am almost certain they
should be considered out of scope for the document
under discussion.

Regards,
Charlie P.


Paul Lambert wrote:
> Hi,
>
> The draft-baccelli-multi-hop-wireless-communication-01 provides an interesting list of issues that might be addressed by this working group.
>
> >From a quick review it does not appear to address:
>  - ad hoc network coalescing.  Coalescing has clear implications for
>    IP address assignment
>  - there is no mention of multicast versus unicast issues.  Perhaps
>    since the document makes all links potentially asymmetric and
>    unreliable there is no distinction.  At least for 802.11 ad hoc
>    I find significant implications.
>  - it does not address link security establishment
>    The process of setting up the link security is out of scope, but as
>    I've mentioned in earlier emails this has a clear impact on available
>    networking mechanisms.
>    It is also a very important architectural consideration to ensure that
>    IP address assignment has some level of security.
>
> Asymmetric links in all "ad hoc" networks.  Is it possible to partition our problem statements so that this is just one of several optional attributes that must be addressed?
>
> Most modern wireless MAC layers have reliable unicast.  I can see some broadcast only links - like satellite broadcast, but outside military applications I am not familiar with broadly deployed commercial wireless networking technologies that are based on asymmetric unicast transmissions. Perhaps someone on this list could point me to the technologies that they are considering for this requirement.
>
>
> Regards,
>
> Paul
>
>