/Karim
-----Original Message-----
From: Rajeev Koodli
To: mip4 at ietf.org; Karim El-Malki (AL/EAB)
Sent: 18/03/2005 22:02
Subject: Re: Differences between Low Latency Handovers and FMIPv4
Hi Karim,
We implemented the FMIPv6 spec and got the performance
we were looking for. When we considered IPv4, we did not
want to change the L2 to provide L3 subnet information,
what LLH provides in various L2-*T style of triggers,
since that would have limited our implementation to a single L2 alone.
We think making changes to L2 is not desirable.
With that, we set out to implement FMIPv4 by simply changing
the packet formats for FMIPv6, which does not require L2 to
provide the L3 information, and hence easy to implement on any
L2. With our FMIPv4, we got the performance we were
looking for real-time voice handover. See Charlie's presentation
at the DC IETF meeting. So, what we are asking is to standardize
the packet formats for IPv4 using the FMIPv6 design which, contrary
to what you suggest, has crucial differences with respect to LLH
(see the list below) although one could also find some similarities.
Finally, our experience is that those who implement FMIPv6 will find
FMIPv4 rather straightforward to implement since the design is identical
and
provides the required performance.
Some comments in-line.. Also, please see the list of differences
we put together, which suggests major differences that exist
in the design.
Regards,
-Rajeev
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
Actually no. Both FMIPv6 and FMIPv4 do not derive L3 information
(nFA's IP address, MN's IP address, their MAC addresses etc.) from the
L2 triggers. This is a big difference since they do not require L2's
to be changed. Please see 3) below.
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
We did not suggest AP scanning as a difference since _any_ handover
protocol
over WLAN has to deal with it. So, it is not essential for discussion
here.
Using an "interface up" is hugely different from "provide L3 info from
L2"
type of trigger. The former is available without requiring changes to
L2. The
latter is not, and would require changes to L2. To be clear, FMIPv6 does
not
tie the protocol operation to L2 triggers at all, leaving implementers
to use
whatever is available.
tunnelling between FAs which is covered by the pre-reg/post-reg.
combination scenario in Low Latency.
The tunnel set up can be lot simpler than having to run pre-reg/post-reg
in
combination :-) This is a reflection from implementing FMIPv4
while trying to understand LLH however.
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
Without a tunnel subsequent to L2 switching, you don't have the reactive
handover.
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.
What we are looking for is a way to use FMIPv6 design using IPv4.
This is necessary to enable us to use FMIPv6 and FMIPv4 together in
environments
where changes to L2 are not necessary nor are required.
/Karim
-----Original Message-----
From: mip4-bounces at ietf.org <mailto:mip4-bounces at ietf.org>
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.
