Subject: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04

From: Manolis Sifalakis <[email-masked]>
Date: Thu, 11 Apr 2002 19:51:11 +0100

Hello all,

I just finished reading some parts of the 
draft-ietf-mobileip-fast-mipv6-04 and I would like to ask some 
questions. My apologies in advance if these things have been discussed 
before but I joined the list only 4 days ago.

1. In Anticipated Handover Overview (3.1.1) it is understood that the 
oAR after sending the PrRtAdv message it waits for an F-BU request 
before starting to tunnel the traffic, destined for the oCoA, to the 
nCoA or the nAR.

Q1. What happens if the MN delays to cross to the new link after sending 
the F-BU (since for a mobile host anything can easily happen to delay 
the link traversal)? Are the packets still delivered to the local link 
untill a L2 trigger appears or are they sent through the tunnel to the 
nCoA/nRA?

Q2. Would it be too much of an overhead if the oAR trasmitted the 
packets both to the local link and through the tunnel for a while, till 
it receives an ACK that traversing has been completed?

2. Q. How can a MN or an oAR possibly have topoloical information of 
where they are heading to, so as to be able to trigger the fast handoff 
mechanism?

3. Q. Up untill section 3.5.2 in the document (that I read), there is 
nowhere mentioned that the aAR may be the HA. Instead it is constantly 
implied that the HA is different from the oAR or the aAR. Is that 
correct? If yes why?

4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is often 
used to mean F-BAck. If I have misanderstood and an AR can indeed send 
F-BUs to the MN, then the typo is in the description of the F-BU.

Regards

.Manolis

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Apr 2002 13:33:22 -0700

> untill a L2 trigger appears or are they sent through the tunnel to the

If there is a L2 Link Down trigger on the old access router, this can be
used to determine when to start tunneling.
If no such trigger exists, the access router can either start tunneling
immediately, in which case the mobile node will miss those packets sent
before it moves, or it can bicast packets down the old link and the
tunnel.

> it receives an ACK that traversing has been completed?

This has been proposed, but there are questions about the effect on the
transport layer, though some people contend that the (IPR-encumbered)
Eiffel draft will solve the problem.

> where they are heading to, so as to be able to trigger the fast
handoff

This comes as part of a Layer 2 trigger, and depends on the particulars
of the Layer 2. For example, it is relatively easy to get this
information on a cellular network. On a WLAN, the mobile knows its
BSSID, this can be sent in the PrxyRtSol. The access router then needs
to perform a kind of cross link RARP to find out the IP address. Seamoby
is looking at a protocol to facilitate dynamic cross link RARP, but
static configuration is always possible.

> implied that the HA is different from the oAR or the aAR. Is that

Would it make any change in the protocol description?

> F-BUs to the MN, then the typo is in the description of the F-BU.

It should probably be F-BAck.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 12 Apr 2002 17:32:50 -0700

> implied that the HA is different from the oAR or the aAR. Is that

Nowhere in the draft it should it suggest that aAR is "the home agent of the
MN for its home address".

But note that, in order to provide "forwarding from previous care-of
address"
functionality, aAR/oAR has to implement home agent functionality. They act
as a home agent for the oldCoA of the mobile node. oAR has to defend the
oldCoA and tunnel packets sent to oldCoA to newCoA.

alper

---

From: [email-masked]
Date: Mon, 15 Apr 2002 08:52:23 +0800 (CST)

> Q1. What happens if the MN delays to cross to the new link after
> sending  the F-BU (since for a mobile host anything can easily happen
> to delay  the link traversal)? Are the packets still delivered to the
> local link  untill a L2 trigger appears or are they sent through the
> tunnel to the  nCoA/nRA?
I think it is decided by the L2 triggers you can get. If you can get L2-LD,
sending packets via local link untill a L2 trigger can save bandwidth and
cache. If you can not get L2-LD, you can only tunnel this packets to nAR.
> implied that the HA is different from the oAR or the aAR. Is that
I think aAR and oAR do the HA function for aCoA or  oCoA while they tunnel
packets to mobile node. But they need not to do all the HA function.
>
>
> 4. Some typos, I suppose, in 3.1.1, 3.1.3, 3.1.8, are that F-BU is
> often  used to mean F-BAck. If I have misanderstood and an AR can
> indeed send  F-BUs to the MN, then the typo is in the description of
> the F-BU.
I also think so. There are many clerical error?

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 17 Apr 2002 11:18:10 -0700

Hi,

some comments below..

James Kempf wrote:

> sending

^^^^
The AR must start tunneling immediately after processing the FBU. In fact,
the control (to turn on tunneling) must reside at the MN.

> before it moves, or it can bicast packets down the old link and the

clarification: bicasting is not proposed in the spec (after a long
discussion
culminating in a vote at London IETF).

> Would it make any change in the protocol description?

I agree with Alper's comment; old AR "acts like" an HA in
tunneling packets to a new IP address.

> often

Thank you for finding the typos, and for your comments.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 06:37:24 -0700

Rajeev,

> culminating in a vote at London IETF).

If it does this, the mobile loses packets between when the FBU is
received
by the AR and when it finally arrives on the other link (remember:
neither
bicasting nor buffering are in this draft).

If the router gets a Link Down, this can be used to reduce the packet
loss
to just the L2 handover blackout period. Of course, if this trigger is
not available, then the FBU must be used.

Or was there some other reason why you feel the FBU must be the
tunnel setup trigger?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 19 Apr 2002 17:20:28 -0700

> bicasting nor buffering are in this draft).

Right, how to handle potential packet loss is another issue.

> Or was there some other reason why you feel the FBU must be the

My concern is redirecting traffic without explicit consent from the
MN. Is "Link Down" enough authorization to start forwarding
traffic on the tunnel ? I am not sure.. The base protocol itself has to
operate with FBU, which authorizes the AR to refirect traffic.

Regards,

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 19 Apr 2002 17:43:49 -0700

Rajeev,

> operate with FBU, which authorizes the AR to refirect traffic.

F-BU is always a must. The feature is: if the network supports
link-down trigger, oldAR can further wait (after receiving F-BU)
for this trigger to change the routing.

 So, this is an additional optimization to change the routing at 
the exact point in time (L2 event), and relies on link-layer triggers.

We must already have this stated (probably not clear enough) in the draft.

alper

---

From: "James Kempf" <[email-masked]>
Date: Sat, 20 Apr 2002 10:20:13 -0700

Rajeev,

The FBU is always needed. The Link Down is just an optimization to avoid
starting the tunnel before the MN has actually moved. Hope that
clarifies.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Manolis Sifalakis" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 19, 2002 5:20 PM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04

> James Kempf wrote:
>
> > Rajeev,
> >
> > > ^^^^
> > > The AR must start tunneling immediately after processing the FBU.
In
> > fact,
> > > > immediately, in which case the mobile node will miss those
packets
> > sent

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Apr 2002 09:39:24 -0700

Hello Alper and Jim,

Ok. This clarifies.. What happens if FBU is not received
but the old AR gets Link Down ? I think the old AR must not
tunnel packets then.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Apr 2002 10:37:20 -0700

Rajeev,

I suppose your reasoning for this is because the tunnel terminates at
the MN and not the AR, correct? So the FBU is the indication that the MN
is ready to take packets at the new CoA. Without that, the AR acting as
an on-link HA doesn't know that the MN is established on the new link.

If that is it, then I agree.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Manolis Sifalakis"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, April 23, 2002 9:39 AM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Apr 2002 13:56:01 -0700

Hi Jim,

> an on-link HA doesn't know that the MN is established on the new link.

Right. More generally, FBU must authorize packet forwarding
on the tunnel independent of where the tunnel terminates as long as the
packets are destined for the MN. The issue is who has control over the
forwarding of MN's packets. If a MN has chosen a node as its AR, that
node has an obligation to forward packets to the MN. If the MN moves to a
new
location, it is the IP layer at the MN that is responsible for authorizing
the redirection to the new location. At least, IP layer authorization is
what
is of relevance to FMIPv6. Of course, if link-specific optimizations are
feasible, they should be available as options. They cannot be used as
substitutes for FBU for traffic redirection however.

Regards,

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 23 Apr 2002 14:58:30 -0700

> but the old AR gets Link Down ? I think the old AR must not

yes.

alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Apr 2002 00:55:21 -0700

Rajeev,

> substitutes for FBU for traffic redirection however.

I don't think this follows. If the tunnel terminates at new AR, the new
AR may buffer the packets until the MN shows up on the link. In BETH,
the ARs co-operate to set up the routing, so a Link Down on the old AR
is the appropriate trigger for setting up the tunnel. The MN isn't
involved in determining the routing, the routers are. This is consistent
with the basic history and design philosophy of IP routing, namely that
a host doesn't concern itself with the path its packets take through the
network, it is the task of the routers to perform this function. Hosts
have never been responsible for determining routing in IP (modulo source
routes of course) except to select their default router.

In Mobile IP if the old AR is functioning as an on-link HA, as the MIPv6
draft indicates, then the same mechanism used by the MN to communicate
with the HA in the home network are appropriate for indicating to the
old AR when the MN is on the new link, thus the FBU acts as the
indicator for setting the tunnel up to the MN. But this is only because
Mobile IP makes an exception to the standard IP routing design for a
specific case, namely changing the care of address. This case doesn't
occur with BETH because the care of address doesn't change prior to the
Layer 2 handover. BETH uses standard IP routing mechanisms to fix up the
change in link, Mobile IP mechanisms are used after the link switch to
change the care of address as in standard Mobile IP, rather than
changing the care of address before, as in FMIPv6.

So I agree that the FBU is the proper signal for starting the tunnel in
FMIPv6, but I do not agree that it holds as a general principle that a
MN can determine the routing of its packets, as this would be in direct
contradiction of basic Internet routing design principles.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Apr 2002 10:05:01 -0700 (PDT)

James Kempf writes:
 > > on the tunnel independent of where the tunnel terminates as long as

 > contradiction of basic Internet routing design principles.

   It might be helpful to step back to the non-mobile
   case here. You're correct to say that once I've
   sent a packet, I have no influence over where
   it goes. On the other hand, I do have a great
   deal of influence where I send it to in the first
   place; that is, I choose the interface. Since MIP
   tunnels are essentially virtual interfaces, the
   distinction you're making doesn't seem as cut
   and dried to me. Creating and deleting virtual
   interfaces is definitely new ground from the
   original security/routing premises of the net.

   It seems to me that it should be perfectly
   reasonable for a host to request a forwarding
   service to a co-located address which it
   believes it will arrive on. For that, I agree
   with Rajeev that the mobile node has a part to
   play in the authorization. In the purely
   "network does the routing" model you suggest,
   I believe that you unreasonably constrain the
   mobile node's ability to move, possibly with
   the help of a local forwarding service. This is
   especially unreasonable if you want that
   forwarding service, but the two AR's don't have
   a business relationship with one another. Thus,
   it seems quite reasonable that the mobile node
   should ultimately have some influence in the
   service it is asking the AR to provide. In the
   end, while we might provide support for network
   centric moves (ala cellular), but on the
   Internet, the host is King so any solution 
   MUST have a way to control its destiny first
   and foremost.

   On the other hand, it seems reasonable that an
   AR might want to control the tunnel endpoints
   in some way so as to thwart reflection attacks,
   etc. But I'm not sure that we need to do much
   beyond what we need to do for normal home agent
   like signaling; if the local AR has a way to
   authenticate and authorize a mobile node and/or
   other AR's, isn't that enough? We presumably
   have made our peace with reflection attacks
   through a home agent (? haven't we?) so the
   localized equivalent shouldn't be any
   different. Also: the AR is perfectly at liberty
   to not provide the local forwarding service at
   all -- which is current state of affairs,
   afterall.

   What am I missing?

	   Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 24 Apr 2002 14:08:16 -0700

Hi,

> is the appropriate trigger for setting up the tunnel. The MN isn't

Ok. The difference between BETH and FMIPv6 is noted.

> routes of course) except to select their default router.

Well, I agree with you that routing (i.e., the way a packet traverses
nodes to reach the destination) is not what hosts typically get
involved in. However, a host has to be able to determine whether
it receives packets or not in the first place, independent of _how_ the
packets arrive.  More to the point, the MN must decide
whether its current AR should redirect traffic or not.

> specific case, namely changing the care of address. This case doesn't

I would say that standard IP routing is not affected at all by Mobile IP.
Whether Mobile IP chose to be that way or it was the result of a routing
exception (or both) is another issue. In any case, it is crucial to note
that the
burden of mobility (i.e., being reachable in the presence of handovers and
roaming) is on the mobile node with Mobile IP, that allows it to operate
without special IP routing support.

> Layer 2 handover. BETH uses standard IP routing mechanisms to fix up the

Ok. This distinction between BETH and FMIPv6 is also noted.

> changing the care of address before, as in FMIPv6.

However, let me point out that a mode in FMIPv6 allows a MN to keep
its old CoA.

> contradiction of basic Internet routing design principles.

As I mentioned above, an end-point must control the destiny of its
packets, if not the way the packets get there (as you point out
above, there is a routing exception: source routing).

In any case, I notice that FMIPv6 and BETH design points are somewhat
different (even though improved handover is the target) including
- who has the control in deciding when forwarding on the tunnel is
   activated
- whether the MN always keeps the old CoA (BETH) or it uses the
   new CoA or the old CoA (FMIPv6)
- whether L2 triggers are used (BETH) or IP messages are used (FMIPv6)
    for handover switching

I think it makes sense to document these and others, at the very least.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Apr 2002 01:04:28 -0700

Hi Michael,

Your analysis is correct if the mobile node knows that a handover is
occuring. I probably didn't make this clear enough, but as I mentioned,
IP hosts have always had the option of choosing their default router,
and if they becme aware that this router is changing, they should have
the option of choosing a new one. Security, to the extent it is possible
with currently unsecured protocols such as ND, should of course also
play a role as you describe.

I was objecting to what I detected  in Rajeev's note that this must
always be the case, even when the mobile did not have any knowledge that
the handover was occuring. In my view, this corresponds to a failure of
a router in the network.

Which occurs depends on how much informatoin is made available to which
entity by the wireless protocol.

Does this make sense?

            jak

PS: BTW, I followed up that reference on routing security. Dan Harkin in
his book on IPSEC mentions on pg. 111 that a separate ISAKAMP DOI for
OSPFv2 and RIPv2 has been written. He says that this is separate from
the IKE DOI and IPSec DOI.

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Rajeev Koodli" <[email-masked]>; "Alper E. YEGIN"
<[email-masked]>; "Manolis Sifalakis"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 24, 2002 10:05 AM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Apr 2002 01:17:02 -0700

Rajeev,

One issue is where the information about the failure of routing due to
link handover is available. If the MN knows, then it can take measures.
If the network knows, then it can. FMIPv6 and BETH are two design points
to cover these. These are covered in the draft.

The other issue is when the information is available, before or after
the point of link attachment has been changed (or both). Both FMIPv6 and
BETH cover only the before case. Optimized standard Mobile IP handover,
Forwarding from Previous Care of Address, and Posthandover Mobile
Initiated Tunneling cover after. These are not covered in the draft, but
are in other drafts.

I think all of these are possible cases, unfortunately, and they all
have different preformance characteristics.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Alper E. YEGIN" <[email-masked]>; "Manolis Sifalakis"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 24, 2002 2:08 PM
Subject: Re: [mobile-ip] some questions about
draft-ietf-mobileip-fast-mipv6-04

---

From: Michael Thomas <[email-masked]>
Date: Thu, 25 Apr 2002 05:58:01 -0700 (PDT)

> entity by the wireless protocol.

   Yes, I understand where you're coming from, but
   my gut level feeling is that Rajeev is right to
   be suspicious because the issues don't seem to be
   100% parallel. What this seems like to me --
   and I might be in left field here -- is
   something more akin to ICMP REDIRECT. That is,
   I'd like you to move elsewhere because it's a
   better route. But in the REDIRECT case, the
   node doesn't have to actually honor it; after a
   few retries, the router gives up and assumes
   they won't move. This isn't entirely unlike
   another scenario where a router has dynamic metrics 
   which for whatever reason it just ignores (say
   it has a static route too). 

   Thus to my mind, the nature of these changes
   are *cooperative* on a hop-by-hop basis. That
   is, I'd like you to do something and you
   oblige. Therefore, if it makes sense in this 
   case -- and I'm not sure because which piqued
   my interest here was the Internet gestalt -- it
   does seem that to mimic the current net, the
   exchange needs to be "may I? yes, please do"
   which sort of favors Rajeev's contention that
   it must be authorized by the MN. The reason
   is because the MN ultimately needs to
   participate in the move (eg, retune its radio,
   etc), right?

		Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 25 Apr 2002 09:56:16 -0700

Hi Jim,

> to cover these. These are covered in the draft.

Clarification: In FMIPv6, the AR can send ProxyRtAdv without the MN
soliciting it. This covers the scenario when the information about
"routing failure", as you put it, is available at the network. BTW, isn't
"impending link failure" a better descriptor compared to "routing failure"
?
Anyway, this is a terminology nit.

> Initiated Tunneling cover after. These are not covered in the draft, but

Agreed. If the MN is already attached to the new link, not much
pre-processing can be done.

Regards,

-Rajeev

---

From: Joe Lau <[email-masked]>
Date: Thu, 25 Apr 2002 10:49:09 -0700 (PDT)

Hello,

Has anyone used a wireless interface with HUT' MIPv6 Mobile Node? 
Thanks for the info.

Joe

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 25 Apr 2002 11:02:49 -0700

>    it has a static route too).

Interesting analogy. Some more thoughts..

- in the REDIRECT case or more generally the
   network-triggered case, the MN is informed and
   the MN has the option to disregard it as opposed to
   unilaterally deciding the destination for MN's packets.
   This is a crucial point.
- if the knowledge that MN is about to "lose its link"
   resides exclusively at the network, the network can
   _still_ provide such an indication to the MN, e.g., via
   ProxyRtAdv in FMIPv6 or REDIRECT. [coincidentally, we
   used REDIRECT for network-triggered handover
   in our version of the fast handover draft back
   in October 2000]. If such a knowledge resides exclusively
   at the MN, the MN can always solicit a move and then
   authorize it. In either case, the MN _can_ be (and should be)
   given the token to authorize redirection.
- if notification fails (e.g., due to bad terrain), there is
   standard MIP with the possibility of
   siphoning packets from the previous AR.

>    oblige. Therefore, if it makes sense in this

Good point. If the MN does not engage, then it
won't gain and might lose.

>    participate in the move (eg, retune its radio,

Right.

Regards,

-Rajeev

ps. BTW, is there a version of Redirect for
      renumbering with an alert option ?

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Apr 2002 15:25:11 -0700

Michael/Rajeev,

I understand the desire to get the mobile involved in making the
handover decision, but there really is a problem if you are concerned
about reliable performance improvement. If reliability is not a concern,
then signaling the mobile over the air prior to the handover and letting
it decide is clearly the right way to go.

If you are concerned about reliable performance (such as might be needed
to do VoIP), then there is an issue with any signaling to the mobile
getting cut off prior to the mobile's moving. We've done some simulation
work on the FMIPv4 algorithms, and, together with Motorola, have
implemented them on 802.11b and IS-2000 RAN. The Prereg algorithm
(analogous to the original FMIPv6 algorithm) performs poorly in
comparision to the Postreg algorithm (like BETH) on IS-2000 RAN because
sometimes the initial signaling between the access router and the mobile
node gets cut off, This occurs if the mobile node moves before the
signaling can complete.

If the mobile node has enough time for signaling to complete between the
prehandover trigger informing it that a handover is pending and the time
at which the actual Layer 2 handover occurs, then it can achieve
performance equal to that achieved when the access router simply
switches the routing without consulting the mobile node. However, radio
conditions around handover are always dicey (since, otherwise, the
mobile node wouldn't be handing over) and the mobile node may speed up.
As a result, the actual prehandover trigger time is really a random
variable, and it could end up being too short. In that case, the mobile
node must recover on the new access router by using standard Mobile IP,
during which time its traffic on the old access router is dropped. So,
if a prehandover trigger is available on the access router, reliability
is improved by starting the tunnel, then having the mobile node fix up
things afterwards if it doesn't happen to like the access router on
which it is located.

Another alternative which works about equally as well, if there is no
prehandover trigger available on the access router, but the mobile node
does obtain a trigger on the new link when the link comes up, is for the
mobile to initiate the tunnel itself after the link switch. In this
case, the mobile is involved, but it takes longer.

Smoothing (buffering or bicasting) is also possible, but our experiments
on IS-2000 RAN indicated that an average of between 1 and 2 packets were
dropped if the access router just switched on the tunnel. The traffic
generator we were using was simulating real time traffic. A drop rate of
1 to 2 packets (with 20 ms packet interarrival time) would probably not
be noticed with voice, so it hardly seems worth it to introduce
smoothing, though it might be for other traffic or if no predictive
information was available in the network.

Of course, none of this matters if one is not concerned with reliable
real time performance suitable for replacing current circuit switched
cellular with VoIP (as I am). I can send you some slides with
preliminary measurments. We are continuing measurements on FMIPv4 (I'd
like to do some statistics on the results) and will be attempting the
same kinds of measurements on FMIPv6.

                    jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Alper E. YEGIN"
Sent: Thursday, April 25, 2002 11:02 AM

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 25 Apr 2002 19:02:36 -0700

Hello again Jim,

performance considerations is relevant. Clearly, fine tuning per
link type is needed. However, I would argue that such a need should
not alter the basic design principle(s). Mechanisms that preserve
the principles and provide the desired performance should be preferred,
at least in IETF work. For instance, if reliability of delivering a
handover
message to the MN is a concern, the previous AR could buffer data packets
and deliver them in case the link does fail to deliver the
handover message to the MN. Sure, there might be jitter (when there
is talkspurt, which BTW is a minority percentage in the ON-OFF
voice behavior), but an application such as VoIP has jitter buffers and
adaptive playout. I would be more inclined towards such an approach since
- not all links behave the same way; actually they hardly do
- not all applications have the same constraints
- a single design principle is applicable regardless of the link
   idiosyncracies and application requirements

I have more comments/questions below :-)

Regards,

-Rajeev

> it decide is clearly the right way to go.

Reliability is a concern, but the solution to address unreliability is
multi-fold, isn't it ?

> switches the routing without consulting the mobile node. However, radio

This is to be expected but good to hear empiricial validation.

> mobile node wouldn't be handing over) and the mobile node may speed up.

I tend to agree, but also would like to mention that MN may be interested
in getting "better" link connectivity from an existing "ok" link.

> during which time its traffic on the old access router is dropped. So,

Alternatively, these packets, when there are any, could be buffered and
delivered once the MN regains connectivity.

> dropped if the access router just switched on the tunnel. The traffic

Just curious if you did try the case when the router waited for the MN to
send authorization..

> same kinds of measurements on FMIPv6.

Good. Hopefully, we can compare notes. I have recently seen
some preliminary results from folks at UCLA on FMIPv6 which
closely match our preliminary tests on FMIPv6 (for WLAN).

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Apr 2002 01:04:09 -0700

Rajeev,

I rather favor some mechanism to inform the MN after the move has
occured. For example, sending the MN an ICMP REDIRECT message after the
access router has changed, as Michael has suggested, would do the trick,
as it would avoid the problem of the signaling getting cut off
prematurely.

Buffering in the context of predictive algorithms that utilize
prehandover over-the-air siginaling (such as FMIPv6) is difficult
because the amount of data to be buffered is not deterministic. It
depends on the speed of the mobile node, the data rate on the channel,
and the Layer 2 handover latency. Calculating the size of the buffer
becomes a major deployment headache. One can set the buffer size to
catch N standard deviations, but what about the N+1st? In particular,
the N+1st could be a rare event where the consequences of not handling
it are severe, like an emergency vehicle that moves much more quickly
than the average traffic.

In contrast, predictive algorithms that utilize network predictive
information to switch the routing without prehandover involvement of the
mobile don't run into this problem. The buffer size is deterministic,
making deployment much easier.

So I favor a statement in the FMIPv6 draft that the new AR SHOULD send
an ICMP REDIRECT message to the mobile node if BETH handover is
utilized.

Specific responses to your questions below.

            jak

> Just curious if you did try the case when the router waited for the MN
to

We did not examine that case. Obviously, it would delay handover even
more. I think there is some work to be done here on context transfer for
speeding authentication. I believe 802.11i is looking at preflooding
authentication to surrounding access points in order to avoid handover
delay, a similar technique or targeted context transfer could be used
for cellular.

> closely match our preliminary tests on FMIPv6 (for WLAN).

I've also seen some results from the EU Moby Dick project on FMIPv6
which match your results. However, I think more work needs to be done to
characterize the behavior of FMIPv6 under load. In particular, the
"hack" of forcing handover by resetting the BSSid effectively makes the
prehandover layer 2 trigger time deterministic, so the experimenter can
optimize this time to avoid having the FMIPv6 signaling cut off. In
reality, this time will be a random variable, just like it is for
cellular, if the 802.11 committee ever manages to define its handover
conditions precisely enough so the NIC manufacuturers can offer a
uniform L2 trigger API.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 26 Apr 2002 01:46:29 -0700

> contradiction of basic Internet routing design principles.

These principles are still valid as long as mobile node stays on the same
network. But of course these principles didn't account for the case of
"hosts" going "mobile". In which case, Mobile IP principles should
be applicable: mobile node is in charge of getting its routing fixed. Mobile
node cannot do this on its won, needs support from the network. At least
the home agent, if not the access routers on the access network should
cooperate.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Apr 2002 09:48:34 -0700

> as it would avoid the problem of the signaling getting cut off

REDIRECT is not sent _after_ the change of access router, but before
the MN moves. It is a notification for an impending handover, at least
that was my understanding and the basis for our now old proposal.

> than the average traffic.

It could be simpler: handover delay over the expected inter-packet arrival
time.
So, if expected handover delay is 100 ms, with 20 ms inter-packet
separation for
voice, you need room for 5 packets. Charlie has looked into buffering in
greater detail, and we have an implementation as well. We need to study the

performance aspects.

> making deployment much easier.

Ok. This is a design choice. For handover smoothing, which is a related
albeit separate topic, we need to evaluate the available options.

> an ICMP REDIRECT message to the mobile node if BETH handover is

Well, I don't believe that was the proposal, but if you wish BETH to have
such a message, we could consider it.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Apr 2002 23:55:44 -0700

Rajeev,

> that was my understanding and the basis for our now old proposal.

I don't think any signaling should be done over the air prior to
handover, unless it is possible for optimized handover to complete
successfully without it. Otherwise, if the signaling fails, then the MN
must recover using standard Mobile IP at a significant cost. I think the
optmized handover should strive for reliable, deterministic handover
performance.

> greater detail, and we have an implementation as well. We need to
study the

Right, so if the expected value of delay is 100 ms but the variance is
400 ms^2, one could get between 4 to 6 packets at one standard
deviation, 3 to 7 at 2, and so forth. If the buffer is sized for 5
packets, then you'd expect to end up dropping about 25% of the time.
That is the point I was trying to make.

On the other hand, if the handover delay is deterministic, or nearly so,
then a buffer for 5 packets should work almost all the time.

> albeit separate topic, we need to evaluate the available options.

Agreed. I also think we need more study about the various smoothing
algorithms (buffering v.s. bicasting).

> such a message, we could consider it.

I don't think it is a good idea if the message is issued over the air
prior to handover, and I don't think it's a good idea if the handover is
dependent on it. But it may be a good idea to inform the Mobile Node,
without requiring it to change care of address, after handover.

            jak