[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
- [rrg] belated msg: further description of the rec… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… Michael Menth
- Re: [rrg] belated msg: further description of the… Robin Whittle
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Scott Brim
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- [rrg] On mapping systems Michael Menth
- Re: [rrg] belated msg: further description of the… Vince Fuller
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- [rrg] Summary of RANGI//re: belated msg: further … Xu Xiaohu
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Lixia Zhang
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] Summary of RANGI//re: belated msg: furt… Tony Li
- Re: [rrg] belated msg: further description of the… Tony Li
- Re: [rrg] belated msg: further description of the… $witch
- Re: [rrg] belated msg: further description of the… Charrie Sun
- Re: [rrg] belated msg: further description of the… Noel Chiappa
- Re: [rrg] belated msg: further description of the… HeinerHummel
- Re: [rrg] belated msg: further description of the… Brian E Carpenter
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Patrick Frejborg
- Re: [rrg] belated msg: further description of the… heinerhummel
- Re: [rrg] belated msg: further description of the… Flinck, Hannu (NSN - FI/Espoo)
- Re: [rrg] belated msg: further description of the… Yangyang Wang
- [rrg] Summary of GLI-Split Michael Menth
- Re: [rrg] belated msg: further description of the… Lixia Zhang