Re: [Seamoby] Minutes for Meeting at IETF 53

["Hemant Chaskar" <[e-mail]>]

Hi James:

If there are more than one L2 beacons available (of comparable signal 
strength), probably governed by different ARs, how do we choose? I do not 
have problem choosing randomly, but just want to confirm if this is the way 
we want to proceed.

There is no doubt that handoff is necessary as old link will fade, but you 
still have choice as to which new beacon to hold on to.

Hemant


>From: "James Kempf" <[e-mail]>
>To: "Hemant Chaskar" <[e-mail]>, <[e-mail]>
>Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
>Date: Tue, 16 Apr 2002 15:44:48 -0700
>
>Right, that's what I'm saying. There is one case where the MN needs to
>choose, and the other where the MN and AR get an L2 address and don't
>have a choice. The handover happens because, if not, the power will fade
>and the MN loses link connectivity.
>
>The former case might require capabilities, the latter just requires
>cross link ARP.
>
>             jak
>
>----- Original Message -----
>From: "Hemant Chaskar" <[e-mail]>
>To: <[e-mail]>; <[e-mail]>
>Sent: Tuesday, April 16, 2002 2:17 PM
>Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
>
>
> > Hi James:
> >
> > What do you mean when you say that hearing multiple L2 is equivalent
>to
> > inter-technology case? I do not get the point. Why can't the MN listen
>to
> > different L2 beacons of the same technology? I guess it can, and
>hence, it
> > still needs to chose one among them for handoff. Then the issue is
>exactly
> > the same as Glenn raised for single NIC case: How to get capabilities
> > without letting go the old connection? Of course, I am assuming that
>these
> > L2's have comparable signal strengths.
> >
> > Hemant
> >
> > >From: "James Kempf" <[e-mail]>
> > >To: "Hemant Chaskar" <[e-mail]>, <[e-mail]>
> > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
> > >Date: Tue, 16 Apr 2002 10:26:45 -0700
> > >
> > >
> > > > >[The Issue]
> > > > >It seems that the minutes indicate that people have somehow come
>to a
> > > > >conclusion that there is no need for access routers to divulge
>that
> > >they
> > > > >are
> > > > >geographically adjancent to themselves via the IP infrastructure.
>The
> > > > >minutes also seem to indicate that the mobile alone should be the
> > >only way
> > > > >to pass addresses of CARs to source ARs.
> > > > >
> > > > >[Technical Questions]
> > > > >O.K. If this is true then how will a mobile pass this information
>to
> > >their
> > > > >source AR if the mobile only has one NIC and that NIC is only
>capable
> > >of
> > > > >listening to one media at once?
> > > >
> > > > [HC] I agree that this is a genuine technical problem. What I
>would
> > >really
> > > > like to understand is whether the above is a relevant case for CAR
> > >discovery
> > > > or we simply neglect it and focus only on two physical interfaces
> > >case. I
> > > > raised this question before, but we have not had much discussion
>on
> > >it. In
> > > > any case, address translation part of CARD will be required in
>this
> > >case for
> > > > fast handoff support.
> > > >
> > >
> > >In a single interface handoff situation, Layer 2 typically delivers
>the
> > >AP or AR L2 identifier to which the MN will be handed over. This
> > >information is required (by the MIP fast handover algorithms) at the
> > >MN's AR. So the issue is fairly simple: the AR must be able to do
> > >reverse address translation in order that it can contact the other
>AR.
> > >Capabilities aren't involved, except to the extent that the MN can
>hear
> > >multiple L2s and make the decision. But this is exactly the same as
>for
> > >the intertechnology case.
> > >
> > >             jak
> > >
> >
> >
> > _________________________________________________________________
> > Join the world's largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
> >
> >
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby