Subject: [RRG] Mobility frequency

From: Randall Atkinson <[email-masked]>
Date: Thu, 21 Feb 2008 05:37:30 -0800

An earlier separate comment by Scott Brim triggered this thought...

Some in the IETF (historically at least, maybe not now) have wanted
to have IP mobility work well with many roaming events in 1 minute.

There is a useful and interesting NATO technical report [1] on IP mobility
that concludes that current IP mobility schemes don't really work well
for a device that moves its (layer-3) location more often than once
every few minutes.  Their conclusion, as I recall, was that when
considering mobility one ought to be trying to use Layer-2 mobility
(e.g. radios, satellites) for smaller and high frequency movements
(e.g. movements on the scale of seconds) and using layer-3 mobility
much less frequently (e.g. movements on the scale of several minutes
or longer).

That NATO report seems pretty sensible to me.  If one considers a
classical radio LAN, a node typically can move for a while/distance
before one needs to find and engage with a new uplink base station.
At least some mobile phone technologies also support the idea of
L2 mobility (e.g. between individual cells, but within one super-cell)
where an L3 handoff is only needed/applicable/useful between
super-cells.

The question of how much mobility a proposal ought to support,
if any at all, seems like a good one to ponder.

Yours,

Ran
[email-masked]

[1] A search engine likely can find a PDF copy of this;
I don't have one to hand this minute.

--
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: Eliot Lear <[email-masked]>
Date: Thu, 21 Feb 2008 14:53:19 +0100

Ran,

I didn't quite follow your conclusion.  Here is my own:

Future L3 solutions may provide the user with other options, but NATO's 
decisions seem prudent given the state of the art today.

A related thought:

The MIP and MIPv6 people developed their solutions based on a certain 
set of assumptions. taking into account any number of corner cases, as 
well as the general case.  What could another mobility solution offer / 
fix that MIP/MIPv6 didn't?

Regards,

Eliot

---

From: Randall Atkinson <[email-masked]>
Date: Thu, 21 Feb 2008 05:58:18 -0800

Earlier, Eliot wrote:
% I didn't quite follow your conclusion...

I did not attempt to make a conclusion.  I made an observation
about existing systems and posed a question for folks to ponder.

My apologies that I was somehow unclear.

% The MIP and MIPv6 people developed their solutions based on a certain
% set of assumptions. taking into account any number of corner cases, as
% well as the general case.  What could another mobility solution offer /
% fix that MIP/MIPv6 didn't?

Also good questions to ponder.

Ran

---

From: Scott Brim <[email-masked]>
Date: Thu, 21 Feb 2008 09:52:47 -0500

On 2/21/08 8:37 AM, Randall Atkinson allegedly wrote:
> Their conclusion, as I recall, was that when

> if any at all, seems like a good one to ponder.

IMHO routing and addressing is not the right place to deal with 
mobility, but routing and addressing must support a really good solution 
to mobility.  So it is a good idea to look at a particular approach and 
say "what kind of cool mobility tricks could I do in that environment", 
but whatever we come up with, other people will think of cool mobility 
tricks that we can't right now.

Based on history (and discussion with Lixia :-)) it is important that 
routing and addressing architecture be general, flexible and adaptable, 
and not precisely tuned to any presumed uses at this time.  For example, 
we do not know that MIPv6, or HIP, or PMIP is ever going to see serious 
deployment ... and we don't know what the next generation, being much 
cleverer than we are, will be able to do with whatever architecture we 
come up with.  I think we can safely assume that there will be a lot of 
good ideas at the session layer and higher.  Therefore we cannot put 
specific mobility requirements on our routing and addressing 
architecture.  We can, however, look at what mobility capabilities a 
particular approach *excludes* and have opinions about that.

> fix that MIP/MIPv6 didn't?

Right.

Scott

---

From: <[email-masked]>
Date: Thu, 21 Feb 2008 18:08:17 +0200

Hello Ran, 

There has been a lot of work in the IETF and IRTF that shows that
feasibility to use IP layer protocols to implement fast handovers. 

Please notice this one as well. There are many more similar results.

http://ieeexplore.ieee.org/iel5/10360/32961/01543800.pdf?isnumber=&arnum
ber=1543800
 
Even if mobility is persistently highly  exciting research question, I
believe the problem of this group is without mobility a challenging one.

Regards Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Randall Atkinson
>Sent: Thursday, February 21, 2008 15:38
>To: Routing Research Group
>Subject: [RRG] Mobility frequency
>
>Some in the IETF (historically at least, maybe not now) have 
>wanted to have IP mobility work well with many roaming events 
>in 1 minute.
>
>There is a useful and interesting NATO technical report [1] on 
>IP mobility that concludes that current IP mobility schemes 
>don't really work well for a device that moves its (layer-3) 
>location more often than once every few minutes.  Their 
>conclusion, as I recall, was that when considering mobility 
>one ought to be trying to use Layer-2 mobility (e.g. radios, 
>satellites) for smaller and high frequency movements (e.g. 
>movements on the scale of seconds) and using layer-3 mobility 
>much less frequently (e.g. movements on the scale of several 
>minutes or longer).
>
>That NATO report seems pretty sensible to me.  If one 
>considers a classical radio LAN, a node typically can move for 
>a while/distance before one needs to find and engage with a 
>new uplink base station.
>L2 mobility (e.g. between individual cells, but within one 
>super-cell) where an L3 handoff is only 
>needed/applicable/useful between super-cells.
>
>[1] A search engine likely can find a PDF copy of this; I 
>don't have one to hand this minute.
>
>--

---

From: Robin Whittle <[email-masked]>
Date: Fri, 22 Feb 2008 03:18:38 +1100

Eliot Lear wrote:

> What could another mobility solution offer / fix that MIP/MIPv6
> didn't?

Ivip's mobility works in the same way for IPv4 and IPv6, has:

1 - Generally optimal or nearly optimal path lengths.

2 - Requires no "home register" router.

3 - Requires no changes in the correspondent host.

4 - Requires minimal changes in the mobile host.

Point 3 alone makes it a very different kind of mobility than what
has been created with MIP/MIPv6.  I guess the developers never
contemplated a global ITR ETR system which could be controlled in
five seconds or so.

I don't think Ivip's kind of mobility is suitable for changes every
minute, on a continuing basis, unless the end-user is happy to pay
for the burden their updates place on the global fast push network.

This may be OK, since people are paying for cellphone calls (at
least hear in Australia) at rates of $30 an hour or more.  I am not
sure what a mapping update would cost, but I am thinking between a
cent and ten cents.

Scott Brim wrote, in part:

> We can, however, look at what mobility capabilities a particular
> approach *excludes* and have opinions about that.

A pure pull (ALT), or a slow push (NERD) or a slow hybrid push-pull
(ALT) is not easily upgradeable to a system which could provide a
genuinely new and attractive form of mobility: fast hybrid push-pull
(Ivip or similar).

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2008 10:20:38 +1300

I think we should also remember Layer 7 mobility. There are many
application suites that recover in one way or another from
a low frequency of Layer 3 disconnects and re-addressing events,
using Layer 7 identities to restore a connection and to maintain
application state. This is so much established practice that it
really gives us license to offer best-effort mobility at Layer 3.
That doesn't mean we shouldn't strive for fast handover etc.,
but ultimately it's the applications' job to survive connectivity
problems.

   Brian