From mobopts-bounces@irtf.org Fri Oct 12 11:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMsu-000616-8R; Fri, 12 Oct 2007 11:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMss-0005zs-UO for mobopts@irtf.org; Fri, 12 Oct 2007 11:57:06 -0400 Received: from mail1.is.haw-hamburg.de ([141.22.192.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgMsm-0002tR-L1 for mobopts@irtf.org; Fri, 12 Oct 2007 11:57:06 -0400 Received: from mailgate.informatik.haw-hamburg.de (isis2.informatik.haw-hamburg.de [141.22.10.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail1.is.haw-hamburg.de (Postfix) with ESMTP id 5655E620A8; Fri, 12 Oct 2007 17:56:40 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31559-01-5; Fri, 12 Oct 2007 17:56:40 +0200 (CEST) Received: from [141.22.26.203] (unknown [141.22.26.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id C5A673C0012C; Fri, 12 Oct 2007 17:56:39 +0200 (CEST) Message-ID: <470F9936.7090700@informatik.haw-hamburg.de> Date: Fri, 12 Oct 2007 17:56:38 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: multimob@ietf.org, mobopts@irtf.org Subject: [Mobopts] Re: [multimob] review of draft-irtf-mobopts-mmcast- X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Hesham, thanks for too many flowers ;) In prior discussions you pointed at a more detailed/explicit listing of=20 future steps, so that this can serve as input for future work items ...=20 we'll fix that. thomas Hesham Soliman wrote: > Hi all,=20 >=20 > I reviewed Thomas' problem statement draft. One of the few times I don'= t > have any comments on a draft :) I think it's very well written and serv= es as > a good reference for the current state of the art. I also find the > comprehensive references very useful. I hope this can be used as a base= for > a charter (if there is a WG) or a guideline for further work in this ar= ea in > IETF.=20 >=20 > Hesham >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www1.ietf.org/mailman/listinfo/multimob --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Oct 17 17:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiGQ6-0004ik-8Q; Wed, 17 Oct 2007 17:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiGQ5-0004i9-57 for mobopts@irtf.org; Wed, 17 Oct 2007 17:27:13 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiGPy-0004go-Oo for mobopts@irtf.org; Wed, 17 Oct 2007 17:27:13 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9HLQgoH001214 for ; Thu, 18 Oct 2007 00:26:54 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 00:26:49 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 16:26:34 -0500 Received: from 10.241.58.106 ([10.241.58.106]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Oct 2007 21:26:34 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 17 Oct 2007 14:27:03 -0700 From: Rajeev Koodli To: "mobopts@irtf.org" Message-ID: Thread-Topic: Location Privacy Solutions Document Thread-Index: AcgRBHWQtAtRanz3EdyNewAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 21:26:34.0820 (UTC) FILETIME=[64C48040:01C81104] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mobopts] Location Privacy Solutions Document X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, This is an RG Last Call on draft-irtf-mobopts-location-privacy-solutions-06.txt This LC expires on November 2, 2007. Please provide your input. That's the only way to ensure quality of the RG documents. Thanks, -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Oct 18 18:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidkb-0003Rj-0N; Thu, 18 Oct 2007 18:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IidkZ-0003Rb-RC for mobopts@irtf.org; Thu, 18 Oct 2007 18:21:55 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IidkE-0003mE-VL for mobopts@irtf.org; Thu, 18 Oct 2007 18:21:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9IMLGGA004277 for ; Fri, 19 Oct 2007 01:21:17 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 01:19:56 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 17:19:51 -0500 Received: from 10.241.58.22 ([10.241.58.22]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 22:19:28 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 18 Oct 2007 15:19:57 -0700 From: Rajeev Koodli To: "mobopts@irtf.org" Message-ID: Thread-Topic: RG update Thread-Index: AcgR1QPUQqexU33IEdyNewAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 22:19:51.0419 (UTC) FILETIME=[00808CB0:01C811D5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Mobopts] RG update X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, I just wanted to provide an update on the RG documents, and share some thoughts. 1. The L2 abstractions for L3-driven handover ID is on its way to become an RFC (having finished IRSG review) 2. Location Privacy Solutions document is in RG LC. Please provide your reviews. (draft-irtf-mobopts-location-privacy-solutions-06.txt) 2.a. The CN-targeted location privacy solution is recently adopted as an RG document (draft-weniger-mobopts-mip6-cnlocpriv-02.txt). Please provide your input. 3. The multicast and mobility problem statement has received some good reviews already, and will perhaps be ready for RG LC soon. (draft-irtf-mobopts-mmcastv6-ps-01.txt) 4. The media independent pre-authentication document needs discussion. ( draft-irtf-mobopts-mpa-framework-00.txt) The RG will continue work on these to publish them. In the meanwhile, we need to look at what other topics we need to be addressing.. We have a unique forum to look at wireless/mobility problems in general as they relate to Internet. I encourage folks to make use of this. As we plan for the Vancouver meeting, should we have a mini-workshop on mobility related topics? What topics are interesting? Does wireless link virtualization make sense? Is there interest in reviewing GENI wireless models and contributing to them? Any other? I look forward to your thoughts. Best, -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Oct 18 18:35:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidxt-00037n-NI; Thu, 18 Oct 2007 18:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iidxs-00037i-BB for mobopts@irtf.org; Thu, 18 Oct 2007 18:35:40 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iidxi-0004B4-Rh for mobopts@irtf.org; Thu, 18 Oct 2007 18:35:40 -0400 Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l9IMZKQf029796; Thu, 18 Oct 2007 18:35:20 -0400 (EDT) Message-ID: <4717DFA7.1010903@research.telcordia.com> Date: Thu, 18 Oct 2007 18:35:19 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] RG update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, Is there any way to find out what is going on in the GENI Wireless world? The talk by Allison Mankin at last IRTF was quite informative, but how do we plug into and contribute to that research activity? Do we need to get in touch with BBN folks or Aaron Falk? Thanks Ashutosh Rajeev Koodli wrote: > > Hello folks, > > I just wanted to provide an update on the RG documents, and share some > thoughts. > > 1. The L2 abstractions for L3-driven handover ID is on its way to become an > RFC (having finished IRSG review) > > 2. Location Privacy Solutions document is in RG LC. Please provide your > reviews. (draft-irtf-mobopts-location-privacy-solutions-06.txt) > > 2.a. The CN-targeted location privacy solution is recently adopted as an RG > document (draft-weniger-mobopts-mip6-cnlocpriv-02.txt). Please provide your > input. > > 3. The multicast and mobility problem statement has received some good > reviews already, and will perhaps be ready for RG LC soon. > (draft-irtf-mobopts-mmcastv6-ps-01.txt) > > 4. The media independent pre-authentication document needs discussion. > ( draft-irtf-mobopts-mpa-framework-00.txt) > > The RG will continue work on these to publish them. > In the meanwhile, we need to look at what other topics we need to be > addressing.. We have a unique forum to look at wireless/mobility problems in > general as they relate to Internet. I encourage folks to make use of this. > > As we plan for the Vancouver meeting, should we have a mini-workshop on > mobility related topics? What topics are interesting? Does wireless link > virtualization make sense? Is there interest in reviewing GENI wireless > models and contributing to them? Any other? > > I look forward to your thoughts. > > Best, > > -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Oct 18 19:09:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieUB-0000MT-Lg; Thu, 18 Oct 2007 19:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IieU9-0000MN-QG for mobopts@irtf.org; Thu, 18 Oct 2007 19:09:01 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IieTq-0005CK-At for mobopts@irtf.org; Thu, 18 Oct 2007 19:09:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9IN8R6N010586; Fri, 19 Oct 2007 02:08:33 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 02:06:45 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 18:06:24 -0500 Received: from 10.241.58.22 ([10.241.58.22]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Oct 2007 23:06:23 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 18 Oct 2007 16:06:53 -0700 Subject: Re: [Mobopts] RG update From: Rajeev Koodli To: ext Ashutosh Dutta Message-ID: Thread-Topic: [Mobopts] RG update Thread-Index: AcgR25JL0LaorH3OEdyNewAWy5YJpw== In-Reply-To: <4717DFA7.1010903@research.telcordia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Oct 2007 23:06:24.0461 (UTC) FILETIME=[8148EFD0:01C811DB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Ashutosh, I think the GENI website is a good start. http://www.geni.net/documents.html has documents; more recent documents may be interesting. If there is interest, we can talk to folks in GENI to investigate some way of participation. Regards, -Rajeev -- http://people.nokia.net/~rajeev On 10/18/07 3:35 PM, "ext Ashutosh Dutta" wrote: > Rajeev, > Is there any way to find out what is going on in the GENI > Wireless world? The talk by Allison Mankin at last IRTF was quite > informative, but how do we plug into and contribute to that research > activity? Do we need to get in touch with BBN folks or Aaron Falk? > > Thanks > Ashutosh > > Rajeev Koodli wrote: >> >> Hello folks, >> >> I just wanted to provide an update on the RG documents, and share some >> thoughts. >> >> 1. The L2 abstractions for L3-driven handover ID is on its way to become an >> RFC (having finished IRSG review) >> >> 2. Location Privacy Solutions document is in RG LC. Please provide your >> reviews. (draft-irtf-mobopts-location-privacy-solutions-06.txt) >> >> 2.a. The CN-targeted location privacy solution is recently adopted as an RG >> document (draft-weniger-mobopts-mip6-cnlocpriv-02.txt). Please provide your >> input. >> >> 3. The multicast and mobility problem statement has received some good >> reviews already, and will perhaps be ready for RG LC soon. >> (draft-irtf-mobopts-mmcastv6-ps-01.txt) >> >> 4. The media independent pre-authentication document needs discussion. >> ( draft-irtf-mobopts-mpa-framework-00.txt) >> >> The RG will continue work on these to publish them. >> In the meanwhile, we need to look at what other topics we need to be >> addressing.. We have a unique forum to look at wireless/mobility problems in >> general as they relate to Internet. I encourage folks to make use of this. >> >> As we plan for the Vancouver meeting, should we have a mini-workshop on >> mobility related topics? What topics are interesting? Does wireless link >> virtualization make sense? Is there interest in reviewing GENI wireless >> models and contributing to them? Any other? >> >> I look forward to your thoughts. >> >> Best, >> >> -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Oct 19 07:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqLO-0006cd-8X; Fri, 19 Oct 2007 07:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiqLM-0006Xo-EE for mobopts@irtf.org; Fri, 19 Oct 2007 07:48:44 -0400 Received: from mail2.is.haw-hamburg.de ([141.22.192.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiqLG-0003bN-U6 for mobopts@irtf.org; Fri, 19 Oct 2007 07:48:44 -0400 Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.is.haw-hamburg.de (Postfix) with ESMTP id EFA6B55F89; Fri, 19 Oct 2007 13:48:32 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01696-01-7; Fri, 19 Oct 2007 13:48:32 +0200 (CEST) Received: from [192.168.178.22] (e178180009.adsl.alicedsl.de [85.178.180.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 201D23C000D3; Fri, 19 Oct 2007 13:48:31 +0200 (CEST) Message-ID: <4718998C.9050409@informatik.haw-hamburg.de> Date: Fri, 19 Oct 2007 13:48:28 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] RG update References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.7 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi all, Rajeev Koodli wrote: >=20 > 3. The multicast and mobility problem statement has received some good > reviews already, and will perhaps be ready for RG LC soon. > (draft-irtf-mobopts-mmcastv6-ps-01.txt) >=20 We are currently preparing a major revision and very much solicit any=20 feedback: so, if you have some comments in the queue, please let us know=20 asap. > The RG will continue work on these to publish them. > In the meanwhile, we need to look at what other topics we need to be > addressing.. We have a unique forum to look at wireless/mobility proble= ms in > general as they relate to Internet. I encourage folks to make use of th= is. >=20 A suggestion would be to look closer at the mobile multicast source=20 problem, particularly solutions and their implication for infrastructure=20 capabilities. This relates to the more general questions of * do we need to change MIPv6 stacks for mobile multicast support and h= ow? * do we need to require properties/changes from infrastructural=20 entities (ARs, MAPs, Mcast-Routers, Tunnel Gateways) to support=20 multicast source mobility and which? > As we plan for the Vancouver meeting, should we have a mini-workshop on > mobility related topics? What topics are interesting? Does wireless lin= k > virtualization make sense? Is there interest in reviewing GENI wireless > models and contributing to them? Any other? >=20 A discussion of methodical issues for experimental and simulation=20 analysis could be of interest: This would go along with Geni wireless=20 models, but could include simulation models / tools / data input, as well= . We could offer a presentation on Internet topology measurement data=20 (e.g., comparing Caida & Dimes) and tools. Regards, thomas --=20 =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg =B0 Germany, Fon: +49-40-42875-8157 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Oct 19 15:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IixNI-0002rt-Uj; Fri, 19 Oct 2007 15:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IixNH-0002qU-7D for mobopts@irtf.org; Fri, 19 Oct 2007 15:19:11 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IixNA-0006CV-RP for mobopts@irtf.org; Fri, 19 Oct 2007 15:19:11 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JJBrkj009747; Fri, 19 Oct 2007 22:12:16 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 22:12:11 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 14:12:03 -0500 Received: from 10.241.58.247 ([10.241.58.247]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Oct 2007 19:11:56 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 19 Oct 2007 12:12:28 -0700 Subject: Re: [Mobopts] RG update From: Rajeev Koodli To: "ext Thomas C. Schmidt" Message-ID: Thread-Topic: [Mobopts] RG update Thread-Index: AcgSg/1QO63x+H53EdyNewAWy5YJpw== In-Reply-To: <4718998C.9050409@informatik.haw-hamburg.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Oct 2007 19:12:03.0415 (UTC) FILETIME=[EEA95670:01C81283] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, On 10/19/07 4:48 AM, "ext Thomas C. Schmidt" wrote: >> The RG will continue work on these to publish them. >> In the meanwhile, we need to look at what other topics we need to be >> addressing.. We have a unique forum to look at wireless/mobility problems in >> general as they relate to Internet. I encourage folks to make use of this. >> > A suggestion would be to look closer at the mobile multicast source > problem, particularly solutions and their implication for infrastructure > capabilities. This relates to the more general questions of > > * do we need to change MIPv6 stacks for mobile multicast support and how? > * do we need to require properties/changes from infrastructural > entities (ARs, MAPs, Mcast-Routers, Tunnel Gateways) to support > multicast source mobility and which? > Indeed, these are big questions. And, we should ask such questions. It would help to start with a)why multicast source problem is important, and then b)justify/investigate the need for changes as above. > A discussion of methodical issues for experimental and simulation > analysis could be of interest: This would go along with Geni wireless > models, but could include simulation models / tools / data input, as well. > > We could offer a presentation on Internet topology measurement data > (e.g., comparing Caida & Dimes) and tools. That would be interesting. I don't know if there are any wireless-specific samples also (which would make it even more interesting). Regards, -Rajeev -- http://people.nokia.net/~rajeev > > Regards, > > thomas _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Oct 24 11:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiB2-00021q-JI; Wed, 24 Oct 2007 11:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiB1-0001tY-IQ for mobopts@irtf.org; Wed, 24 Oct 2007 11:29:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiAu-0002Ev-GK for mobopts@irtf.org; Wed, 24 Oct 2007 11:29:47 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E1D161EF369; Wed, 24 Oct 2007 18:29:23 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 42CCD1EF364; Wed, 24 Oct 2007 18:29:17 +0300 (EEST) Message-ID: <471F6490.2010700@nomadiclab.com> Date: Wed, 24 Oct 2007 17:28:16 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mobopts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.8 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ktaniuchi@tari.toshiba.com, William Arbaugh , vfajardo@tari.toshiba.com, Henning Schulzrinne Subject: [Mobopts] Review of draft-irtf-mobopts-mpa-framework-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, Ashutosh asked me to take a look at draft-irtf-mobopts-mpa-framework-00, which I am happy to do. Draft-irtf-mobopts-mpa-framework-00 specifies a framework for efficient and secure handovers of mobile hosts between administrative separate networks. This includes a pre-authentication of the mobile hosts to one or more candidate networks. The framework is generic in that it is independent of the authentication mechanism and mobility protocol. A strength of this framework is that it is based on security relationships between a mobile host and different networks, whereas it does not depend on trust or security relationships between administrative separate networks. This is an advantage in terms of deployment scalability, in particular in a more and more heterogeneous Internet. The draft is of good editorial quality. It also describes related work and clearly explains how it differs from that. Below some more specific technical comments: - One meta-question I have is why the proactive handover tunnel connects the mobile host's old point of attachment with the new access router, and not the mobile host's new point of attachment with the old access router. In most cases, this may not make a difference. But if the signal strength on the old link is fading quickly, it would be advantageous to have the mobile host connect to the new point of attachment as early as possible. E.g., F-MIPv6 follows the latter approach and may hence work better when the overlap between the old and new point of attachment is small. - Section 1.1 lists end-to-end delay as a performance requirement and cites ITU-T G.114 (One-Way Transmission Time). The transmission time is not directly related to mobility management, however, unless you consider propagation stretches that arise from tunneling, such as in case of the proactive handover tunnel. - Section 1.1: > During a mobile's handover, transient traffic cannot > reach the mobile and this contributes to the jitter as > well. Transient traffic during a handover is lost, whereas jitter considers the deviation in inter-arrival times of successfully delivered packets. So the loss of transient traffic during a handover does not contribute to jitter. I would rephrase this. > According to ETSI TR 101 [ETSI], a normal voice > conversation can tolerate up to 2% packet loss. This value is, to my knowledge, the mean packet loss probability that can be repaired by loss concealment techniques. The value hence does not apply to the handover case, which is special in that the packet loss probability is 100% for a short period. Total packet loss cannot be repaired by loss concealment techniques -- although some techniques /attempt/ to repair it by repeating the last received voice frame several times with decreasing volume. A more appropriate metric than the average packet loss probability would be the handover delay (i.e., for how long there is a packet loss of 100%). The handover delay is the time during which the user does not hear anything. Unfortunately, ITU has to my knowledge never developed a recommendations on what the maximum handover delay should be. - Figure 1: Connection between access routers misses in domain B. L2 switch in domain B is not labeled. - Section 6.3: Maybe you should add some recommendations on who eagerly the mobile host should pre-authenticate with different candidate networks. These recommendations should optimally consider the mobile host's policies, signaling overhead, and handover robustness. This is a valuable contribution. Go ahead and publish once Rajeev and William give you green light! :-) Ciao, - Christian _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Oct 24 12:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikieq-0002yg-Qr; Wed, 24 Oct 2007 12:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikiel-0002t6-9p for mobopts@irtf.org; Wed, 24 Oct 2007 12:00:32 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikieg-0003RU-2a for mobopts@irtf.org; Wed, 24 Oct 2007 12:00:31 -0400 Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l9OFxtER010352; Wed, 24 Oct 2007 11:59:56 -0400 (EDT) Message-ID: <471F6BFA.6050809@research.telcordia.com> Date: Wed, 24 Oct 2007 11:59:54 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Christian Vogt References: <471F6490.2010700@nomadiclab.com> In-Reply-To: <471F6490.2010700@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ktaniuchi@tari.toshiba.com, William Arbaugh , Mobopts , vfajardo@tari.toshiba.com, Henning Schulzrinne Subject: [Mobopts] Re: Review of draft-irtf-mobopts-mpa-framework-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Christian, Appreciate your careful review of the draft draft-irtf-mobopts-mpa-framework-00. We will take care of these comments and suggestions in the revised version of the draft. Based on Rajeev's email few days back, I also take this opportunity to solicit comments and suggestions from others in the mailing list on this draft. Regards Ashutosh Christian Vogt wrote: > Folks, > > Ashutosh asked me to take a look at > draft-irtf-mobopts-mpa-framework-00, which I am happy to do. > > Draft-irtf-mobopts-mpa-framework-00 specifies a framework for efficient > and secure handovers of mobile hosts between administrative separate > networks. This includes a pre-authentication of the mobile hosts to one > or more candidate networks. The framework is generic in that it is > independent of the authentication mechanism and mobility protocol. > > A strength of this framework is that it is based on security > relationships between a mobile host and different networks, > whereas it does not depend on trust or security > relationships between administrative separate networks. > This is an advantage in terms of deployment scalability, in > particular in a more and more heterogeneous Internet. > > The draft is of good editorial quality. It also describes > related work and clearly explains how it differs from that. > > Below some more specific technical comments: > > - One meta-question I have is why the proactive handover > tunnel connects the mobile host's old point of attachment > with the new access router, and not the mobile host's new > point of attachment with the old access router. In most > cases, this may not make a difference. But if the signal > strength on the old link is fading quickly, it would be > advantageous to have the mobile host connect to the new > point of attachment as early as possible. E.g., F-MIPv6 > follows the latter approach and may hence work better when > the overlap between the old and new point of attachment is > small. > > - Section 1.1 lists end-to-end delay as a performance > requirement and cites ITU-T G.114 (One-Way Transmission > Time). The transmission time is not directly related to > mobility management, however, unless you consider > propagation stretches that arise from tunneling, such as in > case of the proactive handover tunnel. > > - Section 1.1: > >> During a mobile's handover, transient traffic cannot >> reach the mobile and this contributes to the jitter as >> well. > > Transient traffic during a handover is lost, whereas jitter > considers the deviation in inter-arrival times of > successfully delivered packets. So the loss of transient traffic during > a handover does not contribute to jitter. I would rephrase this. > >> According to ETSI TR 101 [ETSI], a normal voice conversation can >> tolerate up to 2% packet loss. > > This value is, to my knowledge, the mean packet loss > probability that can be repaired by loss concealment > techniques. The value hence does not apply to the handover > case, which is special in that the packet loss probability > is 100% for a short period. Total packet loss cannot be > repaired by loss concealment techniques -- although some > techniques /attempt/ to repair it by repeating the last > received voice frame several times with decreasing volume. > > A more appropriate metric than the average packet loss > probability would be the handover delay (i.e., for how long > there is a packet loss of 100%). The handover delay is the time during > which the user does not hear anything. Unfortunately, ITU has to my > knowledge never developed a recommendations on what the maximum handover > delay should be. > > - Figure 1: Connection between access routers misses in > domain B. L2 switch in domain B is not labeled. > > - Section 6.3: Maybe you should add some recommendations on who eagerly > the mobile host should pre-authenticate with different candidate > networks. These recommendations should optimally consider the mobile > host's policies, signaling overhead, and handover robustness. > > This is a valuable contribution. Go ahead and publish once Rajeev and > William give you green light! :-) > > Ciao, > - Christian > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Oct 24 19:33:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpiH-0000XD-Kj; Wed, 24 Oct 2007 19:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpiG-0000P2-Pc for mobopts@irtf.org; Wed, 24 Oct 2007 19:32:36 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikpi7-0000qp-KG for mobopts@irtf.org; Wed, 24 Oct 2007 19:32:33 -0400 Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l9ONUsSh026122; Wed, 24 Oct 2007 19:30:54 -0400 (EDT) Message-ID: <471FD5AD.7040803@research.telcordia.com> Date: Wed, 24 Oct 2007 19:30:53 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Christian Vogt References: <471F6490.2010700@nomadiclab.com> In-Reply-To: <471F6490.2010700@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: ktaniuchi@tari.toshiba.com, William Arbaugh , Mobopts , vfajardo@tari.toshiba.com, Henning Schulzrinne Subject: [Mobopts] Re: Review of draft-irtf-mobopts-mpa-framework-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Christian, Please see answers to some of the technical questions you have asked. We can probably take care of most these comments by explaining properly in the revised document, but I am answering some of those for the benefit of discussion. Please see inline. Christian Vogt wrote: > Below some more specific technical comments: > > - One meta-question I have is why the proactive handover > tunnel connects the mobile host's old point of attachment > with the new access router, and not the mobile host's new > point of attachment with the old access router. In most > cases, this may not make a difference. But if the signal > strength on the old link is fading quickly, it would be > advantageous to have the mobile host connect to the new > point of attachment as early as possible. E.g., F-MIPv6 > follows the latter approach and may hence work better when > the overlap between the old and new point of attachment is > small. > There are basically three reasons why the proactive tunnel is set up between the new AR and the mobile in the old PoA during proactive operation of MPA. 1. Since this draft emphasizes on inter-domain handoff optimization, security association between the end-points of the proactive transient tunnel is very important. Thus, security association can be ensured by having a secured tunnel between new AR (NAR) and the mobile in the old PoA, as the pre-authentication with the target network takes place before the secured tunnel is established. 2. By having the secured proactive tunnel between NAR and the mobile in old PoA, binding update can be sent when the mobile is in the previous network. This will avoid the delay due to binding update after the handover and effect will be felt the best in cases where CN and MN are far part. 3. Since this inter-domain optimization framework is independent of the mobility protocol (e.g., MIPv6, SIP, PMIP) one does not need to couple it with the specific optimization techniques associated with each of the candidate mobility protocols. It can just use the regular binding update and re-INVITE that are part of MIPv6 or SIP respectively over this secured tunnel. On other hand as you have pointed out, there is a tradeoff associated here, e.g., it is important to pre-authenticate and set up the tunnel ahead of time in case of quickly fading signal or fast-moving vehicle. Pre-authentication time can be pre-determined based on mobile's movement pattern or signaling fading pattern. Assuming inter-domain handoffs are not that frequent or sudden, this problem could be taken care of by completing pre-authentication on certain threshold of SNR for example. > - Section 1.1 lists end-to-end delay as a performance > requirement and cites ITU-T G.114 (One-Way Transmission > Time). The transmission time is not directly related to > mobility management, however, unless you consider > propagation stretches that arise from tunneling, such as in > case of the proactive handover tunnel. Although, tunneling may contribute to the one-way delay, we are talking about the one-way-delay (OWD) for the in-handoff transient packets. It is important to reduce the one-way-transmission delay for the in-handoff packets, and that is where we need to worry about one-way transmission delay. If there is a way to Although tunneling may contribute to the one-way-delay little bit, we are focusing on the one-ways-delay (OWD) for the in-handoff packets that are in transit. It is important to reduce the one-way transmission delay for the in-handoff packets. If we capture the in-handoff packets by applying buffering, then impact on one-way-delay for these packets could be considered important. > - Section 1.1: > >> During a mobile's handover, transient traffic cannot >> reach the mobile and this contributes to the jitter as >> well. > > Transient traffic during a handover is lost, whereas jitter > considers the deviation in inter-arrival times of > successfully delivered packets. So the loss of transient traffic during > a handover does not contribute to jitter. I would rephrase this. First successful packet after the handoff still has a large inter-arrival packet gap compared to the packet that arrived successfully before handoff. Additionally, when buffering module is used at NAR, packets in transit are not lost, but these are buffered, and their arrival is delayed thus contributing to the jitter for those in-handoff packets. One could see a spike for the in-handoff packets, when buffer is flushed after the handoff is complete. We have seen these both for FMIPv6 and MPA. This could be rephrased as you suggested to make it more clear. >> According to ETSI TR 101 [ETSI], a normal voice conversation can >> tolerate up to 2% packet loss. > > This value is, to my knowledge, the mean packet loss > probability that can be repaired by loss concealment > techniques. The value hence does not apply to the handover > case, which is special in that the packet loss probability > is 100% for a short period. Total packet loss cannot be > repaired by loss concealment techniques -- although some > techniques /attempt/ to repair it by repeating the last > received voice frame several times with decreasing volume. > > A more appropriate metric than the average packet loss > probability would be the handover delay (i.e., for how long > there is a packet loss of 100%). The handover delay is the time during > which the user does not hear anything. Unfortunately, ITU has to my > knowledge never developed a recommendations on what the maximum handover > delay should be. Agreed, this value is mean packet loss and may not make sense to a single handover but may apply to a multiple handovers during a single conversation, with each contibuting to some packet loss. Although there are several techniques such as FEC to reduce the packet loss, for handoff scenarios one can reduce the packet loss by using buffering techniques at the expense of additional one-way-delay. Thus, one can practically reduce the packet loss to zero by adding additional buffering delay at the network node, such as NAR. For real-time traffic such as VoIP, this does not help however, if the buffering delay is too much. A trade-off between buffering delay and packet loss is important and an optimal buffering technique is important to support real-time traffic during handoff. We have done some experiments in that respect and had published some results in a paper in PIMRC 2006 (Helsinki), where we used this framework and adjusted the buffer value to obtain a reasonable balance between packet loss and one-way-delay (OWD) for the in-handoff packets. > - Figure 1: Connection between access routers misses in > domain B. L2 switch in domain B is not labeled. Will take care of the correction. > - Section 6.3: Maybe you should add some recommendations on who eagerly > the mobile host should pre-authenticate with different candidate > networks. These recommendations should optimally consider the mobile > host's policies, signaling overhead, and handover robustness. I think one can use some policy-based decision making for supporting pre-authentication with multiple candidate networks or deciding which one is the preferred target network to pre-authenticate. We can add some recommendations on what metrics could be used to optimally decide the target network. Regards Ashutosh > This is a valuable contribution. Go ahead and publish once Rajeev and > William give you green light! :-) > > Ciao, > - Christian > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts