[RRG] Re: Supposed impossibility of scaling for mobility

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

Hi Hannu,

Thanks for your message, in which you wrote:

> Routing and mobility act on different time scales. 5 - 10s
> handovers are not acceptable in any working system. 

The model of mobility I am proposing is significantly different from
that developed in mobile IPv4/6.  With a global network of ITRs,
some new and much simpler and better methods can be employed.

Since you have read my message:

  http://psg.com/lists/rrg/2008/msg00535.html

I think you can see that the mapping doesn't have to change every
time the mobile device hands over from one base-station to another.
 As long as the base-stations belong to the same access network,
then the mobile device will be using the same TTR.  The mapping
points to the TTR, not to the mobile node's care of address.

If a mobile node leaves one access network and finds another, it can
still keep using the same TTR.  It would use the new care-of address
to establish a tunnel to the current TTR.

However, it might be best to establish an encrypted tunnel to a
second TTR which is topologically closer to the new access network.
 Once that is up, then the mapping can be changed.  There will be no
loss of connectivity, since the mobile device is receiving incoming
packets on two tunnels with two TTRs, and the correspondent hosts'
packets are being tunnelled by all the world's ITRs to one or the
other of these.


> I agree that
> an ideal routing scalability solution could support and handle
> some forms of mobility (maybe network mobility?), but I fail to
> see why to put so much emphasis to mobility support as we do not
> even have the scalability part carved out.

It so happens that the essentially real-time control of ITR
tunnelling which I think is the best approach for scalable
multihoming, TE and portability can also be used for this new
approach to mobility.  Mobility is such a valuable thing that even
if we didn't care at all about it, it would be good to have so we
could convince people to adopt the new map-encap type of address space.


> Robin, your solution seems to build on the idea that the MN could
> tell its location and from there to determine where the closest
> TTR is located. Are you assuming GPS or are you possibly
> concluding from the EID (care of address) that is not
> topologically determining? Or are you pinging the original TTR?

I envisage that the TTRs will be run by some company, and that there
will probably be multiple competing global networks of TTRs.  Each
such company, say GTI (Global TTRs Inc) will as part of its system
provide its customers (each with a mobile laptop, cellphone or
whatever) with software to run which sends out packets to GTI's
management servers around the Net.

The GTI servers and this software would regularly exchange packets,
enabling the GTI system to monitor reachability via the one or more
TTRs the device has 2-way tunnels to and/or directly to the devices
one or more care-of addresses.


This mobile host software would be aware that it has a new care of
address every time it connects to a new network.  Say it can use 3G,
WiFi, WiMax, Bluetooth and cabled Ethernet - all at the same time.

Every time it gets a new care-of address it sends out a few probe
packets, identifying itself, to various GTI servers.

The care-of address may be behind one or more layers of NAT.  But
this still enables the GTI servers to figure out where the mobile
device is, and to send packets back to it.  I am assuming UDP
packets with nonces, crypto etc. to make it robust against attackers.

The GTI management system would probably make the decision about
which TTR the mobile device should try to build a 2-way tunnel to.
This would require some sophistication, but before actually building
the tunnel, the GTI system could give the mobile device a few TTR
addresses, which it could ping or traceroute to.  Then the system or
the host software could decide which one to build a tunnel to.

Once it has done so, then the GTI system can use that tunnel to
verify delay, packet loss etc. characteristics of the link to the
second TTR.

Probably the control of mapping would by by the GTI system, rather
than directly by software in the mobile device.

If the GTI software for some reason figures the previous care of
address is going to disappear soon - and with it the tunnel to the
first TTR - then it will change the mapping over to the second TTR.

Also, if there is a second TTR established, but not yet in use for
traffic, and the first TTR link disappears, the GTI system would
detect this reasonably quickly and change the mapping - so the
end-user's connectivity would be re-established after (ideally) 5
seconds or so.


> Many times in the real life systems it is exactly the access that
> costs, therefore the access authorization plays a critical role.
> TTR or some other part of the system, maybe the AAA needs to be
> involved to grant the access. Naturally we need to bring in the
> user identities as well for the AAA.

I envisage the end-user being a customer of one of the TTR
companies, and giving that company their username and password or
whatever is needed to control the mapping of the end-user's micronet
(which is probably a single IPv4 address, or a /64 in IPv6).

The end-user would pay for the TTR service, which would be wholly
independent of whatever access networks they were using.
Nonetheless, the TTR company could have its own TTRs embedded in
particular access networks, as well as TTRs outside but near to
those access networks.  Also, the TTR company could pay to use the
TTRs of other TTR companies - so there could be TTR "wholesalers"
and customer-facing "retailers".


> There are a number of active WGs addressing the various aspects
> of the mobility, shouldn't we co-ordinate with them?

Probably, but this Ivip approach to mobility is in its early stages
of development, and seems to make at least some of the current
mobility work irrelevant.  People have put a lot of effort into this
work, and I am wary about presenting the Ivip proposal too boldly,
since it depends on new routing and addressing architecture and a
global ITR system which is yet to be built.

I did write to a few WG mailing lists last year when I first
developed this concept.  One or two people joined the RAM mailing
list and could see the value in what I was suggesting.

However, until about two weeks ago I had assumed that the TTR needed
to change with every new access network.  That involved relatively
frequent mapping changes.  Now I think that in most mobile
scenarios, as long as the TTR is within 1000km or so of the access
network, there is no pressing need to use another one - so the
mapping can remain stable until people move really large distances.

In many cases, they wouldn't move this 1000km for months.  So most
of the mobility action is taking place between the mobile device and
its nearby chosen TTR.  Also, there is access network mobility in
actions, such as between different base-stations or base-station
controllers, all of which is invisible to the IP system as long as
the mobile device keeps its care-of address.

This new approach to mobility is only possible because we assume we
have a global TTR system to send packets on optimal paths to the TTR.

The whole thing would work with LISP, APT and TRRP too - its just
that Ivip's fast control of all the world's ITRs enables fast
responses to the need to use a different TTR.

Just because this fast (ideally 5 second) mapping change time is
valuable for mobility (sometimes essential, like when you fire up
your device in another part of the world, and it makes no sense to
use the old TTR in Melbourne when you are in London) doesn't mean
that these mapping changes need to be frequent.  People don't move
1000km every few minutes.


I am working on a message depicting how a mobile device (such as a
laptop) keeps its own IP address as I fly from Melbourne to London,
with continued connectivity via WiFi to the passenger jet's network,
which also uses an Ivip-mapped micronet to seamlessly switch between
different ground-stations as it flies around the world.  SSH
sessions stay up, browsing continues etc.

I know this seems like overkill, but once you have a real-time
controllable global ITR system, it makes sense to develop the TTR
system and host software and do mobility this way.  Then it all
happens automatically, with generally optimal path lengths, no need
for new applications or specific mobility protocols (apart from the
tunnelling stuff in the mobile device) - and no mucking around
getting a new IP address, playing with DNS, starting up sessions
again etc.

 - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg