[RRG] Re: Mobility in the future - passenger jets again

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

I am responding to Tony Li and Jari Arkko.

Tony Li wrote, quoting Russ White, quoting me:

>>> I agree.  An ITR-ETR scheme with mapping updates which take a few
>>> seconds to be implemented in all ITRs provides a whole new global
>>> system for highly optimised mobility - for both IPv4 and IPv6, with
>>> few new host requirements.
>>
>> But.... A few seconds is probably too long for it to be useful in a
>> mobile environment.
> 
> A few seconds is more than sufficient to deal with a number of
> portability and migration use cases.  In particular, anything that is
> quick enough so that TCP connections don't break is extremely interesting.
> 
> This isn't to say that this type of delay is acceptable for all mobility
> use cases.  You'd probably be pretty upset if your cell phone cut out
> for two seconds at the edge of every cell.  However, for cases where
> your laptop transitions from WiFi to wired Ethernet, a few seconds to
> transition seems eminently doable and beneficial.

In general, Ivip's mapping wouldn't need to change when the Mobile
Node (MN = host or router for some network) changes from one
cell-phone base-station to another.  The same ETR would still be used.

The mapping would only need to change when the MN - or some external
monitoring system which controls the mapping - chooses another ETR.

Let's say the MN is a laptop with 3G, WiFi and wired Ethernet.

Initially the MN uses 3G, in a single mobile carrier's network,
using multiple base-stations.  Unless they cross some fundamental
border between sections of that network (maybe France to Germany or
similar) then at all times, the optimal ETR to use will be one
provided by that mobile carrier.  (The MN could also use a
Translating Tunnel Router - a combined ETR and ITR - outside the
carrier's network, but close to it.)

Now lets say the MN comes into a WiFi hotspot and is able to
establish a connection.  Mobility like this could be managed
manually, but I think the best approach is for the MN to work with
some global, distributed, management system to help it find ETRs in
the networks it connects with or to choose a TTR near to those
networks.

There could be all sorts of management systems.  These are not part
of the Ivip system, but the one chosen by this end-user would have
his or her credentials so it could authenticate itself and reliably
change the mapping of the MN's micronet.

The management system would also change the mapping for the micronet
the MN is using (perhaps a single IP address) according to whatever
logic the system has, and the end-user wants, to cause packets to be
tunneled to one ETR or another.  This would probably include a fancy
systems to organise and authorise the ETR in the new network to
handle packets for this MN, and probably for that network to accept
outgoing packets with the MN's micronet address in the source address.

Lets say the MN can now receive packets from an ETR in the WiFi
operator's network.  This is a cheaper and faster path for data than
the 3G network.  So the MN keeps the (presumably volume-charged,
rather than time-charged) 3G link going, but has the mapping changed
so incoming data comes to the ETR in the WiFi network.  Whether the
MN itself (automatically or manually) or the management system
changes the mapping is up to the end-user.  Most likely it would be
the management system communicating with suitable software in the
MN.  There could be a role for IETF involvement in such protocols,
but they don't directly impact Ivip or whatever ITR-ETR scheme is
used, so the end-user can create their own systems, or use other
organisation's management systems.

Over a few seconds (ideally) the ITRs through which packets
addressed to this micronet are being tunneled change their tunneling
to the new ETR in the WiFi network.

As long as there are two links and two ETRs operating at the same
time, there is no break in connectivity.  So VoIP and all other
protocols would be completely unaffected.

If the WiFi link fails for more than some predetermined time, then
the MN and/or the management system needs to change the mapping.
One option is the MN using the 3G link to send packets to the
management system to this effect.  (Cryptographic credentials
required, using something previously established.)  Then the
management system can issue a mapping change so the ITRs send
packets to the 3G network's ETR.

Ideally, before leaving the WiFi zone, the mapping needs to be
changed back to 3G system's ETR, so there is no break in service.
The MN could signal this to the management system, due to the user
indicating that the WiFi link was about to disappear.

Alternatively, the MN could tell the management system to do so
after when the WiFi signal became so weak as to cross some threshold
beyond which the 3G system is preferred.

The same principles apply when switching between 3G, WiFi and wired
Ethernet - or any other physical layers which can operate at the
same time.


The same principles apply when a passenger jet is flying from one
country to another.

The aircraft initially has a link via some means to a network X, and
the mapping for its micronet sends packets to the correct ITR at X.

Alternatively, the aircraft's router itself has some PA of address
space it temporarily uses from network X.  Then, the aircraft's
router can be the ETR for its micronet, even if XX is only one IP
address.

While connected to network X, the aircraft comes close to another
country and establishes a connection to network Y in that country.
When this connection is robust and preferred over the X connection,
either the aircraft's router or some centralised management system
(the airlines would run their own, most likely) would switch the
mapping to the ETR in Y's address space.

There would be absolutely no loss of connectivity.

Also, the aircraft can use both links for outgoing packets, as it
chooses.

In this way, an aircraft could travel the globe, with continual
connectivity for its own micronet.


Jari wrote:

> Maybe, maybe not. You are skipping over a lot of significant
> detail.

Me, skip over details??  I am trying to keep it brief, since this is
a mailing list.

The Ivip ID has lots more detail, but would be longer if I covered
mobility in it.  Instead, I refer readers to some June discussions
on the RAM list, which contain informative diagrams and descriptions
of the Translating Tunneling Router (TTR), such as:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01547.html

> What type of mobility are you trying to solve? Networks moving
> around? Hosts moving around?

Both, since they both need a micronet - one or more IP addresses.

An IPv6 host is likely to be indistinguishable from a network
anyway, since I can't imagine that any ITR-ETR scheme will divide
IPv6 space into divisions finer than a /64 for the purposes of
tunneling one ETR or another.

> The implications for what the global routing system
> must know about the moving entities are big.

I agree.  Pure push to every ITR in the world is not practical.

Pure pull is too slow, as long as the queries are typically answered
by only one or a few authoritative sources in the world.

Ivip enables any locally chosen penetration of push - to ITRDs and
QSDs.  Beyond that, it is pull, with the QSDs being smart enough to
remember recent queries about particular micronets, and to push
updates to the querier (a caching Query Server or an ITRC or ITFH in
host) when it receives updated mapping information for that micronet.

I think there needs to be some kind of financial charge for changed
mapping.  Maybe this needn't be more than a few cents - but it is
needed to deter high volumes of changes from users, unless of course
they actually value the mobility enough to pay for their global
impact.  This could be tricky, since there is a big difference in
impact between a cell-phone changing mapping, when only one or two
ITRs in the world are handling packets to its micronet - and a whole
public server farm changing its mapping, since there could be tens
of thousands of caching ITRs sending packets to the micronet at that
time.


> Also, what are the requirements for speed of updates?

I think it will be possible to securely and robustly get changes out
to all ITRDs and QSDs in "a few seconds".  In principle, maybe two
seconds or so, but it is early days yet and I am yet to write up a
detailed proposal for what I currently call the "Replicator" system.


> The type of mobility that is requested in today's networks goes
> all the way to up to the speed that is capable of avoid
> interruptions in VoIP calls.  This may be possible to
> do in the routing system, too, but the requirements are very
> different from merely supporting, say, site multihoming.

I can't imagine a secure, robust, way of getting mapping data out to
ITRs all over the Net in less than about a second.  That is bad news
for VoIP, but cellphone users tolerate such glitches now.

As noted above, the changed mapping only occurs when there is a
switch from one network's ETR to another.  In many cases, this will
involve simultaneous links to the two networks, using two radio or
wired technologies at the same time.

Assuming the 3G radio in the mobile device can't maintain
communications with two separate 3G networks at the same time, then
there will be a break of a few seconds when roaming to another,
commercially and technically separate network.  Maybe 3G voice
systems can minimise that glitch - I am not sure.

I think this approach of using a fast push distribution of probably
simple mapping data has many advantages for ordinary multihoming and
portability - most notably the modular approach of allowing the
end-user to employ their chosen control system.  This extends
directly into "mobile" speeds and frequencies of mapping changes.
But there there needs to be some kind of fee to help finance the
impact of each change on the global ITR-ETR system.

  - Robin    http://www.firstpr.com.au/ip/ivip/





--
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