We have implemented and tested it. Greg Daley was modifying radvd for hmip so he added this as well. We have combined it with link layer signalling to trigger router solicitations (Nick and Bretts work). The combination of HMIP, triggered RS, fast RA and HMIP is very effective in an 802.11 environment L3 handover is much shorter than L2. In the absence of fast handover support we think this is a good solution. We will be publishing test results soon although we could put some preliminary ones up on a website if anybody wanted to see them.
Richard. ----- Original Message ----- From: "James Kempf" <[EMAIL PROTECTED]> To: "Bound, Jim" <[EMAIL PROTECTED]>; "Brett Pentland" <[EMAIL PROTECTED]>; "Thomas Narten" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 17, 2002 1:40 AM Subject: Re: Changing RS Reply Timing for Mobile IPv6 > 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:kempf@;docomolabs-usa.com] > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
