Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and FMIP v4

From: Kent Leung <[email-masked]>
Date: Tue, 22 Mar 2005 13:47:20 -0800

Adding my 2 cents too.  See "KL>" below.

>If we do propose to take this up in the new charter proposal, do we
>have people who would be willing to spend some time and energy on
>this?
>
>         Henrik

KL> Count me in.

At 03:48 PM 3/22/2005 -0500, Soliman, Hesham wrote:
>Hi Henrik,
>
>Jumping in to add 2 cents below
>
>  > on 2005-03-22 8:14 pm Karim El-Malki (AL/EAB) said the following:
>  > > I agree with what you are saying regarding L2 triggers and
>  > > deployment. However I have a comment on the technical
>  > > argument and the FMIP/LLH discussion. The issue is not
>  > > whether FMIP is superior to LLH or viceversa. My argument
>  > > is that they are basically the same thing and use the same
>  > > set of messages between MN and FA: proxy router solicitation,
>  > > proxy router advertisement, registration request/FBU.
>  > > I can't see how one can be better than the other. I'm also
>  > > not surprised since FMIPv4 is a v6-ification on FMIPv6 while
>  > > FMIPv6 and LLH specs were made similar in the first place.
>  >
>  > No, the similarity is not surprising, and more importantly, we're
>  > not saying one is inherently better than the other.  If that was
>  > the case, there would be no sense in having both head for
>  > experimental.
>  >
>  > Quite to the contrary, we should hope to gain experience with both,
>  > to increase our understanding and work towards something which
>  > may later be standardised.
>
>=> I understand we'd want to do that when we see two (or more)
>proposals doing things differently and/or are suited to different
>environments, and/or are making different assumptions.
>The only things I see different here are:
>1. Packtization of information (and different names)
>2. Allowing IP handover after L2 handover.
>
>I don't see how 1) is worth pursuing, but 2) would be interesting.
>For 2), why don't we revive PFANE from the route opt draft. It seems
>like the most useful part of that old draft.

KL> PFANE is good to have.  Also the BU and BAck messages to
set up tunnel between FAs is good.  As I said before, I'm keen to
keep the solution in line of MIPv4 (FMIPv4 on FAs only).

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 Internet Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 22 Mar 2005 14:52:17 -0800

Hi Kent,

> keep the solution in line of MIPv4 (FMIPv4 on FAs only).
FMIPv4 has the PFANE-type reactive handover; it is also better because
movement detection and agent discovery delays are effectively eliminated
due to performing neighborhood discovery (out of handover critical timing)
on the previous link.

Regards,

-Rajeev

---

From: Kent Leung <[email-masked]>
Date: Tue, 22 Mar 2005 15:23:41 -0800

Hi Rajeev.

My personal take on this is that the early agent discovery is unnecessary
in the overall latency.  The return on investment of the new messaging and
operation is minimal.  I think having the agent advertisement sent by the
new FA after access authorization will provide fast handover.  The time for
MN to learn about FA can be sub-msec range.  With PFANE and BU/BA,
the packets in transit are no lost during registration period to acheive
the smooth handover.  It is my opinion that we can achieve good optimization
with some basic messages and extension, without adding much complexity
to the mobility agents.

Kent

---

From: Charlie P <[email-masked]>
Date: Tue, 22 Mar 2005 15:31:23 -0800

Hello Kent,

Kent Leung wrote:

> MN to learn about FA can be sub-msec range.

This would be a specification written for very particular systems that
had the hardware characteristics you see.  Other people have been
persuaded that the only possible solution was make-before-break.
I am much in favor of a more widely applicable layer-3 solution,
particularly because it enables better performance in systems with
multiple physical media available for Internet connectivity.

>   With PFANE and BU/BA,
> the smooth handover.

I don't think this is correct.  But I will agree that the motivation for
PFANE was to minimize packet loss (and of course eliminate if it
happens to be a good day).

>   It is my opinion that we can achieve good optimization

We should structure the solution so that, in the case you envision,
the minimal implementation is enabled by the specification.

Regards,
Charlie P.