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
On 7/30/09 12:16 AM, RJ Atkinson wrote:
>
> 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
>
>
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
