Subject: [mobile-ip] Fast Handovers in MIPv6 - flags

From: Jørn Hunskaar <[email-masked]>
Date: Tue, 6 Mar 2001 08:07:24 +0100

Hi,

Fast Handovers for MIPv6 (draft-ietf-mobileip-fast-mipv6-00.txt)
suggests that the Binding Update Option should be changed by adding two
more flags, B and U, to the flag bits. The intention is to indicate that
the mobile node would like the (old) access router to do bicasting and
buffering. The draft also specifies that the access router MAY honor
these requests or reject them silently.

When a BU is sent to the oldAR, the traffic will be redirected to the MN
by the way of the newAR. Since a fast handover procedure has been
initiated (either through a RtSolPr or PrRtAdv message), the MN would
like the handover to be fast and with a small packet loss. Consequently,
both the B and U bit will probably be set by the MN to improve the
handover quality.

In other words, the MN will set the bits to make the handover as fast as
possible. If these requests are silently ignored by the oldAR (when the
MN is a part of a fast handover procedure), this is most likely due to
link-layer conditions or because of insufficient resources.

Why use these bits in the Binding Update Option when they probably will
be set all the time anyway? Maybe supporting bicasting and buffering
should be made mandatory in the oldAR when using fast handovers?

Regards,
Jorn

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Fri, 9 Mar 2001 17:15:44 -0500

I have a slightly different question related to the B and U flag bits in BU
option. I will appreciate if the design team can provide a rationale for
that. See my question below.

> -----Original Message-----
> From:	Jørn Hunskaar [SMTP:[email-masked]]
> Sent:	Tuesday, March 06, 2001 2:07 AM
> To:	mobile-ip
> Subject:	[mobile-ip] Fast Handovers in MIPv6 - flags
> 
> Hi,
> 
	[MJ]  It seems that bicasting and buffering are network engineering
issues and mobiles need not dictate the network which approach(es) to take.
How would  a mobile know that the network supports bicasting or buffering? I
don't recall that these capabilities are annouced in the RA.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 9 Mar 2001 23:58:31 +0100

> I have a slightly different question related to the B and U flag bits in BU option. I will appreciate if the design team can provide a rationale for that. See my question below.
> 
> 
> => I agree that they should not be silently ignored
> this is something we need to fix in the next revision.
> 
> 
> 	[MJ]  It seems that bicasting and buffering are network engineering issues and mobiles need not dictate the network which approach(es) to take. How would  a mobile know that the network supports bicasting or buffering? I don't recall that these capabilities are annouced in the RA. 
> 
> => If the AR doesn't support the B and /or U flags then it should indicate
> so in the BAck. The MN needs to request this (especially the B flag)
> because the timer in the BUL for the lifetime of the BU MUST be 
> aligned with the lifetime of the Binding Cache entry in the AR.
> 
> Regards,
> Hesham
> 
>