Subject: RE: [Seamoby] Minutes for Meeting at IETF 53

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 18 Apr 2002 16:08:39 +0200

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:[email-masked]]
 > Sent: den 17 april 2002 21:22
 > To: [email-masked]; [email-masked];
 > [email-masked]; [email-masked]
 > 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)" <[email-masked]>
 > >  > To: "'James Kempf'" <[email-masked]>; "Hemant Chaskar"
 > >  > <[email-masked]>; <[email-masked]>
 > >  > 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
 > >[email-masked]
 > >https://www1.ietf.org/mailman/listinfo/seamoby
 > 
 > 
 > _________________________________________________________________
 > Chat with friends online, try MSN Messenger: http://messenger.msn.com
 > 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Apr 2002 09:58:49 -0500

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,

> > >  > > meeting is compatible with MIP Fast Handoffs.
--behcet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Apr 2002 08:55:35 -0700

Hello Behcet,

> drafts do provide a solution to CARD.

That's not what I read, but I'll wait to see what Karim has to say.

> first presented by Saltzer, Reed and Clark in as early as 1984.

I heard Steve's presentation.  I asked a question at the microphone
about whether he believed it precluded network-controlled operation.
He said it did not, but he wanted to restore mobile nodes to be
full citizens (paraphrasing, and it's been a few weeks now).
Subsequent discussion seems to be going to extremes, to the point
of ignoring obviously reasonable network-constrolled designs for
which [seamoby] ought to be responsive.

The paper you cite does not preclude such operation.  We can
view the mobile node as a client which is making use of available
service.  If the network provides the service, it is free to
establish parameters by which it provides the service, and if
it is beneficial to have a mobile node move to another point of
attachment, I see nothing wrong with notifying the node about
that, along with a good candidate for an access router.  I don't
see any reason why the network should be restricted from using
a CAR discovery protoocol to identify such a candidate.

>   Maybe the question is what business Seamoby has here?

My answer would be that [seamoby] ought to be making protocols
by which we can expedite smooth handovers.  That's a good piece
of work, and one for which we can exhibit existence proofs to
show that it is possible.  I think that so far that there has
been trouble to get agreement on "general" goals, but that there
are particular instances where the intended results should be
obvious.  I believe these particular instances include
network-controlled and mobile-controlled scenarios.

===================================================================

Somewhere else, it was stated that only the mobile node can
possibly know all of the CARs.  I would amend this to instead
say that the mobile node can always know about CARs that are
not visible to the network.  But, as it turns out, the network
can always know CARs that are not visible to the mobile node
also.  So, we have to allow the mobile node to make the choice,
but we should not prevent the mobile node from following
network-directives.  Thus, we should develop a model by which
CAR discovery is allowed to provide input to a network-controlled
handover scheme, which is nonetheless subject to possible rejection
by the mobile node.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Apr 2002 08:55:35 -0700

Hello Behcet,

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Apr 2002 09:58:49 -0500

Karim et al.,

Regards,

--behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Apr 2002 11:41:09 -0500

Hello Charlie,
  Absolutely.
What I was pointing out is looking at the history of Seamoby WG, it is 
keeping to jettison out (as James says) its work items. Maybe Seamoby WG 
is an incubator of new WGs.
So CARD and CT are being incubated and sometime in the future new work 
items are going to come out with  well defined scopes. The discussions 
here could serve this goal and as such they are probably very useful.
  This is how I see it.

Regards,

--behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Apr 2002 11:41:09 -0500

Hello Charlie,
  Absolutely.

Regards,

--behcet

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 08:40:33 -0700

CARD and CT are in the charter and will stay there. There are just the
right number of people and a good technical discussion going. These are
precursors for a successful technical solution in IETF, though success
is at this point by no means guaranteed.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 08:40:33 -0700

jak