Re: [Seamoby] Minutes for Meeting at IETF 53

"Eunsoo Shim" <eunsooshim@hotmail.com> Wed, 17 April 2002 11:29 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 HAA14655 for <seamoby-archive@odin.ietf.org>; Wed, 17 Apr 2002 07:29:01 -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 HAA02402; Wed, 17 Apr 2002 07:22:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02375 for <seamoby@optimus.ietf.org>; Wed, 17 Apr 2002 07:22:40 -0400 (EDT)
Received: from hotmail.com (oe25.law4.hotmail.com [216.33.148.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14601 for <seamoby@ietf.org>; Wed, 17 Apr 2002 07:22:36 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 04:22:08 -0700
X-Originating-IP: [211.192.81.212]
Reply-To: Eunsoo Shim <eunsoo@ctr.columbia.edu>
From: Eunsoo Shim <eunsooshim@hotmail.com>
To: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>, 'Hemant Chaskar' <hchaskar@hotmail.com>, kempf@docomolabs-usa.com, seamoby@ietf.org
References: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117>
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
Date: Wed, 17 Apr 2002 20:27:13 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <OE25GMX5qK7QaaC4omk00002592@hotmail.com>
X-OriginalArrivalTime: 17 Apr 2002 11:22:08.0633 (UTC) FILETIME=[1C8BC690:01C1E602]
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Hi, Karim,

What kind of L2 triggers provide the IP address(es) of the target
(candidate) access routers?
Would you mind providing some examples?
Thanks.

Eunsoo
----- Original Message -----
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: "'Hemant Chaskar'" <hchaskar@hotmail.com>; <kempf@docomolabs-usa.com>;
<seamoby@ietf.org>
Sent: Wednesday, April 17, 2002 3:13 AM
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53


> > >  > 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.
>  > >
>  > >This is not really applicable to Mobile-Initiated MIP Fast Handoff.
>  > >In Mobile-initiated we consider the useful case where the
>  > MN can recover
>  > >the CAR IP address/es from the L2 trigger. The MN then sends a Proxy
>  > >Router Solicitation (RtSolPr) to its curent AR containing
>  > one or more CAR
>  > >IP addresses. This means that the source AR already gets
>  > the CAR addresses.
>  > >So we can do without the AR doing translation or
>  > discovering geographical
>  > >adjacency. The MN can pass these CAR address/es to the
>  > source AR for both
>  > >single and multiple-interface MNs. So I think that the
>  > conclusion from the
>  > >meeting is compatible with MIP Fast Handoffs.
>  > >
>  > >/Karim
>  >
>  > [HC] I am wondering, if this useful case is genral enough.
>  > In other words,
>  > can MN always get IP addresses from AP beacons (or L2
>  > triggers) without
>  > having to acquire connectivity with AP. More so, in single NIC case.
>
> [KEM] If you get a trigger at the MN you are somehow told
> that you have to move and this could contain the network's desired
> place where you should move (if it's multi-technology then one network
> may not know all that is possible). Here it is assumed that these are
> IP addresses or that the IP addresses can be easily recovered. The MN
> collects the full list of CAR addresses and decides. At least that's
> what I understood people wanted at the last meeting. Do you think it
> is not generic enough since it relies on IP addresses recovered from
> triggers?
>
>  >
>  > Also, could you please say what conclusion you are referring to.
>
> [KEM] I'm referring to the discussion about mobile-centric vs
network-centric
> approaches related to Steve's presentation. I believe there was a
> consensus on mobile-centric, which favours a CAR discovery solution where
the
> MN is involved and takes the decisions.
>
> /Karim
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

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