Re: [Seamoby] Minutes for Meeting at IETF 53

["Eunsoo Shim" <[e-mail]>]

James,

To put a somewhat diverging comment, the low-latency handoff proposal of the
MobileIP WG requires the L2 triggers (L2-MT, L2-ST) contain the IP address
of the nFA. So in the scenario of the proposal, the mapping should happen
before the L2 trigger message is composed. Actually I prefer having L2
triggers with just L2 identifiers and then doing the mapping as you
described in the below.
Thanks.

Eunsoo

----- Original Message -----
From: "James Kempf" <[e-mail]>
To: "Hemant Chaskar" <[e-mail]>; <[e-mail]>
Sent: Saturday, April 20, 2002 8:50 AM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53


> I see two cases for CAR discovery. Simple case is L2 trigger on the AR
> or MN delivers an L2 identifier for the new AR or AP, AR or MN must map
> to IP address of new AR. This is essentially cross link reverse ARP and
> the MN doesn't have any choice about where it is going because it is
> moved by the Layer 2. Complex case is MN wants to find out what's
> available, uses CAR discovery to find an AR for the wireless
> medium/QoS/etc. that matches its preferences.
>
>             jak
>
> ----- Original Message -----
> From: "Hemant Chaskar" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Friday, April 19, 2002 10:03 AM
> Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
>
>
> > Hi James:
> >
> > L2 beacons have nothing to do with CAR discovery. I would like to
> understand
> > however if the capability set of ARs  behind those beacons is
> important or
> > not. If it is, it has to be indentified by CAR discovery protocol. If
> that
> > is the case, then there needs to be a creative implementation of CAR
> > discovery protocol for the case that this thread is concerned with,
> namely,
> > MN having single NIC and not being able to communicate with ARs behind
> those
> > L2 beacons without letting go the old connection (the difficulty
> persists
> > even if MN gets IP addresses in beacons).
> >
> > Hemant
> >
> > >From: "James Kempf" <[e-mail]>
> > >To: "Hemant Chaskar" <[e-mail]>, <[e-mail]>
> > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
> > >Date: Fri, 19 Apr 2002 09:18:53 -0700
> > >
> > >I don't see what L2 beacons has to do with CAR discovery. The issue
> is
> > >what ARs the MN has access to and what are their capabilities. How
> the
> > >MN chooses to use that in the context of a particular L2 is up to the
> > >MN.
> > >The ARs may be identified by their L2 identifier or by an IP address.
> > >
> > >             jak
> > >
> > >----- Original Message -----
> > >From: "Hemant Chaskar" <[e-mail]>
> > >To: <[e-mail]>; <[e-mail]>
> > >Sent: Friday, April 19, 2002 8:12 AM
> > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
> > >
> > >
> > > > Hi James,
> > > >
> > > > TAR is not in scope. I am talking about identifying capabilities
> of
> > >ARs (or
> > > > identifying match between capabilities of these ARs and MN's
> > >requirements)
> > > > that govern these L2 beacons.
> > > >
> > > > So, is it in scope of CAR discovery or we delegate the matter to
> IEEE?
> > > >
> > > > Hemant
> > > >
> > > >
> > > >
> > > > >From: "James Kempf" <[e-mail]>
> > > > >To: "Hemant Chaskar" <[e-mail]>, <[e-mail]>
> > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
> > > > >Date: Thu, 18 Apr 2002 08:33:10 -0700
> > > > >
> > > > >Hemant,
> > > > >
> > > > >Remember, TAR is not in scope.
> > > > >
> > > > >As a practical matter, I believe the 802.11 standard should
> provide
> > >some
> > > > >guidance, currently it doesn't.
> > > > >
> > > > >             jak
> > > > >
> > > > >----- Original Message -----
> > > > >From: "Hemant Chaskar" <[e-mail]>
> > > > >To: <[e-mail]>; <[e-mail]>
> > > > >Sent: Wednesday, April 17, 2002 2:45 PM
> > > > >Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
> > > > >
> > > > >
> > > > > > 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.
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Send and receive Hotmail on your mobile device:
> http://mobile.msn.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
>

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