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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 21:09:24 +0100

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

=> Ok but this is coming down to operator taste/preference. 
There is nothing in the draft that hints at using this
as a general case. You are optimising it for location privacy
purposes, others might optimise its location for different uses
like handovers. Also, it comes down to how large is the 
coverage area of each AR (geographically). In some cases
the MAP can be one hop away from an AR, yet gives enough
location privacy.

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

=> MAP handovers take exactly the same amount of signalling
as FMIP, as far as changing the routing is concerned. 
In your example above, you will have to do the same thing
whether a  "FMIPv6 AR" or MAP is in the AR. Note that
I'm not advocating this particular use of a MAP, but I
don't see any additional work. In fact based on our 
implementation experience with FMIPv6 so far (not an
easy task), I think a simple HA at the AR (like the 
way early drafts of MIPv6 suggested) is much simpler 
than the current proposals. Seriously, I'm involved 
in implementing FMIPv6 now and I can confidently say
it's a nightmare with all the options we have/HI/HACK
options ...etc  can't see how this is simpler.

  > 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 think we associate different things with the term
"HA". An HA is a router, it receives BUs and forms
tunnels. Like all other routers, it can be small or 
large, you can make it redundant or not...etc

  > 
  > This is where we disagree. I don't see an AR needing to 
  > process BUs. 

=> I'll read your draft, but this is how
it works today. In fact (we can discuss this in Atlanta
off line) I think that it is not possible to have an
access independent mobility management protocol that 
does not involve the MN.

  > Currently, one of two ways:
  > 
  > - nAR gets a link up trigger and initiates HI/HAck for 
  > target triggered handover
  > with oAR.

=> A couple of comments on this (we can also discuss this later):
1. It's too late when the NAR gets this info.
2. It does not allow for the AP - AR separation like in 
pretty much all WLAN deployments. 
3. It is not technology independent (see 2). 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Nov 2002 12:45:54 -0800

> don't see any additional work.

Do you mean that a MAP handover without FMIP requires as much signaling as FMIP?
Because if they are used together, there will be twice as much signaling.

> In fact based on our
> than the current proposals.

The issue here is security.

> Seriously, I'm involved

It's complex because there are two basic philosophical approaches in FMIP that
have been merged. One or the other alone would be simpler. If one doesn't insist
on trying to cover all cases with a link independent optimization and rather
views each case as a particular way to optimize on a particular link type, it
becomes much simpler. The Layer 2 trigger profile of a particular link layer
determines which particular technique is appropriate for that link layer. I've
been arguing this as the way to do FMIP for a while.

The issues I have with HMIP are primarily deployment/scalability issues. With
extended mode removed, it is now much simpler, but it is unclear to me whether
it will scale. The simulations you spoke about would help clarify this.

> 1. It's too late when the NAR gets this info.

In general, sure. But if the link layer doesn't provide you with anything else,
then you have to work with what you've got. That's why I've always been
skeptical about the need for an FMIP definition that is divorced entirely from
how the link layer works.

> pretty much all WLAN deployments.

If the MN initiates the tunnel, then there is no problem.

Alternatively, the IETF  could stop insisting that APs are wireless bridges and
start admitting that they perform many IP functions (NAS, handover, etc.) which
could profitably be defined in a way common to many links. Why people insist on
calling IAPP a Layer 2 protocol when it clearly runs over IP and is clearly
involved in doing functions that would be common to many different wireless
links is beyond me. The AP is a big architectural hole in the IETF at the
moment, which the wired types don't understand and the wireless types don't have
enough critical mass to forcefully argue the need for some attention.

> 3. It is not technology independent (see 2).

See my rant about APs above.

                jak