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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 18 Jul 2002 09:30:23 -0500

Hello Alper,
Please find my inline reply.
regards,
ajoy

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 9:40 PM
To: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'
Cc: 'James Kempf'; Rajeev Koodli; [email-masked]
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

Hi Ajoy,

> Hi Ajoy,
>
> > Ajoy-> Target trigger will be suitable for cellular
> > networks.  BTW, even in case of WLAN, you can receive
> > L2-TT trigger at nAP. L2TT (Re-association Request) can
> > provide nAP the L2 address of the oldAP as well as L2
> > address of the mobile node. If we implement FA function
>
> Does re-association also apply to BSS mode, or when
> the station moves between two different ESS?
>
> If it is only used when the station moves from one AP
> to another in the same ESS, this is not as interesting,
> because the mobility is already handled at link-layer
> in 802.11b.
>
> Ajoy-> Mostly I have seen Re-association Request is sent
> whenever an MN moves from one AP to other AP in the same ESS.
> This is partly because IAPP handles intra-ESS handoff.

Exactly.... So, IAPP already takes care of the mobility, no need
for higher layer mobility management in that particular case.

> I believe this is an implementation issue and
> can be easily extended, if Mobile/IP provides appropriate hooks.

I wonder if the spec allows/enables use of re-association messages
in BSS mode.

And than, if client is already sending a re-association message, why not
use ESS and IAPP for this? Why would people need another protocol
that looks like IAPP on the same network..

Ajoy-> Typically (I think) the IP address of MN is topologically 
not correct after inter ESS handoff. This why Mobile/IP is 
required. BTW, this mobility should not be handled by IAPP. Hope
this helps. 

>
> > at AP, then this becomes an implementation issue.
> > If not, then you need to define some protocol between
> > AP and AR which can be addressed in separate document.
>
> http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt
>
> ...
>
> > Ajoy->IP layer protocol only works for Mobile Initiated trigger. It does
> > not work for network initiated trigger. BTW, based upon our
> > implementation, we found anticipated handover does not provide
> > good performance on cellular link. Hence, anticipated handover
> > is not going to address fast handoff need for various cellular networks.
>
> Ajoy, was that an FMIPv4 implementation, or FMIPv6 implementation?
>
> Ajoy-> We implemented FMIPv4. But I do not believe FMIPv6 implementation
> will provide substantially better performance. More or less the basic
> idea is same. I think the part of the problem is high RTT of 3G wireless
> link (MN to AR). So, adding lots of signaling messages over the high RTT
> link will require sufficiently higher anticipation time. If you keep
> very high anticipation time, handover may not be consistently
> reliable.
>

Generalizing "anticipated FMIPv4" results to "anticipated FMIP" and
then applying to "anticipated FMIPv6" without experimenting is not a
good idea. Protocols are sufficiently different to make considerable
performance differences.

Ajoy-> I think claiming something works without proper data and 
argument is also not a good idea. BTW, do you agree that due to higher
RTT of cellular link, FMIPv6 will require higher anticipation
time ? As you increase anticipation time, the likelihood
of handover failure will increase. I do not think this has 
anything to do with FMIPv6 or FMIPv4. You will observe
similar behavior in either case. 

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 25 Jul 2002 17:29:59 -0700

Hello Ajoy,

> time ? 

Yes of course.

> As you increase anticipation time, the likelihood
> of handover failure will increase. 

This statement by itself also make sense...

But, the question is how much difference does it make?
Experimentation can help answer this question, and this is 
why I was asking if your statements were based on 
FMIPv6 experiments...

Also, how much heads up can the mobile terminal or the network
get before the link is broken without any anticipation? 
I presume link down doesn't happen instantly, at least L2 has to 
exchange some messages. Is there a window
in which L3 can exchange packets?

> I do not think this has 

But there is more... A fundamental difference between
FMIPv6 and pre-reg FMIPv4 is that with the latter the
registration request has to go all the way to home agent.
This not only effects the latency, but also prevents taking
advantage of L2 triggers on the oFA/oAR to precisely
determine when the routing should change.. And this
should make a difference in the observed performance..

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 25 Jul 2002 18:37:30 -0700

Ajoy, Alper,

I have few questions for you.

1. How does the MN get the L2 address and IP address of the
     new AR ? I see the following possibilities
a) PrRtAdv provides this
b) upon establishing a new link, the MN does RS and gets an RA

How can you avoid PrRtAdv ? Can we assume that L2 trigger
provides the necessary information ? Which L2 trigger today
provides such information? Isn't this at best a recommendation
to future L2 designers ? In any case, can we specify that
the protocol operates based on this assumption on _all_ links ?

2. When does the previous AR actually start forwarding packets
    on the tunnel ? Should it do so even when it has not received a
    FBU ? I think use of L2 triggers to more precisely time
    forwarding is useful when the router has received FBU. Doing
    forwarding in the absence of FBU is redirecting traffic without
    proper authorization, and as we have seen inMIPv6 security
    exercise, involves security considerations. Can we say here that
    L2 trigger will have the necessary authorization to redirect
    traffic ? Even so, how can a base spec generalize it to all possible
    link layers ?

These are the crucial questions that determine the trade-off. I
would like to know what you and others think.

Regards,

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 25 Jul 2002 19:40:55 -0700

Hi Rajeev,

Let me make an attempt to answer your questions.

> How can you avoid PrRtAdv ?

Please see CARID in draft-gwon-mobileip-efwd-fmipv6-00.txt.
While MN is still connected to the oAR, it can request
a table that maps L2 id of access points to L2/L3 ids of
access routers. Than, after the movement MN learns
the L2 id of the AP, and performs a table lookup for AR
information.

The difference between PrRtAdv and CARID is that the
latter can happen any time before handover, not necessarily
right before handover or upon anticipation.

> Can we assume that L2 trigger
> provides the necessary information ?

Nope.

> Which L2 trigger today
> provides such information?

I'm not aware of any...

> Isn't this at best a recommendation
> to future L2 designers ?

I personally wouldn't recommend
providing this L3 information via L2 signaling.

> In any case, can we specify that
>     forwarding is useful when the router has received FBU.

I agree.

> Doing

IMO, we should stay in the boundaries of Mobile IP model
and only allow explicite BUs change routing state...
IP can receive help from L2 though, in the form of L2
suggesting a BU be sent, or L2 suggesting precise time
of routing change once AR/MN decided to do so.

alper

---

From: "Raymond Jayaraj" <[email-masked]>
Date: Fri, 26 Jul 2002 10:54:48 +0800

Just a 2 cents worth from ppl other than you guys discussing this

> the protocol operates based on this assumption on _all_ links ?

a) PrRtAdv is a L3 element. It should not be carried over L2 messaging.
b) L2 designers should not have to know what L3 is. 
c) Whenever a handoff involves L3, messaging should be done at L3.
d) We need L3 handoff messaging to carry L2 information.

Regards,
Raymond

---

From: Joseph Soma Reddy <[email-masked]>
Date: Thu, 25 Jul 2002 21:58:59 -0700 (PDT)

Hello all,
I would like to point out that mobility protocol should not
only ensure routing to mobile hosts, it should be able to
support macrodiversity(i.e. soft handoff) which is very
important in cdma systems. Macrodiversity is already being
incorporated in systems like HDR(High Data Rate system from
Qualcomm) where the mobile can move between different
cell sectors before receiving each packet. With a good
mobility scheme, it is possible to extend this and enable
the mobile to handoff quickly between BS, which can result
in coverage and capacity increase.

I have addressed this issue in a recent draft
("macrodiversity in IP based cellular networks"
available at http://cwc.ucsd.edu/~soma ).
The main conclusions were that the mobile should be able to
handoff as soon as channel conditions changes(i.e. post-reg
handoff) and that it should be possible to handoff without
requiring any over-the-air signalling.
I am concerned that the v5 draft provides for these
mechanisms only as error conditions.

Another concern I have with respect to anticipated handoffs
is that it seems to place requirements on the physical/link
layers with respect to how channel conditions change(i.e. it
assumes that they change gradually enough to be anticipated).
This is not necessarily true even in current systems. For
example, the so called "street corner effect" occurs in dense
urban areas where the base stations are mounted on poletops.
The coverage of these BS extends linearly(along a block) rather
than omnidirectionally. A mobile user who turns a street corner
in such an environment will lose line-of-sight with current BS
and enter line-of-sight of another BS. This causes a sudden handoff
which can only be handled by post-reg type of mobility.
These type of situations are common in micro-cellular
networks which will become more common in future
as increased demand for capacity is met by reducing cell
size.

Comments are appreciated.

Regards,
Joseph

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Jul 2002 10:49:19 -0700

Hello Joseph,

thanks for your input. I have some general comments first.
An IP-based protocol has to work on all link types, while
allowing individual links to customize the protocol for
improving performance. If the protocol is based on the
chatacteristics of a single link type, then the chances are the
protocol won't work at all or won't work the way it should
on all the link types.

Did you see my earlier posting in which I had asked few
questions ? Those questions directly relate to your comment
regarding over-the-air signaling. Specifically,

- how do you inform the new AR's L2 and IP address to the MN ?
- should we assume that L2 specific information is sufficient to
   redirect traffic without explicit authorization (in the form of FBU)
   from the MN ?

These are broader questions, and are not specific to a particular
link technology. I would be interested in hearing how your proposal
would address these two key questions. I would also appreciate if you
could take a look at my previous posting and respond to the questions
there.

Now, some comments below..

> in coverage and capacity increase.

Role of IP in dealing with macrodiversity is an interesting topic and
I am sure will spur lot of discussion. However, increasing capacity, or
more generally, the topic of macrodiversity itself is not an objective
of fast handover. If there is sufficient interest, I think this should
be
explored separately in the WG.

> mechanisms only as error conditions.

Well, if the AR does not change during such a handover,
there is not anything for the protocol to do. One could argue
that this is a matter of how you roll out the network.

The v05 version allows tunnel establishment subsequent
to the MN attaching to the new link. I don't know if you
have followed the previous versions of the draft or not, but
the reason for this is that the protocol begins on the old link
and the FBU is anticipated to be sent from the old link.
In any case, I have received comments that it would be better
to explain this under a separate section, and I will do that.

> assumes that they change gradually enough to be anticipated).

Actually, there is no such assumption. If the MN does not receive
PrRtAdv, it triggers tunnel establishment after attaching to the
new link. If PrRtAdv can be delivered to the MN on the previous
link, then, also providing the new router's prefix information
facilitates faster new IP address configuration (aka anticipation).
So, consider the following network-controlled handover scenario.

- the previous AR sends PrRtAdv to the MN providing
    - new AR's L2 address, IP address and network prefix info. Note:
        PrRtAdv is needed independent of "anticipation" in order to
       provide the new AR's L2 address and IP address.
- the MN moves and starts sending packets using previous CoA
    immediately. It also sends FNA to confirm if it can use a new CoA.
    [This FNA can be an option in a Router Solicitation which a MN
     needs anyway in order to obtain a Router Advertisement.]
- depending on when the FBU is received, the previous AR
   starts forwarding the packets to the MN. If the FBU is received
   on the old link itself, the packets will be delivered as soon as the
   new AR detects that MN is attached to it. If the FBU is received
   from the new link, they will start arriving from the previous AR.

So, in order for the protocol to work on all link types without
making specific assumptions about what _a_ link type "might be able
to provide", and more importantly, to keep following the principle
of specifying IP protocols for IETF standardization, we need to
specify PrRtAdv and FBU.  At the same time, the draft should be
able to allow L2-specific customizations.

> as increased demand for capacity is met by reducing cell

I agree that the protocol should support the case when the MN
simply attaches to a link without any forewarning. This is why the
draft allows sending FBU from the new link even when the MN has
not received a PrRtAdv, and the previous router should engage in
HI/HACK when it receives a FBU and it has not seen a PrRtSol or not
sent a PrRtAdv.
You might also observe that base Mobile IP draft recognized this
long ago (by allowing forwarding from previous CoA).

Thanks for your interest.

-Rajeev

ps. terms like "post-reg handover" "pre-reg handover" are not
used the fmipv6 draft. I think I know what you mean by them, but
I would rather stick to terms which have been used since v00.
The draft makes a distinction between protocol operations
"prior to" or "subsequent to" new link establishment.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Jul 2002 10:56:46 -0700

Hello Alper,

> right before handover or upon anticipation.

I agree that your proposal, after looking at the description
above, allows a MN to send packets on the new link when it
has not received PrRtAdv. I think others are also possible.
For instance, the MN can send a RS as soon as it detects a
new link and force the router to send an RA. There are
pros and cons associated with these mechanisms, of course.

However, the question I have is, can we NOT specify PrRtAdv ?
Seems to me that we need it for the base spec, and when additional
methods are available, the protocol can work well even when the MN
does not receive it. I am not sure if we can specify each of those
additional methods in the base spec..Do you agree ?

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 26 Jul 2002 18:10:02 -0700

Rajeev,

> pros and cons associated with these mechanisms, of course.

The advantage of CARID is that it saves one RTT on the new
link. Latency associated with this can be significant especially
in cellular networks.

> However, the question I have is, can we NOT specify PrRtAdv ?

I'm not suggesting removal of PrRtAdv.. No problems there...

> additional methods in the base spec..Do you agree ?

Adapting CARID section of draft-gwon-mobileip-efwd-fmipv6-00.txt
can be an option. This way, if MN cannot complete an anticipated
handover, it can fall back to using information provided in CARID
to create a tunnel between oAR and nAR after L2 handover,
and preserve its oCoA.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Jul 2002 19:17:43 -0700

> link. Latency associated with this can be significant especially

Ok.

> I'm not suggesting removal of PrRtAdv.. No problems there...

Ok.

> to create a tunnel between oAR and nAR after L2 handover,

The draft certainly does not disallow using methods like yours if they
are available.

-Rajeev

---

From: Joseph Soma Reddy <[email-masked]>
Date: Mon, 29 Jul 2002 12:13:04 -0700 (PDT)

I agree.

> could take a look at my previous posting and respond to the questions

Signalling on cellular link introduces high delay. So it may
be useful to do away with it in some situations. I proposed
one way in "microbility strategies in IPCN"(available at
http://cwc.ucsd.edu/~soma ). Other mechansims have been
suggested in recent mails.
Of course, there is no need to include these mechanisms in
the current draft.

> explored separately in the WG.

I am not suggesting that macrodiversity be included in this
draft. Rather, I was giving an example of a link layer
consideration that would influence the choice of
performing protocol operations "prior to" or "subsequent to"
handoff.
I think this choice will be dependent on particular L2
technology and there is no need for the current draft to
propose a preferred("prior to") mode and an error
condition("subsequent to").

> that this is a matter of how you roll out the network.

The AR does change during handoff. But that does not
necessarily mean there should be over-the-air signalling, as
explained above.

> .............

I have no problem with specifiing PrRtAdv. But, in order to
work or all link layers, the protocol should also be able to
operate without it, depending instead on L2-specific
customizations. I understand the draft allows that.

Regards,
Joseph

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 30 Jul 2002 16:11:59 -0700

I think we need to include the complete question here:

Does MN really get "L2 and IP address of the new AR"?
I see MN is aware of the L2 id of the Base Stations, but note
that this is not same as L2 id of AR(s) behind them.

alper

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>
Cc: "Singh Ajoy-ASINGH1" <[email-masked]>; "'Vijay Devarapalli'"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 30, 2002 1:58 PM
Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions

> I refer you to "Draft Standard for W-CDMA (Wideband Code Division Multiple
> Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS
> Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation",
Section
> 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", and
> Section 12.25.3.8, "Handoff Indication". This version is a little old but
> probably not very far off from the current W-CDMA specification.
>
> In Section 11.7, the procedures for mobile controlled and network
controlled
> handover are described. In the mobile controlled case, the mobile sends a
layer
> 2 identifier to the current base station indicating the target base
station to
> which the mobile wants to hand over, and gets back a response indicating
whether
> handover is allowed or denied. In the network controlled case, the current
base
> station sends the same information to the mobile. (Note: "layer 3" in this
> specification actually refers to what from the IP viewpoint would be the
MAC
> layer, or layer 2). The network controlled case is used to manage power
and cell
> load, the mobile controlled case is used when the power level on the
mobile goes
> below the specified handoff point.
>
> In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the IP
layer,
> what W-CDMA already does at the MAC layer. Also in either case, the layer
2
> information should be sufficient to allow the base station to perform a
layer 3
> handover without any over the air layer 3 signaling, provided the base
station
> has a way to map the target base station id to an IP address, using GAARD
or a
> preconfigured table.
>
> Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under
the NBAP
> and RNSAP RAN protocols.
>
> I don't have access to an IS-2000 specification at the moment, but I'm
working
> on getting the same information. Other wireless link layers must provide
this
> information in some form, either before handover, as with the cellular
> protocols, or afterwards, as with 802.11. Barring make before break,
without
> some information at layer 2 about where the mobile is going, it is simply
> impossible for the link to get switched, and, without a link, it is not
possible
> to do IP. If the layer 2 protocol supports real make before break (not
soft
> handover), none of the fast handover protocols are necessary, since the
mobile
> can do RS/RA on the forward link while receiving its traffic on the
backward
> one.
>
>             jak
>
> (fyi, Alper, the specification in question is in the DoCoMo library, if
you care
> to check it out.)