[rrg] draft-jen-mapping does not apply to the TTR Mobility architecture
Robin Whittle <rw@firstpr.com.au> Wed, 06 January 2010 07:29 UTC
Return-Path: <rw@firstpr.com.au>
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 A418F3A67E9 for <rrg@core3.amsl.com>; Tue, 5 Jan 2010 23:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 UAlB-+HlouSA for <rrg@core3.amsl.com>; Tue, 5 Jan 2010 23:29:16 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C3B5A3A67C1 for <rrg@irtf.org>; Tue, 5 Jan 2010 23:29:15 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9124D175E57; Wed, 6 Jan 2010 18:29:11 +1100 (EST)
Message-ID: <4B443BC9.4050105@firstpr.com.au>
Date: Wed, 06 Jan 2010 18:29:13 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Dan Jen <jenster@CS.UCLA.EDU>
Subject: [rrg] draft-jen-mapping does not apply to the TTR Mobility architecture
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: Wed, 06 Jan 2010 07:29:17 -0000
Short version: This ID assumes that mobility involves the mapping changing every time the MN gains a new physical address. If this were the case, its conclusions would be valid. However, this is not true of the TTR Mobility architecture - so the ID's conclusions are incorrect. I meant to respond to this ID earlier: http://tools.ietf.org/html/draft-jen-mapping-00 Understand Mapping Lixia Zhang and Dan Jen 2009-10-19 Abstract: This draft discusses the different requirements that mapping to support mobility has versus mapping to support routing scalability. In mobility solutions, packets are forwarded to the location where mapping information is stored so that they can be encapsulated to the final destination. In routing scalability solutions, mapping information needs to be available at packet entry points to the network. Attempts to use one mapping system for both purposes can lead to high overhead in either mapping information distribution or otherwise mapping information discovery, as well as stale mapping information being used for data forwarding. I think this analysis is applicable to traditional Mobile IP (MIP) and to the LISP-MN mobility approach: http://tools.ietf.org/html/draft-meyer-lisp-mn-00 It does not apply at all to the TTR Mobility architecture, which was first described in June 2007: http://www.ietf.org/mail-archive/web/ram/current/msg01518.html and which was fully written up in August 2008: TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem Robin Whittle, Steven Russert http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf draft-jen-mapping is written as if all approaches to mobility involve the MN (Mobile Node) being tracked by the mapping system. This is the case for LISP-MN, critiques of which are: http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html In the TTR Mobility architecture, the ETR function is performed by TTRs (Translating Tunnel Routers) which are near, or perhaps within, whatever network the MN is currently using for one or more of its physical addresses. The MN establishes a 2-way tunnel to one or more nearby TTRs and the ITRs in the core-edge separation system tunnel traffic packets to one or more (one only for Ivip) of these TTRs. Another advantage of the TTR approach over conventional MIP or LISP-MN is that the MN can establish this tunnel from behind one or more layers of NAT. The MN can change its physical address frequently, establishing a new 2-way tunnel to the one or more TTRs it is using. So there is no need to change the mapping of its SPI (Scalable PI - AKA "EID" in LISP terminology) address space every time it gains a new physical address. If the MN's new physical address is physically distant - such as more than 1000 km in terms of actual packet paths - from the TTR it is currently using, then the MN can still use it perfectly well. This includes the MN gaining a physical address which, due to topology (such as a geostationary satellite link) involves paths to the current TTR which span the Earth. However, in the interests of shorter paths (reduced latency and fewer dropped packets) it is best for the MN to find a new, closer, TTR and have the mapping changed to point to this new TTR. Ivip can change the mapping in a few seconds, and the other core-edge separation schemes (LISP-ALT, APT, TRRP and TIDR) would take much longer. Still, all such schemes would work with the TTR Mobility architecture. With Ivip, the MN could drop its tunnel to the old TTR within a few seconds, whereas with LISP-ALT etc. it would need to maintain this tunnel for tens of minutes or more, due to the impossibility of getting fresh mapping information to all ITRs which might need it. The central point of draft-jen-mapping is: "attempts to inject mobility mappings into the scalability mapping system have revealed that the two do not fit together very well. "It is still very possible that a mobility solution can co-exist with a scalability solution, but one must be careful not to try to bundle both solutions into one mapping system." However this is based on the assumption that the mapping must be changed, for all ITRs which might need it, every time the MN gains a new physical address: "Once a entry router caches the current address of a mobile nodes, it has no way to know when the mobile moves again, resulting in stale cache entries being used for packet forwarding. So far there has been no good solution to this problem. Using short TTLs for caching simply lead us back to an overload of the mapping system." but this does not apply to the TTR Mobility approach. ITRs cache the mapping of the TTR, which does not change when the MN changes its physical address. - Robin http://www.firstpr.com.au/ip/ivip/
- [rrg] draft-jen-mapping does not apply to the TTR… Robin Whittle
- Re: [rrg] draft-jen-mapping does not apply to the… HummelResearch