Subject: [mobile-ip] RE: Mobile IP Fast Handover Architecture

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 18:10:29 +0100

> > Now in the absence of anticipation, I don't see a
  > > point of doing fast handovers in 802.11. If we're going
  > > to wait until the MN moves to a new link then just use
  > > HMIPv6 and the performance will be exactly the same, if not
  > > better than updating oAR.
  > > So I can't (and I'm trying) see the point of removing
  > > anticipation and calling it a "Fast handover".
  > >
  > 
  > Some operators may want to use HMIPv6 for location privacy, 
  > in fact, that's the
  > way I advocate its use. If you use HMIPv6 primarily for 
  > location privacy, it
  > argues for having the MAP as close to the border router as 
  > possible, so that you
  > get maximum coverage of topology/geography, consistent with 
  > good scalability and
  > performance.

=> You seem to assume that only one MAP can exist in an
operator's domain. I see nothing in the draft that gives
that impression. If you do, please let us know and we can
make this clearer. 

If I were advising an operator I would tell them to
have more than one MAP in a single "LMM area" so that
they would have overalapping coverage. This is good
for many reasons outlined in the draft, like load balancing
and redundancy.

  > I don't see putting a MAP in every subnet, the architecture 
  > you seem to be
  > advocating, 

=> I never advocated that, I said that the distance between
NAR and the MAP, can very well be the same as the distance
between NAR and PAR. Notwithstanding that, you seem to assume
that having a MAP in the AR is more costly than having
FMIPv6. I can't see how that is possible. A MAP is essentially
a HA with much less complexity than what an FMIPv6 AR has.

as a cost effective, viable option, because it 
  > requires an extra box
  > in every subnet in addition to the access router. 

=> Why ?? Are you saying a HA can't be an AR?

I also 
  > don't agree that HMIPv6
  > should be built into the routers, because that would 
  > effectively turn MIPv6 into
  > MIPv4, since the MAP/AR would effectively be acting as an 
  > FA. That option would
  > also provide zero location privacy benefit, and no 
  > performance benefit, since
  > the MN would have to perform a change of RCoA on every 
  > subnet move. I see FMIP
  > as providing fast handover, and HMIP as providing location 
  > privacy, with some
  > minor performance benefit.

=> I don't understand this at all. To me MAP = HA = router that receives BUs.

  > 
  > The architectural advantage of HMIPv6 comes primarily from 
  > the ability to cover
  > a broad topological/geographic area, and thus mask the 
  > exact location of the
  > mobile node, in the absence of any radical change in the 
  > routing algorithms,
  > similar to the way RFC 3041 allows a host to mask its 
  > identity. 

=> Agreed that this is one of the benefits.

HMIP is not the
  > ideal solution for location privacy, but it works with 
  > existing routers.

=> ok.

  > 
  > Well, in fact, they are, so we clearly disagree. We have 
  > tunnel based handover
  > working here. There are two types of tunnels, one initiated 
  > by the mobile node
  > and one initiated by the access router or access point. 
  > Tunnels allow the mobile
  > node to obtain its traffic while RO is happening.

=> How does the oAR know when to setup the tunnel? 
I assume you do it without anticipation, hence my 
statement. So we only disagree about terminology I think.

  > 
  > How do you expect the traffic to get to the MN while the BU 
  > to HA and RR/BU to
  > CNs is occuring?

=> You anchor the traffic in the oAR or a MAP as we
all know. If there is no anticipation, then to me
there is zero point in anchoring the traffic in the 
oAR. The MAP is probably just as close.

I will answer the rest in a separate mail because I
think the above shows a more fundamental misunderstanding 
from one of us. 

Hesham

  > Having 802.11 scanning be host controllable, which is what 
  > the driver for the
  > Orinoco card you pointed me to does, still won't give you 
  > much. The scanning
  > must be done regardless of whether anticipated signaling is 
  > happening or not. So
  > instead of bunding the scanning and handover together in 
  > the firmware, the
  > sequence will look like this;
  > 
  >     Layer            Operation                       
  > Approximate Time
  >     -----             -----------                      
  > -------------------
  > 
  >    802.11           Scan                            80-300 
  > ms gap in host IP
  > service
  > 
  >     IP                 Perform Prereg/
  >                         anticipated signaling       
  > variable depending on the
  > traffic load, but typically 80-200 ms, possible
  >                                                             
  >  gap in IP service
  > if host forced to backoff.
  > 
  >    802.11          Reassociation                Probably 
  > less than 20 ms gap in
  > host IP service
  > 
  > If the scanning and reassociation are done together, then 
  > the sequence looks
  > like this:
  > 
  >     Layer            Operation                       
  > Approximate Time
  >     -----             -----------                      
  > -------------------
  > 
  >    802.11           Scan                            80-300 
  > ms gap in host IP
  > service
  > 
  >    802.11          Reassociation                Probably 
  > less than 20 ms gap in
  > host IP service
  > 
  >     IP                 Posthandover                10-20 ms
  >                          Tunnel initiation
  > 
  > The net effect is that the user traffic would probably be 
  > interrupted less with
  > post handover tunnel initiation, because there is less signaling.
  > 
  > If 802.1x is used and the prehandover signaling results in 
  > a tunnel being set
  > up, there is more of a benefit because 802.1x can delay 
  > re-establishing IP
  > service on the new access point considerably.
  > 
  >                     jak
  >

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Nov 2002 11:36:19 -0800

> for many reasons outlined in the draft, like load balancing

I agree that multiple MAPs are needed, also for purposes of redundancy. But I
see them primarily deployed further out, potentially on border routers, or, at
least, as close to border routers as possible. By deploying them there, it is
possible to break the topology to geography mapping over a wider area.

> a HA with much less complexity than what an FMIPv6 AR has.

It is more costly in terms of handover. If you must do a MAP handover every time
you do a FIMP handover, you have two additional messages (plus or minus RR
signaling), plus messages to HA, CNs, etc. I think we want to minimize the
amount of MAP handover.

> => Why ?? Are you saying a HA can't be an AR?

It is certainly possible for an HA to be an AR, it is just not clear to me at
this point that it is viable from a cost perspective.

Like wireless access points, there will be a lot of ARs, so it makes sense from
a cost perspective to have them be lower cost. An HA, on the other hand, must be
redundant and high reliability because it is a single point of failure, thus
more expensive. I think it makes a certain amount of sense to have HAs
specialized. In addition, I can see some operators offering MIP service without
actually having any wireless access points. So from a vendor standpoint also, it
makes sense to keep the two separate to address that market.

> => I don't understand this at all. To me MAP = HA = router that receives BUs.

This is where we disagree. I don't see an AR needing to process BUs. See
draft-kempf-mobileip-fmipv6-sem-00.txt for how I think this should work. BUs
should be sent to HAs and CNs. ARs should use routing mechanisms (including the
local link access mechanisms in RFC 2461 and the security therefore) to
commuicate with hosts.

> statement. So we only disagree about terminology I think.

Currently, one of two ways:

- nAR gets a link up trigger and initiates HI/HAck for target triggered handover
with oAR.
- MN sends F-BU to oAR, oAR conducts HI/HAck with nAR if it hasn't already,
starting tunnel.

There are some problems with the second way which
draft-kempf-mobileip-fmipv6-sem-00.txt addresses.

> think the above shows a more fundamental misunderstanding

OK.

            jak