There are the following motilities.
1. Node mobility
(as an aside, if it is a 3000Kg IBM mainframe there should be enough
resources on it
to support Mobile-IPv6)
2. Subnet/router mobility
I guess there was a comment on it from Boeing yesterday at the niim
bof.
(what about a mobile Cisco GSR ? )
Does MIPv6 say anything about it ?
Subrata
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jari Arkko
> Sent: Wednesday, March 19, 2003 9:30 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Mobility in Nodes Requirements
>
>
> [EMAIL PROTECTED] wrote:
> > Jim,
> >
> >
> >>>I don't believe that servers, for example, need to implement mobile
> >>>node functionality. If a node is fixed and will not move, what use
> >>>is mobile node functionality?
> >>
> >>A server in a helicopter or plane is mobile for a few
> applications. I
> >>understand I am trying to make a point that this exercise
> needs to be
> >>focused on more than the term "node".
> >
> >
> > So, perhaps I should have said 'Nodes which change their IP
> addresses,
> > for example base on Mobile IP, MUST implement mobile node
> > functionality.'
> >
> > Would that kind of text cover your needs.
>
> This is a circular definition. The issue is that a node might
> not know whether its attachment to a network is going to
> change or not. Those that get these changes, could use mobile
> IPv6 to deal with it and still keep sessions flowing.
>
> Jim may have a point here about the server in a helicopter.
> But where do we draw the limit? How do we know that 3000 kg
> IBM mainframe isn't being flown around in a cargo aircraft?
> Also, the type of the interface on the device may have
> significance. Or the application; a sensor reporting its
> findings using a single packet would not need mobility.
>
> In conclusion I don't think we can base the mobile node
> support requirement on the above definition. The options that
> I see are the following:
>
> - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the
> current text uses MAY).
>
> - "Hosts SHOULD/MUST support mobile node functionality <condition>".
>
> Here <condition> could be e.g. related to the
> type of the device "on portable devices", or maybe "on devices
> weighing under 2 kilograms" ;-)
>
> We could base it on the type of the interfaces supported,
> e.g., "on devices that may use wireless interfaces",
>
> We could base it on the type of the application, e.g., "on
> devices that may have applications that require sessions to
> survive movements".
>
> Frankly, I'm not sure it is possible to formulate a good
> condition for the second option. So I'm inclined to think
> that its either the current MAY support or possibly SHOULD
> support. What do people think?
>
> >>>>> Hosts SHOULD support route optimization requirements for
> >>>>> correspondent nodes. Routers do not need to support route
> >>>>> optimization.
> >>>>>
> >>>>> Routers MAY support home agent functionality.
> >>>>
> >>>>Routers SHOULD support the HA is correct effort. Otherwise MIPv6
> >>>>don't work.
> >>>
> >>>Not all routers need to be Home Agents I don't believe that plain,
> >>>vanilla routers will be affected by home agent
> functionality.
> >>
> >>Routers that implement MIPv6 SHOULD support HAs. Again context is
> >>everything.
> >
> >
> > That text works for me.
>
> Uh... that's also a circular definition. Like Pekka noted
> already, there are two pieces of router functionality
> (sections 8.3 and 8.4). The current keywords are SHOULD for
> the AI option etc and MAY for the HA functionality. We can
> debate these keywords, but I personally think they are fairly
> close to the right thing.
>
> Jari
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
