Subject: (ION) Mobile NHC concept

From: Albert Manfredi <[email-masked]>
Date: Fri, 27 Mar 1998 17:26:43 -0500

I'm trying to understand this concept of a mobile NHC. Perhaps it
could work in different ways.

1. Assume, since this is the IETF, that we're talking IP over ATM
and the client is a mobile IP over ATM unit.

2. The mobile unit connects to a local ATM-capable ISP.

3. The mobile unit is assigned a temporary IP address, the visited
server finds the home server, and we're set up for mobile IP.

4. Now, the question is, what NHS does it make sense to use as the
"serving" NHS for this mobile client? I maintain that the only NHS
that makes sense must be the one at this mobile ATM ISP. No?

After all, within the model used by the IETF ION, there is no
guarantee that this remote ISP has ATM connectivity clear back to
the mobile's "home NHS," as it were. And the serving NHS MUST have
direct ATM connectivity to the NHC.

And even if there were ATM connectivity all the way back, it seems
unwise to have the "home NHS" be the one which determines the
shortcut, via IP routing, to the mobile unit. I mean, the mobile
unit might be next door to a non-ATM destination host, and this
distant NHS could end up being in, or close to, the "shortcut path"
between mobile unit and non-ATM destination next door. Wow.

So in this scenario, I believe it only makes sense to talk about ATM
shortcuts if the serving NHS is taken from somewhere _close_ to the
mobile NHC. Unless I'm missing something here.

I suppose we could go the other way, not use mobile IP concepts at
all, and have the NHC become a mobile ATM unit that simply links
back, via ATM, to the "home server" and "home serving NHS." And
carries out its remote communications using the home IP address.
This would be little more than a long distance phone link to a home
server, though. But at least the home NHS would make sense as
serving NHS.

Interested to hear what others are thinking. Thanks.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.