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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Tue, 22 Mar 2005 10:53:39 -0600

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

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

-- 
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: Narayanan Vidya-CVN065 <[email-masked]>
Date: Tue, 22 Mar 2005 13:23:13 -0600

It seems to me that the one thing that is missing from LLH is a method of doing mobile initiated post-reg. This is provided by FMIP. 

Vidya

-----Original Message-----
From: Karim El-Malki \(AL/EAB\) [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2005 1:14 PM
To: James Kempf ; Narayanan Vidya-CVN065; Rajeev Koodli 
Cc: [email-masked]
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and FMIP v4

I agree with what you are saying regarding L2 triggers and deployment. However I have a comment on the technical argument and the FMIP/LLH discussion. The issue is not whether FMIP is superior to LLH or viceversa. My argument is that they are basically the same thing and use the same set of messages between MN and FA: proxy router solicitation, proxy router advertisement, registration request/FBU. I can't see how one can be better than the other. I'm also not surprised since FMIPv4 is a v6-ification on FMIPv6 while FMIPv6 and LLH specs were made similar in the first place. /Karim

-----Original Message-----
From: James Kempf
To: Narayanan Vidya-CVN065; Karim El-Malki (AL/EAB); Rajeev Koodli
Cc: [email-masked]
Sent: 22/03/2005 18:40
Subject: Re: [Mip4] RE: Differences between Low Latency Handovers and FMIP v4

I think this whole discussion about L2 triggers and LLH is a red herring. People are taking the wording "L2 trigger" too literally. It doesn't actually have to be a protocol message in the L2 protocol, it just must be indication that handover has occured or will occur. The handover indication doesn't have to include all the L3 information in Table 1 in one L2 message. It can be deduced. For example, using something like CARD or even the RtPrxy messages, the MN can build up a table of AP L2 address to FA address map, and use that. I believe that is what Karim means when he says that FMIP also needs this kind of information. Unless an FMIP MN has some way to know that a handover has occured or will occur, there's no FBU. And unless it has some information about what new subnet the MN is in or will be, it can't put that information into the FBU to tell the old FA where to send packets.

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; 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. 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 their own solution in the A!
 10/A11 interface, which looks strikingly like the solution adopted by the WLAN switch vendors.

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

            jak

----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "'Karim El-Malki \(AL/EAB\)'" <[email-masked]>; "Rajeev Koodli" <[email-masked]>
Cc: <[email-masked]>
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.
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
Karim El-Malki \(AL/EAB\)
> >>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?
> >>
> >>
> >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.
> 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 
Router
> >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.
> >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.
> >from the actual handover signaling. This not only reduces the number 
> >of signaling messages
> 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 21:15:22 +0100

As I wrote in a previous emaul to Rajeev, the reason why it
was left out of LLH is that there was an existing mechanism
for this in the route optv4 spec: PFANE (previous FA notification
extension).
/Karim

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

It seems to me that the one thing that is missing from LLH is a method
of doing mobile initiated post-reg. This is provided by FMIP. 

Vidya

-----Original Message-----
From: Karim El-Malki \(AL/EAB\) [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2005 1:14 PM
To: James Kempf ; Narayanan Vidya-CVN065; Rajeev Koodli 
Cc: [email-masked]
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and
FMIP v4

I agree with what you are saying regarding L2 triggers and deployment.
However I have a comment on the technical argument and the FMIP/LLH
discussion. The issue is not whether FMIP is superior to LLH or
viceversa. My argument is that they are basically the same thing and use
the same set of messages between MN and FA: proxy router solicitation,
proxy router advertisement, registration request/FBU. I can't see how
one can be better than the other. I'm also not surprised since FMIPv4 is
a v6-ification on FMIPv6 while FMIPv6 and LLH specs were made similar in
the first place. /Karim

-----Original Message-----
From: James Kempf
To: Narayanan Vidya-CVN065; Karim El-Malki (AL/EAB); Rajeev Koodli
Cc: [email-masked]
Sent: 22/03/2005 18:40
Subject: Re: [Mip4] RE: Differences between Low Latency Handovers and
FMIP v4

I think this whole discussion about L2 triggers and LLH is a red
herring. People are taking the wording "L2 trigger" too literally. It
doesn't actually have to be a protocol message in the L2 protocol, it
just must be indication that handover has occured or will occur. The
handover indication doesn't have to include all the L3 information in
Table 1 in one L2 message. It can be deduced. For example, using
something like CARD or even the RtPrxy messages, the MN can build up a
table of AP L2 address to FA address map, and use that. I believe that
is what Karim means when he says that FMIP also needs this kind of
information. Unless an FMIP MN has some way to know that a handover has
occured or will occur, there's no FBU. And unless it has some
information about what new subnet the MN is in or will be, it can't put
that information into the FBU to tell the old FA where to send packets.

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; 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. 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 their own solution
in the A!
 10/A11 interface, which looks strikingly like the solution adopted by
the WLAN switch vendors.

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

            jak

----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "'Karim El-Malki \(AL/EAB\)'" <[email-masked]>; "Rajeev
Koodli" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 21, 2005 5:56 PM
Subject: RE: [Mip4] RE: Differences between Low Latency Handovers and
FMIP v4

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

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

Router
> 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.
to
> 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.
> 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: "Soliman, Hesham" <[email-masked]>
Date: Tue, 22 Mar 2005 15:48:28 -0500

Hi Henrik, 

Jumping in to add 2 cents below

 > on 2005-03-22 8:14 pm Karim El-Malki (AL/EAB) said the following:
 > > I agree with what you are saying regarding L2 triggers and
 > > deployment. However I have a comment on the technical
 > > argument and the FMIP/LLH discussion. The issue is not
 > > whether FMIP is superior to LLH or viceversa. My argument
 > > is that they are basically the same thing and use the same
 > > set of messages between MN and FA: proxy router solicitation,
 > > proxy router advertisement, registration request/FBU.
 > > I can't see how one can be better than the other. I'm also
 > > not surprised since FMIPv4 is a v6-ification on FMIPv6 while
 > > FMIPv6 and LLH specs were made similar in the first place.
 > 
 > No, the similarity is not surprising, and more importantly, we're
 > not saying one is inherently better than the other.  If that was
 > the case, there would be no sense in having both head for
 > experimental.
 > 
 > Quite to the contrary, we should hope to gain experience with both,
 > to increase our understanding and work towards something which
 > may later be standardised.

=> I understand we'd want to do that when we see two (or more)
proposals doing things differently and/or are suited to different
environments, and/or are making different assumptions.
The only things I see different here are:
1. Packtization of information (and different names)
2. Allowing IP handover after L2 handover.

I don't see how 1) is worth pursuing, but 2) would be interesting.
For 2), why don't we revive PFANE from the route opt draft. It seems
like the most useful part of that old draft.

Hesham

 > 	Henrik
 >      Charter page: 
 > http://www.ietf.org/html.charters/mip4-charter.html

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================