Re: [Mip4] Differences between Low Latency Handovers and FMIPv4

["Qiang Zhang/Aber" <[e-mail]>]

Hello, All

>From an implementor point of view, since there is already a llh draft in
experimental standard,  it will be interesting to debate on the technical
pros/cons between, or if they are having a lot similarity, can those be
combined?

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt

and

http://www.ietf.org/internet-drafts/draft-koodli-fmipv4-00.txt

Thanks
Qiang


----- Original Message ----- 
From: "Karim El-Malki (AL/EAB)" <[e-mail]>
To: "Charles E.Perkins " <[e-mail]>; "Mobile IPv4 Mailing
List " <[e-mail]>
Cc: "Rajeev Koodli" <[e-mail]>
Sent: Friday, March 18, 2005 9:11 AM
Subject: RE: [Mip4] Differences between Low Latency Handovers and FMIPv4


Following Henrik's note I'll expand on the technical
issues. As I wrote in my previous email I cannot quite
see the major difference between these drafts. Your new
draft considers link-layer triggers just as FMIPv6 and Low
Latency in order to improve performance. You describe AP
scanning etc. which is not different from the existing
approach. An IP interface becoming available is just a
way of implementing a mobile trigger right? You describe
tunnelling between FAs which is covered by the pre-reg/post-reg.
combination scenario in Low Latency.
One other mechanism was however pointed out a while back: sending
the mobile registration to create the FA-FA tunnel AFTER L2
handoff. I assume that this is the mechanism you want to add
since the advantages you note below are applicable to that
scenario? This wasn't covered in low latency because it was covered
by the PFANE mechanism in route optv4. Have you considered PFANE?
I think the rest is covered already by pre-reg, post-reg and the
combined mechanism.
/Karim

-----Original Message-----
From: [e-mail]
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: [e-mail]
    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: [e-mail]
    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: [e-mail]
    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/