Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 23 July 2010 08:11 UTC

Return-Path: <alexandru.petrescu@gmail.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 645D43A696C for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 HeIsbJKIvzEH for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:11:14 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 775FA3A67B4 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:11:14 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N8BRrP004785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:11:27 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8BQUh007419; Fri, 23 Jul 2010 10:11:26 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N8BQcB030621; Fri, 23 Jul 2010 10:11:26 +0200
Message-ID: <4C494EAE.9000600@gmail.com>
Date: Fri, 23 Jul 2010 10:11:26 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de>
In-Reply-To: <201007230951.51192.henning.rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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: Fri, 23 Jul 2010 08:11:17 -0000

Le 23/07/2010 09:51, Henning Rogge a écrit :
> On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote:
>>> if each of the MRs use a wireless interface, the linklocals WILL
>>> BE VISIBLE outside their direct link.
>>
>> Well, the link local addresses will not be visible outside their
>> direct link, because the different links are on different ESSIDs
>> and moreover on different channels.  Using wireshark on IP packets
>> on these different links shows that the link local addressess are
>> not visible from one link to another.
>
> This would only work with preplanned links,

Most deployments have a high degree of planning.

> because otherwise you would have trouble to do neighborhood
> detection. How do you detect new nodes coming into range if they
> cannot announce their presence with a broadcast, because they got no
> unique ESSID to their neighbors ?

Well good question - and I have tried.  The difficult thing is the first
detection - the "wifi scan" phase; once the drivers have their data set
up then re-detection is very fast, in the order of tens of milliseconds.
  We could use that to signal between two approaching vehicles.

More specifically, on WiFi, a beacon is sent periodically, but there are
also periodic requests replied with a beacon.  These help a lot to
detect presence of a neighbor previously learned, and fast.

> MANET routing protocols are specially designed for the case of
> unplanned networks. You have a single shared medium which the routing
> protocol use for it's work, to do neighborhood/link detection.

Well very good.  Is there a case where wireless multi-hop networks are
possible _without_ MANET routing protocols?  I believe yes, and I
prototyped and demo.

Besides, there exist deployments where even though the MRs are mobile
they stay relatively fixed with respect to each other, in some very
simple topology: truck convoy, wagons in a train, etc.  These things
stay formed for long hours and reform right after.  These things don't
need the power of MANET routing protocols because there are never loops
formed at link layer, the topology is really simple.

> If you push this down to link layer, you just move the whole problem
> down one layer, because you need unique addresses on the link layer
> to do neighborhood detection and link establishment.

WEll yes... I tend to agree.

However, one would avoid to bring existing link layer mechanisms up to
the IP stack too.  These link layer mechanisms are there and work very
well in their domain.

The IP stack is not fast enough on the CPU to work at vehicular speeds,
interruptable by some GUI or heavy TCP.

The link layer driver executing on a dedicated chipset is much more
reliable for these kinds of movements.

> If you already have a unique link-layer address, just use it to
> generate a unique linklocal-IP.

Hmmm... right, that's how link local addresses are generated.

Alex

>
> Henning Rogge
>