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

From: "Karim El-Malki \(AL/EAB\)" <[email-masked]>
Date: Fri, 18 Mar 2005 12:47:46 +0100

Hi Charlie
I am a bit surprised by the many differences you see
between FMIPv6 and Low Latency. In actual fact low
latency was written first and most of the stuff was
reused when FMIPv6 was first drafted in Madrid (when
George was editing FMIPv6). The same pre-reg (updating
routing before actual handoff) and post-reg (updating
routing after handoff) are still there. I am not
against changes in the spec but it took a while to
get to a stable document to go out as exp rfc with the
purpose of seeing what interest there is. I would hang
on to making changes until we know what are the real
needs from people (apart from ourselves since we
authored these specs) that have reviewed the exp rfc and
want to take it a step further.
Rgds
/Karim

-----Original Message-----
From: [email-masked]
To: Mobile IPv4 Mailing List
Cc: Rajeev Koodli
Sent: 2005-03-18 00:47
Subject: [Mip4] Differences between Low Latency Handovers and FMIPv4

Hello folks,

FMIPv4 is a straightforward adaptation of the
Fast Handovers for Mobile IPv6 specification. 
The intention is to utilize the same design for
IPv4 networks, but that requires different 
packet formats.  We would like the [mip4] WG
to standardize these packet formats.  Both the
FMIPv6 and FMIPv4 draft mentioned here have been
implemented and offer the performance needed for 
real-time handovers.  Below, we offer a list of
some differences between our FMIPv4 spec and
the previously published Low Latency Handovers
("LLH") specification for Mobile IPv4.

1) We believe that FMIPv4 will avoid the pitfalls
   documented in the paper from Kempf et al.
   which were described quite a while back.

2) Tight coupling to L2 triggers: The entire LLH
   process is very tightly coupled to L2 triggers, to the
   extent that the protocol does not work without such
   triggers.  In contrast, FMIPv4 can make use of such
   triggers, but entire protocol operation does not
   depend on the availability and tight coupling of L2
   triggers.  For instance, the standard Linux function
   ll_handoff() indicates to IP layer that an interface
   has become available.  FMIPv4 code for FBU from the new
   link can be invoked within ll_handoff().

3) Changes to L2 triggers: In addition to the reliance
   on L2 triggers in LLH, the triggers themselves need to
   be modified to include parameters such as new FA IP
   address, MN IP address, their MAC addresses etc.
   within the triggers themselves.  This would require
   changes to whatever L2 triggers are available on _all_
   links where such triggers are supported. 
 
   This is not at all required for FMIPv4 operation.
   Nor does the spec recommend such changes.
 
4) The number of messages exchanged during handover:  
   4.a) Pre-reg LLH: 
   All the messages between the MN and FAs are exchanged 
   once the trigger event occurs.  This includes two proxy
   router messages and a registration request and 
   possibly registration reply on the old link.  In
   FMIPv4, a single message (FBU) is sent once the 
   decision to undergo handover is made.  The MN need not
   stay on the old link once FBU is sent. 
   4.b) Post-reg LLH: 
   No messages are exchanged between the MN and FA. 
   However, since the MN does not have means to change 
   the default router, it will continue to send packets 
   from the new link to the oFA's MAC address, which 
   should be dropped by the IP stack.  And, consideration
   (3) above applies; the triggers on oFA and nFA must
   contain MN's IP addresses, necessitating changes to L2 
   where the protocol might be useful.  Plus, such a mode
   "defers" MIPv4 operation, which is additional code on 
   the MN. 
   
   FMIPv4 works without imposing restrictions on when
   MIPv4 protocol messages need to be carried out.

5) Changes to MIPv4 operation: The MN changes its
   default access router once the registration reply is
   received in pre-reg LLH even if the MN is still on the
   oFA.  So, packet forwarding needs to be carefully
   constructed. (In post-reg LLH on the other hand, the
   MN does not change its default router at all, even
   though it is on the nFA.  This leads to different set
   of additional considerations).

   In FMIPv4, no changes to default router processing are
   needed.  That is, the MN is free to perform and process
   agent/router advertisements just as any normal
   (mobile) node would.

6) Protocol design: The FMIPv4 protocol clearly
   separates movement detection, IP address and nFA
   configuration, and registration request phases.  None
   of these phases is in the critical time path.  The only
   message that is on the criticial path is the FBU
   message.  For movement detection and IP/nFA
   configuration, the FMIPv4 protocol uses the Proxy
   Router messages, which are exchanged ahead of
   handover, as opposed to intitiating the handover in
   LLH.  There are quite a few other differences to list
   here.

In summary, Rajeev and I believe that the differences are
important enough to consider a separate spec of choice
to implementors.  It is especially appealing to those
considering FMIPv6 as well.

Regards,
Charlie P.

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

-- 
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: Henrik Levkowetz <[email-masked]>
Date: Fri, 18 Mar 2005 14:17:29 +0100

Hi Karim,

<hat type="chair">

    I think it would be good if we could look at this proposed workgroup
    item according to its merits, rather than go into its history, where
    there is a bit of controversy which we don't need to repeat here.

    That the low-latency draft is due for publication as experimental does
    not preclude other experimental drafts in the same area if there is
    good motivation for them.  Quite to the contrary, actually - this is a
    way to improve our understanding and move forward as a community.

    When this work has been discussed in the meetings, there has seemed to
    be a good amount of interest in it, which makes it a valid candidate
    for adoption.  So again, let's consider it on its objective merits.

    I'd also like to hear other people's comments on the merits of adopting
    this as a workgroup item, and the level of interest there currently is in
    this.

</hat>

	Henrik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 18 Mar 2005 11:42:07 -0800

Henrik,

I'm in support of doing this work. Since MOBOPTS seems to have a lot on its
plate at the moment and MIP4 doesn't, perhaps MIP4 would be the right place.

As Kent mentioned in his email, 802.11 wireless switches now do inter-subnet
handover optimization for "lightweight AP" 802.11 without any need for host
involvment (essentially using a nonstandardized version of Post-reg), so it
is not clear to me how relevant this work is to 802.11. I think it might
make sense to look into bringing the switch vendors into the discussion,
since wireless LAN switches are a large and growing part of the 802.11
market. From a service provider/enterprise customer standpoint, having a PS
RFC protocol for inter-subnet handover on wireless switches would be ideal,
because the switches are shipping product, are being deployed, but are not
interoperable at this level today. Unfortunately, FMIPv4 won't address this,
but it might be useful for other link technologies and for intertechnology
handover.

With regard to Charlie's email about the technical drawbacks of LLH, what
our research found for three different link technology types (simulated
using 802.3, CDMA2K, and 802.11) and with some analysis is that Pre-reg is
nondeterministic for certain deployment and link technology situations, and
we therefore believe it would be very hard to deploy. Post-reg performs very
well when the required link triggers are available (such as on CDMA2K), but
it cannot be implemented on "standalone AP" 802.11 because the link triggers
aren't there (it can be implemented on "lightweight AP" 802.11 because the
wireless switch provides the link trigger and anchor point for the tunnel).
In our research, we implemented an FMIP-like protocol on 802.11 and the
results were good within statistical range for both network-triggered
handover (using the Post-reg and Reassoc.Request() arrival on the AP and a
single AP per subnet) and host-triggered handover (using the FMIPv4 like
protocol).

Note, however, that if one assumes completely decoupled handover at L2 and
L3, as now is apparently the case with "standalone AP" 802.11 due to the
potential for 802.11i/r reauthentication on every AP move, the host must
perform DNAv4 on every L2 handover, which will involve an ARP to the router.
This means that, effectively, there are at least four IP round trips prior
to the MN receiving traffic from the previous FA. Exactly what the impact of
that is on performance-sensitive traffic, such as VoIP, needs to be
clarified.

With respect to the security issue, there is still not a resolution of how
to secure the host to network interaction in FMIPv6, and it is even more
unclear for FMIPv4, particularly in a roaming situation. There are a couple
approaches being worked on for FMIPv6. One approach, on which I am
co-author, uses SEND and therefore is not applicable directly to FMIPv4,
though it could be modified to be so. Another is under development to use
the EAP key hierarchy to derive a handover key, but as yet there is no
written draft in this area.

So, I think this would be a good item for the WG to take up, but I believe
the primary hurdle is security.

        jak

----- Original Message ----- 
From: "Henrik Levkowetz" <[email-masked]>
To: "Karim El-Malki (AL/EAB)" <[email-masked]>
Cc: "Mobile IPv4 Mailing List" <[email-masked]>; "Charles E.Perkins"
<[email-masked]>; "Rajeev Koodli" <[email-masked]>
Sent: Friday, March 18, 2005 5:17 AM
Subject: Re: [Mip4] Differences between Low Latency Handovers and FMIPv4