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