Subject: RE: Mobility in Nodes Requirements

From: [email-masked]
Date: Thu, 20 Mar 2003 02:00:19 +0200

Jari,

Do you have any specific text changes compared to the current
version?

John

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 19 March, 2003 19:30
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Mobility in Nodes Requirements
> 
> 
> [email-masked] 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-masked]
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Mar 2003 03:07:36 +0200

> Do you have any specific text changes compared to the current

What I was trying to say was that we can debate the right keywords,
e.g. HA support MAY => SHOULD but that the current text structure
is probably more or less what should have.

And I vote for keeping the current keywords, too.

Jari