RE: [Seamoby] Minutes for Meeting at IETF 53

["Karim El-Malki (ERA)" <[e-mail]>]

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)" <[e-mail]>
 > To: "'James Kempf'" <[e-mail]>; "Hemant Chaskar"
 > <[e-mail]>; <[e-mail]>
 > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby