[rrg] On mapping systems

Michael Menth <menth@informatik.uni-wuerzburg.de> Mon, 14 December 2009 23:07 UTC

Return-Path: <menth@informatik.uni-wuerzburg.de>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D483A68C5 for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 15:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 lm7Mq3NtdZkQ for <rrg@core3.amsl.com>; Mon, 14 Dec 2009 15:07:48 -0800 (PST)
Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 8EFB73A68B8 for <rrg@irtf.org>; Mon, 14 Dec 2009 15:07:48 -0800 (PST)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 262835AC92; Tue, 15 Dec 2009 00:07:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 22F095AC91; Tue, 15 Dec 2009 00:07:34 +0100 (CET)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (g226139096.adsl.alicedsl.de [92.226.139.96]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id C26F15CCAE; Tue, 15 Dec 2009 00:07:33 +0100 (CET)
Message-ID: <4B26C52A.80802@informatik.uni-wuerzburg.de>
Date: Tue, 15 Dec 2009 00:07:22 +0100
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <5976B445-7209-4DE5-9D83-E2920265EB27@CS.UCLA.EDU> <4B25275A.4050101@informatik.uni-wuerzburg.de> <4B2665B9.2080903@tony.li> <4B269571.10406@gmail.com>
In-Reply-To: <4B269571.10406@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rrg@irtf.org, Lixia Zhang <lixia@CS.UCLA.EDU>
Subject: [rrg] On mapping systems
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2009 23:07:50 -0000

Hi Brian,

Brian E Carpenter schrieb:
> On 2009-12-15 05:20, Tony Li wrote:
>   
>> Michael Menth wrote:
>>     
>>> Hi Lixia,
>>>
>>> do mapping systems also belong to the discussed proposals? I assume
>>> they do not although a lot of the complexity taken out of the routing
>>> is put into them? If I am wrong, I would like to add FIRMS to the list
>>> of discussed proposals:
>>> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09-FIRMS.pdf
>>>       
>>
>> Michael,
>>
>> Mapping systems are obviously a component of a solution but are not by
>> themselves a solution.  To be considered seriously, they should be used
>> in conjunction with some network layer solution.
>>     
>
> Hmm. Don't you think that to some extent these should be orthogonal?
> A mapping mechanism needs to meet the specific requirements of a network
> layer mechanism, but that doesn't require the two to be irrevocably
> bound to each other.
>
> I have a feeling that the mapping system should be very general in
> nature, in case the first cut at either the locator or identifier space
> proves to fall short. Also I feel it should support hierarchy, even if
> we don't need a hierarchy from the start.
>
>     Brian
>   
I absolutely agree. However, I see two basically different cases:
a) mapping lookup performed only by hosts
b) mapping lookup performed also by intermediate nodes
In case of a), the mapping lookup must be fast but not very fast. DNS 
would certainly do. In case of b), the mapping lookup must be very fast 
because intermediate nodes need to store/drop/relay packets without 
locators and the time span for that should be minimized. In addition, a 
relaying function is possibly of interest to avoid extensive packet 
delay and loss which is not necessary for a). Hence, designing a mapping 
system for b) is more challenging than for a).

Security and scalability are general requirements for all mapping systems.

Best wishes,

    Michael


-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn