I do understand it exactly and you are 100% correct. Lets do some testing.
/jim -----Original Message----- From: Tony Hain [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 5:19 PM To: 'Charles E. Perkins' Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] Subject: RE: Optimistic DAD draft ... inline > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Charles > E. Perkins > Sent: Tuesday, October 15, 2002 2:47 PM > To: [EMAIL PROTECTED] > Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > > > Hello Tony, > > It is possible to have nice handoffs even with > break-before-make, as long as "break" is not > too lengthy. It seems like this would be a bigger latency concern than DAD. > If the determination about the > destination network is available in time, completing > DAD before switching is a good idea -- whether or > not the handoff is "break-before-make". Maybe I just don't understand the technology well enough, but I from my limited perspective it would seem that the current GGSN would know which radio system the MN was attached to, and therefore could figure out the candidate set of destinations for a hand-off. That list could be forwarded to the MN, so personal policy and signal strength could be applied to sort the list to come up with the best candidates. With that an out of band predictive DAD could be done. This would make much more sense than moving, stepping on an existing node, then backing off. It seems that a little bit of overhead traffic is better than dropping 2 connections. > > This is under discussion within the seamoby working > group. We have a draft about it, and an optimistic > DAD scheme. When my head rises more than an millimeter > above water, I'll read the draft in the Subject: line > (glub, glub). > > Regards, > Charlie P. > > > Tony Hain wrote: > > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can > decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to > start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as currently > > > specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > handovers working > > > > > for IPv6 mobility is the long delay involved in > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate > while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour > in order to > > > > > minimize disruption in case of an address conflict > (and maintain > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > and I've > > > > > formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > <http://www.ctie.monash.edu.au/ipv6/fastho.htm> > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the > draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore > <[EMAIL PROTECTED]> > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > -------------------------------------------------------------------- > > > > > 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] > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > -------------------------------------------------------------------- > > 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
