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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 29 Jul 2002 09:41:32 -0500

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

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

Singh Ajoy-ASINGH1 wrote:

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

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.

AJOY-> BTW, when there is a serial pipe (link) between MN and AR, the MN
should 
be able to route packet even without getting the actual IP address of the
new 
AR. Suppose at some of point of time, MN is connected to oAR and 
using the IP address of oAR as the default gateway. Also, the routing table
entry 
indicates that to reach the default gateway (oAR), the serial interface s0
should 
be used. In this case, an MN will be sending all the outgoing packets to a
CN over 
the serial link s0. Now, even after MN moves from oAR to nAR, it will have
the 
same routing table entries. The only difference will be that the serial link
s0 
will terminate to nAR instead of oAR. The relocation of termination point of

the serial interface (s0) from oAR to nAR should be handled by the link
layer 
handoff. So, in this case also, mobile node should be able to send any
outgoing 
packets to a CN through the serial interface s0 as it was doing while
connected 
with oAR. Moreover, the nAR should be able to route any MN originated
outgoing 
packet to CN using standard IP routing. So, in case of serial link, we can 
probably afford to wait for default route update until standard Mobile/IP
registration 
is performed. I do agree this approach may not work for the Ethernet type of
MAC. 
BTW, as far as I know, most of today's bandwidth constraint links provide
serial 
connection between MN and AR. So, I guess we should make PrRtAdv as an
optional 
message rather than a mandatory one. I also see a possibility of CARD to
obtain the 
IP address of nAR. Please let me know in case I missed something.

The L2 address is needed for encapsulating the IP packet
in a L2 frame.

AJOY-> In case of serial link, L2 address is not required to be present 
in each and every L2 frame. Such information is only required during link
setup.

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

Visitor list entry? Do you mean host route entry?

Ajoy-> Yes, I used MIPv4 term.

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

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.

AJOY-> Probably this is not an issue when we have serial 
link between MN and AR. In this case, even if we 
do not update the default route of MN with nAR, all 
the packets sent over serial link will reach to nAR.
Mostly low bandwidth wireless links are serial
link. I still think, we should keep PrRtAdv as 
an optional message that should be sent by the nAR to MN
in case of Ethernet type of MAC. What you think?

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

AJOY-> I was not assuming that L2 trigger will provide the
IP address of nAR. My assumption was that in serial
link, we can get away by without updating the default 
route at MN in critical path of handover. 

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

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.

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

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)..

AJOY-> Yes. But we should state that this should be implemented in 
case of secure link layer.

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

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.

AJOY-> I am not sure if IP can enforce the security of link layer. 
I think we should state the implication of using in-secure link layer 
triggers in security section of the draft.

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

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.

AJOY-> Hopefully, I have addressed these points in
this email. 

Thanks,

-Rajeev

>
> 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: Tue, 30 Jul 2002 10:10:50 -0700

Hello Ajoy,

thanks for your input. Some comments..

- I think PrRtAdv is needed in order to work on
    all link types. Note that the protocol does work
    when the MN moves without receiving it, i.e.,
    the tunnel is established subsequent to new link
    establishment. I think the scenario you describe
    could be covered by this with the addition that
    HI/HAck exchange could occur in response to
    the network detecting imminent handover.
    Also note that there is L2 signaling exchange
    for handover and it could very well be possible
    for PrRtAdv message to get through during this
    time period.

- I am still not convinced that we can avoid FBU
    by assuming a secure link layer. The issue is more
    of authorizing the network to redirect traffic. A
    secure link layer does not necessarily provide such
    a feature.  Besides, shouldn't we be focussing on
    IP and Mobile-IP related protocol exchange, rather
    than speculating the availability and features of
    secure link layers ?

Regards,

-Rajeev