[mobile-ip] Re: hmip and mobile routers
[Sorry if you received this email twice or more, but it didn't get
through the list, to my knowledge. This is a last attempt, now that the
mobile-ip seems to (re)work]
Hi,
> Section 6 describes a mechanism of how mobile
> routers might be supported by HMIP. However, I
> think there is a fundamental category error being
> made here. Namely, it is expected that behind the
> mobile router are, in fact, mobile nodes.
I agree with this and this was already pointed out on this list between
48 and 49th IETF.
> reason why this expectation should be made: there
> is no reason why a non-mobile widget, say a PC,
> should not be able to be attached to a mobile
> router on a moving train. As currently defined,
> mobile IP is only a requirement if the device
> (router, host) is itself mobile. I do not see why
> we should expand that requirement to anything
> which is *behind* something that is mobile. In
> fact there could be a huge downsides to doing so,
> not to mention a whole lot of uncharted territory.
This question is addressed in my draft "Mobile Networks Support in
Mobile" IPv6
(http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt).
In this draft, the mobility of the network is completely transparent to
all nodes located in the mobile network. Following your instance,
the train is a mobile network and the gateway between the train and the
Internet is a mobile router. The Mobile Router obtains a new care-of
address at each new point of attachment to the Internet. There are
basically 2 kinds of nodes in this mobile network: permanently fixed
ones (TV screens, sensors, on-board computers, seats, ...) and mobile
ones. Mobile ones may be composed of those belonging to the train
(the ticket-collector ?), and some entering and leaving the train
(Passengers, PDAs, Mobile Phones).
In this proposal, Passengers get a care-of address when they enter the
train (obvious), but they don't need to acquire a new care-of address
every time the train is reachable from a new care-of address. IP
mobility of the network is therefore hidden to them.
I do see a benefit for Passengers to operate HMIP. In this case, the
MAP would be located in the Mobile Router.
On the other hand, it also seems obvious to me that fixed nodes should
not operate HMIP.
> Also: what happens if there is more than one
> router in between MR and the stationary host
> in MR's subnet? What happens if there's more
> than one MR? What delineates "my" MR versus
> somebody else's MR?
See my draft as it does address Mobile Networks of arbitrary size (one
or more subnets)
> It's possible I'm misreading that section, but if
> I am it's probably because the section doesn't say
> what needs to happen when the mobile router itself
> moves.
I agree with Mickael that the HMIP draft does not elaborate much about
this special case, but I must also advocate that it is not the object of
the HMIP draft to discuss about it. As I see it, the HMIP draft only
outline one instance where HMIP could be used: mobile nodes visiting a
mobile network and I agree with this. For the more general case
peculiar to mobile networks, I think that the debate turning around HMIP
should now be left out of this thread.
> However, even if nothing catastrophic
> happens, my original issue still stands:
> non-mobile hosts shouldn't be forced to become
> mobile aware by virtue of a mobile router some
> arbitrary number hops away.
As said before, this question is covered by my proposal in
draft-ernst-mobileip-v6-network-01.txt. The mobility of the network
is transparent to all the nodes located in the mobile network. The
Mobile Router is the only one that do manage mobility. The Mobile
Router sends Binding Updates containing the prefix of the Mobile Network
in addtion to a care-of address. See the draft for details.
May I have your comments on my draft ?
Thanks,
Thierry.
--
* mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69
* INRIA Rhone-Alpes Projet PLANETE (fax 52 52)
* MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html
Partial thread listing: