Re: [Autoconf] Re: movement scenario

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 04 December 2007 22:08 UTC

Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfwJ-0007Ju-7d; Tue, 04 Dec 2007 17:08:27 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzfwH-0007Hf-Nk for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:08:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfwH-0007HU-Dw for autoconf@ietf.org; Tue, 04 Dec 2007 17:08:25 -0500
Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzfwG-00081k-OX for autoconf@ietf.org; Tue, 04 Dec 2007 17:08:25 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-11.tower-119.messagelabs.com!1196806104!22689432!1
X-StarScan-Version: 5.5.12.14.2; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13202 invoked from network); 4 Dec 2007 22:08:24 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 4 Dec 2007 22:08:24 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB4M8JAg006199; Tue, 4 Dec 2007 15:08:24 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lB4M8JIh029220; Tue, 4 Dec 2007 16:08:19 -0600 (CST)
Received: from [127.0.0.1] (mvp-10-197-20-84.corp.mot.com [10.197.20.84]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB4M8FMS029173; Tue, 4 Dec 2007 16:08:16 -0600 (CST)
Message-ID: <4755CFCF.1000409@gmail.com>
Date: Tue, 04 Dec 2007 14:08:15 -0800
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Yangwoo Ko <newcat@icu.ac.kr>
Subject: Re: [Autoconf] Re: movement scenario
References: <B1CA250F-56DE-4F6E-89D4-E138AF9A4F8C@gmail.com> <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl> <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp> <4754AB65.2090800@gmail.com> <7.0.0.16.2.20071204134958.0476dac8@ie.niigata-u.ac.jp> <4754E18D.3080302@gmail.com> <7.0.0.16.2.20071204143038.047a72d0@ie.niigata-u.ac.jp> <25c114b90712040946j47de7a71ve45b50e341ef4dc6@mail.gmail.com> <47559847.3070206@icu.ac.kr>
In-Reply-To: <47559847.3070206@icu.ac.kr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
X-Spam-Score: -4.0 (----)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: autoconf@ietf.org
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Errors-To: autoconf-bounces@ietf.org

Hi Yangwoo Ko,

Yangwoo Ko wrote:
> 
> I got lost. Can somebody clarify how mobility affects address 
> configurations?

Well, it's simple.  If we agree that mobility is when a node changes its
address (remark it's different than that 'mobility' that defines a node
that physically moves).  We may not, probably.

> It is very obvious that mobility affects decisions on which solutions
> are better than others. But it seems only related with how dynamic
> the characteristics of MANET-type links are rather than with what
> kinds of prefixes/addresses are to be given.

I kind of see what you mean.

But it is often important to have a good idea about what addresses and 
their scopes are going to be used because that has immediate 
consequences on the existing protocols.

Or maybe you mean something else I don't see?

Alex

> 
> Ulrich Herberg wrote:
>> Hi,
>> 
>> I agree with Kenichi. Maybe one could mention different scenarios
>> in the PS, but basically no particular mobility model should be 
>> considered in my opinion. For Alex's concern about comparability, I
>>  don't think this should be part of a PS (maybe more in a solution 
>> space? or something like 
>> draft-bernardos-autoconf-evaluation-considerations ?). The problem
>> of autoconfiguration should be applicable to all mobility patterns
>> to my understanding.
>> 
>> Ulrich
>> 
>> On 12/4/07, mase <mase@ie.niigata-u.ac.jp> wrote:
>> 
>>> Hi Alex,
>>> 
>>> At 14:11 07/12/04, Alexandru Petrescu wrote:
>>> 
>>>> mase wrote:
>>>> 
>>>>> Hi, At 10:20 07/12/04, Alexandru Petrescu wrote:
>>>>> 
>>>>>> mase wrote:
>>>>>> 
>>>>>>>> I want to share my thoughts on link-local addresses and
>>>>>>>> MLA with you. I think link-locals are essential to
>>>>>>>> IPv6. I do not understand why we have a discussion on
>>>>>>>> this. It is to be used for single hop communication,
>>>>>>>> which is also very applicable in MANET.
>>>>>>>> 
>>>>>>> Yes, but your former neighbor may be now
>>>>>>> out-of-transmission range and only communicated over
>>>>>>> multi-hop. Do you prefer to change your
>>>>>>> source/destination address from a link-local address to
>>>>>>> MLA?
>>>>>>> 
>>>>>> Ha!  That's right... Src/dst address rewriting makes
>>>>>> immediately think of NAT :-) I think the case you describe
>>>>>> above (former neighbor moves from a link to another)
>>>>>> deserves deep analysis.  What are the mobility scenarios
>>>>>> considered?  How do entities move, from where to where?
>>>>>> 
>>>>> Any mobility. We do not assume a particular mobility scenario
>>>>> when designing MANET routing protocols.
>>>>> 
>>>> I think that is a problem.  If we don't know the landmarks, the
>>>>  movement patterns, the dependencies... then it's very
>>>> difficult to design something meaningful, that fits some
>>>> initial goals and requirements.
>>>> 
>>>> I think people who have prototyped MANETs have always tested
>>>> certain movement scenarios.  At least these could be
>>>> documented.
>>>> 
>>>> It's really very tough to design something that acomodates
>>>> _any_ mobility...
>>>> 
>>>> Besides, such thing risks of not being able to be qualified,
>>>> can not be evaluated, can not be compared.  Of course, it _can_
>>>> be designed _and_ prototyped but how would one compare it.
>>>> 
>>> I understand your concern. "Any mobility" may not be adequate. 
>>> pedestrian ad hoc networks, vehicular ad hoc networks, ... 
>>> Different ad hoc networks may have different mobility models 
>>> (maximum speed, etc.). I only wanted to point out we do not
>>> assume a particular mobility model in developing
>>> autoconfiguration solutions.  In general, we do not assume
>>> apriori knowledge on locations and movement of MANET routers.
>>> 
>>> Kenichi
>>> 
>>> 
>>> 
>>>> Alex
>>>> 
>>>> 
>>>>>> After a node moves from one subnet to another: does it keep
>>>>>> its address?  Does it keep both its address _and_ its
>>>>>> prefix?  When it keeps its address - nobody else on the
>>>>>> previous link can use that address on that previous link?
>>>>>> 
>>>>> Yes, in the same MANET. We thus need to define MANET-local
>>>>> address. Kenichi
>>>>> 
>>>>> 
>>>>>> Despite the apparent complexity of describing this, I think
>>>>>> it's not so difficult - as long as two or more people have
>>>>>> encountered the same movement scenario. Alex
>>>>>> 
>>>>>> ______________________________________________________________________
>>>>>> 
>>>>>> 
>>>>>> This email has been scanned by the MessageLabs Email
>>>>>> Security System. For more information please visit 
>>>>>> http://www.messagelabs.com/email 
>>>>>> ______________________________________________________________________
>>>>>> 
>>>>>> 
>>>>>> 
>>>> ______________________________________________________________________
>>>>  This email has been scanned by the MessageLabs Email Security
>>>> System. For more information please visit 
>>>> http://www.messagelabs.com/email 
>>>> ______________________________________________________________________
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________ Autoconf mailing
>>> list Autoconf@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/autoconf
>>> 
>>> 
>> 
>> 
>> _______________________________________________ Autoconf mailing
>> list Autoconf@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/autoconf
>> 
>> 
> 
> 
> 
> _______________________________________________ Autoconf mailing list
>  Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf
> 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf