Subject: RE: [seamoby] nomenclature

From: "Gary Kenward" <[email-masked]>
Date: Fri, 5 Jan 2001 18:54:59 -0500

I agree in that we should not MIP nomenclature
until we understand the relationships between functional
entities.

Of course, if we are discussing MIP, we have to use
MIP nomenclature. Let's just not prematurely 
introduce it into SeaMoby.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 4:42 PM
> To: seamoby
> Subject: [seamoby] nomenclature
> 
> 
> 
> I don't want to pick on Dave in particular here,
> but it seems to me that it would be good if we
> could all try to converge on the same
> nomenclature. I see that Dave is using "FA" here
> which conjures up mipv4 FA's in my mind at least
> which he may or may not be intending.
> 
> In draft-blair-rt-mobileip-seamoby-00, we tried to
> gather up what we thought were the current
> as-consensus-as-we-could-figure-out terms for the
> various functional pieces out of MIPv6
> discussions. In this particular case, the term
> would be AR (= access router) instead of FA which
> seems more v6/v4 neutral.
> 
> I'd encourage everybody here to look over the
> nomenclature in the draft and either we decide to
> use it as a basis going forward, a refinement, or
> something else altogether, but I think it would
> generally help move discussions forward if we
> could come to some agreement on what we mean by
> various pieces of functionality.
> 
> 	       thx, Mike
> 
> Dave Martin writes:
>  > <snipping stuff about problem statement needed>
>  > 
>  > Here's a crack at one problem I would like to see solved.
>  > 
>  > Mobile IP does a decent job of tracking mobility, but it needs some
>  > improvements to support certain types of applications.  
> When a mobile node
>  > crosses from on FA cloud to another, the network will 
> likely lose several
>  > packets while the network is updated with the mobiles new location.
>  > Furthermore this period of "unreachability" while in the 
> transitioning phase
>  > generally lasts too long for time sensitive applications 
> (e.g., duplex
>  > voice, etc).  A mechanism is needed that will allow mobile nodes
>  > unrestrained mobility while minimizing (eliminating?) 
> packet loss and
>  > latency.
>  > 
>  > It probably needs some word-smithing.
>  > 
>  > 
>