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

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

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

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