Subject: RE: [mobile-ip] some comments on the FMIP draft

From: Alper Yegin <[email-masked]>
Date: Mon, 7 May 2001 20:03:31 -0700 (PDT)

...

> > > 5) Is the FBU/FBACK really a different kind of BU?
> > >    It looks the same as a normal BU. That would 
> > >    actually be rather nice if it were the same
> > >    since we're probably need to consider the
> > >    security aspects of them, and it would be nice
> > >    to have exactly one kind of BU to modify if
> > >    necessary. Same goes for HMIP as well.
> > > 
> > 	=> It would be the same from a security 
> > 	poin of view. I don't see why not. Same 
> > 	for HMIPv6. The F-BU will include the 
> > 	M flag to ensire coexistence with HMIPv6.
> > 
> > 	The reason for having a different type is 
> > 	the HI/HACK messages. We need to know 
> > 	if the BU should trigger HI/HACK or not.
> > 
> 	[MJ]  Hesham, this point is not clear. I don't think that as the
> draft stands today there is no scenario described where Bu is triggering
> HI/HACK? or may be I have missed some subtle issues. I will appreciate your
> response.

Regular BU changes the routing as soon as it's received. But F-BU cannot change 
routing by itself. The receiving newAR also needs to wait for a successful HACK. 
And on top of this, if the L2 supports, newAR might even wait for "MN detached" 
signal from its L2 to start tunneling packets to newCoA.

Therefore F-BU is really different than BU.

alper

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 May 2001 07:47:49 -0700 (PDT)

> signal from its L2 to start tunneling packets to newCoA.

   I thought the scenario was:

   MN          ARold        ARnew

   RS------------>
                  HI---------->
                  <--------HACK 
   <------------RA
   BU------------>
   <--------BU_ACK

   Ie, MN knows everything it needs to know once
   it gets the RA and ARnew is ready.

 > Therefore F-BU is really different than BU.

   Even with the above said, I don't see why this
   requires that F-BU be a different BU
   though. Why couldn't there just be a flag in
   the BU which explicitly controls this behavior?

	  Mike