Subject: [rrg] Mobility, frequency of mapping changes and TTRs

From: Robin Whittle <[email-masked]>
Date: Sun, 01 Feb 2009 13:37:21 +1100

Hi Noel,

In "Please respond: Questions from the IESG as to whether a WG
forming BOF is necessary for LISP" you wrote:

> Not necessarily. It all depends on what functionality you're
> trying to get out of that layer of binding, i.e. how often the
> average binding changes.   E.g. if you try and do some
> mobility through that binding layer (I'm not saying we should,
> just as an illustration) that will radically increase the
> rate/amount of updates.

The most obvious thought about using a core-edge separation
scheme such as LISP, APT, Ivip, etc.  (Six/One Router too?) for
mobility is that the mapping needs to change every time the
Mobile Node (MN) gets a new Care of Address (CoA).  This is not
the case, since the best way to cater for MNs is to have them
establish two-way tunnels to a "nearby" Translating Tunnel
Router (TTR).

The TTR acts as an ETR for packets going to the MN, and probably
as an ITR for packets coming from the MN.  The MN may have
multiple CoAs and would establish a tunnel from each to the
"nearby" TTR.  It is up to the MN and the TTR (not a concern of
the core-edge separation scheme) how traffic is directed over
these multiple tunnels.

If one or more of the new CoAs are not "near" the current TTR,
the MN can keep the current TTR and establish tunnel(s) from the
CoA(s) to another TTR which is "nearby".

There only needs to be a mapping change from the first TTR's
address to the second TTR's address when the excessive distance,
(or perhaps some other impediment, such as congestion) to the
first TTR makes the second preferable.

With Ivip, the end-user network (in this case, the owner of the
MN) pays a small fee per mapping change.  So the frequency of
mapping changes and their impact on the fast-push mapping
distribution system will tend to be a commercially agreeable
arrangement.

The consortium of Root Update Authority System organisations
which build and run the network (or all but the last stages,
near the ISPs) will be charging their end-user customers
directly or indirectly.  They will try to reduce fees and costs,
while making the system have the greatest capacity and performance.

The end-users pay for most of the fast-push infrastructure and
if they are not paying enough to run it well, the operators put
up the prices.  So the "tragedy of the commons" arrangement
where people can impose their changes on a global system without
in some way paying for the cost of these changes is largely or
entirely avoided.

I think we should encourage mobility for Ivip, since mobility is
so valuable and the revenues from this potentially huge number
of end-users will help pay for the fast-push mapping system.

The TTR approach to mobility for core-edge separation schemes is
described here:

  TTR Mobility Extensions for Core-Edge Separation Solutions to
  the Internet's Routing Scaling Problem

  Robin Whittle (First Principles) and Steven Russert (Boeing)
  2008-08-25
  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

This is not a peer-reviewed paper.  RRG folks are peers - so
please review it on the RRG list!

Not using something like the TTR approach turns out to be
difficult or impossible.  When a MN gets a CoA, it might be
behind NAT.  Also, the CoA address is probably not a place where
the MN could successfully send packets to the rest of the Net
with the source address being its EID/micronet address.

An ETR could presumably connect to some MN, if the ETR was wise
to the local network in which the MN had its CoA.  However, this
is impossible if the CoA is behind NAT - so in this situation
and perhaps in others, the MN needs to connect to the ETR by
establishing a two-way tunnel to the ETR *from* its CoA.

To get outgoing packets to the Net, the MN needs to have some
device which it can tunnel to which is able to forward these
packets.  When you look at doing all this starting with the
ordinary, non-mobile, ETR as a starting point, pretty soon you
realise the MN needs to create a two-way tunnel to the ETR
anyway.  Then, you might as well make this ETR handle outgoing
packets too - in which case it probably makes sense for it to be
an ITR too.  Then, you realise that this combined device - the
same thing as a TTR - does not have to be in the same access
network as the MN.  For efficiency (short physical paths, low
hop count, short delays, less packet loss), it needs to be
"near" to wherever the MN connects to an access network - but it
will still work, with more delays and greater risk of packet
loss, if the TTR and the MN are on opposite sides of the world.

"Near" probably means something like 1000km or so.  So a mapping
change is typically "needed" - more likely is desirable, but not
absolutely needed - when the MN moves more than 1000 km.   Some
MNs will move this far once or more a day - but only when on
commercial airliners or by car or train on long, linear, journeys.

Most MNs will stay in the same area for months or years and so
can keep using the one TTR - so there is no need for a mapping
change - despite connecting and disconnecting potentially
thousands of times to different access networks and so having at
various times potentially thousands of different CoAs.

While I agree that mobility would drive a much greater number of
mapping changes, this is not due to MNs getting new CoAs.  It
would be caused primarily by there being a vastly greater number
of mobile "end-user networks", each a handset or PC etc. than
there are conventional, non-mobile, end-user networks with any
need for multihoming, TE and portability.

A new CoA could happen very frequently, such as switching to
WiFi in a subway tunnel and then back to 3G when out of the
tunnel.  Just walking around a large city on a 3G network could
put the MN in an area for a different IP gateway, so it gets a
different CoA.

Moving something like 1000km - or whatever change in CoA is
required to make the now more distant current TTR a problem - is
a far less frequent event.

You are not saying that mobility should be handled by a
core-edge separation scheme but I am saying emphatically that it
should be.

The LISP folks must be assuming the use of their system for
mobility.  How else would there be 10^10 EIDs?  This is the
target set by Dino in recent posts for LISP-ALT and any other
core-edge separation scheme.

Mobility is at least as big a deal for TCP/IP as it is for
telephony.  The TTR approach enables the MN to retain its one or
more IP addresses - an EID prefix, micronet or whatever -
indefinitely.  As long as there is a mapping change to the new
TTR when the MN moves so far as to make it worth tunneling to a
new, closer, TTR, then the overall path of packets to and from
the MN and all its correspondent nodes is either optimal or
generally close to optimal.

Other than some tunneling and TTR communications software in the
MN, there are no stack, API or application changes in the MN.
Correspondent nodes require no changes whatsoever.  This will
work fine with IPv4 or IPv6.

However, global mobility for anything more than a billion or so
devices is going to require IPv6.

A billion single IPv4 address micronets would probably be fine
with Ivip.  The system can use address space close to 100%
efficiently, for instance breaking a /12 Mapped Address Block
(MAB) into 2^20 single IP address micronets, one for each
cellphone-PC-media-player-whatever.

Massive global mobile IP access networks will generally need to
be built with IPv6.  A MN can always tunnel to a TTR via IPv6
and conduct IPv4 communications to the rest of the world through
that tunnel - but in the long-term, if billions of people are to
have these things, even with 100% efficient utilization of IPv4
space with one IPv4 address micronet per each device, there is
not going to be enough IPv4 space to go around.

  - Robin

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg