Re: [Seamoby] Minutes for Meeting at IETF 53
"James Kempf" <kempf@docomolabs-usa.com> Fri, 19 April 2002 05:50 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 BAA02980 for <seamoby-archive@odin.ietf.org>; Fri, 19 Apr 2002 01:50:46 -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 BAA12483; Fri, 19 Apr 2002 01:37:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12451 for <seamoby@ns.ietf.org>; Fri, 19 Apr 2002 01:37:10 -0400 (EDT)
Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02686 for <seamoby@ietf.org>; Fri, 19 Apr 2002 01:37:09 -0400 (EDT)
Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3J5aTI15929; Thu, 18 Apr 2002 22:36:30 -0700 (PDT)
Message-ID: <000d01c1e763$ef9fcb50$4c6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Hemant Chaskar <hchaskar@hotmail.com>, Karim.El-Malki@era.ericsson.se, seamoby@ietf.org
References: <F4f5CftQMTgY7JCjBCJ00007776@hotmail.com>
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
Date: Thu, 18 Apr 2002 11:23:59 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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
I don't think one can assume that IP addresses are available in L2 triggers in the general case. But it must still be possible to map an L2 identifier for an AP/AR to an IP address. I think there is one class of problem involving L2 handover where power is the only criterium in which capabilities are not of interest and handover is controlled at L2. That's how it is done today. There is another class where L3 had some input, especially for the intertechnology case but also potentially for intratechnology where time is not of the essence and potentially also for a future L2 where IP makes most of the decisions. In this case, capabilities are of interest. My 0.02 euro. jak ----- Original Message ----- From: "Hemant Chaskar" <hchaskar@hotmail.com> To: <Karim.El-Malki@era.ericsson.se>; <seamoby@ietf.org> Sent: Wednesday, April 17, 2002 2:56 PM Subject: RE: [Seamoby] Minutes for Meeting at IETF 53 > Hi Karim: > > >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 > > > > > > > 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? > > [HC]I think the issue was raised about single NIC case. So, if you are > saying that in general single NIC case, IP addresses will always be > available in beacons (L2 triggers), then our problem becomes simpler, that > is great. I am still looking for answer to question: Is capability discovery > required in this case and how to do this? When you receive multiple L2 > becons (and hence multiple IP addresses from those beacons from L2 triggers > that you have in mind), which one to choose still remains a question. Or, > will L2 triggers also include capability set of ARs? > > Also, another issue that was raised for both single and multiple NIC case > was about power and bandwidth considerations in receiving capabilities at > MN. Again, if that is not a concern then our problem becomes simpler. > > > > > > > > > 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 > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > > _______________________________________________ > 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
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- RE: [Seamoby] Minutes for Meeting at IETF 53 Dirk.Trossen
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- RE: [Seamoby] Minutes for Meeting at IETF 53 Govind Krishnamurthi
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Gary Kenward
- Re: [Seamoby] Minutes for Meeting at IETF 53 Charles E. Perkins
- RE: [Seamoby] Minutes for Meeting at IETF 53 Gary Kenward
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Govind Krishnamurthi
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- RE: [Seamoby] Minutes for Meeting at IETF 53 Karim El-Malki (ERA)
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Hemant Chaskar
- Re: [Seamoby] Minutes for Meeting at IETF 53 Phil Neumiller
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 James Kempf
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Xiaoming Fu
- Re: [Seamoby] Minutes for Meeting at IETF 53 Xiaoming Fu
- RE: [Seamoby] Minutes for Meeting at IETF 53 Singh Ajoy-ASINGH1
- RE: [Seamoby] Minutes for Meeting at IETF 53 Glenn Morrow
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim
- Re: [Seamoby] Minutes for Meeting at IETF 53 Behcet Sarikaya
- RE: [Seamoby] Minutes for Meeting at IETF 53 Singh Ajoy-ASINGH1
- Re: [Seamoby] Minutes for Meeting at IETF 53 Eunsoo Shim