Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 19 Apr 2002 17:03:45 +0000

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" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>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" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>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" <[email-masked]>
> > >To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
> > >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" <[email-masked]>
> > >To: <[email-masked]>; <[email-masked]>
> > >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" <[email-masked]>
> > > > >To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
> > > > >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" <[email-masked]>
> > > > >To: <[email-masked]>; <[email-masked]>
> > > > >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" <[email-masked]>
> > > > > > >To: "Hemant Chaskar" <[email-masked]>,
><[email-masked]>
> > > > > > >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
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Phil Neumiller" <[email-masked]>
Date: Sat, 20 Apr 2002 07:35:13 -0400

Some comments...
----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 1:03 PM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

> Hi James:
>
> L2 beacons have nothing to do with CAR discovery.

This would be one thing that I "would" create an L2->L3 trigger for.  This
is
really important.  You want a real tight interface between CAR and the
radio.
If we throw this out, CAR becomes pretty useless IMO.

In addition to the beacon itself, link quality assesment would be essential
too.

Thanks,

Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Sat, 20 Apr 2002 07:35:13 -0400

Some comments...
----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 1:03 PM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

Thanks,

Phil

---

From: "James Kempf" <[email-masked]>
Date: Sat, 20 Apr 2002 08:50:54 -0700

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 10:03 AM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

<[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Sat, 20 Apr 2002 08:50:54 -0700

jak

----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 10:03 AM
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53

<[email-masked]>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 21 Apr 2002 13:21:35 -0700

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 21 Apr 2002 13:21:35 -0700

James,

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Sun, 21 Apr 2002 02:47:29 -0700

> triggers with just L2 identifiers and then doing the mapping as you

The L2 triggers require some identifier. In general, I would think that
this would be an L2 identifier, but for particular L2s where it is
possible to provide the IP address and the network topology is fixed, it
could also be the IP address. The prototype IS-2000 RAN work falls into
the latter case. It is just a further optimization.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sun, 21 Apr 2002 02:47:29 -0700

jak