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

Paul Lambert <paul@marvell.com> Tue, 24 February 2009 16:43 UTC

Return-Path: <paul@marvell.com>
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 45A603A6804 for <autoconf@core3.amsl.com>; Tue, 24 Feb 2009 08:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Qw7RQBL1bnG2 for <autoconf@core3.amsl.com>; Tue, 24 Feb 2009 08:43:52 -0800 (PST)
Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id 78EA23A6B28 for <autoconf@ietf.org>; Tue, 24 Feb 2009 08:43:52 -0800 (PST)
Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 060A662013; Tue, 24 Feb 2009 08:44:12 -0800 (PST)
Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 08:44:11 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 24 Feb 2009 08:44:11 -0800
From: Paul Lambert <paul@marvell.com>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
Date: Tue, 24 Feb 2009 08:44:03 -0800
Thread-Topic: [Autoconf] updated draft on aspects of multi-hop wireless communication
Thread-Index: AcmV438KEDo4WTpzQTOdCOhPU7DhSQAs/e3A
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net>
In-Reply-To: <49A2E90E.10808@earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Feb 2009 16:44:11.0748 (UTC) FILETIME=[1ECCE240:01C9969F]
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: Tue, 24 Feb 2009 16:43:53 -0000

Hi Charlie,

I'm traveling with limited email ... so I just now saw your note.

> I am almost certain they
> should be considered out of scope for the document
> under discussion.

In looking at the reference in the charter for "ad hoc" (RFC 2501) the defined MANET is a Chimera - a mythical beast made of the parts of many other animals. It is a shame that smaller monsters are out of scope (like 802.11 ad hoc) ...

Paul



> -----Original Message-----
> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net]
> Sent: Monday, February 23, 2009 10:21 AM
> To: Paul Lambert
> Cc: Emmanuel Baccelli; autoconf@ietf.org
> Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless
> communication
>
>
> 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
> >
> >