[RRG] Mobility in the future

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

I am replying to Russ White's message 716 (Thoughts on the
RRG/Routing Space Problem) regarding mobility.

Hi Russ,

You wrote, in part, quoting Scott Brim:

>> - Routing and addressing are more fundamental than mobility.
>> Mobility can adapt to R&A but not vice versa.
>
> In other words, mobility is a secondary requirement for IP
> transport. Either it is a small part of the traffic, and will not
> grow, so there is no need to address it (?).... Or, it's not a
> problem that needs to be addressed through routing, it should be
> handled elsewhere. IE, IP == POTS.
>
> That "stuff" folks are running over our transport are fine, just
> solve your own problems, and don't ask me to do it for you. IMHO,
> this is shortsighted.

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.

The mobile host needs one or more care-of addresses and a tunnel
from an ETR.  It also needs a tunnel to an ITR, if it can't send
packets out the way it likes from its care-of address.  Ivip
combines ETR, ITR and two-way tunneling into a "Translating Tunnel
Router", as described in this and subsequent messages on the RAM
list around 17 to 18 June:

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

If something slow like LISP was built - slow global query system for
pull (CONS and ALT), or slow push (NERD) - then people would soon be
wanting to make it go much faster to support mobility.

The high speed push Ivip intends to implement isn't just there for
mobility support.  It enables the end-user to implement their own
multihoming service restoration system, with whatever reachability
detection system they like, whatever logic, algorithms, manual
controls etc.  This is much more flexible and modular than forcing
all end-users to rely on whatever logic is built into the ITR, by
the RFC and the restricted nature of the mapping data.

The fast push system also relieves the ITRs of the difficult job of
deciding which of multiple ETRs to send packets too - with many such
ITRs trying to figure out the same stuff on their own.

Another major reason for the fast mapping updates is that it greatly
simplifies the mapping data: just a micronet's starting address, its
length and a single address for the ETR.  This, in turn, enables the
mapping system to work faster than if each item of mapping
information contained a bunch of ETR addresses, priorities etc.

(However, the non-Ivip ITR-ETR schemes which use such complex
mapping data and demand so much of their ITRs have an advantage over
Ivip in terms of load-sharing Traffic Engineering.  Ivip can only
split traffic over multiple ETRs by splitting a range of addresses
into smaller micronets, and having one or more micronet go to one
ETR and the others go to other ETRs.  So Ivip can't split the load
of traffic directed to one destination host.)

>> - In the real world mobile users are rather
>> provider-aggregated, and even if we use the currently conceived
>> route optimization mechanisms, the need for new map lookups
>> will be less than one would think.
>
> Today. Again, I believe it's wrong to base an architecture on
> today's traffic patterns. Part of the job of the IETF isn't to
> solve today's problems, it's to solve tomorrow's problems in a
> way that doesn't impact today's services.

Yes!

IP mobility today is like cellphones in the late 1970s.  We can only
vaguely imagine what it might do, how useful it might be and how
widely it will be adopted.

The ITR-ETR scheme needs to be built anyway, to solve the routing
scalability problem.  Done right, it can be the basis for a new form
of mobility with far surpasses the efficiency and usefulness of
current approaches.

Maybe we can get the cashed up mobile folk to pay for most of the
costs of the ITR-ETR scheme.  Hundreds of millions of people pay
very high rates for cellphone services.


  - 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