From mobopts-bounces@irtf.org Fri Jan 13 07:52:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOQB-0001W7-Fj; Fri, 13 Jan 2006 07:52:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOQA-0001W2-Ih for mobopts@megatron.ietf.org; Fri, 13 Jan 2006 07:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02803 for ; Fri, 13 Jan 2006 07:51:25 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+ERZSllDowhZN/JwLeA8yoJzg/eYXw1Z8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExOXT-0001if-8N for mobopts@irtf.org; Fri, 13 Jan 2006 08:00:20 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ExOPs-0007gE-Hr for ; Fri, 13 Jan 2006 13:52:38 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 687BF7E2E for ; Fri, 13 Jan 2006 13:52:28 +0100 (CET) Message-ID: <43C7A28C.50508@tm.uka.de> Date: Fri, 13 Jan 2006 13:52:28 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Mobopts X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.5 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -2.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Mobopts] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org I would like to call your attention on work that we have done on IPv6 handoff procedures: "A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization" http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf Abstract: Optimizations to reduce handoff delays inherent in Mobile IPv6 Route Optimization as well as IPv6 router discovery, address configuration, and movement detection have so far been mostly considered on an individual basis. This document evaluates three integrated solutions for improved handoff experience in surroundings with different preconditions: reactive handoffs with unmodified routers, reactive handoffs with router support, and movement anticipation and proactive handoff manage- ment. Your feedback will be welcome! Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jan 15 10:16:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9c3-0001pX-Hq; Sun, 15 Jan 2006 10:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9bw-0001lM-Da; Sun, 15 Jan 2006 10:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29460; Sun, 15 Jan 2006 10:14:37 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey9Rl-0000zk-Cj; Sun, 15 Jan 2006 10:05:34 -0500 Received: from e178178094.adsl.alicedsl.de ([85.178.178.94] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Ey9Ju-000C1V-Jq; Sun, 15 Jan 2006 15:57:26 +0100 Message-ID: <43CA6387.8080306@fhtw-berlin.de> Date: Sun, 15 Jan 2006 16:00:23 +0100 From: Thomas C Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de> In-Reply-To: <43CA50C7.1000206@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Christian, the mailinglist seems to be gone for the weekend ... so this is very private ... Christian Vogt wrote: > While your results [1] on FMIPv6 and HMIPv6 shed light on the > performance of proactivity in combination with local mobility > optimizations and are as such undoubtedly very important, I do not > necessarily consent with your statement that those results can be > conveyed to the end-to-end mobility management that we have been > analyzing [2]. > I perfectly agree with your characterisation. I did'nt mean to say that both approaches are the same. What I tried to suggest is that there might be some lessons to be learned from [1] for your work. From an abstract point of view the approaches of FMIPv6 (predictive part) and proactive end-to-end mobility management agree in hiding update delays by advancing handover negotiations on the basis of predictions. Beside problems with the reliability of predictions they both rely on timing issues: negotiations have to be successfully completed for the schemes to work. You are addressing this issue in section 7.1 of [2], but what we would like to contribute as the essence of [1] reads: There are three different timescales, one defined by the HO scheme + Internet topology, another by the L2 technologie and the third by the actual movement of the mobile user. They are fairly independent of each other. It may as well happen that the degree of coincidence required by your scheme corresponds to a quite narrow regime in phase space, which is hardly ever met. Thus it is *possible* that the fascinating perspective of zero update delay is just a conceptual result, which basically does not hold in reality. Details of course are subject to a thorough analysis, which you will probably do. Best regards, thomas > [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf > [2] > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jan 15 10:32:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9rq-00080i-L5; Sun, 15 Jan 2006 10:32:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9qj-0007Fs-L4; Sun, 15 Jan 2006 10:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01057; Sun, 15 Jan 2006 10:16:32 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18J92O5oGuMkfz3/gDdHaWyNKWIDkFZeio=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey8FZ-00009i-Kh; Sun, 15 Jan 2006 08:48:56 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Ey87O-0000w2-C8; Sun, 15 Jan 2006 14:40:32 +0100 Received: from [192.168.2.100] (p54A35C6C.dip.t-dialin.net [84.163.92.108]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E41B38A4D; Sun, 15 Jan 2006 14:40:24 +0100 (CET) Message-ID: <43CA50C7.1000206@tm.uka.de> Date: Sun, 15 Jan 2006 14:40:23 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: schmidt@fhtw-berlin.de References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> In-Reply-To: <43C91C45.3090909@fhtw-berlin.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > We analysed these properties for the case of FMIPv6 (which should be > transferable in major parts, e.g., fmip needs fback, you need BU to > arrive ...) and found no significant improvement by predicitions (see > bib-reference attached). Thomas, thanks for bringing this up. While your results [1] on FMIPv6 and HMIPv6 shed light on the performance of proactivity in combination with local mobility optimizations and are as such undoubtedly very important, I do not necessarily consent with your statement that those results can be conveyed to the end-to-end mobility management that we have been analyzing [2]. During an end-to-end Mobile IPv6 handoff, communications are delayed for at least a global RTT between the MN and the CN (assuming that end-to-end optimizations such as EBU and CBA are deployed). This minimum delay can basically be eliminated in two ways: - Proactivity, i.e., send a BU from the old location and move to the new location only when packets can expected to have arrived there. - Local mobility optimizations such as FMIPv6 and HMIPv6, which either eliminate global signaling (HMIPv6), or move it off the critical blackout period (FMIPv6). Your work [1] deals with the second option, our's [2] deals with the first. To be more explicit, let's assume we use FMIPv6. All global signaling is then deferred until the MN has already resumed communications, from the new link, through the AR-to-AR tunnel. This is true for both proactive and reactive FMIPv6 modes. What *FMIPv6 proactivity* saves you is just an FBU's propagation time from the new AR to the old AR. Compare this to the global RTT that *end-to-end proacitvity* potentially saves you. Referring to the problems with predictive handoff procedures that you mention: You are correct, and section 7.1 in our analysis duely discusses this. As far as unreliability in predictions goes: Unfortunately, you are right, but that's a different construction site. ;) Regards, - Christian [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf [2] http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Thomas C Schmidt wrote: > Dear Christian, > > thanks for bringing your technical report to our attention! > > For a comment: it is our experience that the optimistic concept of zero > handover delay due to predictive procedures does not survive reality. > > This is mainly due to > > - the independence of anticipation, signaling and handoff in > occurrence and timescale. > > - predictions turning out as rather unreliable. > > We analysed these properties for the case of FMIPv6 (which should be > transferable in major parts, e.g., fmip needs fback, you need BU to > arrive ...) and found no significant improvement by predicitions (see > bib-reference attached). > > Song et al. ([11] in our references) made empirical studies on > predicitions including the campus geometry, statistical correlation > analysis of user date ... and arrived at dissapointing 72 %. > > It's a nice vision - but sometimes real-world isn't as nice ;) > > Best regards, > > thomas > > Christian Vogt wrote: > >> I would like to call your attention on work that we have done on IPv6 >> handoff procedures: >> >> "A Comprehensive Delay Analysis >> for Reactive and Proactive Handoffs >> with Mobile IPv6 Route Optimization" >> >> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf >> >> >> Abstract: Optimizations to reduce handoff delays >> inherent in Mobile IPv6 Route Optimization as well >> as IPv6 router discovery, address configuration, >> and movement detection have so far been mostly >> considered on an individual basis. This document >> evaluates three integrated solutions for improved >> handoff experience in surroundings with different >> preconditions: reactive handoffs with unmodified >> routers, reactive handoffs with router support, and >> movement anticipation and proactive handoff manage- >> ment. >> >> Your feedback will be welcome! >> >> Regards, >> - Christian >> > > ------------------------------------------------------------------------ > > @article{sw-pvrah-05, > author = {Thomas C. Schmidt and Matthias W{\"a}hlisch}, > title = {{P}redictive versus {R}eactive -- {A}nalysis of {H}andover {P}erformance and {I}ts {I}mplications on {IP}v6 and {M}ulticast {M}obility}, > journal = {Telecommunication Systems}, > volume = {30}, > number = {1--3}, > pages = {123--142}, > month = {November}, > year = {2005}, > publisher = {Springer}, > address = {Berlin Heidelberg}, > url = {http://dx.doi.org/10.1007/s11235-005-4321-4}, > abstract = {Handovers in mobile packet networks commonly produce packet loss, delay and jitter, thereby significantly degrading network performance. Mobile IPv6 handover performance is strongly topology dependent and results in inferior service quality in wide area scenarios. To approach seamless mobility in IPv6 networks predictive, reactive and proxy schemes have been proposed for improvement. In this article we analyse and compare handover performance and frequencies for the corresponding protocols, as they are an immediate measure on service quality. Using analytical methods as well as stochastic simulations, we calculate the performance decreases originating from different handover schemes, the expected number of handovers as functions of mobility and proxy ratios, as well as the mean correctness of predictions. In detail we treat the more delicate case of these rates in mobile multicast communication. > It is obtained that performance benefits, expected from simple analysis of predictive schemes, do not hold in practice. Reactive and predictive handovers rather admit comparable performance. Hierarchical proxy environments -- foremost in regions of high mobility -- can significantly reduce the processing of inter--network changes. Reliability of handover predictions is found on average at about 50 \%.}, > theme = {mipv6|mmcast}, > file = {http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf} > } _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jan 15 12:59:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC9z-0005zk-Ar; Sun, 15 Jan 2006 12:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC9w-0005dH-1q for mobopts@megatron.ietf.org; Sun, 15 Jan 2006 12:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11893 for ; Sun, 15 Jan 2006 11:59:41 -0500 (EST) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExheM-0001QD-9y for mobopts@irtf.org; Sat, 14 Jan 2006 04:24:43 -0500 Received: from thlemaxos.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Sat, 14 Jan 2006 09:16:31 +0000 Message-ID: <43C8C199.2000402@cs.ucl.ac.uk> Date: Sat, 14 Jan 2006 09:17:13 +0000 From: Theodoros Pagtzis Organization: Nets & Mobile Systems Group, UCL-CS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Subject: Re: [Mobopts] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A28C.50508@tm.uka.de> In-Reply-To: <43C7A28C.50508@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: mipshop@ietf.org, Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: t.pagtzis@cs.ucl.ac.uk List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Christian, I have done this as part of my 571-page PhD thesis completed last year. Perhaps we want to cross-check your results with what I have come up with in terms of delay. The thesis is in my web page. cheers Theodoros Christian Vogt wrote: > I would like to call your attention on work that we have done on IPv6 > handoff procedures: > > "A Comprehensive Delay Analysis > for Reactive and Proactive Handoffs > with Mobile IPv6 Route Optimization" > > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf > > > Abstract: Optimizations to reduce handoff delays > inherent in Mobile IPv6 Route Optimization as well > as IPv6 router discovery, address configuration, > and movement detection have so far been mostly > considered on an individual basis. This document > evaluates three integrated solutions for improved > handoff experience in surroundings with different > preconditions: reactive handoffs with unmodified > routers, reactive handoffs with router support, and > movement anticipation and proactive handoff manage- > ment. > > Your feedback will be welcome! > > Regards, > - Christian > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Jan 15 13:59:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD6O-00070D-KG; Sun, 15 Jan 2006 13:59:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD4E-0004NV-Av; Sun, 15 Jan 2006 13:57:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01538; Sun, 15 Jan 2006 11:20:22 -0500 (EST) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExneJ-0008Sw-9z; Sat, 14 Jan 2006 10:49:05 -0500 Received: from e178165109.adsl.alicedsl.de ([85.178.165.109] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1ExnWV-000DJA-3J; Sat, 14 Jan 2006 16:40:59 +0100 Message-ID: <43C91C45.3090909@fhtw-berlin.de> Date: Sat, 14 Jan 2006 16:44:05 +0100 From: Thomas C Schmidt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt References: <43C7A215.1040804@tm.uka.de> In-Reply-To: <43C7A215.1040804@tm.uka.de> Content-Type: multipart/mixed; boundary="------------000001090005080001050904" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Mip6 , mipshop , mobopts Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --------------000001090005080001050904 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Dear Christian, thanks for bringing your technical report to our attention! For a comment: it is our experience that the optimistic concept of zero handover delay due to predictive procedures does not survive reality. This is mainly due to - the independence of anticipation, signaling and handoff in occurrence and timescale. - predictions turning out as rather unreliable. We analysed these properties for the case of FMIPv6 (which should be transferable in major parts, e.g., fmip needs fback, you need BU to arrive ...) and found no significant improvement by predicitions (see bib-reference attached). Song et al. ([11] in our references) made empirical studies on predicitions including the campus geometry, statistical correlation analysis of user date ... and arrived at dissapointing 72 %. It's a nice vision - but sometimes real-world isn't as nice ;) Best regards, thomas Christian Vogt wrote: > I would like to call your attention on work that we have done on IPv6 > handoff procedures: > > "A Comprehensive Delay Analysis > for Reactive and Proactive Handoffs > with Mobile IPv6 Route Optimization" > > http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf > > > Abstract: Optimizations to reduce handoff delays > inherent in Mobile IPv6 Route Optimization as well > as IPv6 router discovery, address configuration, > and movement detection have so far been mostly > considered on an individual basis. This document > evaluates three integrated solutions for improved > handoff experience in surroundings with different > preconditions: reactive handoffs with unmodified > routers, reactive handoffs with router support, and > movement anticipation and proactive handoff manage- > ment. > > Your feedback will be welcome! > > Regards, > - Christian > --------------000001090005080001050904 Content-Type: text/plain; name="sw-pvrah-05.bib" Content-Disposition: inline; filename="sw-pvrah-05.bib" Content-Transfer-Encoding: quoted-printable @article{sw-pvrah-05, author =3D {Thomas C. Schmidt and Matthias W{\"a}hlisch}, title =3D {{P}redictive versus {R}eactive -- {A}nalysis of {H}andover {= P}erformance and {I}ts {I}mplications on {IP}v6 and {M}ulticast {M}obilit= y}, journal =3D {Telecommunication Systems}, volume =3D {30}, number =3D {1--3}, pages =3D {123--142}, month =3D {November}, year =3D {2005}, publisher =3D {Springer}, address =3D {Berlin Heidelberg}, url =3D {http://dx.doi.org/10.1007/s11235-005-4321-4}, abstract =3D {Handovers in mobile packet networks commonly produce pack= et loss, delay and jitter, thereby significantly degrading network perfor= mance. Mobile IPv6 handover performance is strongly topology dependent an= d results in inferior service quality in wide area scenarios. To approach= seamless mobility in IPv6 networks predictive, reactive and proxy scheme= s have been proposed for improvement. In this article we analyse and comp= are handover performance and frequencies for the corresponding protocols,= as they are an immediate measure on service quality. Using analytical me= thods as well as stochastic simulations, we calculate the performance dec= reases originating from different handover schemes, the expected number o= f handovers as functions of mobility and proxy ratios, as well as the mea= n correctness of predictions. In detail we treat the more delicate case o= f these rates in mobile multicast communication. It is obtained that performance benefits, expected from simple analysis = of predictive schemes, do not hold in practice. Reactive and predictive h= andovers rather admit comparable performance. Hierarchical proxy environm= ents -- foremost in regions of high mobility -- can significantly reduce = the processing of inter--network changes. Reliability of handover predict= ions is found on average at about 50 \%.}, theme =3D {mipv6|mmcast}, file =3D {http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys0= 5.pdf} } --------------000001090005080001050904 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --------------000001090005080001050904-- From mobopts-bounces@irtf.org Mon Jan 16 02:11:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOW4-0002z7-0Y; Mon, 16 Jan 2006 02:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOW0-0002y8-US; Mon, 16 Jan 2006 02:10:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18321; Mon, 16 Jan 2006 02:09:32 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX19QGUynzpWoRb4JKtbt5spvKg9jqWsIH2o=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyOds-0005Vp-9s; Mon, 16 Jan 2006 02:19:05 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOVn-0001gd-BM; Mon, 16 Jan 2006 08:10:46 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BD3A18B94; Mon, 16 Jan 2006 08:10:40 +0100 (CET) Message-ID: <43CB46F0.5020001@tm.uka.de> Date: Mon, 16 Jan 2006 08:10:40 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "Atiquzzaman, Mohammed" Subject: Re: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6Route Optimization References: <96F80D7EBB8DC34092D083C6E2EE5EF504EA2165@XMAIL1.sooner.net.ou.edu> In-Reply-To: <96F80D7EBB8DC34092D083C6E2EE5EF504EA2165@XMAIL1.sooner.net.ou.edu> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.2 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.8 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts , schmidt@fhtw-berlin.de X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Mohammed, it's very good that you point to related work that you did. Still, I refer to the discussion that Thomas and I had yesterday on the differences between network-assisted mobility (which is what you have experimented with) and end-to-end mobility (which is what our analysis is about). To be brief: Our work is truly orthogonal. Further, I should mention that our analysis assumes the use of DNA mechanisms (DNA protocol, CPL, FastRA) to eliminate router-discovery and movement-detection delays during reactive handoffs, Optimistic DAD to get rid of the address-configuration latency, and Media Independent Handover Services (including Information Services) to facilitate proactive handoffs. Hope this makes things more clear. Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Atiquzzaman, Mohammed wrote: > We also studied the handoff delay between various MIPv6 variants and > SIGMA (a transport layer handoff scheme) and presented the result at > Globecom 2005. In most cases, SIGMA achieved a lower handoff latency > than the MIPv6 variants by exploting multihoming. > > Shaojian Fu, Mohammed Atiquzzaman, Handover latency comparison of SIGMA, > FMIPv6, HMIPv6, and FHMIPv6, IEEE GlobeCom, St. Louis, MO, November > 28-December 02, 2005 > http://www.cs.ou.edu/~netlab/Pub/L2effect-TraSH-globecom05-camera.pdf > > > Mohammed Atiquzzaman Tel: (405) 325 8077 > Professor, School of Computer Science Fax: (405) 325 4044, > University of Oklahoma > 200 Felgar St., Room EL-160 Email: atiq@ou.edu > Norman, OK 73019-6151 atiq@ieee.org > www.cs.ou.edu/~atiq _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jan 16 02:14:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOZc-0003QW-8l; Mon, 16 Jan 2006 02:14:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOZZ-0003PG-MZ; Mon, 16 Jan 2006 02:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18474; Mon, 16 Jan 2006 02:13:12 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1/lx/hLh7icVOVXtXRbCa2/3R4Z5aWQYQA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyOhR-0005az-3N; Mon, 16 Jan 2006 02:22:46 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOZU-0001ql-VX; Mon, 16 Jan 2006 08:14:34 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C61E68B8A; Mon, 16 Jan 2006 08:14:32 +0100 (CET) Message-ID: <43CB47D8.1040103@tm.uka.de> Date: Mon, 16 Jan 2006 08:14:32 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: t.pagtzis@cs.ucl.ac.uk Subject: Re: [Mobopts] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization References: <43C7A28C.50508@tm.uka.de> <43C8C199.2000402@cs.ucl.ac.uk> In-Reply-To: <43C8C199.2000402@cs.ucl.ac.uk> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.1 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.7 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mipshop@ietf.org, Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Cross-comparing would be good. Can you send us a direct link to your thesis? The link on your home page points to a project page, which doesn't seem to have the thesis on it. Thanks, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Theodoros Pagtzis wrote: > Hi Christian, > > I have done this as part of my 571-page PhD thesis completed last year. > Perhaps we want to cross-check your results with what I have come up > with in terms of delay. The thesis is in my web page. > > cheers > Theodoros > > Christian Vogt wrote: > >> I would like to call your attention on work that we have done on IPv6 >> handoff procedures: >> >> "A Comprehensive Delay Analysis >> for Reactive and Proactive Handoffs >> with Mobile IPv6 Route Optimization" >> >> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf >> >> >> Abstract: Optimizations to reduce handoff delays >> inherent in Mobile IPv6 Route Optimization as well >> as IPv6 router discovery, address configuration, >> and movement detection have so far been mostly >> considered on an individual basis. This document >> evaluates three integrated solutions for improved >> handoff experience in surroundings with different >> preconditions: reactive handoffs with unmodified >> routers, reactive handoffs with router support, and >> movement anticipation and proactive handoff manage- >> ment. >> >> Your feedback will be welcome! >> >> Regards, >> - Christian _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jan 16 02:40:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOy8-0000vU-TT; Mon, 16 Jan 2006 02:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOy6-0000uP-0D; Mon, 16 Jan 2006 02:39:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19827; Mon, 16 Jan 2006 02:38:33 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX194y3HCdnkp2b3vbNzjFm1G5v3rQ9+BU2s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyP5y-0006Dk-Dv; Mon, 16 Jan 2006 02:48:07 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOxz-0002qP-Tx; Mon, 16 Jan 2006 08:39:54 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7B29886BB; Mon, 16 Jan 2006 08:39:51 +0100 (CET) Message-ID: <43CB4DC7.7030600@tm.uka.de> Date: Mon, 16 Jan 2006 08:39:51 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: schmidt@fhtw-berlin.de References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de> <43CA6387.8080306@fhtw-berlin.de> In-Reply-To: <43CA6387.8080306@fhtw-berlin.de> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -6.1 (------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.7 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: Mip6 , Mipshop , Mobopts Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Thomas. > I perfectly agree with your characterisation. I did'nt mean to say > that both approaches are the same. What I tried to suggest is that > there might be some lessons to be learned from [1] for your work. Yes, in particular with respect to the reliability of movement predictions, which you are considering in [1]. This is definitely an interesting issue, albeit it is the link-layer folks that must eventually solve it. I would also assume that the reliability of predictions strongly depends on the access technology. E.g., in GSM, you have bidirectional measurements that you can take into account. This is not necessarily true for other link layers, such as IEEE 802.11. > It may as well happen that the degree of coincidence required by your > scheme corresponds to a quite narrow regime in phase space, which is > hardly ever met. Zero handoff delay, at the IP layer, is indeed possible only when certain assumptions hold. And as discussed in section 7.1 of [2], this is not always the case. However, end-to-end proactivity can perform better than reactive approaches even when conditions are sub-optimal. To exemplify this, let's consider the packet-propagation latencies on the old path versus the new path during a proactively managed handoff: If the new path is longer, the mobile node may have to wait for packets after it has switched links (subsequent to receiving a Binding Acknowledgment on the old link). If the new path is shorter, some packets may already be lost on the new link before the mobile node arrives there. But in both cases, the blackout time is usually shorter than in a pure reactive approach. Anyway, all this is discussed in more detail in [2]. - Christian [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf [2] http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Thomas C Schmidt wrote: > Hi Christian, > > the mailinglist seems to be gone for the weekend ... so this is very > private ... > > > Christian Vogt wrote: > >> While your results [1] on FMIPv6 and HMIPv6 shed light on the >> performance of proactivity in combination with local mobility >> optimizations and are as such undoubtedly very important, I do not >> necessarily consent with your statement that those results can be >> conveyed to the end-to-end mobility management that we have been >> analyzing [2]. >> > > I perfectly agree with your characterisation. I did'nt mean to say > that both approaches are the same. What I tried to suggest is that > there might be some lessons to be learned from [1] for your work. > > From an abstract point of view the approaches of FMIPv6 (predictive > part) and proactive end-to-end mobility management agree in hiding > update delays by advancing handover negotiations on the basis of > predictions. > > Beside problems with the reliability of predictions they both rely on > timing issues: negotiations have to be successfully completed for > the schemes to work. You are addressing this issue in section 7.1 of > [2], but what we would like to contribute as the essence of [1] > reads: > > There are three different timescales, one defined by the HO scheme + > Internet topology, another by the L2 technologie and the third by > the actual movement of the mobile user. They are fairly independent > of each other. > > It may as well happen that the degree of coincidence required by your > scheme corresponds to a quite narrow regime in phase space, which is > hardly ever met. Thus it is *possible* that the fascinating > perspective of zero update delay is just a conceptual result, which > basically does not hold in reality. Details of course are subject to > a thorough analysis, which you will probably do. > > Best regards, > > thomas > >> [1] >> http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf >> [2] >> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Jan 16 09:16:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVA3-00014u-Gl; Mon, 16 Jan 2006 09:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVA0-00014E-Rf for mobopts@megatron.ietf.org; Mon, 16 Jan 2006 09:16:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15800 for ; Mon, 16 Jan 2006 09:15:15 -0500 (EST) Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX18JHOx/bNP2g9vf9PqXyAnqTEHpKN6owaQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVHw-0002xO-3L for mobopts@irtf.org; Mon, 16 Jan 2006 09:24:53 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyV9n-0006Yu-A0 for ; Mon, 16 Jan 2006 15:16:37 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 297C68BFD for ; Mon, 16 Jan 2006 15:16:27 +0100 (CET) Message-ID: <43CBAABA.6090600@tm.uka.de> Date: Mon, 16 Jan 2006 15:16:26 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Mobopts X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.9 (-----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.5 AWL AWL: From: address is in the auto white-list X-Spam-Score: 2.4 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Mobopts] EBU/CBA Implementation X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Everybody, here is a link to our software implementation of Early Binding Updates and Credit-Based Authorization: http://www.tm.uka.de/~chvogt/ebucba/ The implementation is a patch for the Kame- Shisa Mobile IPv6 software, version 20050822, for FreeBSD 5.4. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jan 19 19:02:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezjk2-0006YI-4I; Thu, 19 Jan 2006 19:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezjjz-0006Y6-Lf for mobopts@megatron.ietf.org; Thu, 19 Jan 2006 19:02:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11510 for ; Thu, 19 Jan 2006 19:01:29 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezjsb-0003EK-86 for mobopts@irtf.org; Thu, 19 Jan 2006 19:11:50 -0500 Message-ID: <01cb01c61d55$003ad880$226115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Date: Thu, 19 Jan 2006 16:03:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Subject: [Mobopts] Looking for Newer Version of HMIP X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org We're looking for a newer version of HMIP for Linux that works on RFC 3775 MIPv6. The newest we can find is the Monash version corresponding to HMIP draft version 6, and MIPv6 draft version 15 from 2004. The latest MIPv6 is now out of the kernel, so we cannot use the Monash version with the latest MIPv6. Any pointers? jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Jan 19 21:48:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmKK-00035K-H3; Thu, 19 Jan 2006 21:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmKE-00031G-HC for mobopts@megatron.ietf.org; Thu, 19 Jan 2006 21:48:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25864 for ; Thu, 19 Jan 2006 21:47:03 -0500 (EST) Received: from static-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmSr-0000Rg-Pm for mobopts@irtf.org; Thu, 19 Jan 2006 21:57:27 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 9B03970052B; Fri, 20 Jan 2006 13:48:16 +1100 (EST) Date: Fri, 20 Jan 2006 13:48:15 +1100 From: "Nick 'Sharkey' Moore" To: mipshop@ietf.org, mobopts@irtf.org Subject: Re: [Mobopts] Looking for Newer Version of HMIP Message-ID: <20060120024815.GA3941@zoic.org> Mail-Followup-To: mipshop@ietf.org, mobopts@irtf.org, James Kempf References: <01cb01c61d55$003ad880$226115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01cb01c61d55$003ad880$226115ac@dcml.docomolabsusa.com> X-URL: http://zoic.org/sharkey/ User-Agent: Mutt/1.5.9i X-Spam-Score: 2.4 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: James Kempf X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org On 2006-01-19, James Kempf wrote: > We're looking for a newer version of HMIP for Linux that works on RFC 3775 > MIPv6. The newest we can find is the Monash version corresponding to HMIP > draft version 6, and MIPv6 draft version 15 from 2004. The latest MIPv6 is > now out of the kernel, so we cannot use the Monash version with the latest > MIPv6. G'day James, Unfortunately, Greg, Brett and I are no longer employed by Monash CTIE / ATcrc, so we're no longer maintaining that code. As you point out, it's probably now a bit long in the tooth. -----Nick _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts