Re: [Seamoby] Minutes for Meeting at IETF 53

Behcet Sarikaya <behcet.sarikaya@alcatel.com> Thu, 18 April 2002 15:13 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 LAA09788 for <seamoby-archive@odin.ietf.org>; Thu, 18 Apr 2002 11:13:23 -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 KAA02557; Thu, 18 Apr 2002 10:58:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02530 for <seamoby@optimus.ietf.org>; Thu, 18 Apr 2002 10:58:56 -0400 (EDT)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09288 for <seamoby@ietf.org>; Thu, 18 Apr 2002 10:58:52 -0400 (EDT)
Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IEwPx22591 for <seamoby@ietf.org>; Thu, 18 Apr 2002 09:58:25 -0500 (CDT)
Message-ID: <3CBEDF29.2050707@alcatel.com>
Date: Thu, 18 Apr 2002 09:58:49 -0500
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: seamoby@ietf.org
Subject: Re: [Seamoby] Minutes for Meeting at IETF 53
References: <795A014AF92DD21182AF0008C7A404320DFBF087@esealnt117>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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

Karim et al.,
  It seems to me that what Karim is arguing is MIPv4/v6 fast handover 
drafts do provide a solution to CARD.
  And he is saying that these are MN centric solutions and bode well 
with Steve's arguments and the end-to-end arguments in system design 
first presented by Saltzer, Reed and Clark in as early as 1984.
  Maybe the question is what business Seamoby has here?

Regards,

Karim El-Malki (ERA) wrote:

>Since a couple of emails disagreed with me about this point,
>I'm sending one email reply to clarify. As in the minutes,
>the concept was that the only entity which can find out
>all the possible CARs is the MN (that's what I mean by mobile-centric).
>The network could give hints, but it is the MN that has the complete
>view and decides. That's what I understood from the meeting and there
>seemed to be consensus on this. Hope we agree so far. The network
>could assist in CAR discovery (e.g. it's L2 can help in anticipating
>the movement). That's also somewhere in the minutes. In fact what I
>said below was that I couldn't understand why there was focus on a
>network-centric solution (i.e. where the MN is NOT involved). I wasn't
>ruling out network involvement, but I couldn't understand why there
>was work on ARs only doing CAR discovery. Hope my point is more clear
>now. Maybe I misinterpreted some emails and people are in agreement
>with this. I think Dirk's email at least was in line with what I
>have above (i.e. we need to focus on the MN's role and allow the
>network to assist where needed).
>Rgds
>/Karim
>
> > -----Original Message-----
> > From: Govind Krishnamurthi [mailto:govs23@hotmail.com]
> > Sent: den 17 april 2002 21:22
> > To: Karim.El-Malki@era.ericsson.se; kempf@docomolabs-usa.com;
> > hchaskar@hotmail.com; seamoby@ietf.org
> > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
> > 
> > 
> > 
> > 
> > 
> > Hello Karim,
> > First, I don't think that Steve Deering said anything about excluding
> > the network from CAR discovery. All he said (AFAIK) was that the MN's
> > preferences must be satisfied in the decision of selecting the TAR.
> > Now that doesn't imply MN based CAR discovery: that the MN 
> > should receive 
> > all the capabilities and GAAR IDs and then make the decision.
> > 
> > 
> > Regards,
> > Govind.
> > 
> > >
> > >The reason I sent my previous email was that I got the feeling
> > >from this thread that there is focus on providing a solution for
> > >the network-centric case (i.e. the network handles CAR discovery
> > >and the MN isn't involved). I wanted to point out that this
> > >solution would not be applicable to the mobile-centric case and
> > >clarify that this case is supported by MIP (v4 and v6) fast
> > >handoffs.
> > >
> > >From the IETF meeting there was a majority who wanted to go for
> > >the mobile-centric case (i.e. where the mobile is involved and
> > >decides). Following Steve's presentation I think that became
> > >quite clear. So, why are there discussions about doing a solution
> > >which is meant for the network-centric case only? This solution
> > >wouldn't apply to the mobile-centric case. That's what I was meant
> > >to ask in my last email.
> > >
> > >/Karim
> > >
> > >  > Karim,
> > >  >
> > >  > But it is applicable to network initiated handoff. And 
> > there are two
> > >  > algorithms, one in which the access router sends a PrxyRtAdv
> > >  > to the MN
> > >  > and one in which the MN is switched (for FMIPv4).
> > >  >
> > >  >             jak
> > >  >
> > >  > ----- Original Message -----
> > >  > From: "Karim El-Malki (ERA)" <Karim.El-Malki@era.ericsson.se>
> > >  > To: "'James Kempf'" <kempf@docomolabs-usa.com>; "Hemant Chaskar"
> > >  > <hchaskar@hotmail.com>; <seamoby@ietf.org>
> > >  > Sent: Tuesday, April 16, 2002 11:55 AM
> > >  > Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
> > >  >
> > >  >
> > >  > > > > >[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.
> > >  > >
> > >  > > 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
> > >  > >
> > >  >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> > 
> > 
> > _________________________________________________________________
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> > 
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>
--behcet


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