Subject: [RRG] RRG shouldn't try to directly address mobility, including qualifying mobility attributes

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 19 Mar 2008 14:10:36 -0700

Team-mates:

I've been grappling with mobility affects upon routing systems for much
of this decade. I am not optimistic that this group will be able to
directly address mobility in a manner that will result in an RRG
consensus. I also do not believe that this group is likely to be able to
qualify mobility attributes such as "granularity and churn" in a
satisfying manner. Rather, the following is the view from my knothole:

1) The semantics of mobility differs in different contexts. In my own
research, I have found it helpful to distinguish between geographical
mobility (i.e., the affects of one node moving relative to another,
which can also include the signal intermittence affects caused by
attenuation (distance) or signal blockages due to landforms, foliage,
buildings, particulate matter (dust storms), the weather, or the pitch,
roll, or yaw of the moving node impacting its own antenna's signal
propagation or reception) and organizational mobility (i.e., moving a
computer from one vehicle to another, moving part of an organization
into another part of an organization).

2) Different systems interpret geographical movement as being "mobility"
very differently. For example, for certain satellite systems, an entity
can move hundreds of miles and not leave the satellite's beam. From the
perspective of that satellite, that entity has not moved (i.e., no
mobility has occurred). By contrast, stationary nodes may exhibit
"mobility" given certain weather or particulate matter environments
(e.g., as a function of frequency ranges).

3) Routing protocols confuse underlying signal intermittence with
mobility. The impact of signal intermittence varies in terms of which
part of the protocol stack is being focused on. The higher one goes up
the protocol stack, the longer the duration the signal intermittence
event can be before the protocol must address it. One can take steps to
dampen these affects, but ultimately signal intermittence events will be
noted if their duration is long enough.

4) Mobility affects are a partial function of the network architecture.
Architectures similar to 3GPP, for example, naturally view mobility from
a mobile IP (MIP) perspective. By contrast, I have primarily been
working in MANET environments and those environments view similar
mobility events quite differently. It is my personal belief that
adherents of those two perspectives naturally interpret the same facts
differently -- and certainly various mobility attributes have very
different routing implications to each orientation.  

5) Ran Atkinson's posting on February 21st focused on a technical report
that for entities moving every few minutes or less, the protocol system
works better if mobility is handled at L2 than L3. Because I largely
agree with this conclusion, I mention Ran's posting here as another
datapoint suggesting that this group can't (fully) consider mobility
because L2 issues are out of RRG's scope. 

6) A great deal of published research has been addressing various
cross-layer protocol integration mechanisms for wireless systems over
the past many years. I believe that the technical literature is
concluding that cross-layer protocol integration techniques can
significantly dampen mobility affects upon IP routing protocols.
However, even if you agree with this conclusion, can RRG presume that
such techniques will be implemented in a consistent manner? I think not
(for the foreseeable future) ... thereby making the creation of a
consensus position for this group all the more difficult because we will
be talking apples and oranges -- and to what purpose?

7) I believe that the research community has already formed a consensus
that in wireless environments network performance and scaling is
enhanced if the network's topology is hierarchical. Of all of my
observations, I believe that this is the only useful observation that is
suitable for the RRG to use in order to create a consensus position.

Therefore, I believe that if RRG is to address mobility, it is because
the selected RRG approach is so clean that it incidentally also enhances
mobility (i.e., mobility is a secondary affect for RRG and not a gating
requirement).

--Eric

-----Original Message-----
From: William Herrin [mailto:[email-masked]] 

On Thu, Mar 13, 2008 at 6:18 PM, Tony Li <[email-masked]> wrote:
>  Or, in other words, we should drop the mobility discussion for now, 
> deal  with the granularity and churn issues, and then see if we are 
> happy with the  bounds that that imposes on mobility.

Hi Tony,

Do we have a consensus on what target numbers for granularity and churn
could support mobility directly in the routing system? If not, I submit
that we should continue our tangent long enough to get them.

While we might or might not want to support mobility directly in the
routing architecture, it would be very informative if we could say:
yes, this proposal meets the target criteria for mobility in the routing
architecture and no, that proposal does not.

Regards,
Bill Herrin

--
to unsubscribe send a message to [email-masked] 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

---

From: Robin Whittle <[email-masked]>
Date: Thu, 20 Mar 2008 11:43:30 +1100

Hi Eric,

In some ways I tend to agree with you that the RRG shouldn't devote
its attention in detail to mobility - which, as you wrote, is a huge
and somewhat disjointed field.

However, I actually disagree. I think it would be best to have a
continued exploration of mobility, as part of exploring what any
map-encap scheme will be required to do.

We cannot assume that mobility in the future will be exactly as it
is done now with mobile IPv4 and IPv6 techniques.  This is because
the existence of a global map-encap ITR network will, in my view,
render those techniques obsolete.  I think mobility in the map-encap
era will involve a new approach which supports all existing hosts
(no software upgrades) as correspondent hosts, with generally
optimal path lengths and without any fixed "home agent" router.

This will make it attractive for a mobile device to have as its
micronet or EID prefix a single IP address (or subnet) and retain it
indefinitely, including retaining connectivity all the way from one
city to another, via a passenger jet flight.

As I intend to write up in the future, this would work fine with the
mobile device having a WiFi link to the aircraft's NAT box, with the
public address of the NAT box being part of the aircraft's micronet
which is tunnelled to a TTR near the currently used ground station.
 The mobile device finds and tunnels to TTRs near the TTR currently
used by the aircraft - which change every few hours or so, with a
geostationary satellite link to one or more ground stations. This is
somewhat involved, but could be automated nicely so end-users never
have to think about it.  It would have generally optimal path
lengths and work fine with all existing hosts as correspondent hosts.

I think all the map-encap schemes support this new approach to
mobility, without any additional complexity.  (Though only Ivip has
the low-latency control of mapping which would be most desirable.)
So I think that mobility will be a big part of the usage of whatever
map-encap system is deployed.

I believe the RRG needs to assume massive adoption, massive number
of micronets/EIDs, greater total rate of updates and the
desirability of "single host" mapping granularity when developing
any map-encap scheme.

There seem to be two alternatives at least:

1 - Ignore mobility and go on and develop the most scalable, most
    deployable, most elegant etc. map-encap scheme for the basic
    routing scaling problem - and then when it is reasonably well
    developed see how well it would support mobility.

2 - Discuss mobility as part of the RRG process, since we can't
    reasonably forget about mobility due to it meaning  a much
    larger scale adoption of the map-encap scheme than would
    otherwise be the case.

Because of what I believe about all the map-encap schemes, 1 above
seems fine, but only if the RRG assumes "single host" mapping
granularity and massive deployment, high total update rates etc.

Since we have not reached consensus on this, I think it would be a
bad idea to try to lock away the mobility genie for the time being -
as if we already know enough about it or as if it doesn't matter
much in the design process to know whether the map-encap scheme will
be involved in mobility, or how it would be involved.

> mobility (i.e., mobility is a secondary affect for RRG and not a gating

LISP, APT, Ivip and TRRP can all do the same tunnelling of packets
to TTRs (Translating Tunnel Routers, which behave to the map-encap
scheme just like an ETR), in the model of map-encap assisted
mobility I describe at:

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

This is a very different approach from existing Mobile IP techniques
- and relies entirely on a global map-encap scheme which I guess
might be widely deployed in 4 or 5 years.

The map-encap scheme is involved only in the third level in the
whole system:

     1 - Layer 1 and 2 - below the IP layer.  Within the access
         network, such as switching between base stations, but
         always retaining the one IP address, which is used as a
         care-of address by the mobile node.

     2 - Between the the mobile node with its one or more care-of
         addresses to the one TTR.  Each care-of address is from
         a different access network in the one city - or the one
         1000km area or whatever - but also temporarily (with longer
         paths) from any access network no matter how distant.

     3 - The map-encap scheme using a mapping change to tunnel
         packets from correspondent hosts to the new TTR - and there
         typically only needs to be a new TTR after the mobile node
         travels 1000km or whatever.  Therefore mapping changes need
         not be frequent, but would ideally be conveyed to all the
         world's ITRs within a few seconds.

Jari Arkko agreed that this approach to mobility would not require a
change in mapping every time the mobile node moved to a new access
network:

   http://psg.com/lists/rrg/2008/msg00834.html

If one considers the interactions between the mobile node and the
TTR as separate from the map-encap scheme, and leaving aside the
latency of mapping changes for a moment, there is absolutely no need
for extra complexity in LISP, APT, Ivip or TRRP to support this
approach to mobility.

This TTR-based approach to mobility does not involve frequent
changes in mapping, but it would be very widely used and so
contribute enormously to the adoption of the map-encap scheme. So it
would lead to a greater total rate of mapping updates.

So perhaps we can't avoid the tentative assumption that a successful
map-encap scheme will be widely used for mobility - and that this
will involve potentially billions of micronets/EIDs, with a much
greater total rate of mapping updates than if the map-encap system
had nothing to do with mobility.

This greater number of EIDs and micronets is a consideration for the
RRG design process.  Likewise the granularity of mapping required
for cellphone and laptop mobility will probably be a single IPv4
address or IPv6 /64 (or perhaps IPv6 address).

All these systems - LISP, APT, Ivip and TRRP are "clean" in that
they are a previously not anticipated global tool for bringing
packets from non-upgraded correspondent hosts to a chosen TTR
(chosen to be close to or inside the current access network) along
generally optimal paths.  I think that the widespread deployment of
any one of these schemes would naturally lead to it being used in
this way to support mobility.

The main advantage of Ivip for mobility compared to LISP, APT or
TRRP is that Ivip is intended to support the end-user changing the
mapping of all ITRs in a few seconds - while the other schemes would
have typical latencies of minutes or more likely tens of minutes or
perhaps hours.  This low latency control of mapping is already part
of Ivip, to enable ITRs and ETRs to be simpler and to enable the
mapping information to be simpler - a single ETR address.

I think all these map-encap schemes meet your criteria of having
something already - as part of their basic support for multihoming,
TE and portability - that happens to strongly support mobility, at
least in the TTR-based approach I suggest.

As long as the RRG plans the map-encap system to support single IP
address granularity, and plans the system to cope with the massive
number of end-users and consequent number of micronets/EIDs and
higher total rate of updates, then perhaps we can not discuss
mobility . . .

But in order to reach consensus on this, we would have to keep
discussing mobility!

 - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 16:05:33 +1300

I too suggest *not* boiling this particular part of the
ocean. If we don't have a viable fixed network, mobility
will become moot anyway. First things first, for all the
reasons Eric gives.

    Brian