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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 8 Nov 2002 20:16:23 +0100

> The problem is the following. I can think of an alternate 
  > way to optimize
  > handover, namely use FMIPv6. 

=> This is statement, I gave you an analysis of 2 different
ways of combining FMIP with HMIP. It's difficult to understand
your point of view if you state it like a fact, it's far from 
a fact IMO.

  > I can't think of an alternate way to achieve location 
  > privacy without modifying
  > some or all the routers in the local routing domain, and 
  > some network operators
  > may not want to use special routers. Since there are 
  > already IPv6 routers
  > deployed (though not many), I tend to trade the 
  > optimization aspects of HMIPv6
  > away because I view the location privacy aspects as more valuable.

=> I'm not at all disputing that. I'm just saying that
you might want to make this tradeoff but there is 
no need to generalise. Different operators have different
needs. HMIPv6 allows for these different need by allowing
them to flexibly locate the MAP.

  > > http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html
  > >
  > > 
  > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eif
  > el-alg-06.txt
  > >
  > > 
  > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eif
  > el-response-01.txt
  > >
  > 
  > I'll check them out. I'm interested in actual measurments.

=> Then read the first one. There are several more papers
that you can get if you contact the author.

  > What is the return address of the BU if the MN doesn't have 
  > a new CoA because,
  > like 802.11, it was not able to do prehandover signaling or 
  > the prehandover
  > signaling gets cut off? 

=> If anticipation fails in a wLAN then you just have to
revert to standard MIPv6.

  > >   > APIs, in general, are hard to standarize because vendors
  > >   > use them to strategic
  > >   > advantage.
  > >
  > > => We seem to be doing well enough with the sockets API.
  > >
  > 
  > The standard is being written, we will see whether the 
  > vendors implement it as
  > written. Are there plans to do code portability tests, to 
  > make sure that every
  > vendor's implementation follows the API? That is what helps enforce
  > interoperability among wire protocols.

=> You mean there is an L2 API being written now?
We don't test the sockets API and people are not obliged
to implement it, but they do because they want apps 
to work on their OSs.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 11:41:16 -0800

> your point of view if you state it like a fact, it's far from

I'm just saying what my point of view is. The way I see FMIPv6 being used is
like it is in the draft. Draft 5 does a pretty good job of combining anticipated
and tunneled, now we just need to work out how it works when there is no
prehandover signaling. I would rather not confuse the issue by bringing LMM into
the picture.

So, basically, we disagree about the need for LMM to achive fast, smooth
handover.

> them to flexibly locate the MAP.

Sure, I'm aware of that. Nothing in the current FMIP draft prohibits anyone from
deploying a MAP whereever they want.

> revert to standard MIPv6.

Well, we have a basic disagreement about the utility of anticipation for 802.11.

            jak