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

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 17 Mar 2005 15:47:56 -0800

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/

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 18 Mar 2005 13:02:07 -0800

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: [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,
>

---

From: "Karim El-Malki \(AL/EAB\)" <[email-masked]>
Date: Tue, 22 Mar 2005 12:13:06 +0100

As you can see from the table some triggers provide very
little info (e.g. link up - L2UP). Others provide L2 OR
L3 parameters (e.g. L2-MT). The result of an AP scan to get
BSSIDs e.g. above a certain signal strength (SNR) is defined
as a trigger in LLH (L2-MT). No L3 parameters involved there.
That doesn't need any special change to L2s, like WLAN in
this example. So my point is that it is incorrect to say
that LLH requires special changes to L2. LLH covers different
types of L2s that provide different trigger info.
/Karim

-----Original Message-----
From: Narayanan Vidya-CVN065
To: Karim El-Malki (AL/EAB); Rajeev Koodli
Cc: [email-masked]
Sent: 22/03/2005 02:56
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and FMIPv4

Karim,
I have a rather stupid question. All the triggers listed in table 1 of
LLH list some L3 parameter or another that needs to be present in the
trigger. This suggests to me that any kind of L2 trigger that is needed
for LLH (Pre-reg or post-reg) requires the presence of the appropriate
parameter listed in the "Parameters" row of the table. 

Am I missing something here? 

Vidya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karim El-Malki \(AL/EAB\)
Sent: Monday, March 21, 2005 5:20 PM
To: Rajeev Koodli 
Cc: [email-masked]
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and
FMIPv4

>>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?
>>  
>>
>As I explained below (and also itemized in the List below), the 
>essential difference is that LLH requires L2 to provide L3 information 
>(nFA, MN IP addresses, their MAC addresses etc.) via various L2-*T type

>of triggers.
>This is a Big difference for us since we do not wish to change L2 to
>implement fast handovers. Both FMIPv6 and FMIPv4 work without
>requiring such changes to L2. 

That's not correct.
Let's take the case where the L3 handoff is initiated before
L2 handoff. Taking WLAN for example, in LLH the MN gets info from L2
(e.g. AP scan) and sends a PrRtSol to get a PrRtAdv containing
information of the subnet it may move to. I can't see any change
required to L2. Where is the difference compared to what you have
described? The only difference is that we definied all "handoff hints"
as L2 triggers, just as a result of the AP scan is defined as a mobile
trigger. The LLH spec doesn't mandate the presence of all trigger types
in all cases. It depends on what the L2 has to offer.

>>The messages are even called the same. Nothing special
>>or L2-dependent about this L2 trigger. For example PRE-REG
>>  
>>
>Well, the essential difference is what requirements LLH imposes on L2 
>triggers. Table 1 in LLH specifies what information is expected from L2

>triggers including the nFA, MN IP addresses from the various L2-*T 
>triggers.

LLH can work with different types of L2 triggers (which is very
different from requiring L2 changes) and supports the case you have
described in FMIPv4. Table 1 specifies the different types of triggers
that LLH can utilise. Note that it includes very simple triggers that
work even on WLAN. It is wrong to say that all triggers in Table 1 are
required on all L2s for LLH to work.

>>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.
>>  
>>
>Perhaps you have missed something.. The FMIP design allows movement 
>detection and router/FA discovery phases to be done prior to L2 
>handover. The "reactive" handover we refer to is the one where the FBU 
>is sent from the
>new link. But, the MN uses the neighborhood information via Proxy
Router
>messages to determine movement detection and router/FA config 
>information of the
>new subnet. So, your description above is not accurate.

Note that I first addressed the L3-movement-before-L2 (where I am saying
that FMIPv4 is no different from LLH) and then I wrote "the other case
you are considering....". Am I incorrect in saying that FMIPv4 also
supports the L3-handoff-after-L2-handoff case? I think I had read that
case in FMIPv4 (i.e. FBU sent from new link). That's why I had asked
about PFANE.

>>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?
>>  
>>
>Please see above. The key difference with respect to Previous FA (what
>used to be Previous AR
>notification in v6) Notification is that you don't incur delays due to 
>movement detection and
>router/FA discovery.

If you are only considering the L3-handoff-before-L2-handoff case then
there are very little differences between FMIPv4 and LLH for the reasons
given above.

>So, apart from the independence from L2 to provide L3 information, the 
>other crucial difference is the decoupling of neighborhood discovery 
>from the actual
>handover signaling. This not only reduces the number of signaling
>messages
>during the handover itself, but also makes the reactive fast handovers 
>possible.

Again I can't see the crucial difference from LLH.
The ND messages are basically the same (even almost called the same):
PrRtSol and PrRtAdv. LLH uses standard MIPv4 naming (Registration
Request and Reply) while FMIPv4 achieves the same result but calls this
an FBU. Tunnelling between FAs is supported in both specs. LLH
furthermore supports anticipated HA updating or "local" HA updating
(regional registrations). It seems to me that to make things "faster"
one would want to update the local/global HA directly if possible since
FA-FA routing can be inefficient in a tree-like network structure
compared to updating a local HA. I am curious to understand why you have
eliminated that option in FMIPv4 compared to LLH. Measurements performed
on FMIPv6+HMIPv6 integration prove that it makes sense to combine
local/global HA updating with the FMIP mechanism. /Karim

---

From: "Karim El-Malki \(AL/EAB\)" <[email-masked]>
Date: Tue, 22 Mar 2005 19:58:07 +0100

Here is one way of doing it: the BSSID would be used
in the PrRtSol from MN to oFA, and the oFA would need
to know which AP/BSSID is served by which FA. The BSSID
would therefore be the nFA "identifier". It seems to me
like this is a generic problem with all solutions that
try to anticipate mobility on WLAN. Or am I missing a
case where we can do without these scans and still
achieve L3 mobility before or in parallel with L2
mobility?
/Karim

-----Original Message-----
From: Narayanan Vidya-CVN065
To: Karim El-Malki (AL/EAB); Rajeev Koodli
Cc: [email-masked]
Sent: 22/03/2005 17:53
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and FMIPv4

Maybe I am just missing something important here. Sorry, but I still
don't understand. 

Both in the L2LU and L2MT, it seems like LLH is expecting at least the
nFA L2 address (if not the IP address) or some nFA identifier - is that
true? 

Typically, this information is not available as a result of the AP scan,
right? The FA is most likely more than one L2 hop away from the MN. An
AP, by default, will not include any information about the nFA in its
beacon. 

What am I missing here? 

Thanks,
Vidya

-----Original Message-----
From: Karim El-Malki \(AL/EAB\) [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2005 5:13 AM
To: Narayanan Vidya-CVN065; Rajeev Koodli 
Cc: [email-masked]
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and
FMIPv4

As you can see from the table some triggers provide very
little info (e.g. link up - L2UP). Others provide L2 OR
L3 parameters (e.g. L2-MT). The result of an AP scan to get BSSIDs e.g.
above a certain signal strength (SNR) is defined as a trigger in LLH
(L2-MT). No L3 parameters involved there. That doesn't need any special
change to L2s, like WLAN in this example. So my point is that it is
incorrect to say that LLH requires special changes to L2. LLH covers
different types of L2s that provide different trigger info. /Karim

-----Original Message-----
From: Narayanan Vidya-CVN065
To: Karim El-Malki (AL/EAB); Rajeev Koodli
Cc: [email-masked]
Sent: 22/03/2005 02:56
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and
FMIPv4

Karim,

Vidya

-----Original Message-----

>implement fast handovers. Both FMIPv6 and FMIPv4 work without requiring

>such changes to L2.

That's not correct.

Router

>used to be Previous AR notification in v6) Notification is that you 
>don't incur delays due to movement detection and
>router/FA discovery.