Re: [Seamoby] Minutes for Meeting at IETF 53

"James Kempf" <kempf@docomolabs-usa.com> Tue, 16 April 2002 17:36 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 NAA23955 for <seamoby-archive@odin.ietf.org>; Tue, 16 Apr 2002 13:36:17 -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 NAA01060; Tue, 16 Apr 2002 13:28:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01029 for <seamoby@ns.ietf.org>; Tue, 16 Apr 2002 13:28:55 -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 NAA22893 for <seamoby@ietf.org>; Tue, 16 Apr 2002 13:28:52 -0400 (EDT)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3GHSMI27814; Tue, 16 Apr 2002 10:28:22 -0700 (PDT)
Message-ID: <011001c1e56b$e203b640$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Hemant Chaskar <hchaskar@hotmail.com>, seamoby@ietf.org
References: <F255Na0yYZdqQGMTM63000060bb@hotmail.com>
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
Date: Tue, 16 Apr 2002 10:26:45 -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

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


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