Re: [RRG] Mobility, update rates & charging per update

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

Hi Jari,

Thanks for this:

> And I agree with Robin that mobility does not have to imply change of
> the tunnel router endpoint. This does reduce mapping changes. 

I am maintaining links to messages and other resources concerning
map-encap support for mobility at:

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

> However, I'll note that administrative boundary crossings are quite 
> typical even in situations where you don't move a lot physically. 
> E.g., from my office to the city and then to my home; not far away 
> physically, but they reside in very different places in the Internet 
> topology.

The mobile node can still use the original TTR (Translating Tunnel
Router, which behaves like an ETR to the map-encap system).  The only
reason for using another TTR would be that it is closer to the currently
used access network and that the first one was far enough away (assuming
this distance would worsen traffic path lenghts, which would often be
the case) that the extra path lengths was a concern to the user.  Then,
it would be worth doing a mapping change to the new TTR.  

Assuming TTRs were located at or near major Internet peering points, I
imagine that most networks in most major cities or geographical areas
would have a link of some kind leading to that peering point.

With traffic to the mobile node from globally dispersed hosts, it
probably doesn't matter much if the TTR is 1000km away, unless for some
reason there are so many hops in that distance, or packet loss, that it
would be better to have a closer TTR.

Also, if you were in a city getting a lot of traffic from that city, or
from the same access network, then it would be best to have a TTR as
close as possible to or within the access network.

But the mobility system will still work even if the TTR is on the other
side of the planet.  Choosing a closer TTR and changing the mapping to
that is simply to reduce path length, delays and packet loss.

If you working for a large corporation, your mobile node's care-of
address at work (say WiFi in the office, or via an Ethernet cable) would
be in the corporate network - which may not have many links to the rest
of the Net.  Perhaps it works primarily over private links, to support
inter-office communication as the first priority.  Then, the nearest
link to the rest of the Net may be some distance away - perhaps in
another country.  That would be a case where it might be best to use a
nearby TTR.  If you were exchanging a lot of traffic with other hosts in
the same network, including mobile hosts, it would be best if your
mobile node and and the others used a TTR in your network, reasonably
close to your point of connection.


> (In any case, what I am looking forward from the RRG or anyone who is
> working in this space is a solution to the routing scalability 
> problem. I don't have a solution for that. 

   http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

> I do have plenty of solutions for the mobility problem, however, 
> some deployed some not. 

The map-encap mobility approach with TTRs I suggest is the only one I am
aware of which provides generally optimal path lengths without requiring
any new software in the IPv4 or IPv6 correspondent host.

> I have a hard time believing mobility is going to be the deciding 
> factor with regards to a new routing architecture. Lets see a working 
> routing architecture first. Just a personal opinion...)

I think there are big differences between the map-encap proposals, such
as Ivip being modular - leaving reachability and multihoming failure
restoration decisions to the user to perform in real-time.

Nonetheless, if two map-encap systems were judged reasonably equivalent
in terms of overall support for scalable multihoming, portability and
TE, and one could support a powerful new form of mobility, while the
other could not (such as LISP, which aspires only to work with current
mobile-IP techniques) then I would think that mobility would be the
deciding factor.

  - 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