This is pretty simple folks.  Just focus the title of the document and
not make it general node requirements.  The general node reqs are in the
RFCs for IPv6.  They do not need to be re-written.

This document started because the 3GPP vendors did not want to do all
the musts in the RFCs.  Fine so lets just make this a 3GPP document
which it was in the first place.

/jim

 


> -----Original Message-----
> From: Jari Arkko [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 19, 2003 12:30 PM
> To: [EMAIL PROTECTED]
> Cc: Bound, Jim; [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]
--------------------------------------------------------------------

Reply via email to