Subject: RE: [mobile-ip] Fast Handover draft: proposed revisions

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 26 Jul 2002 13:47:07 -0500

Hello Rajeev,
Please find my inline reply.
regards,
ajoy

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, July 25, 2002 8:38 PM
To: Alper E. YEGIN
Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; 'James Kempf';
[email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

Ajoy, Alper,

I have few questions for you.

1. How does the MN get the L2 address and IP address of the
     new AR ? I see the following possibilities
a) PrRtAdv provides this
b) upon establishing a new link, the MN does RS and gets an RA

AJOY-> In case of network controlled handoff, why MN is required 
to get the IP address of the new AR ? Could you clarify 
this? 

How can you avoid PrRtAdv ? Can we assume that L2 trigger
provides the necessary information ? Which L2 trigger today
provides such information? 

AJOY-> As I said, in case of network controlled handoff, both ARs 
can communicate to create visitor list entry for the Mobile
node at the nAR. Why we need PrRtAdv in critical path in this 
case? As far as I know, BETH can be implemented in any wireless 
technology capable of supporting network controlled handover. 
Even this can be extended for Mobile controlled handover.
Please let me know in case you know of something where this can
not be implemented. 

Isn't this at best a recommendation
to future L2 designers ? 

Ajoy-> To make something useful, we need to consider the 
need of present network. I will be skeptical to 
standardize something in the hope of being used in 
remote (?) future. 

In any case, can we specify that
the protocol operates based on this assumption on _all_ links ?

2. When does the previous AR actually start forwarding packets
    on the tunnel ? Should it do so even when it has not received a
    FBU ? 

AJOY-> In BETH, as far as I remember, oAR will start forwarding packets
after 
receiving link down event. 

I think use of L2 triggers to more precisely time
    forwarding is useful when the router has received FBU. Doing
    forwarding in the absence of FBU is redirecting traffic without
    proper authorization, and as we have seen inMIPv6 security
    exercise, involves security considerations. Can we say here that
    L2 trigger will have the necessary authorization to redirect
    traffic ? Even so, how can a base spec generalize it to all possible
    link layers ?

AJOY-> Base protocol will just have to state that link layer must be 
secure. Since, we are not defining link layer triggers in 
base draft, we do not need to be concerned about how 
L2 trigger will be secured. 

These are the crucial questions that determine the trade-off. I
would like to know what you and others think.

AJOY-> We are talking about fast handoff. So, we need a solution
that can provide reliable fast handoff. 

Regards,

-Rajeev

"Alper E. YEGIN" wrote:

> Hello Ajoy,
>
> > Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and
> > then applying to "anticipated FMIPv6" without experimenting is not a
> > good idea. Protocols are sufficiently different to make considerable
> > performance differences.
> >
> > Ajoy-> I think claiming something works without proper data and
> > argument is also not a good idea. BTW, do you agree that due to higher
> > RTT of cellular link, FMIPv6 will require higher anticipation
> > time ?
>
> Yes of course.
>
> > As you increase anticipation time, the likelihood
> > of handover failure will increase.
>
> This statement by itself also make sense...
>
> But, the question is how much difference does it make?
> Experimentation can help answer this question, and this is
> why I was asking if your statements were based on
> FMIPv6 experiments...
>
> Also, how much heads up can the mobile terminal or the network
> get before the link is broken without any anticipation?
> I presume link down doesn't happen instantly, at least L2 has to
> exchange some messages. Is there a window
> in which L3 can exchange packets?
>
> > I do not think this has
> > anything to do with FMIPv6 or FMIPv4. You will observe
> > similar behavior in either case.
>
> But there is more... A fundamental difference between
> FMIPv6 and pre-reg FMIPv4 is that with the latter the
> registration request has to go all the way to home agent.
> This not only effects the latency, but also prevents taking
> advantage of L2 triggers on the oFA/oAR to precisely
> determine when the routing should change.. And this
> should make a difference in the observed performance..
>
> alper

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Jul 2002 14:34:43 -0700

> to get the IP address of the new AR ? Could you clarify

The MN needs an IP address of the gateway for a default
destination. If you have a unix system, "netstat -rn" should
produce the route table entries that includes the Gateway
address for default destination.
The L2 address is needed for encapsulating the IP packet
in a L2 frame.

> node at the nAR. Why we need PrRtAdv in critical path in this

Visitor list entry ? Do you mean host route entry ?

> Please let me know in case you know of something where this can

The routers communicate to establish a host route entry for the MN
on the new AR. But, that does not help the MN in _sending_ packets
unless it has the new AR's addresses. The purpose of PrRtAdv is
to provide this information.
As I asked in my questions, who provides this information ? Are we
assuming that L2 trigger will be able to provide this ? If yes, then I
am asking can we specify that in the base draft which ought to work
on all link types ? I also don't know which L2 type provides such
information today..

> standardize something in the hope of being used in

Good. I didn't say we should standardize this. I am saying to
expect something from link layers should be part of a wish list.

> after receiving link down event.

But, my question is should we allow that even in the absence of
receiving an FBU ? See the questions below (in my previous e-mail)..

> L2 trigger will be secured.

Well, how can we enforce that a particular L2 be secure in the base
draft ? In an IP protocol, we can certainly state that FBU must be
protected before traffic can be redirected.

> that can provide reliable fast handoff.

I agree we are talking about fast handover :-)
In what way is the protocol not robust ? It should work in
the presence of lost messages and should provide the desired
performance. I would be happy to address those considerations.

Also, could you comment specifically on how we can
avoid PrRtAdv and FBU ? That would be more useful.

Thanks,

-Rajeev