Re: [rrg] draft-jen-mapping does not apply to the TTR Mobility architecture

[[e-mail]]

In einer eMail vom 06.01.2010 08:29:35 Westeuropäische Normalzeit schreibt  
[e-mail]:

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_ 
(http://tools.ietf.org/html/draft-meyer-lisp-mn-00) 

IMHO, mobility needs some sort of stability - coming from outside. I once  
referred to the lie baron Muenchhausen's story how he rescued himself from  
drowning, by grabbing his own hair and pulling himself out of the deep 
water.  Also, it is not very helpful if one endangered swimmer throws a life-belt 
to the  other swimmer. I think everyone understands (meanwhile) what I want 
to express  in this context.
Heiner
 
 


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  mailing  list
[e-mail]
http://www.irtf.org/mailman/listinfo/rrg