RE: [Seamoby] Minutes for Meeting at IETF 53

"Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se> Wed, 17 April 2002 10:21 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 GAA13790 for <seamoby-archive@odin.ietf.org>; Wed, 17 Apr 2002 06:21:53 -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 GAA29709; Wed, 17 Apr 2002 06:16:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29668 for <seamoby@optimus.ietf.org>; Wed, 17 Apr 2002 06:16:01 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13754 for <seamoby@ietf.org>; Wed, 17 Apr 2002 06:15:58 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3HAFx3G017050 for <seamoby@ietf.org>; Wed, 17 Apr 2002 12:15:59 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 17 12:13:21 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTNKX2>; Wed, 17 Apr 2002 12:17:51 +0200
Message-ID: <795A014AF92DD21182AF0008C7A404320DFBF085@esealnt117>
From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
To: 'Hemant Chaskar' <hchaskar@hotmail.com>, kempf@docomolabs-usa.com, seamoby@ietf.org
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
Date: Wed, 17 Apr 2002 12:13:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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

 > >  > 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