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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 17 Jul 2002 18:51:42 +0200

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. 
- L2 triggers are needed.
- We need an access independent solution.

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

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. 

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.

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. 

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. 

Hesham

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 17 Jul 2002 10:11:17 -0700

Experiences with 802.11 IAPP (any version) would be relevant for
fast-handover issue. If someone can post a brief on the following issues
it would be educative for the whole list.

1. When is the IAPP standard expected to be completed ?
2. What is being included in the standard ?
3. Is IAPP adequate for IP handovers, any limitations ?

Thanks

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hesham Soliman
(EAB)
Sent: Wednesday, July 17, 2002 9:52 AM
To: [email-masked]
Subject: [mobile-ip] Fast handovers - proposal for moving forward

Hi, 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Jul 2002 19:32:36 -0700

> should be included in the draft, and the value of tunnel-based

There is an additional point on which we disagree. The need for a handover
solution in which there is no over the air signaling, either pre- or
posthandover.

> and will inform the IP layer.

Well, the claim was made that the current draft was specfically written to
exclude any reference to hints from Layer 2.

My opinion is that it was written to specificallly exclude certain handover
techniques that require hints from Layer 2, namely those that require no over
the air signaling, and to relegate those that require posthandover over the air
signaling to error cases. Those that require prehandover over the air signaling
were included as the normal cases, regardless of whether they required layer 2
information or not. Curiously, the normal cases were exactly those that were
included in draft 02, which was the result of now long concluded design team
discussions.

Thus, I have a difficult time understanding the logic behind what was included
and eliminated from draft 4.

>I believe that's

Here's what I think the current draft needs:

1) A clear statement of the problem.

2) A high level perspective on the proposed solution space that clearly
describes the two processes proposed for solving the problem of optimizing
Mobile IP handover:
    a) Prehandover address configuration
    b) Repair of routing failure due to old link termination.

The first process is not required because it is not possible for certain link
layers, the second is required for optimization otherwise the mobile node loses
in flight packets.

3) A short description of requirements on link layers. These requirements may
not all hold for all link layers. In addition, this should include a grouping of
requirements into classes of link layers based on what kinds of prehandover and
posthandover information is available on handover sequencing. For example, one
class has prehandover sequencing information available on the mobile node, and
thus can support prehandover address configuration.

This section should also describe when this protocol is not required, for
example, when the layer 2 supports make before break handover.

4) A description of the IP signaling required to perform prehandover address
configuration, and the IP signaling required to perform routing failure repair,
without any reference to the availabity of layer 2 handover sequencing
information.

5) A description of what IP signaling would occur for particular classes of
available layer 2 handover sequencing information.

If this sounds complicated, its because there are time dependencies and
dependencies on lower layers that don't occur for other IP protocols. I believe
igoring those would result in a base specification without sufficient detail to
guide implementors having to implement the protocol on a particular link layer.

                jak