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

Thomas Heide Clausen <thomas@thomasclausen.org> Fri, 23 July 2010 08:15 UTC

Return-Path: <thomas@thomasclausen.org>
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 480113A698C for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:15:19 -0700 (PDT)
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 R0xduqVySbsh for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:15:17 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id DC7EB3A6841 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:15:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 37F903236DB1; Fri, 23 Jul 2010 01:15:36 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1CD923228050; Fri, 23 Jul 2010 01:15:34 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="iso-8859-1"
From: Thomas Heide Clausen <thomas@thomasclausen.org>
In-Reply-To: <4C494EAE.9000600@gmail.com>
Date: Fri, 23 Jul 2010 10:15:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <01937057-07D5-44BF-BB89-CF86EB08858C@thomasclausen.org>
References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> <4C494EAE.9000600@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1078)
Cc: autoconf@ietf.org, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
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:15:19 -0000

On Jul 23, 2010, at 10:11 , Alexandru Petrescu wrote:

> 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.

Then, they're (by definition) not ad-hoc networks.

>> 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.

Very well, but then that's not a MANET.

> 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.

Very well, but then that's not a MANET.

Alex, can we agree that things that are not MANETs tautologically are not MANETs?

Thomas


>> 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
>> 
> 
>