Re: [Seamoby] Minutes for Meeting at IETF 53

"Hemant Chaskar" <hchaskar@hotmail.com> Fri, 19 April 2002 15:25 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23577 for <seamoby-archive@odin.ietf.org>; Fri, 19 Apr 2002 11:25:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17570; Fri, 19 Apr 2002 11:12:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17526 for <seamoby@ns.ietf.org>; Fri, 19 Apr 2002 11:12:41 -0400 (EDT)
Received: from hotmail.com (f52.law7.hotmail.com [216.33.237.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23077 for <seamoby@ietf.org>; Fri, 19 Apr 2002 11:12:37 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 08:12:10 -0700
Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 15:12:09 GMT
X-Originating-IP: [63.78.179.5]
From: Hemant Chaskar <hchaskar@hotmail.com>
To: kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
Date: Fri, 19 Apr 2002 15:12:09 +0000
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
Message-ID: <F52Dv4tJWFOBNxeWAre00009c23@hotmail.com>
X-OriginalArrivalTime: 19 Apr 2002 15:12:10.0008 (UTC) FILETIME=[93A1F980:01C1E7B4]
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

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" <kempf@docomolabs-usa.com>
>To: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
>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" <hchaskar@hotmail.com>
>To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
>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" <kempf@docomolabs-usa.com>
> > >To: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > >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" <hchaskar@hotmail.com>
> > >To: <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> > >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" <kempf@docomolabs-usa.com>
> > > > >To: "Hemant Chaskar" <hchaskar@hotmail.com>, <seamoby@ietf.org>
> > > > >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


_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby