Re: [RRG] RRG shouldn't try to directly address mobility, including qualifying mobility attributes

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

Hi Eric,

In some ways I tend to agree with you that the RRG shouldn't devote
its attention in detail to mobility - which, as you wrote, is a huge
and somewhat disjointed field.

However, I actually disagree. I think it would be best to have a
continued exploration of mobility, as part of exploring what any
map-encap scheme will be required to do.

We cannot assume that mobility in the future will be exactly as it
is done now with mobile IPv4 and IPv6 techniques.  This is because
the existence of a global map-encap ITR network will, in my view,
render those techniques obsolete.  I think mobility in the map-encap
era will involve a new approach which supports all existing hosts
(no software upgrades) as correspondent hosts, with generally
optimal path lengths and without any fixed "home agent" router.

This will make it attractive for a mobile device to have as its
micronet or EID prefix a single IP address (or subnet) and retain it
indefinitely, including retaining connectivity all the way from one
city to another, via a passenger jet flight.

As I intend to write up in the future, this would work fine with the
mobile device having a WiFi link to the aircraft's NAT box, with the
public address of the NAT box being part of the aircraft's micronet
which is tunnelled to a TTR near the currently used ground station.
 The mobile device finds and tunnels to TTRs near the TTR currently
used by the aircraft - which change every few hours or so, with a
geostationary satellite link to one or more ground stations. This is
somewhat involved, but could be automated nicely so end-users never
have to think about it.  It would have generally optimal path
lengths and work fine with all existing hosts as correspondent hosts.

I think all the map-encap schemes support this new approach to
mobility, without any additional complexity.  (Though only Ivip has
the low-latency control of mapping which would be most desirable.)
So I think that mobility will be a big part of the usage of whatever
map-encap system is deployed.

I believe the RRG needs to assume massive adoption, massive number
of micronets/EIDs, greater total rate of updates and the
desirability of "single host" mapping granularity when developing
any map-encap scheme.

There seem to be two alternatives at least:

1 - Ignore mobility and go on and develop the most scalable, most
    deployable, most elegant etc. map-encap scheme for the basic
    routing scaling problem - and then when it is reasonably well
    developed see how well it would support mobility.

2 - Discuss mobility as part of the RRG process, since we can't
    reasonably forget about mobility due to it meaning  a much
    larger scale adoption of the map-encap scheme than would
    otherwise be the case.

Because of what I believe about all the map-encap schemes, 1 above
seems fine, but only if the RRG assumes "single host" mapping
granularity and massive deployment, high total update rates etc.

Since we have not reached consensus on this, I think it would be a
bad idea to try to lock away the mobility genie for the time being -
as if we already know enough about it or as if it doesn't matter
much in the design process to know whether the map-encap scheme will
be involved in mobility, or how it would be involved.

You wrote:

> Therefore, I believe that if RRG is to address mobility, it is because
> the selected RRG approach is so clean that it incidentally also enhances
> mobility (i.e., mobility is a secondary affect for RRG and not a gating
> requirement).

LISP, APT, Ivip and TRRP can all do the same tunnelling of packets
to TTRs (Translating Tunnel Routers, which behave to the map-encap
scheme just like an ETR), in the model of map-encap assisted
mobility I describe at:

   http://www.firstpr.com.au/ip/ivip/#mobile

This is a very different approach from existing Mobile IP techniques
- and relies entirely on a global map-encap scheme which I guess
might be widely deployed in 4 or 5 years.

The map-encap scheme is involved only in the third level in the
whole system:

     1 - Layer 1 and 2 - below the IP layer.  Within the access
         network, such as switching between base stations, but
         always retaining the one IP address, which is used as a
         care-of address by the mobile node.

     2 - Between the the mobile node with its one or more care-of
         addresses to the one TTR.  Each care-of address is from
         a different access network in the one city - or the one
         1000km area or whatever - but also temporarily (with longer
         paths) from any access network no matter how distant.

     3 - The map-encap scheme using a mapping change to tunnel
         packets from correspondent hosts to the new TTR - and there
         typically only needs to be a new TTR after the mobile node
         travels 1000km or whatever.  Therefore mapping changes need
         not be frequent, but would ideally be conveyed to all the
         world's ITRs within a few seconds.

Jari Arkko agreed that this approach to mobility would not require a
change in mapping every time the mobile node moved to a new access
network:

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

If one considers the interactions between the mobile node and the
TTR as separate from the map-encap scheme, and leaving aside the
latency of mapping changes for a moment, there is absolutely no need
for extra complexity in LISP, APT, Ivip or TRRP to support this
approach to mobility.

This TTR-based approach to mobility does not involve frequent
changes in mapping, but it would be very widely used and so
contribute enormously to the adoption of the map-encap scheme. So it
would lead to a greater total rate of mapping updates.

So perhaps we can't avoid the tentative assumption that a successful
map-encap scheme will be widely used for mobility - and that this
will involve potentially billions of micronets/EIDs, with a much
greater total rate of mapping updates than if the map-encap system
had nothing to do with mobility.

This greater number of EIDs and micronets is a consideration for the
RRG design process.  Likewise the granularity of mapping required
for cellphone and laptop mobility will probably be a single IPv4
address or IPv6 /64 (or perhaps IPv6 address).


All these systems - LISP, APT, Ivip and TRRP are "clean" in that
they are a previously not anticipated global tool for bringing
packets from non-upgraded correspondent hosts to a chosen TTR
(chosen to be close to or inside the current access network) along
generally optimal paths.  I think that the widespread deployment of
any one of these schemes would naturally lead to it being used in
this way to support mobility.

The main advantage of Ivip for mobility compared to LISP, APT or
TRRP is that Ivip is intended to support the end-user changing the
mapping of all ITRs in a few seconds - while the other schemes would
have typical latencies of minutes or more likely tens of minutes or
perhaps hours.  This low latency control of mapping is already part
of Ivip, to enable ITRs and ETRs to be simpler and to enable the
mapping information to be simpler - a single ETR address.

I think all these map-encap schemes meet your criteria of having
something already - as part of their basic support for multihoming,
TE and portability - that happens to strongly support mobility, at
least in the TTR-based approach I suggest.

As long as the RRG plans the map-encap system to support single IP
address granularity, and plans the system to cope with the massive
number of end-users and consequent number of micronets/EIDs and
higher total rate of updates, then perhaps we can not discuss
mobility . . .

But in order to reach consensus on this, we would have to keep
discussing mobility!


 - 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