Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 Aug 2005 12:02:44 -0400

> I think, atleast to notify NAR about MN arrival, so that
 > NAR can forward the buffered packets, we need
 > some message(FNA). This may be done by some
 > other means like L2 trigger at NAR, if available.

=> This was discussed for a very long time late 2003. 
You can do that by sending a standard NA. It works fine 
according to 2461 and 2461bis.

Hesham

 > 
 > Thanks & Regards,
 > Subba Reddy
 > 
 > >
 > >             jak
 > >
 > > ----- Original Message -----
 > > From: "Subba Reddy" <[email-masked]>
 > > To: "Junghoon Jee" <[email-masked]>; "'Koshiro MITSUYA'"
 > > <[email-masked]>; "'Alexandru Petrescu'"
 > > <[email-masked]>
 > > Cc: <[email-masked]>
 > > Sent: Tuesday, August 09, 2005 6:36 AM
 > > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
 > Mobility Header
 > (FNA)
 > >
 > >
 > > > Hi Junghoon,
 > > >
 > > >
 > > > > What about using FBU solely without FNA ?
 > > >
 > > > If MN has sent FBU in PAR's link, and if it has not 
 > received FBack,
 > > > there can be two possibilities
 > > >
 > > > 1. Tunnel is not established between PCoA and NCoA, 
 > because FBU itself
 > > might
 > > > be lost.
 > > > 2. All the message exchange happened successfully 
 > (FBU,HI,HAck), but by
 > > the
 > > > time PAR sends
 > > > FBack MN might have moved to NAR.
 > > >
 > > > In the second case, if MN sends FNA, MN can receive the packets
 > > immediately.
 > > > Since MN don't
 > > > know whether message processing is successful or not, it 
 > will send
 > > FNA[FBU].
 > > > So this will cover
 > > > both the cases.
 > > >
 > > > If we send only FBU, NAR don't know, when to forward the packets.
 > > >
 > > > Thanks & Regards,
 > > > Subba Reddy
 > > >
 > > > > Some implication from the FMIPv4 draft, "Adapting 
 > Mobile IPv6 Fast
 > > > Handovers
 > > > > for IPv4".
 > > > >
 > > > > Regards,
 > > > > Junghoon
 > > > >
 > > > > > -----Original Message-----
 > > > > > From: [email-masked]
 > > > > > [mailto:[email-masked]] On Behalf Of 
 > Koshiro MITSUYA
 > > > > > Sent: Tuesday, August 09, 2005 10:02 PM
 > > > > > To: Alexandru Petrescu
 > > > > > Cc: [email-masked]; Koshiro MITSUYA
 > > > > > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into
 > > > > > Mobility Header (FNA)
 > > > > >
 > > > > >
 > > > > > Hello,
 > > > > >
 > > > > > I came up against the same situation during 
 > implementing FMIPv6.
 > > > > > All current MIPv6 implementations don't accept the 
 > encapsulated FBU.
 > > > > >
 > > > > > Changing 3775 may work because the last header is still MH.
 > > > > > And sending FBU and FNA separately works fine on my 
 > implementation.
 > > > > >
 > > > > > I personally prefer to send it separately, because it's more
 > > > > > easy to implement, we don't need to modify 3775.
 > > > > >
 > > > > > regards,
 > > > > > Koshiro
 > > > > >
 > > > > >
 > > > > >
 > > > > > On 2005/08/09, at 21:22, Alexandru Petrescu wrote:
 > > > > >
 > > > > > > Hello,
 > > > > > >
 > > > > > > I am not sure whether this issue has been already raised,
 > > > > > sorry if so.
 > > > > > >
 > > > > > > Encapsulating FBU into an FNA may not be a very good idea.
 > > > > > FNA is an
 > > > > > > option in the Mobility Header, whose 3775-specified Payload
 > > > > > Proto is
 > > > > > > IPPROTO_NONE.  That means it can't encapsulate anything.
 > > > > > >
 > > > > > > It is true that 3775 says "Payload Proto [...] intended to
 > > > > > be used by
 > > > > > > a future extension" but only to further refer to a 
 > non-existent
 > > > > > > Appendix B.1.
 > > > > > >
 > > > > > > Any thoughts?
 > > > > > >
 > > > > > > Alex
 > > > > > >
 > > > > > >
 > > > > > > _______________________________________________
 > > > > > > Mipshop mailing list
 > > > > > > [email-masked]
 > > > > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > > > > >
 > > > > >
 > > > > >
 > > > > > _______________________________________________
 > > > > > Mipshop mailing list
 > > > > > [email-masked]
 > > > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > > >
 > > > >
 > > > > _______________________________________________
 > > > > Mipshop mailing list
 > > > > [email-masked]
 > > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > > > >
 > > > >
 > > >
 > > >
 > > > _______________________________________________
 > > > Mipshop mailing list
 > > > [email-masked]
 > > > https://www1.ietf.org/mailman/listinfo/mipshop
 > >
 > >
 > >
 > >
 > 
 > 
 > _______________________________________________
 > Mipshop mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mipshop
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Greg Daley <[email-masked]>
Date: Wed, 10 Aug 2005 12:03:17 +1000

Hi Hesham,

> according to 2461 and 2461bis.

I'd guess that creation of any valid neighbour cache
entry on the router could work for this purpose.
As soon as the NCE is created, forwarding would occur.
So even an NS would do the job.

This should even be applicable if the cache policy was
modified through FMIPv6 signalling previously.

Greg

---

From: Subba Reddy <[email-masked]>
Date: Wed, 10 Aug 2005 09:05:06 +0530

Hi Hesham,

---->True. As I mentioned in the reply to Jak's mail, NAR may need to 
verify buffering database (buffered packets list) for each NA. NAR
needs to stop proxying for NCoA.

Thanks & Regards,
Subba Reddy