Subject: [mobile-ip] Fast Handover draft: proposed revisions

From: Rajeev Koodli <[email-masked]>
Date: Wed, 10 Jul 2002 18:43:10 -0700

Hello folks,

here is a list of proposed changes to the fast handover
draft v04, meant to initiate discussion and arrive at
consensus. Please comment.

Thanks,

-Rajeev

the proposed revisions:

1. Always allow the MN to use its Previous CoA during
    handover to both send and receive IP packets

Change from v04: In v04, PCoA was used only when
 it was not acceptable to use a New CoA.

New Implications: NAR must always have a host route
entry for PCoA (until the MN begins to use NCoA). This
is in addition to the proxy neighbor cache entry that NAR
creates when NCoA is acceptable to use.

Result: The MN is able to send and receive IP packets
while it establishes itself as a Mobile IP end-point.

2. Allow a MN to send FBU to Previous AR to tunnel
    packets arriving at PCoA to NAR.

Change from v04: In v04, only an FBU sent with PCoA as
source IP address would cause packets to be tunneled to
NAR.

New implications:
a) If NAR has not received a HI, it SHOULD
forward FBU to PAR.
b) If PAR has not received PrRtSol, but receives an FBU,
 it SHOULD send a HI to NAR

Result: the protocol can be initiated after the MN establishes
connectivity with NAR.

3. Allow L2 triggers to used

Change from v04: Define generic, L2 independent constructs
(to be done).

New implications: define exact trigger formats elsewhere.
The handover messages should be able to operate transparently.
Introduce a Handover Solicit from NAR (when a trigger indicates
that the MN is attached to it) to PAR to request a HI ?

And, here are the new features

- the MN should be able to maintain uninterrupted IP connectivity
   (i.e., is able to send and receive IP packets) for its existing
   sessions while it expeditiously establishes itself as a Mobile IP
   end-point.
- during the Binding Update procedure, the MN uses its PCoA
    to send and receive IP packets
- the protocol can be initiated when the MN is on the old link
   (via RtSolPr/PrRtAdv) or on the new link (via FBU)

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Jul 2002 09:52:46 -0700

Rajeev,

We implemented draft 04 and we feel that it was basically sound except it needed some editorial tightening. Therefore, the
rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back
to previous drafts, say 01, where many details were not as tightly specified as draft 04.

In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH)
can be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but I
believe we had WG concensus to put this into the draft and I would like to see them back.

However, we have found that implementation is aided by having the specification be very precise about when L2 information is
needed and what information is needed. The FMIPv4 draft has this information in it, as does draft 04, and it has been very
useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain sufficiently detailed information, especially
for Postregv6 but also for Preregv6. Many cases that will be common for particular link layers like standard 802.11 or
cellular are relegated to Section 4.1, the Error Cases. The detailed information on the relationship between L2 events and
FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another.

Remarks on you comments below.

> while it establishes itself as a Mobile IP end-point.

OK.

> Result: the protocol can be initiated after the MN establishes

OK.

But it must also be possible to do this in the absence of any prehandover signaling, for those link layers that specify no
standard prehandover L2 triggers. The current draft treats this as an error case, and it would not be clear to an
implementor on such a link layer that this would be possible and correct.

> that the MN is attached to it) to PAR to request a HI ?

The information about when the L2 information is used and where needs to be specified somewhere. This draft is not
sufficiently precise about that.

>    sessions while it expeditiously establishes itself as a Mobile IP

Disagree about the word "connectivity." IP is not connection oriented. The issue is fixing the transient route failure caused
by the mobile node changing links.

>     to send and receive IP packets

Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled.

>    (via RtSolPr/PrRtAdv) or on the new link (via FBU)

Addition of initiation on the new link is a plus, but it is not clear from this description that this is allowed in the
general case. It is couched as an error case.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Jul 2002 10:36:49 -0700

Hello Jim,

James Kempf wrote:

> In particular, Section 3.3 and 3.4 were dropped from the draft. These are
> critical for describing how Postregv6 (aka BETH) can be implemented.

It is possible to imagine a post-registration scheme for handovers
that does not use BETH.  For instance, one could send a Binding Update
to the previous access router, as is specified in the base draft.

> If there is some problem with too much reference to L2 triggers,
> we can discuss sanitizing them, but I believe we had WG concensus
> to put this into the draft and I would like to see them back.

I think we should characterize the layer-2 triggers by what action
they trigger (e.g., "Handover Solicitation Trigger", or
"Handover Initiate Trigger").  Then, we can point out in the
draft the actions that are taken when a layer-2 trigger happens.
This approach has the following benefits:

1) The protocol actions that are specified are layer-2 actions.
2) The layer 2 triggers can arise from whatever layer 2 satisfies
   the appropriate timing conditions
3) We can identify what layer-3 protocol actions are displaced by
   the availability of the layer-2 triggers.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Jul 2002 10:40:24 -0700

Hello folks,

I made a drastic typo in my previous note!

"Charles E. Perkins" wrote:

..............

> 1) The protocol actions that are specified are layer-2 actions.

I meant, "layer-3" actions!!!

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Jul 2002 10:43:43 -0700

Hello Jim,

James Kempf wrote:

> rather drastic revision represented by 05 is not particularly helpful toward moving this forward. It is actually going back to
> previous drafts, say 01, where many details were not as tightly specified as draft 04.
>

You didn't exactly say what _proposed_ change is drastic. I have itemized the
changes below under issues. Please comment on them.

>
> In particular, Section 3.3 and 3.4 were dropped from the draft. These are critical for describing how Postregv6 (aka BETH) can
> be implemented. If there is some problem with too much reference to L2 triggers, we can discuss sanitizing them, but Ibelieve
> we had WG concensus to put this into the draft and I would like to see them back.
>

Ok. Let's discuss how to accommodate L2 triggers _without_  normative dependency on
all link types that do and don't have such things. Do you have a proposal ?
I would like to be able to define generic constructs that can serve as triggers for the
protocol to be initiated.

> FMIPv6 needs to be described somewhere. If the WG does not want it in this draft, then it must be in another.

Let's seek the WG opinion on this. I think the base protocol should concern itself
with IP messages while allowing any L2 feature to be used. The base protocol itself
could define generic L2 constructs that can initiate the protocol operation.

Others ?

> implementor on such a link layer that this would be possible and correct.

The reason for this is that proposed v05 is an adaptation of v04, in which
a MN attempts to send an FBU prior to moving.
Also, an implementor has to read the Error cases if he/she wishes to
implement a robust protocol.

If the WG agrees that the text should be under a different section,
that's fine with me.

> sufficiently precise about that.

Ok. What does the rest of the WG think about what L2 specific
information should be in the draft ?

> by the mobile node changing links.

I don't see how "IP connectivity" translates to "IP is a connection oriented protocol".
"Internet connectivity" does not translate to "Internet is connection oriented", does it ?
Anyway, the parenthesis should help.
What do others think ?

> Agree. But the removal of the L2 triggers information seemingly excludes Postreg, both mobile and network controlled.

I didn't see the connection between the two on this bullet..

> general case. It is couched as an error case.

Ok. I can include text that allows specific usage.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Jul 2002 10:58:34 -0700

Charlie,

> to the previous access router, as is specified in the base draft.

It is not only possible to imagine, but critical to have in the draft. Some link layers may not support access point or
router triggers, nor any prehandover triggering at all, so the option must be there.

The problem with draft 05 is that this case is not clearly specified as a valid option. It is only specified as an error
case. It is not an option in the current WG draft, and that needs to be fixed.

But, additionally, there must be protocol to support when triggers are available just on the access point or router, or when
these triggers will provide the best performance. Our experience is that these typically get the best performance for low
bandwidth, high latency links, such as are used for WAN cellular voice traffic (which is why we are interested). The draft 05
doesn't clearly specify these cases, whereas Sections 3.3 and 3.4 in the current WG draft do.

>    the availability of the layer-2 triggers.

In addition:

4) What information is provided by layer 2 to layer 3.

We would need to discuss the actual wording but in principle this is what draft-manyfolks-l2-req-xx.txt is trying to do.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Jul 2002 11:35:45 -0700

Rajeev,

> changes below under issues. Please comment on them.

Below is an itemized list of what was removed in draft 05 which we found valuable in or *complete* implemetation of the
current working group draft. In particular, there were a couple important issues that came up in WG discussion which we have
spent lots of time and design cycles on trying to solve which have been ignored or fuzzed over in the current draft but were
clearly if perhaps inaccurately specified in the previous draft:

Draft 05 is missing Sections 3.4 and 3.5 as mentioned. All the protocol support for source and target triggered network
handover has been removed from the message formats.

Sections 3.1: This contains important details about the linking between particular kinds of L2 handover sequencing
information and Preregv6 signaling. This was invaluable for our implementation.

Section 3.5: Tunnel termination conditions. As I recall from the mailing list discussion a year and a half ago (we can check
the archives) this was a hot issue when tunnel based handover was initially introduced into the draft. We've done lots of
work in our implementation to make this possible, in order to conserve access router resources, and we have some suggested
changes to the current WG draft on this. Draft 05 dodges the issue completely by specifying that the tunnel just times out.

Section 4: Interoperability between Prereg and Postreg was another hot issue. We've done lots of work in our implementation
on this, and we now have what we think is a workable interoperability solution. This was completely eliminated from draft 05.

Section 6: Draft 05 removes important details about handling error cases, which are necessary for implementation. We have
additional details that came out of our implemetation effort which are not included in draft 05. Draft 05 also makes cases
that are normal for particular link layers into error cases.

Section 8: Here is what draft 05 has to say about security (from Section 3, Paragraph 3):

        In order to ensure that the target of traffic redirection is not an unsuspecting innocent host, the PAR has to
       determine that the target address belongs to NAR, with which PAR has trust relationships. The
       PAR takes these precautions before it associates PCoA with another address.

This is not sufficient to secure the protocol. Draft 05 Section 9, Security Considerations, is similarly vague about what
must be done. Section 8 in the current WG draft isn't sufficiently precise either, but if draft 05 is supposed to move the
current WG draft forward, then it should be more precise. Instead, draft 05 removes the framework about how to secure the
protocol for network and mobile triggered handover.

Prior to your issuing draft 05, I offered to send you a list of the changes we saw required in the current working group
draft that came out of our implementation experince, but you recommended that I wait until after you had issued draft 05. I
agreed thinking that minor editorial changes would be made in the current WG draft, as is fairly typical with WG drafts at
this stage (two years on) of development, but I was suprised to find, when draft 05 came out, that it was a complete rewrite
removing many important details (which I have outlined above) that were important to our implementation, such that it would
be very difficult to map the changes we saw needed in the current working group draft to draft 05.

Frankly, after two years of working on this protocol, I had thought the draft text had settled down to a state in which it
was implementable with minor changes. Drastically rewriting the draft was unnecessary to introduce the material you describe
in the list below.

What do other people in the WG think (if anybody cares)? Do we need a complete rewrite of this draft?

> protocol to be initiated.

It is not clear that there is WG concensus for removing L2 specific event descriptions from the draft. We have been
discussing a L2 triggers draft, and we could put this information into the draft as we did for FMIPv4.

I would like for us to start with the current WG draft and use that as a base for figuring out what should be done. Draft 05
has eliminated too many details to make it useful. Perhaps we can come up with something based on the current WG draft that
describes how L2 events are utilized that is acceptable to you.

> Anyway, the parenthesis should help.

What's happening is a change in routing. One needs to be precise about this. There is no connection-oriented context being
set up.

> I didn't see the connection between the two on this bullet..

The text in draft 05 is not sufficiently clear or precise to present this as an option to an implementor. It looks like every
handover must consist of Preregv6 signaling, even if that is impossible to do on a particular link layer.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Jul 2002 11:38:18 -0700

Hello Jim,

newlines inserted for shorter linewidths, hope that's O.K.
Plus I fixed my typo.

James Kempf wrote:

> But, additionally, there must be protocol to support when triggers
> are available just on the access point or router, or when
> these triggers will provide the best performance. Our experience
> is that these typically get the best performance for low
> bandwidth, high latency links, such as are used for WAN cellular
> voice traffic (which is why we are interested).

Not all protocol is layer-3 protocol.  Often, layer-2
triggers trigger actions that are layer-2 actions, but
have no layer-3 effects.  This is true especially for some
of the sorts of cellular handovers that I am familiar with,
and I wouldn't expect much controversy.  But we ought to
be careful to use layer-3 controls just where they are needed.

>> 1) The protocol actions that are specified are layer-3 actions.

Agreed.

Regards,
Charlie P.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Jul 2002 12:01:59 -0700

Hi Charlie,

> to the previous access router, as is specified in the base draft.

Actually we worked out a protocol that basically does this.

http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt

This is a stand alone solution itself. It doesn't require anything
but a link-up trigger. A similar approach was presented in the
base draft, as an error case handling. We, the authors, believe
that this can be worked into a complete solution, but of course
there were some details that needed to be worked out (which
the fmipv6 draft missed).

Cheers,

alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Jul 2002 12:12:26 -0700

Hi Charlie,

> be careful to use layer-3 controls just where they are needed.

No disagreement there.

> >> 1) The protocol actions that are specified are layer-3 actions.

The problem here is that Layer 3 needs to know what is going on at Layer 2. So there needs to be a specification of what the
event is at Layer 2 that is triggering the protocol action at Layer 3. For example:

    Layer 2                               Layer 3
    ............                              .............

 Link goes down          Start tunneling packets to NAR

Is this what you have in mind?

                jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Jul 2002 16:16:45 -0700

Rajeev,

> this is a proposal to define the base protocol with IP messages
> alone while allowing L2 triggers to be used. The intention was not
> to take out anything without seeking consensus. A message from
> the chairs yesterday indicated that v04 is the reference document
> and v05 would be updated based on the WG discussion and consensus
> on proposed changes.
>

That's not how I read Raj's note. Raj's note says that draft 04 is the concensus document, and draft 05 will be issued based
on discussion of the currently proposed strawman draft that you issued, and concensus resolution to the list of issues. That
does not necessarily mean that changes will be merged into the current strawman, IHMO. It could equally mean that changes
from the strawman are merged into draft 04, which is what I maintain should be done (based on our success using draft 04 for
implementation, and my lack of confidence that that would be possible, without massive revision, on the current strawman).

Perhaps the WG chairs can clarify.

> So, what is here is a list of proposed changes. I am proposing that the base
> document should define generic L2 constructs that trigger protocol
> operation. The exact format definitions, which depend on particular
> link layers, should be spcified elsewhere.
>

Please point out to me in draft 04 where there are specific formats based on specific L2s.

> I am willing to revise the draft by accommodating whatever the WG
> desires. That's what I have to do. Would you like to help ? If yes, and
> I hope you would, we may start by defining the generic L2 trigger
> definitions that Charlie indicated and ensure that the base draft is
> independent of specific L2 features. Is this acceptable ?
>

I am certainly willing to help, in fact, I am co-author on a draft, draft-manyfolks-l2-req-xx.txt, which does precisely this.
But so far this draft has not got a lot of traction in IETF, which is why I think we may have to describe the coupling
between the handover protocol and L2 directly in the handover document. The coupling description doesn't have to be for a
specific L2, but can be similar to the email Charlie and I exchanged. Then, in separate documents, the exact implementation
on a particular link layer can be described, with the exact L2 protocol.

I really don't think our disagreement has to do with how to incorporate L2 specific information. I think the disagreement is
about whether the current strawman draft 5 contains the kinds of implementation details that were so important to our
implementation effort, especially for Postregv6/BETH, that are in draft 4. I don't see that level of detail, but rather, I
see another year of trying to implement from the draft and trying to get the details up to where they were in draft 4.

So I think a more fruitful course would be to take the new and important changes, like being able to send FBU after handover,
and folding them into draft 4.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Jul 2002 15:35:05 -0700

Hello Jim,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 17:40:09 -0700

hi Jim,

I formatted your text a bit. they were wrapping around too much.

James Kempf wrote:
> 
> Rajeev,
> 
> We implemented draft 04 and we feel that it was basically sound except 
> it needed some editorial tightening. Therefore, the
> rather drastic revision represented by 05 is not particularly helpful toward 
> moving this forward. It is actually going back

this is an extremely unreasonable statement to make. I went through
draft 5. having been one of the two persons who has implemented
draft 4, there is nothing missing in draft 5 for doing fast handovers
that was in draft 4. the only thing that is missing is how to do tunnel
handovers based on some L2 triggers. infact draft 5 simplifies so
many things by eliminating too many different handover scenarios in
draft 4. draft 4 was a nightmare to implement and interoperate 
(sorry Gopal, you were not to blame). ask Jon Wood and Alper Yegin. 
they were there. we spent 4 days at Connectathon 2002 and could do 
only a fraction of testing that we wanted to do. we didnt have one
complete successful handover :(

IMO, it is a big joke if somebody says draft 4 was better than draft
5 when it comes to implementing FMIPv6.

> can be implemented. If there is some problem with too much reference to L2 

Section 3.3 and 3.4 also critically depend on L2 triggers to work. 
BTW, I still havent figured out how to implement L2 triggers on our 
testbed. I dont see FMIPv6 draft moving forward unless the L2 triggers
draft becomes a standard. right?? and the L2 triggers document does
not even have a permanent home (WG).

can you do Postregv6 without using L2 triggers? it can be done
in draft 5.

> triggers, we can discuss sanitizing them, but I

this is better. if there is some way we can do this, we should do
this. not put L2 stuff in the draft.

> useful in both our FMIPv4 and FMIPv6 implementations. Draft 5 does not contain
> sufficiently detailed information, especially
> for Postregv6 but also for Preregv6. Many cases that will be common for particular 

that is something which can be fixed if you feel it is not there.
anyway IMO, draft 5 does both Postregv6 and Preregv6. and I 
certainly dont agree that it does not have enough information for 
implementing Preregv6

> But it must also be possible to do this in the absence of any prehandover
> signaling, for those link layers that specify no

this can be explicitly specified. I dont see a problem in it.

> both mobile and network controlled.

no. Postreg can be done without L2 triggers.

> general case. It is couched as an error case.

again this is something which can be clarified.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 17:54:38 -0700

> but a link-up trigger. A similar approach was presented in the

it can done without the link-up trigger, right?? like receiving a 
router advert on the new link. why cant we design a generic solution
that would not depend on any L2 triggers. and make sure the solution
does not prohibit using L2 triggers if available.

I do agree that you can get better handover performance if you have
L2 triggers. but it is also important, IMO, that the fast handover 
spec advances without having to depend on L2 triggers.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 18:09:20 -0700

James Kempf wrote:

> 
> Section 3.5: Tunnel termination conditions. As I recall from the mailing list 
> discussion a year and a half ago (we can check
> the archives) this was a hot issue when tunnel based handover was initially
> introduced into the draft. We've done lots of
> work in our implementation to make this possible, in order to conserve access
> router resources, and we have some suggested
> changes to the current WG draft on this. Draft 05 dodges the issue completely by
> specifying that the tunnel just times out.

thats because 'Tunnel termination' was a critical issue in BETH. the
BETH protocol does not work without it. it is not the case in 
anticipated handover (as defind in draft 4)

that is why.

> Section 4: Interoperability between Prereg and Postreg was another hot issue.
> We've done lots of work in our implementation
> on this, and we now have what we think is a workable interoperability solution.
> This was completely eliminated from draft 05.

thats because BETH was so different. it includes supressing router
adverts from the routers. you had a problem with respect to 
interoperability between anticipated part and BETH part because the
MN and the access router needed to be told exactly which protocol
it was running. draft 05 has simplified that IMO.

> Section 6: Draft 05 removes important details about handling error cases, which
> are necessary for implementation. We have
> additional details that came out of our implemetation effort which are not

like what? I have Alper's Connectathon report here. I think Rajeev
went through them. if these additional details are something other
than what we found at Connectathon, lets discuss them.

> was implementable with minor changes. Drastically rewriting the draft was
> unnecessary to introduce the material you describe
> in the list below.

frankly, it was needed. we spent four days without one complete 
successful fast handover. it was frustrating to say the least. I would 
call neither implementation (yours nor ours) succesful (sorry Jon).

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 18:13:53 -0700

> anticipated handover (as defind in draft 4)

I wanted to say draft 5.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Jul 2002 18:19:16 -0700

Hi Vijay,

> does not prohibit using L2 triggers if available.

I don't think we can have a reasonable fast handover solution
without relying at least on a link-up trigger on the mobile node.

alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Jul 2002 18:36:54 -0700

> without relying at least on a link-up trigger on the mobile node.

is the link-up trigger available on all mobile nodes? if the
answer is no, then we are stuck without a generic fast handover
solution.

OTOH, with sufficiently fast router advertisements you can have 
a reasonably fast handover. agreed, it is wont be as good when
you have a link-up trigger.

but I didnt say you should not take help from a link-up trigger.

seriously, do you think we can advance the FMIPv6 draft to a
Proposed Standard without having a L2 triggers specification?
anybody has an answer to this question?

Vijay

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 11 Jul 2002 18:38:06 -0700

Hello Alper,

> without relying at least on a link-up trigger on the mobile node.

But we have an implementation that shows otherwise.

One can have an implementation that works well.

> > spec advances without having to depend on L2 triggers.

I also agree with this.

I think we have to make the specification so that it works as
well as it can by itself, and it enables use of  L2 triggers to
work better whenever the triggers are supported by the particular
link layer.

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Jul 2002 20:46:39 -0700

Hello Alper,

> without relying at least on a link-up trigger on the mobile node.

we should allow the use, and benefit from it. In fact, Linux v6 stack
already provides an "upcall" that forces a RS to be sent when a new
interface is detected. However, to say that fast handover won't work
when such a feature is not available is analogous to saying that the
particular link type is not suited for fast handover. We should not
make that conclusion. We should allow all possible hooks for L2-specific
customizations, while not relying on them.

See you in Yokohama..

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Jul 2002 22:47:04 -0700

Vijay,

> answer is no, then we are stuck without a generic fast handover

The answer is  no (as expected :)

But I think this can be fixed. And if a client wants to do
fast handovers, it better be using one of those "fixed"
wireless interfaces. If it doesn't have one, then it is stuck.
It's not good to have such dependencies, but I think this
time it's unavoidable... 

> you have a link-up trigger.

How fast? Note that starting to hear another prefix doesn't mean
that mobile node has handed over. This needs to be coupled with
"not hearing your current prefix" as well. 

Also, people are even trying to avoid sending "any" unsolicited 
router advertisements over the air due to  bandwidth and dormancy 
reasons... Sending high volume of such signaling is very problematic.
This is not an acceptable solution, imo.

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 11 Jul 2002 22:50:25 -0700

Hi Charlie,

> One can have an implementation that works well.

Sure. But some details are critical here. As I was asking
Vijay, what is the advertisement frequency? How soon can
the mobile node realize that it needs to handover?

alper

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Jul 2002 10:25:43 -0700

> not even have a permanent home (WG).

If you want to know how to implement L2 triggers, either I or Jon Wood can help you. I implemented them on the Solaris
emulator and Jon on our Linux/BSD emulator. Jon is also in the process of implementing L2 triggered 802.11 handover, in a
manner that is consistent with the 802.11 spec and doesn't depend on proprietary extensions.

        jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 12 Jul 2002 12:35:24 -0500

I concur with Charlie. At the moment we do not know what will happen to 
L2 triggers in IETF. We expect that a decision will be made soon as to 
grant a BOF on this subject.
  It is not clear in my mind if the BOF happens and L2 triggers (on 
handover) which are already in some drafts become RFCs, would that cause 
a problem? What about the other cases?

Regards,

-- 
Behcet

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Jul 2002 10:42:35 -0700

Vijay,

> anticipated handover (as defind in draft 4)

As Ajoy said, we had working group concensus to include BETH. It is not acceptable to drop it from the draft without
concensus to drop. Neither Ajoy nor I want it dropped.

Furthermore, anticipated handover doesn't cover all cases. For link layers where the mobile node only finds out after it has
moved, but before receiving a new RA beacon, i.e. reactive handover, the mobile should be able to set up the tunnel. The
current draft only covers this as an error case. It must make clear that this is an acceptable alternative, and that no
prehandover signaling is required (because there can't be any for reactive handover).

> it was running. draft 05 has simplified that IMO.

The same point holds for a mobile node enabled to do Prereg but starting in a standard MIP coverage area. I don't think we
want it hammering on the router with PrxyRtSol messages when the router doesn't understand them, especially not over a
wireless link. The current draft has nothing to cover this.

Furthermore, I believe there is working group concensus for including BETH with inter-router movement with RAs suppressed. It
was included in draft 04. Again, it is not acceptable to drop this. This optimization is critical for low bandwidth, high
latency links, and these are the kinds of links the wireless network operators care about because they are costly. 802.11 is
not the same thing, it will work fine with over the air signaling as long as there are not too many mobiles in the cell. And
the spectrum is free.

                jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Jul 2002 10:46:31 -0700

> anybody has an answer to this question?

 I think the MIPv6 fast handovers draft needs to specify the interaction with Layer 2 in an abstract sense, as Charlie and I
were discussing yesterday. Whether that requires a specific L2 triggers specification is another issue.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Jul 2002 10:50:57 -0700

Charlie,

> work better whenever the triggers are supported by the particular

Can you give me an example of how a mobile node might hand over without any help from L2?

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 Jul 2002 11:14:47 -0700

Hello Jim,

I can give an example, and I will do so, but I think the
danger would be that then the example would become the point
of contention, diverting attention from what is really
important.  I think what is really important is to get to
the point where:
1) The layer-3 protocol supports the required functionality
2) The layer-3 protocol supports replacement of some of the
   layer-3 signaling by layer-2 signaling (e.g., "L2 trigger")
3) The layer-3 protocol supports as many layer-2s as
   is possible, including low-bandwidth links (e.g., < 10kb/s).

Here is my example:

Suppose the access routers are beaconing 60 times per second,
and the mobile node hears a new beacon.  Then it can solicit
a handover from the previous access router and get packets
delivered to the new access router within 25 ms of the time
it first moved within range of the new access router.

In this example, source triggers, target triggers, and mobile
triggers from Layer 2 can all act to improve the performance
and/or eliminate the need for beaconing.  There are plenty
of variations, depending on whether you like mobile-controlled
or network-controlled, or whether your physical medium doesn't
have enough bandwidth for the beacons, or whether the handover
is reactive or predictive, or ...

However, all of these cases can be served by the existing
fast handover document as I understand it to have evolved
from the original design team document.  What is needed, as
you have mentioned before, is the clean description of how
layer-2 signals can cause layer-3 actions that otherwise
would require layer-3 signals to have occurred.

Regards,
Charlie P.

PS. I guess your mailer doesn't like newlines as much as mine.
    I hope you don't mind if I put one of them into your message text.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Jul 2002 11:45:04 -0700

James Kempf wrote:
 
> emulator and Jon on our Linux/BSD emulator. 

this was done on an emulator.

> Jon is also in the process of 
> implementing L2 triggered 802.11 handover, in a

but that needs to be specified somewhere, right? are they IP messages?

Jim, I am not against using L2 triggers. I use them too (I use the L2-up 
trigger at the MN). but what I also want to see is FMIPv6 advancing 
without having to depend on L2 triggers.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Jul 2002 12:05:03 -0700

> concensus to drop. Neither Ajoy nor I want it dropped.

Jim,

what was dropped was the description how to setup tunnels between
access routers using L2 triggers. you can set up tunnels between
access routers based on explicit signaling. that is there in 
draft 5. what we now need to do now is make sure we can take
advantage of L2 triggers when they are available.

> prehandover signaling is required (because there can't be any for reactive handover).

Rajeev has already agreed to this. I think it can be made more
explicit.

> The same point holds for a mobile node enabled to do Prereg but starting in a standard MIP coverage area. 

no it doesnt. in the first place, FMIPv6 draft 5 does not affect 
MIPv6 draft 18 functionality on a MN. please let me know if I am
missing something.

> I don't think we

thats not right. the current draft tells you not to hammer the access 
router with PrxyRtSol. from Section 5.1.1 in draft 5

    A MN sends this message if it wishes to initiate fast handover.  It
    indicates its destination with the New Attachment Point Link-Layer
    Address.  A Proxy Router Advertisement message should be received in
    response.  If such a message is not received in a short time period
    but no less than twice the typical round trip time (RTT) over the
    access link or 100 ms if RTT is not known, it SHOULD resend RtSolPr
    message at most twice, waiting for the same time during each
instance
    of retransmission.  If Proxy Router Advertisement is not received by
    the time the MN disconnects from the PAR, the MN SHOULD attempt to
    send FBU as described in Section 4.1.

A proxy router solicitation is resent atmost twice.

> was included in draft 04. Again, it is not acceptable to drop this. 

I am not disputing that there was WG concensus to include BETH. my point
was tunnel termination and suppressed RAs were central for BETH to work.
they are not needed for a generic FMIPv6 solution to work.

> This optimization is critical for low bandwidth, high

why did you assume I am talking about 802.11? its true that our
prototype
is based on 802.11 (yours as well). thats because that is what is
feasible
in a lab. I am concerned about cellular operators too. I work for Nokia.

regards
Vijay