Re: [Mip4] RE: Differences between Low Latency Handovers and FMIP v4

[Rajeev Koodli <rajeev at iprg.nokia.com>]

Hi Jim,



James Kempf wrote:

I still believe there's value for FMIPv4, believe it is superior to LLH if
host based all-L3 handover optimization is required, and support work on it;
  

okay.

however, this whole argument of FMIP v.s. LLH strikes me as being something
like the medieval argument about how many angles can dance on the head of a
pin. Wireless LAN deployments are increasingly going in the direction of
  

:-)

wireless LAN switches (60% of new purchases and practically all upgrades),
and these switches already have nonstandardized solutions for "IP Mobility",
which, in effect, means tunneling L2 frames in L3 between subnets.
  

Looking forward, subnet mobility is crucial for scale and for deployment easy.

Unfortunately, vendors would like to keep it that way, since having a
standardized solution means that enterprise customers and service providers
would be free to mix and match solutions and less likely to go single
supplier. So FMIP is likely to be of limited interest for WLAN deployments
going forward. Perhaps 3GPP2 is interested in it? Though they already have
  

On the contrary, wouldn't you expect the enterprises to start demanding interoperability
between boxes? If vendors have "holds" on enterprises for their boxes alone, that does not
sound like a way going forward.

Anyway, if this WG was serious about its charter to focus on deployment, it
would start up an activity to standardize WLAN switching "IP mobility".

  

Doesn't this mean tunneling?  A switch tunneling an L2 frame in L3 sounds sub-optimal
since it needs to "go back" through the router to reach the IP network, and eventually the
destination router and the switch. Anyway, why is there a need for standardization here?

-Rajeev

            jak


----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <vidya at motorola.com>
To: "'Karim El-Malki \(AL/EAB\)'" <karim.el-malki at ericsson.com>; "Rajeev
Koodli" <rajeev at iprg.nokia.com>
Cc: <mip4 at ietf.org>
Sent: Monday, March 21, 2005 5:56 PM
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and FMIP
v4


  

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: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] On Behalf Of
    

Karim El-Malki \(AL/EAB\)
  

Sent: Monday, March 21, 2005 5:20 PM
To: Rajeev Koodli
Cc: mip4 at ietf.org
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
  

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

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

    

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