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

["Karim El-Malki \(AL/EAB\)" <karim.el-malki at ericsson.com>]

Hi Rajeev
I understand your point that you took FMIPv6 and applied
it to v4 to make FMIPv4. But that doesn't make it
substantially different from Low Latency. Your spec does
use link-layer triggers to be able to send the RtSolPr.
An interface coming up in the MN is used just the same in
Low Latency and is defined as a mobile trigger in Low
Latency (L2-LU). PRE-REG involves the MN getting such a
mobile trigger and sending a PrRtSol and receiving a
PrRtAdv. What's the difference compared to your spec?
The messages are even called the same. Nothing special
or L2-dependent about this L2 trigger. For example PRE-REG
can be applied to WLAN using AP scans. I don't think that
the difference in packet formats makes it a substantially
different spec from low latency.  Also, the other case you
are considering involves an L3 handoff that happens after
the MN attaches to the new link. This cannot really be
considered a "fast" handoff, which would instead be where
the handoff happens before or in parallel with the L2 handoff.
This L3-handoff-after-L2-handoff was already covered in the
route optv4 spec using PFANE. You may have missed the question
so I'll repeat it: did you consider the PFANE? Why aren't
you just reusing the PFANE (Previous FA Notification
Extension) work for that scenario?
/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.



  


--
Mip4 mailing list: Mip4 at ietf.org
    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/