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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 22:14:01 +0100

James, 

there are some interesting points below that 
deserve further discussions. See my comments below.

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

=> Hmm, my turn to rant now :). Ultimately I think that
this is how handover should work:

- ARs are used only for anticipation (just bear with me, your option
will be included below) 
- BUs are sent to the MAP. 
- If you need HI/HACK for address dulpication, you can send them
from the MAP (see HMIPv6 appendix). However, I really think
that optimistic DAD or something similar will make things
so much simpler. I tried to convince the DT to use optimistic
DAD and it was in the 00 draft but it's gone now. 

Now, if you want the two ARs to setup a tunnel without involving
the MN, you can also do that. Whenever the MN detects that it 
moved, it will update the MAP. 

In both alternatives, a single BU will do the job, so the 
answer to your question is that we don't need to double
the no of BUs. 

The advantage of this mechanism is that:
1. It is access independent. It doesn't matter if the 
handover knwoledge is in the AR or the MN, the same result
will be achieved.
2. We get the best of both worlds: FMIPv6 minimises movement
detection time (or eliminates it) and HMIPv6 eliminates additional
signalling, provides location privacy ...etc. Furthermore, if 
you go with the first alternative (MN sending a BU) you will
actually avoid having packets arriving out of order which
is a good thing.

3. In either alternative, security is solved because the
SA is between the MN and MAP and doesn't need to be re-established.
CT of SAs is highly controversial IMHO.

Smoothing techniques can reduce or eliminate packet losses
in either alternative.

  > 
  > > 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.
  > 
  > The issue here is security.

=> Sure, but it won't help to remove the BU
and rely on L2 triggers. 

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

=> And we implement X mobility protocols ? where X = no of link layers?
What we have in the FMIPv6 draft essentially does 
this without the need of multiple protocols.

  > > => A couple of comments on this (we can also discuss this later):
  > > 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.

=> I think link layers provide information, but the problem
we have is that not all vendors pass this info. If 
we make the case in IEEE and get them to follow an IETF-defined
API then we would be doing everyone a great favour. 
I think we have a window of opportunity that we should use. 
Why not compare this with the sockets API for example? 
Imagine what would happen if every application required
a different stack beneath it, or even a different interface
to the IP stack, that wouldn't have been a good idea. In 
fact the sockets API is also an IEEE standard.

  > > 2. It does not allow for the AP - AR separation like in
  > > 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.

=> APs are considered L2 devices because they are not 
visible to the host's IP stack. As far as forwarding packets
is concerned they forward based on MAC addresses not IP addresses. 
If they were visible to IP and forwarded based on IP addresses
then we would call them routers.

Perhaps we should reverse the question and ask why
APs are trying to do authentication ? Please don't answer 
that we suffered enough in PANA :) 

Hesham

---

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

> Smoothing techniques can reduce or eliminate packet losses

The architectural issue with this is the same as I've had for the last two
years: latency and congestion in the AR to MAP connection. If I want to deploy a
MAP to cover all of France for good location privacy, then it may add an
addition 20-60 ms onto the handover, and maybe that squared to the jitter around
handover. By handling the handover locally and in a distributed fashion, this
can be reduced to zero, even for anticipated/prereg, if the prehandover
signaling is not interrupted.

20-60 ms may not sound like a lot, especially when compared to 80-300 ms
currently for Layer 2 handover in 802.11, but for voice traffic, the handover
time must be below 60 ms for "carrier quality" and below 40 ms for superior
performance. It may be too ambitious at this point, and, yes, it is  research
topic, but I'm interested in replacing circuit-switched ATM voice with VoIP. I'd
like the handover architecture to support that goal, even if the current
implementations of Layer 2 don't.

With regard to smoothing, bicasting may work, but I've yet to see a definitive
study that it won't cause problems with TCP traffic, though there have been lots
of arguments here for and against. Buffering for smoothing really doesn't work
well for real time traffic, since if the latency becomes too large, "ringing"
occurs.

> => Sure, but it won't help to remove the BU

It will if you replace the BU by an RS to new AR with old CoA and old AR IP
address, then have new AR signal the tunnel. ND security can be used on the
RS/RA, no need for a new SA for the BU. The MN has to get auth'ed on the new AP
anyway prior to or just after Layer 2 association, probably by some Layer 2
mechanism but possibly by PANA or Seamoby/IAPP CT of auth info.

> this without the need of multiple protocols.

Not multiple protocols, "FMIPv6 over 802.11", "FMIPv6 over wCDMA", etc. Like
"IPv6 over FibreChannel". Except the base draft doesn't try to make a single,
unified protocol that runs on all link layers, but rather provides a toolkit
that can be applied to particular link layers.

Of course, if we are only concerned with an optimization of movement detection
that is "better" in some sense, then having a unified protocol that can't be
optimized for a particular link layers isn't a problem. I just don't think that
this will meet a VoIP performance goal.

> fact the sockets API is also an IEEE standard.

APIs, in general, are hard to standarize because vendors use them to strategic
advantage. Protocols are easy, because customers demand interoperability and
won't buy products that don't exhibit it. An API that works on Vendor L's OS is
not likely to be of interest to Vendor M, though the wire protocol will allow
the two to talk.

As for working with IEEE, I think this would be an excellent idea, we should try
to figure out how do to do this. Perhaps we could do a BAR BOF in Atlanta on it,
or maybe even get the WG chairs to put it on the agenda. :-)

> then we would call them routers.

They are visible through handover (IAPP) and through AAA.

The AP is a network element that performs certain functional tasks, including
handover and AAA.

The