[RRG] Re: Supposed impossibility of scaling for mobility - easy explanation

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

Here's an easy way to convert an understanding of conventional
mobile IP into an understanding of the Ivip approach.

This Ivip vision of mobility is very different from Bill Herrin's
(message 766).  His vision involves the ITRs tunnelling packets
directly to Care of Addresses in each access network.  The Ivip
approach involves the ITRs tunnelling to relatively stable TTRs,
which involves far less mapping changes than with Bill's model.
Also, Bill's model involves each mobile node somehow forwarding
packets with its own IP address as the source, from various access
networks.  In the Ivip model, these outgoing packets are forwarded
from the TTRs, which are operated by a company with which the mobile
end-user has a lasting business relationship.


Start with the MN (Mobile Node) and a Home Agent (HA) router.

The HA is in one fixed location and the MN can be anywhere.  The MN
gains one or more Care of Addresses, CoA-A, CoA-B etc.  It builds a
2-way encrypted tunnel from each CoA to the HA.

Ordinary Correspondent Hosts (CHs) send packets to the MN on its
permanent IP address, which is always handled by the HA.  The HA
tunnels the packets to the MN.  In the opposite direction, the
packets from the MH addressed to the CH are tunnelled to the HA and
forwarded conventionally to the CH.

The MN needs some new software, which is fine.  In the above
scenario, the CH doesn't need new software.

The trouble is that the HA isn't necessarily anywhere near the CH or
the MN, so there is often really excessive path lengths.  If the MN
is in Los Angeles and the CH in San Francisco, it is clearly bad if
the HA is in Prague.  This is called "triangle routing".

The only way of fixing this with conventional Mobile IP is to put
fancy software in the OS of the CH, so it can send the packets
directly to the MN, thereby achieving optimal path lengths.  There
is a lot of complexity in this, in order to do it robustly and
securely.  This is called "route optimisation".

So conventional mobile IP can only achieve optimal path lengths by
the use of elaborate new software in both the MH and the CH - and I
think there needs to be a HA somewhere too to get things going and
to support CHs which lack the fancy software.


Now return to the plain use of the HA, with the CH having no special
software.  This is OK, except for the problem of "triangle routing".

With Ivip, the MH can set up 2-way tunnels with one or more
Translating Tunnel Routers.  These can be thought of like "Home
Agents" - except there are thousands of them around the Net,
operated by some company which the end-user has a business
relationship with.   The MN chooses a TTRs which is close to the
current access networks - and sets up tunnels to that TTR.  Now it
can use it somewhat like a HA.

This is where the map-encap scheme comes in.

Without the map-encap scheme, there is no way CHs could get packets
to these TTRs - unless the CHs had elaborate software and were in
some way coordinated, such as by a HA.

The map-encap scheme solves this problem neatly.  The end-user has a
micronet of address space (EID prefix, in LISP or ALT terminology).
 That micronet may be as small as a single IP address, but it could
be of any size.

The end-user arranges things so the TTR company can control the
mapping of their micronet.

The TTR company sets the mapping to point to the TTR which the MN
has one or more 2-way tunnels to.

This one TTR could have two 2-way tunnels to the MH, each via a
different CoA at a different access network.  Suitable software in
the TTR and MH sends incoming and outgoing packets over both links
for redundancy.

As long as the MH is in the same approximate geographic area, it
gains new CoA addresses in various access networks and makes 2-way
tunnels to the same currently active TTR.

Path lengths are optimal, since the TTR is near the MH and there are
ITRs near all the CHs.  The key point is that there is no need at
all for the CHs to have special mobility software.  So it works fine
for all IPv4 and IPv6 CHs.


When the MH moves significantly - typically 1000s of km - it can
still make 2-way tunnels from its new access network CoAs to the
current TTR.  However, it figures out (with the help of the TTR
company's network and its special software provided by that company)
that it is now far from the current TTR.  So it finds a nearby
second TTR and builds 2-way tunnels to it.

Once this is done, the mapping is changed to point to the new TTR.
There is no break in connectivity, since the MH has tunnels to both
TTRs.

Once the mapping change is complete, the old TTR isn't needed any
more.  All packets are again following optimal or close to optimal
paths, since the new TTR is close to the MN, and all the CHs are
close to ITRs.

As long as there is some kind of connectivity to some access
network, there is no loss of connectivity to the MN.

There is no need for mobility features in CHs, or in the access
networks.

The end-user needs a micronet and to be a customer of a TTR company.
 Neither the end-user or the TTR company need to have any business
relationship or technical coordination with the access network -
beyond whatever the end-user needs for their MN to be admitted to
the access network and to gain a CoA.

It is fine if the CoA is behind one or more layers of NAT, since the
MN makes the 2-way encrypted tunnel to the TTR.

Please see my previous message 765 for how there are 3 separate
mobility systems at work here, and how the mapping only needs to
when the MN moves large geographic distances.

Note that the MN <==> TTR relationship does all the mobility work
which is required while the MN stays in the one geographic area.
The same TTR can be used after a big move, but it is best to get
another one after moving a large distance.  It is only then that the
mapping needs to change.

When the mapping does needs to change, most end-users will want or
need it to change in a few seconds.  However, even the most rapidly
moving end-user won't be changing their mapping more than every hour
or two.

Unlike BGP and APT, which involve flooding of changes, with no
gateway, with difficulties authenticating the changes and with no
reasonable way of charging for each change, Ivip's changes are
propagated by a highly efficient past-push system, which will
involve charges in one form or another per update.

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.pdf


This pays for the fast push system and avoids the problem which is
inherent in BGP and APT of some end-users propagating what others
consider to be an unreasonably number of changes, burdening the
whole system, without contributing any payment towards it.

The role of the map-encap scheme in this form of mobility is to:

1 - Allow the use of TTRs - which are like inventing a HA nice and
    close to the current access network(s), while:

2 - Ensuring packets get to the the TTR with optimal or nearly
    optimal path lengths, while:

3 - Requiring no mobility software in the correspondent hosts.


This is not at all like multihoming to multiple CoAs and access
networks rather than to multiple ETRs.

It is a little like multihoming to one TTR or another according to
large (> 1000km) geographic movements.  However, there is typically
not a way of predicting where the new TTR will be.

So to make the system work well, there needs to be fast (seconds,
not minutes or hours) control of the mapping for all ITRs, so the
end-user can use the nearest TTR without undue delay.  Only Ivip is
intended to provide this.  However, the end users don't need to
change their mapping every few seconds, or in most cases every few
hours.

Since most people spend most of their time in the one 1000km
geographic area, the mapping update rate is slow and not at all
related to the changes in access network, which could be very
frequent indeed.

  - 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