Jim,
We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses
the 802.11 reassociate for a link up trigger to cause the RS. There is a
substantial decrease in packet loss, on the order of the router beacon. This
requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We
have not implemented the optimization described in the draft yet.
jak
----- Original Message -----
From: "Bound, Jim" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "Brett Pentland"
<[EMAIL PROTECTED]>; "Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 16, 2002 8:19 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
> James,
>
> Have you actually tested this with implementation? Or is this
> theoretical debate?
>
> Thanks
> /jim
>
> -----Original Message-----
> From: James Kempf [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 15, 2002 5:40 PM
> To: Brett Pentland; Thomas Narten
> Cc: [EMAIL PROTECTED]
> Subject: Re: Changing RS Reply Timing for Mobile IPv6
>
>
> Thomas,
>
> > Seems to me then that this document is a bit narrowly scoped and may
> > even miss the point. Don't we need to look at the overall problem and
> > then see what can be done to address the overall problem adequately?
> > In general, I don't know that its all that useful to focus on a narrow
>
> > part of a bigger problem unless the bigger problem is sufficiently
> > understood that the point solution is understood to be an important
> > and useful component of it. How do we know that this change will make
>
> > any significant difference in practice given the general problem?
> >
>
> You are right that this document is fairly narrowly scoped. To solve the
> full problem, it requires other parts of the ND process, specifically
> DAD, to be accelerated as well. Additionally, as was brought up on the
> list, the MN must also decrease MAX_RTR_SOLICITATION_DELAY to zero. As
> was also brought up on the list, this can lead to congestion when mobile
> nodes move in concert, or when an access point crashes.
>
> The FMIPv6 work is certainly a more comprehensive solution, however, the
> currently understanding of how FMIPv6 would work together with 802.11 is
> not encouraging. There is, of course, an argument about how much the
> IETF should modify its specifications to be implementable on a specific
> link layer. However, for 802.11 to work well with FMIP, there would
> either need to be a major change in the current firmware implementations
> for anticipated handover, or an additional protocol would be needed
> between the AP and the AR for conveying the reassociation link up
> trigger to the AR, or some special kind of security association would be
> required between the old AR and the MN in order to do unsolicited FBU
> signaling from the AR to the MN. The IETF can do some work on the last
> two of these but the first one is entirely controlled by the IEEE and,
> worse, by card manufacturers who may or may not implement given that
> IEEE has no standard.
>
> So the deployment alternative with ND as defined in RFC 2461 and the
> base FMIPv6 document if one wants faster 802.11 handovers is to set
> MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero.
> Near term, this is likely to be what people do. With this deployment,
> not only could the above two problems with congestion occur, but the
> router is now subject to DoS attacks. The advantage of the proposal in
> draft-khalil-ipng-fastra-00.txt is that the authors believe it would
> reduce the potential for DoS attacks.
>
> Whether or not this is enough of an improvement over the RS reply
> algorithm as defined by RFC 2461 to standardize, is something for WG and
> the IESG to decide.
>
> jak
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
