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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 10 Aug 2005 17:23:16 -0500

> 
> Sounds like you are talking about predictive handover, right? 
> The PAR sends the FBack to both the old and the new link, and 
> if the MN has moved already, the NAR buffers until the MN 
> arrives, then the FBack is the very first packet the MN gets 
> when it comes up on the new link (the packet on the old link 
> is dropped after a time) .
> 

Yes, that is exactly what I am talking about. 

> If the FBack is dropped over the air on the new link, there 
> is very little point in having the MN redo the FBU, because 
> by that time, the MIP handover should be well underway.
> 

Agreed. I think this is less of an issue as well, since the new link is usually more stable (since the MN just handed off to it) than an old link at a time when the MN is about to handoff. 

Vidya

>             jak
> 
> ----- Original Message -----
> From: "Narayanan Vidya-CVN065" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; "'Syam 
> Madanapalli'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 10, 2005 2:01 PM
> Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into 
> Mobility Header (FN
> A)
> 
> 
> > >
> > > The NAR doesn't really know about the FBU, only the PAR 
> does. So I 
> > > don't see how it could retransmit the FBack. Besides, 
> loss rates on 
> > > wired backbones are typically a couple orders of 
> magnitude less than 
> > > on wireless links, even taking congestion into account 
> (yes, I know 
> > > some backbones are wireless too but they are typically point to 
> > > point microwave links that can be managed like wired links).
> > >
> >
> > True. I was thinking of a case where the PAR sends the 
> FBack to the MN
> both directly and via the NAR - the NAR may optionally decide 
> to cache and re-send it to the MN, once it attaches to it. If 
> this is not done, what happens when the MN moves to the NAR 
> and didn't receive the FBack? Does it now just fall back to 
> regular mip6?
> >
> > Vidya
> >
> 
> 

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 10 Aug 2005 19:14:52 -0400

> True. I was thinking of a case where the PAR sends the FBack 
 > to the MN both directly and via the NAR - the NAR may 
 > optionally decide to cache and re-send it to the MN, once it 
 > attaches to it. If this is not done, what happens when the 
 > MN moves to the NAR and didn't receive the FBack? Does it 
 > now just fall back to regular mip6? 

=> I think it's a non-issue. On some level, what's important is
that the PAR received the BU. The fact that the BA was lost
has zero impact on service disruption, although the MN might
think it's a problem. I'd simply suggest using MIP6 always 
as a back up.

Hesham

 > Vidya

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

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 11 Aug 2005 11:30:56 -0500

Well, the fact that the MN thinks it is a problem might be a problem :) I don't think the protocol should mandate a retransmission, but I think it will be nice to have a means by which the MN, say in the FNA, for e.g., sets a flag or something to let the NAR know that it hasn't received the FBack from the PAR and if the NAR has it, it can re-send it. Again - a MAY not a MUST. 

Vidya

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]] 
> Sent: Wednesday, August 10, 2005 6:15 PM
> To: Narayanan Vidya-CVN065; James Kempf; Syam Madanapalli
> Cc: [email-masked]
> Mobility Header (FN A)
> => I think it's a non-issue. On some level, what's important 
> is that the PAR received the BU. The fact that the BA was 
> lost has zero impact on service disruption, although the MN 
> might think it's a problem. I'd simply suggest using MIP6 always 
> as a back up.
> 
> Hesham
> 
>  > 
>  > Vidya
>  > 
> 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.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 11 Aug 2005 12:45:07 -0400

> Well, the fact that the MN thinks it is a problem might be a 
 > problem :) I don't think the protocol should mandate a 
 > retransmission, but I think it will be nice to have a means 
 > by which the MN, say in the FNA, for e.g., sets a flag or 
 > something to let the NAR know that it hasn't received the 
 > FBack from the PAR and if the NAR has it, it can re-send it. 
 > Again - a MAY not a MUST. 

=> But I don't see where the problem is to begin with? 
If service was not disrupted (because the BU was processed
by the PAR) then there is no impact on performance and the 
goal was achieved. If the MN already relies on MIP6 for global
updates then it's a default fallback. If it doesn't normally
update the HA immediately (e.g. it keeps anchor chaining for 
a while) then it has to retransmit. 

Making the NAR aware of this requires special filtering and 
special buffer management (selective discards of packets ...etc), 
which is not necessary. Generally speaking, making a node in the 
middle aware of e2e transactions between other nodes adds complexity, 
which, in this case, doesn't seem to add a benefit.

Hesham

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 11 Aug 2005 11:53:00 -0500

> goal was achieved. If the MN already relies on MIP6 for 
> global updates then it's a default fallback. If it doesn't 
> normally update the HA immediately (e.g. it keeps anchor chaining for 

What happens when the MN transmits packets - if it needs to reverse tunnel to the PAR, do we not have an issue? 

May be there is no issue here - in which case, this is fine. 

Vidya

>  > > To: Narayanan Vidya-CVN065; James Kempf; Syam 
> Madanapalli  > > Cc: [email-masked]  > > Subject: RE: 
> [Mipshop] FMIPv6 - Encapsulating FBU into 
>  > > Mobility Header (FN A)
>  > > 
>  > > 
>  > > 
>  > >