Subject: RE: [mobile-ip] Fast handovers - proposal for moving forward

From: [email-masked]
Date: Tue, 23 Jul 2002 13:27:36 -0500

>Hi, 
>
>I didn't have enough time in the meeting to explain
>clearly what I meant when we discussed Phil's proposal. 
>Since I suddenly have excellent WLAN coverage in the 
>room, I'll try to do it now!
>
>First of all, I'm not sure that the WG is actually
>split. In fact, after reading all emails, I think we 
>agree on many issues. Let me try to list them and 
>see if I'm right. I think we agree on the following:
>
>- L2 triggers will make Fast handovers perform better. 

I do not believe there is any disagreement about this.

>- L2 triggers are needed.

But the Mobile IP WG fast HO specification should only be cognizant of
the existence of L2 triggers and not try to figure out what L2
triggers are available on various links. So the degree to which any
details about L2 triggers are documented should be quite
abstract. 

>- We need an access independent solution.

I believe that is what the FMIPv6 spec's aim is.

>
>But we disagree on the level of detail at which L2 triggers 
>should be included in the draft, and the value of tunnel-based
>handover (I think). 

Comment on detail of L2 tiggers above.

>So, to make my comment clear, I wasn't not against
>Phil's proposal to have a separate draft for Fast
>Handovers in 802.11. I was only against the implicit
>content of such document. 

The signaling details and message details for such a document would be
derived from the FMIPv6 specification. I am of the opinion that a
specification for FMIPv6 over 802.11 will simply specify a much more
narrow scenario for doing Fast HOs. The current FMIPv6 specification
provides multiple scenarios (MN sending a Proxy Solict or AR sending
the Proxy Advt, MN moving before sending or receiving any solicit or
advt etc.). Some of these may not be valid within the scope of
802.11. However I am not sure yet if the details of 802.11 link layer
need to be covered here (eg. the MN completes the Associate with an
AP. So will there be details about what the WLAN driver will provide
to the FastHO module at the IP layer?)

>
>I think that the current draft (v5) provides an 
>access independent framework for Fast handovers, 
>assuming some hints from lower layers, like 
>L2 (in the MN or the AR depending on the type
>of link) knows that handover is about to happen
>and will inform the IP layer. I believe that's 
>about as far as the doc needs to say. However, 
>to get this stuff deployed and make it useful, 
>more detail is needed. But I don't think that 
>this draft can possibly include all the details 
>relevant to all link layers. This is where Fast
>Handovers over foo documents would be needed. 
>
>These documents can show exactly what triggers 
>are needed, and how to integrate FMIPv6 signalling
>at the right time. Frankly, even if the current
>draft shows some names for L2 triggers, I don't
>think it would be useful. We need more detail
>for each link layer.
>

I agree with your views here. However I believe that you could
implement fast HOs based on implementation dependent triggers to test
interoperability. If I have access to my WLAN driver code, I could
build triggers that would initiate the Proxy Rtr Solicit from the
MN. As long as the routers are capable of processing the request, Fast
HO can be accomplished without having to do an explicit
specification. 

>So, to this extent, I think that an FMIPv6 over
>802.11 doc is needed. But I definitely don't think we should 
>do a different IP layer protocol standardised for each link
>layer. I believe it is unnecessary, let alone
>defeats the purpose of doing any fast handover scheme
>on the IP layer. 

I do not believe anyone is proposing doing that.

>
>Does this make sense to anyone ? 
>I wish we had a show of hands during the meeting but
>there was no time to discuss it, because I don't think 
>the WG is very divided on this actually. 

I tend to agree. There are a few issues on which people have some
strong opinions, but the general consensus on the approach to fast HOs
is far greater. 

>Hesham
-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Jul 2002 15:11:43 -0700

> I do not believe anyone is proposing doing that.

I agree that fmipv6 over 802.11 is a good exercise. What
is not clear to me is why this necessarily needs to be done
as a separate PS. The base spec can have a section describing
this. In fact, tunnel establishment subsequent to link establishment
is a proposed feature in v05: I agree better formatting is needed.

> strong opinions, but the general consensus on the approach to fast HOs

I agree.

-Rajeev

---

From: "Raymond Jayaraj" <[email-masked]>
Date: Thu, 25 Jul 2002 11:36:19 +0800

Hi guys,

Sorry to barge in like this, being a nobody in this field. But I'd
like to voice my opinion on this issue, as I have some GSM protocol 
stack development background, and my current field of work involves 
developing an optimised tunnel-based, contextful handover protocol for
research purposes.

Setting aside political constraints, I think the FMIPv6 draft can 
benefit from specifying a framework for a very generic Layer-3 
Wireless Link Management (WLM) protocol between the MN and AR that can
operate over most cellular access technologies.

I had submitted a draft that introduces the WLM framework (specified
as Handover Management there) for seamless, anticipative and 
contextful handover using the tunnel-based FMIPv6 approach. Although 
this draft is geared towards 802.11 type network, I think it can be 
applied to most cases. Details on the draft as follows -

Abstract:
This document describes how the use of MN originated cell-search list 
indications, which carry signal level and signal quality measurements 
of access points in the immediate vicinity of the mobile node, can 
assist in a handover scheme that factors in seamlessness, target 
router selection, context transfer and resource usage information.

URL:
http://search.ietf.org/internet-drafts/draft-rjaya-seamoby-cslist-ind-00.txt

I would be glad to hear any comments on this proposal from you guys.

Cheers,
Raymond Jayaraj