Re: [lisp] LISP Mobility Architecture - mapping requirements for TTR mobility

[Robin Whittle <rw at firstpr.com.au>]

Hi Sam,

You wrote in part:

> I don't know what the TTR mobility approach is.

I proposed the Translating Tunnel Router approach on 2007-06-15:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

It is fully described here:

  TTR Mobility Extensions for Core-Edge Separation Solutions to the
  Internet's Routing Scaling Problem

  Robin Whittle (First Principles) and Steven Russert (Boeing)
  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf  2008-08-25

Briefly, a TTR behaves to LISP etc. just like any ETR.  MNs make a
2-way tunnel from their CoA (including from behind NAT) to a nearby
TTR.  The TTR also sends the MN's outgoing packets to the rest of the
world, so it may include an ITR function too.

TTRs are typically located outside access networks, so a MN using
multiple access networks in the one city or region can keep using the
same TTR.  No mapping changes for the MN's EID are required as long
as it keeps using the same TTR.  The MN can still use that TTR from a
CoA on the other side of the world, but for efficiency it would be
best to use a TTR near where it is currently located.  Then, with a
new TTR, there needs to be a mapping change.

The MN doesn't need any conventional Mobile IP capabilities, or to be
in a mobile-ready access network.  The MN gets its CoA like any other
host - WiFi, cabled Ethernet, 3G or whatever - including behind one
or more layers of NAT and including with DHCP assigned and
potentially unstable addresses.

If the MN's address lease expires and it gets another CoA, it needs
to establish a fresh tunnel from the new CoA to its one or more
current TTRs.  No mapping changes are needed for this.

The TTR system should work fine for IPv4 and IPv6.  It provides
global mobility, with the MN retaining the one EID address for all
application traffic.  The main IP stack in the MN is unchanged, as
are the applications.  The MN communicates normally with all
correspondent nodes - fixed and those using TTR mobility.

Path lengths between CNs and MNs is generally optimal, assuming there
is an ITR (or PTR) near the CN and the MN is using a TTR reasonably
nearby (< 1000 km or so).   There is no fixed "home agent", but the
system does require a sophisticated global network of TTRs.  Most
likely multiple companies will run such networks, charge for access
and compete for business.

Since one TTR, with one RLOC address, can serve thousands of MNs,
there is no wastage of RLOC space as would occur with the current
LISP-mobile approach.  Also, since MNs can be behind NAT, each MN
only consumes from the global unicast address pool its own, unique,
single IP address EID address.  With the current LISP-mobile, each MN
needs a global unicast EID address and its own global unicast (RLOC) CoA.


> What is probably in scope is to contribute a section to the mapping
> analysis/requirements document on what the requirements might be for
> various mobility approaches if we decide LISP should support mobility.
> Any effort you want to expend towards that would be greatly
> appreciated.

OK, here goes:

For the TTR approach, there are no additional mapping requirements
for LISP.

Each MN has its own EID, which may be a single IP address for IPv4 or
probably a /64 for IPv6.  The mapping only needs to change as noted
above - when the MN uses another TTR.

Exactly how MNs find TTRs, how they securely establish their 2-way
encrypted tunnels to the TTR, the commercial arrangements for using
TTRs from any one TTR network etc. are all quite separate from the
core-edge separation scheme (LISP, APT, Ivip or whatever) itself.
The TTR behaves like any ETR.

Each TTR network can have its own arrangements for tunneling,
managing MNs etc. and so would provide each MN with its own software
to implement this.  Ideally there would be IETF standards for all
this, but this is a separate matter entirely from the core-edge
separation scheme.  To the core-edge separation schemes data plane,
the TTR is simply an ETR and also a source of packets, probably with
an ITR integrated in it as well.

As long as the MN has a single TTR, the mapping of the MN's EID is no
different from that of any single-homed EID - it consists simply of
the TTR's address.

If the MN has two or more active TTRs, which is possible, then the
mapping would be like a multihomed end-user network with two or more
ETR addresses in two or more ISPs.  Alternatively, the mapping can be
just for the newest, closest, TTR and it is fine for some ITRs to be
running from their cached version of the old mapping, and so
tunneling packets to the old, and now more distant, TTR.

In principle, the MN itself could control the mapping of its EID.
However, this would be very tricky and I expect the TTR system to
work best when the MN uses a commercial TTR network, whose servers
would control the mapping of the MN's EID and coordinate the way the
MN tunnels to TTRs.

That distributed network of servers would be the best place to decide
on the mapping of the the MN's EID, since that network is robust and
always connected to the Net, which the MN is not.  That network can
probe reachability of its TTRs and it will know which of potentially
several TTRs has the best connectivity to the MN.

Also, the MN has restricted, unreliable and possibly expensive
connectivity, so it would be best if the TTR company's network of
servers managed the MN and the mapping of its EID.

The TTR company's network of servers can interface to the LISP-ALT
network just like any other LISP-using end-user network - in
whichever way makes most sense for LISP.

Typically a MN would choose a single TTR company to manage its EID.
The most likely arrangement would be for that company to have a slab
of address space which it splits into individually mappable EIDs, one
for each of its MN customers.  So a single TTR network company might
control the mapping for millions or hundreds of millions of small
EIDs.  From the point of view of LISP's mapping system, this would be
exactly like a non-mobile end-user network with a large EID address
space which has chosen to split that address space into many
independently mapped EIDs.

Because mapping changes will only typically occur when the MN
connects to the Net somewhere very distant (such as > 1000km) from
its current TTR, mapping changes will not be particularly frequent.
If the mapping change takes some time to propagate to all ITRs, such
as by simple cache expiry, this is fine, since the MN can still have
tunnels to its old, and now distant, TTR, while it has tunnels to a
new, closer TTR.

Unlike the LISP-mobile approach, there is no need for mapping changes
every time the MN gets a new CoA.  Nor is there any need for the MN
to directly update the mapping cache of ITRs which are tunneling
packets to an initial, and now distant, TTR.


The current LISP-mobile I-D involves some mapping system
requirements, such as the ability of the MN to rapidly update the
mapping of ITRs which are tunneling packets addressed to its EID.  I
can't advise on this and I believe this approach to mobility - making
the MN be its own ETR - will not work.

  - Robin