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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 10 Aug 2005 13:55:03 -0500

Hi Syam,
I was addressing the point that James mentioned about losing the FBack. For instance, if the PAR sent the FBack to the MN, but the MN did not receive it, an option to retransmit the FBack to the MN via the NAR or something similar will be useful, rather than saying that the MN falls back to standard mip6. I agree it is simpler to say the latter, but if you are going for total simplicity, then maybe FMIP itself is not needed. 

Perhaps this can be made optional - nevertheless, I can see this being useful. Am I missing something? 

Vidya

> -----Original Message-----
> From: Syam Madanapalli [mailto:[email-masked]] 
> Sent: Wednesday, August 10, 2005 12:30 PM
> To: Narayanan Vidya-CVN065
> Cc: [email-masked]
> Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
> Mobility Header (FN A)
> 
> 
> Hi Vidya,
> 
> What type of failure cases you are talking about?
> 
> Pridiction failure or FBU failure?
> 
> If it is prediction failure DNA (if used) may help.
> If it is FBU failure due to packet loss, MIP6 BU 
> may also fail due to the same reason.  
> 
> -Syam
> 
> > James, Alex,
> > On this particular point, I'd like to add one more objective:
> > 
> > We need to ensure that the failure case in FMIP doesn't lead to a 
> > handoff time that is worse than regular MIP6. This was the biggest 
> > flaw of Mip4 low latency handoffs - it led to worse than 
> standard MIP 
> > handoff times when a message was lost. I think when someone deploys 
> > fast handoffs, they expect the handoff to be no worse than regular 
> > MIP, at the least - when dealing with degrading links, the 
> chances of 
> > losing a message are not that low - so, I think it will 
> help to ensure 
> > that the protocol accounts for this.
> > 
> 
> 
> 
> > Regards,
> > Vidya
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]] On 
> > > Behalf Of Petrescu Alexandru-AAP021
> > > Sent: Wednesday, August 10, 2005 11:19 AM
> > > To: James Kempf
> > > Cc: Junghoon Jee; [email-masked]; Koshiro MITSUYA; Petrescu
> > > Alexandru-AAP021; Soliman, Hesham
> > > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into
> > > Mobility Header (FNA)
> > >
> > >
> > > James Kempf wrote:
> > > > FMIP is an optimization, it isn't required. If the FBack is
> > > lost, the
> > > > MN can simply fall back to standard MIP6 handover. I think it 
> > > > makes more sense to simplify the protocol if we can.
> > >
> > > Let me follow up on this particular issue ("simplify the 
> > > protocol...").
> > >
> > > In one sense - yes, I believe it should be simplified, at 
> least in 
> > > order to be easier to grasp by a programmer.
> > >
> > > Paradoxically, the strange thing about it is that the protocol as 
> > > described depends on at least three other potential 
> protocols that 
> > > are not described anywhere:
> > >
> > > -how do the ARs learn about each other's AR-Info.
> > > -how do the ARs learn their APs' "AP-ID"s, when AP and AR are 
> > > disjoint. -what's "assigned addressing" that NAR uses to assign 
> > > addresses.
> > >
> > > Also, the protocol relies a lot on variable-length link-layer 
> > > addresses.  That's ok but it means it won't work with 0-length 
> > > link-layer addresses, like point-to-point ppp and 
> successors.  Which 
> > > is fine, but should probably be noted somewhere.
> > >
> > > 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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 13:12:01 -0700

> I was addressing the point that James mentioned about losing the FBack.
For instance, if the PAR sent the FBack to the MN, but the MN did not
receive it, an option to retransmit the FBack to the MN via the NAR or
something similar will be useful, rather than saying that the MN falls back
to standard mip6. I agree it is simpler to say the latter, but if you are
going for total simplicity, then maybe FMIP itself is not needed.

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

            jak