Subject: RE: [mobile-ip] New Draft on FMIPv6 over 802.11

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 2 Oct 2002 18:44:00 +0200

> > Again, tunnel _could_ be established using link-layer
  > > features. It is the forwarding on the tunnel that happens
  > > after FBU is received.
  > >
  > 
  > This is the problem. If the MN sends the FBU before it 
  > moves, traffic is sent to
  > the new AR and the MN either loses the packets or the new 
  > AR must buffer (which
  > is not good for real time traffic), exactly like FMIPv4 
  > Prereg. If the FBU is
  > interrupted by the link switch, the MN ends up waiting some 
  > period of time on
  > the new link without packets before resending. These cases 
  > are possible on
  > particular link types.

=> The problem above can be divided into 2 separate issues:

1. The BU might be lost.
2. Some traffic could be lost if the L2 handover
takes too long and packets are dropped at the new
AR. 

For 1) we have a combined mechanism in FMIPv4. In this 
mechanism (applied to v6) the AR would set a timer 
after sending the Pr_rtr_adv. If no BU was received
by the time it expires, the oAR can setup a tunnel
to the new AR or buffer for some period of time.
This approach will only work on a link where the 
oAR is aware that the MN is about to do a handover.
I.e. won't work for 802.11.

For 2), this can be solved by a combination of 
bicasting and buffering. draft-elmalki-... addresses
this issue, but does not look into the details
of buffering implementation. But this might be implementation
dependent anyway, because it's specific to the 
different L2 handover times.

  > Furthermore, how does the MN know that it is on a new link 
  > (which could be used
  > to optimize sending an FBU so as to avoid the two 
  > conditions above) _without_
  > using L2 information? If L2 information is unacceptable for 
  > starting packet
  > forwarding on the old AR, then why is it acceptable for 
  > signaling the MN to send
  > the FBU?
  > 
  > If we are to strictly run this protocol using L3 
  > information, then the MN must
  > wait for the RA beacon from the AR, and then the 
  > performance will be no better
  > or worse than movement detection.

=> I think the idea is that we have a generic
L3 mechanism that can be tweaked by the different
L2s' information. But this information can be included
in different drafts like Pete's draft for 802.11.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Oct 2002 10:30:25 -0700

> different L2 handover times.

What's the problem with using a link down trigger if it is available and secure,
on the old AR? With 802.11, of course, it isn't available.

            jak