Re: [rrg] belated msg: further description of the recommendation process

"Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com> Thu, 17 December 2009 11:36 UTC

Return-Path: <hannu.flinck@nsn.com>
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 7D5DB3A693C for <rrg@core3.amsl.com>; Thu, 17 Dec 2009 03:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 tIgr5NkYSHyI for <rrg@core3.amsl.com>; Thu, 17 Dec 2009 03:36:10 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 2039F3A6924 for <rrg@irtf.org>; Thu, 17 Dec 2009 03:36:09 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nBHBZpML003561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <rrg@irtf.org>; Thu, 17 Dec 2009 12:35:51 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nBHBZoXV017736 for <rrg@irtf.org>; Thu, 17 Dec 2009 12:35:51 +0100
Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 12:35:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7F0D.14FD1F9C"
Date: Thu, 17 Dec 2009 13:35:49 +0200
Message-ID: <2B5F3EA7272CFF47A66518E4FF3BE235045CC2DE@FIESEXC014.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: [rrg] belated msg: further description of the recommendation process
Thread-Index: Acp/DRSxmlYeORtqQZKR6c8JjX3T0Q==
From: "Flinck, Hannu (NSN - FI/Espoo)" <hannu.flinck@nsn.com>
To: <rrg@irtf.org>
X-OriginalArrivalTime: 17 Dec 2009 11:35:49.0952 (UTC) FILETIME=[1524DC00:01CA7F0D]
Subject: Re: [rrg] belated msg: further description of the recommendation process
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 17 Dec 2009 11:36:11 -0000

proposal: Compact routing in locator identifier mapping system
---------


key idea:
---------

Builds a highly scalable locator identity mapping system using compact
routing principles. Provides means for dynamic topology adaption to
facilitate efficient aggregation. Map servers are assigned as cluster
heads or landmarks based on their capability to aggregate EID
announcements.

gains:
------

Minimizes the routing table sizes in at the system level (= map
servers). Provides clear upper bounds for routing stretch that defines
the packet delivery delay of the map request/first packet.  

Organizes the mapping system based EID numbering space, minimizes the
administrative of overhead of managing EID space. No need for
administratively planned hierarchical address allocation as the system
will find convergence into a sets of EID allocations.

Availability and robustness of the overall routing system (including
xTRs and map servers) is improved because potential to use multiple map
servers and direct routes without involvement of map servers.

costs:
------

The scalability gains will materialize only in large deployments. If the
stretch is required to be bound to those of compact routing (worst case
stretch less or equal to 3, on average 1+epsilon) then xTRs need to have
memory/cache for the mappings of its cluster. 

full documentation:
-------------------

Sent to the rrg-mailing list 15th of Dec