[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 []) 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-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 ([]) by localhost (core3.amsl.com []) (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 []) by core3.amsl.com (Postfix) with ESMTP id C3B5A3A67C1 for <rrg@irtf.org>; Tue, 5 Jan 2010 23:29:15 -0800 (PST)
Received: from [] (wira.firstpr.com.au []) 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 (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

I meant to respond to this ID earlier:

  Understand Mapping
  Lixia Zhang and Dan Jen  2009-10-19


     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:


It does not apply at all to the TTR Mobility architecture, which was
first described in June 2007:


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

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:


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

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

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/