Subject: Re: [rrg] RRG Mobility Architecture

From: RJ Atkinson <[email-masked]>
Date: Wed, 29 Jul 2009 14:51:56 -0400

Earlier, Heiner Hummel wrote:
> Suggestion: The RRG group may also discuss the importance and impact
> of IP Mobility for a scalable routing architecture on this Friday.
>
> Wrt above: Eventually by also envisioning roaming users who are ALWAYS
> roaming, i.e. without any home (agent).

I agree on both counts.

I think the community needs a solution that supports not only site
multi-homing in a scalable way, but that also supports individual
host multi-homing, site mobility, and host mobility -- all integrated
together, with suitable scalability, and including appropriate security
capabilities.

An accidental artifact of IETF processes is that work undertaken
in Working Group A is often undertaken in isolation from work
in Working Group B.  This is not the fault of any person, but
just an IETF process artifact that is sometimes unavoidable.
An occasional result is having IETF standards for both A and B,
but that do not necessarily combine together in a harmonious,
integrated, and scalable way.

As this is the IRTF, and as "architecture" is explicitly within
scope, it would be good if we considered the broader set of issues
as the Routing RG examines different architectural alternatives.

Yours,

Ran

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Jul 2009 22:24:03 +0200

It's a worthy endeavor to understand how two hosts that both always move
and have no home rendezvous.

Eliot

On 7/29/09 8:51 PM, RJ Atkinson wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 29 Jul 2009 18:16:03 -0400

On  29 Jul 2009, at 16:24, Eliot Lear wrote:
> It's a worthy endeavor to understand how two hosts
> that both always move and have no home rendezvous.

That's the hardest case, but not impossible operationally
*in the real world with reality constraints*.

THe main trick is to use DNS (or something like it) as
a fallback rendezvous to rediscover the correspondent's
new location.  (I think the idea of first using DNS for
mobility rendezvous might have been first published in
a paper in the IEEE LCS proceedings about a decade back;
it certainly is not my idea.)

One imagines that a control message ("ICMP Location Update")
can be sent by the host (about to move or just finished moving)
to its correspondents && the host also updates its A/AAAA
(or equivalent) records in the DNS using the widely available
Secure DNS Dynamic Update mechanism (available in BIND, MS Windows,
and for MacOS X [source: "DNS & BIND" book, 5th Edition])

If that ICMP message doesn't reach some correspondent (e.g.
because the correspondent moved at the same instant, unlikely
though that might be), then the correspondent can use the DNS
to find the original host's new address (and the original host
can use the DNS to find the correspondent's new address).

In the limit, if both nodes are constantly changing their
point of network attachment, then both nodes will not
be able to send or receive any packets before a new Layer-3
location change -- at which point both nodes are effectively
disconnected, at least until they stand still for a bit.

In practice, most mobility is handled by layer-2 mechanisms
(e.g. mobile phone stuff; IEEE 802.1 bridging) -- at least
part of the time.  For all of the discussion above, only
changes in the layer-3 point of attachment matter.

[In a previous life, I had some small experience dealing with
IPv4 mobility issues, as my then employer had a few hundred
ships deployed around the globe and some large number of
airplanes.  I find that their real-world operational issues
continue to be relevant.  Solutions that will work there
likely also will work nearly everywhere else.]

Cheers,

Ran

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2009 07:49:03 +0200

Ran,

Before we get into method perhaps it's worth understanding (a) which use
cases one wants to solve for, and (b) the idea that perhaps – perhaps –
one size does not fit all.  Also, it seems to me that another reasonable
question to ask in the context of mobility is what signaling is required
between layers?  Both above and below IP.  One thing that might then
prove useful is a comparison to where most implementations are.

The classic case and point of this would be when one wanted to move from
a cell carrier to 802.11 or back.  Another case would be moving from one
carrier to another.  A third would be moving within a carrier between
regions.

And then there's the question of scaling and general use.  For instance,
perhaps something will for cars but not trainloads of people all
rebinding at once.  Perhaps a solution will scale to that but not fast
moving trains.  Perhaps a solution will scale to that but not fast
moving airplanes.

Finally, there's a whole lot of work in this space.  One question that
should be asked is what would any new solution propose to solve that the
old ones don't?

Eliot

---

From: Tony Li <[email-masked]>
Date: Thu, 30 Jul 2009 08:21:17 +0200

> should be asked is what would any new solution propose to solve that the

All of the old ones have great difficulty in changing the L3 point of 
attachment, and end up using the Home Agent concept as the rendezvous 
point.  If location is independent of identity, then it's conceivable 
that one can update peer locations without loosing connections.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 30 Jul 2009 08:40:26 +0200

> together, with suitable scalability, and including appropriate security

I just wonder if they all should be solved with the same mechanism.  The 
issues in site mobility are by necessity network-level issues, but 
issues in individual node mobility are not all solvable at the network 
layer.  If some node mobility issues must be dealt with at higher 
layers, then that changes the context in which the ones that _can_ be 
solved at the network layer are considered.

> as the Routing RG examines different architectural alternatives.

Agreed, as long as we do it from the perspective of "RRG".

> disconnected, at least until they stand still for a bit.

... using the mechanisms you are assuming. :-)

Scott

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2009 08:41:20 +0200

> that one can update peer locations without loosing connections.

What about HIP?

---

From: Tony Li <[email-masked]>
Date: Thu, 30 Jul 2009 10:15:16 +0200

>> that one can update peer locations without loosing connections.

Yes, ok, if you go to the trouble of CGI's then you can change too. 
Wouldn't it just be simpler and cleaner to have location be separate?

Tony

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Thu, 30 Jul 2009 01:19:57 -0700

> > that one can update peer locations without loosing connections.

With HIP, how do two correspondents (which negotiate a HITs between
them) refer to a 3rd which they don't communicate with at the moment?
Ephemeral IDs are problematic in the real world, since global naming and
referrals today tends to use unique and semi-permanent IDs.

-Darrel

---

From: Scott Brim <[email-masked]>
Date: Thu, 30 Jul 2009 13:53:42 +0200

>> that one can update peer locations without loosing connections.

HIP doesn't handle both ends moving without at least one rendezvous 
server.  I don't know of anything that doesn't need some kind of stable 
point.

> Wouldn't it just be simpler and cleaner to have location be separate?

(1) it's possible to run HIP with only control messages secured, or 
various levels of security on the data packets.  (2) HIP is getting put 
in chips ...

... but (3) I don't understand, how does HIP not separate location?

> referrals today tends to use unique and semi-permanent IDs.

Referrals are another problem.  In a simple world you just go look up 
the referred HI or address or other stable identifier in a registry, 
like DNS or whatever you used to find the first peer you're talking to. 
  In a complex world, you may need something like 
http://tools.ietf.org/html/draft-carpenter-behave-referral-object (which 
was presented in BEHAVE).

swb

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 30 Jul 2009 09:24:08 -0400

On  30 Jul 2009, at 02:40, Scott Brim wrote:
> I just wonder if they all should be solved with the same mechanism.

I suggested that we needed an architecture that supports the
broad range of issues before the RG.  Eliot sought an example,
so I provided *an example*.

Now you and Eliot have both gotten bogged down in the example,
and discussion of architecture seems gone from the thread.

Sigh.

> The issues in site mobility are by necessity network-level issues,

That claim isn't obviously true.

For example, one imagines that an architectural approach that
supports host mobility could also support groups of hosts
being mobile together (i.e. network mobility).

Yours,

Ran
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2009 15:54:52 +0200

> and discussion of architecture seems gone from the thread.

I raised engineering constraints that we need to consider when designing
a system, and by no means all of them.  Determining the point at which
that crosses to architecture should occur directly after we've counted
the number of angels on a pin.

Eliot

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 30 Jul 2009 10:34:28 -0400

> the number of angels on a pin.

No.  You saw it yourself.  As soon as the phrase "engineering
constraints" appears, one has left architecture behind and crossed over
into engineering.

Mind, it is very important to get the engineering right.  The Internet
community keeps learning the hard way that it is also very important
to sort out the architecture BEFORE crossing over into engineering.

This is the kind of thing that jnc and some others of us have been
saying for a few years now on this list, so it is neither a new thought
nor uniquely mine.

Yours,

Ran

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jul 2009 16:35:56 +0200

And so the counting of angels has begun (or continued).

Eliot

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 30 Jul 2009 08:09:22 -0700

Beating an already dead horse: The MANET deployments I have been
involved with handle mobility within the L3 routing system and, of
course, have no difficulty in readily changing L3 attachment points. The
network attachment points may or may not be re-numbered, based upon the
nature of the movement (e.g., intra-subnetwork moves are transparent)
and scaling issues. 

Concerning HIP, we have extensive demos that show how HIP protects
communicating end systems from the effects of mobility and multihoming
in MANET environments. 

Our Secure Mobile Architecture (SMA), which is now available from The
Open Group, also shows that one can even replace entire underlying
network systems in real time without impacting the existing sessions of
communicating hosts that use HIP.

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 1:15 AM
To: Eliot Lear
Cc: RJ Atkinson; [email-masked] RG
Subject: Re: [rrg] RRG Mobility Architecture

Tony