From behcetsarikaya@yahoo.com Wed May 5 09:02:46 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBD93A6C3C for ; Wed, 5 May 2010 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWUVQdzcKHOV for ; Wed, 5 May 2010 09:02:45 -0700 (PDT) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 573AA3A6C67 for ; Wed, 5 May 2010 08:56:05 -0700 (PDT) Received: (qmail 3785 invoked by uid 60001); 5 May 2010 15:55:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273074949; bh=8zY4nyWU9RjwZ3cejzE5tgIAeWIKViNG49FSk+tnS/k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WehanYn6v93XZKVcJ8DikzVB0o8b/ebHUXFua9nHF0ccqoN78yT3tIaYzQFDYKYFNJReIOfA8hs35XefnzC8c3s9APFkhiWm/V/twENXuITJMz3k+kob9AOAcS6S5uTluBX3D8sWVap5ll8E5gNNqgWEN/Dt/TTyQLZ8z6EvTH4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mFRKdaMA5D4Rf8qqMkZxRFG+/msWdwxIv+ndq0MErzIshN+rzBpLbKTE+S3eTQrD0ls/PVDXz+6GzLz9kwsg6CLzHe/IGWS4ctfu3ubFpBxlAB7H9nABeWoaX4X2Qm5Yz1Kmtfa2Umwq+6q2n6lifj6plrOkDFGnaiVDZ3RfiSc=; Message-ID: <674681.1458.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: d3L28wEVM1kvVf.b52V.DmROGxBmBPoZmJ2EIRWIX56S19J IPdgIO6XAOcgWorDpmLzi9PvGdFiutqSTXp4yUHuJtaVoIfg_n0VK9rcjM1A kMfA5J0o95q2AJ5HD_pQFuRFYNPHGtHQbnM3OVnWsfqWMg1dkbdHUI5NAxFO qh9fDeIezB41w0La6loUb6a.VRgK9Id2swUQ4Yjhk.lOu6YEmQhsV5adzgfc 5FmczgMpLzqYAOyTyGTHA9oNkiKxUG6v5XbbrjUk86jTd6K9zKleQwRwSpEi bj1u7B7jTP00mTYhbfllW0V30w8d79HeIrvurPeKEBe390U_lcQ56SjwzdV5 K Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Wed, 05 May 2010 08:55:49 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 Date: Wed, 5 May 2010 08:55:49 -0700 (PDT) From: Behcet Sarikaya To: Thomas C Schmidt , multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] PMIPv6 base solution draft - NAT issue X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 16:02:46 -0000 Hi Thomas, all,=0A=A0 Regarding draft-ietf-multimob-pmipv6-base-solution-00= , Section 4.4, I was wondering if we should discuss NAT issues?=0A=A0=0AWhe= n we deal with IPv4, IESG I think cares a lot about what happens with any N= AT boxes in the path.=0A=A0=0ARecently I came to know RFC 5135 and I think = this RFC could provide some help on this issue.=0A=A0=0ARegards,=0A=A0=0ABe= hcet=0A=0A=0A=0A From behcetsarikaya@yahoo.com Wed May 5 12:12:24 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C7028C172 for ; Wed, 5 May 2010 12:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[AWL=-2.033, BAYES_99=3.5, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwWcyU0oQJ9E for ; Wed, 5 May 2010 12:12:23 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 116C328C168 for ; Wed, 5 May 2010 12:12:15 -0700 (PDT) Received: (qmail 77948 invoked by uid 60001); 5 May 2010 19:12:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273086722; bh=dAdw4T4IhQQYH3cZsWi10unkh6PPb6jzoyfKNC9p9rc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U9/heatCUZCikqyKb4F2Cz0z5SCkucfA38DMxpVApVybbfS9nkA4P7nlyzcFgSWAbzsVqPCatzgxJHaAh3X2jbmSzNQyNl5HxXhAEdzI1Ctv1AcdnpFcChxW1J7E0fXGcZpCCuJ20+LrQwRq5QYKDggT0OrNx2U6za5sU9T5qCo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I7WdtwTNfpTyrKRRJj7QdxOJ7oFVGXhGbVERX8hlNDpBLHuH5PGobXV5P4Q6KxSf8GORcZ/SR3WnHrH8N34z/+F8BnWEcN2zDQmRoA8/bZgRM2EH8oaE8xit13OFK3MR8c4mVqrSFsClvYftkx7nM4ByZt5CcwxmExG+zRy1Vy8=; Message-ID: <923101.73555.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: RxCgUMAVM1mA0ZVvw_J9lKlLPh980akAXdA7N3B9HSsmLfp HkqjmyMQJGjw_..b1bIjckr1VLQRk1iol.7vilFS0gOEQN4wVB2OowTJ..96 3wSrz53f7rmCIV1QjGlRZXl4URQrdvW_KE1nYNBq.FMWEnn36htheqGgnL0F nB65MT.dWbXTYh.vS3bHzZ5M4osZG2pz6Z4tse6gFR1YTpoUWhM08CHMQ6w. Kd3wKvv95QLmOLro0b3nP8hYaIOD4PxBGUxWgmkqL0RNg6fZkZMaHeM6jDU3 UaZbZLitkavH5zVZniZDVBTPDC_Vkp4xXQaf0HJK8 Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 05 May 2010 12:12:02 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 Date: Wed, 5 May 2010 12:12:02 -0700 (PDT) From: Behcet Sarikaya To: Thomas C Schmidt , multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] PMIPv6 base solution draft - tunnel convergence X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 19:12:24 -0000 Hi Thomas, all,=0AIn Appendix C Comparative Evaluation of Different Approac= hes=0AI was thinking that the main issue is so-called "tunnel convergence".= If you remember, we discussed this offline way back in January 2010.=0ATun= nel convergence =A0=0Aoccurs when different MNs =0Aconnected to the same MA= G belong to different LMA. Then if they =0Asubscribe to the same multicast = group, multicast data from several =0ALMAs are replicated at the MAG to MNs= and thus MN receives duplicate multicast data.=0ACan you please clarify wh= y the tunnel convergence is not happening in your draft? =0A=A0=0AI think w= e need to resolve this issue clearly.=0A=A0=0AThx.=0A=A0=0ABehcet=0A=0A=0A= =0A From behcetsarikaya@yahoo.com Fri May 7 08:43:21 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00B63A6887 for ; Fri, 7 May 2010 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.702 X-Spam-Level: * X-Spam-Status: No, score=1.702 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_95=3, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQTe35u53fCq for ; Fri, 7 May 2010 08:43:21 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 72B0A3A6960 for ; Fri, 7 May 2010 08:43:20 -0700 (PDT) Received: (qmail 32748 invoked by uid 60001); 7 May 2010 15:43:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273246988; bh=v0YxpXx+aum5CjrcPQP+27JRx8T9tI50j+jxi7vr+x0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=XZwEvc13eBvpRV1Sb+EuDBykATgbI14SMqwI67FYGFv+mY5LCXa2wKiaMvo0nmreep/EEaQhn0LgVeC7WjUNa9l2bNYBXofZUiNFqgW3sEenorKmvZtMYuO+idzrVxCgTuMoh1Z55/03+7yYtRdI84O+7oLmFMRFmATMPul9+48= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=DMEXehwH/4FjN2hnHswJ0OlrfCiQu7EKQQIyjS+fFwcIkgbfdlRUmwUD3YklUIZg1OrQSYRg9UWpiZqJ+E0yzyMNQKmUyICnrNPTMFBlrUf7yC5zbf6p3WP5wCbQgqsno6jGiPgCbAQUCg+gRZYsKuitCBv4PrwiZ6HzQiS5DF0=; Message-ID: <345664.28770.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: KmsKVusVM1lJAgE1YMkDfxj63EXOLJ5g_h69zJE62FUPWaK JokZjB8JxPDwzeJz9NmPj65fGe8oXPcbflxDWvep5GbHYRbRW.wRRU1Ct6uJ zgPwI2LGrDx.bKSja2gGg3kr4BkbmMmdfXHNkVIpyrPgWheoRC9MJuvPL2UR 1vNHGRL36Yhr95oFSDlgMPUtGTVSmoGahdtyZdreMxw_mS.eYHbt4h6vSAXt s84Dl51f2cEYxOHLLtZdiLHl6gQt.rvnM.FW8qFeJShBNSMT1Pfv4PQvRGGy oQJG_GjDO1CkGGPfCygwjfRyWLNe.ynWFmHHKlW40Cg6d.pDe_mMghO8- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Fri, 07 May 2010 08:43:08 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.103.269680 Date: Fri, 7 May 2010 08:43:08 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 15:43:21 -0000 The chairs have requested a meeting slot for the Maastricht IETF. If you have items you wish to discuss during the face-to-face meeting, please send the chairs an email. For Maastricht, -00 drafts must be posted by July 5th and revised drafts posted by July 12th. From Dirk.von-Hugo@telekom.de Tue May 11 01:57:14 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDEF3A6B57 for ; Tue, 11 May 2010 01:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nS-9kI8EGWT for ; Tue, 11 May 2010 01:57:14 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id CED963A6B8A for ; Tue, 11 May 2010 01:57:07 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 11 May 2010 10:56:49 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 10:56:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 10:56:39 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <345664.28770.qm@web111415.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Request for agenda items Thread-Index: Acrt/AMkyTa82yGWQdKXMGlCwiE6PQC54pKQ References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 11 May 2010 08:56:41.0028 (UTC) FILETIME=[DF707040:01CAF0E7] Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 08:57:14 -0000 Dear all, >From the official charter we should have achieved a milestone in=20 Apr 2010 Submit a document on how to tune IGMPv3/MLDv2 for mobility, = for publication as either Informational or Best Current Practice =20 Here we still have no WG draft approved but had a discussion on the = tuning and/or optimization issues after Anaheim meeting. According to = meeting minutes a cooperation between both draft authors was proposed - = have you already achieved progress here? Reason for the question is also = to identify which parts of optimization should be seen as protocol = change - so it would fit to future work items (which should also be = discussed in Maastricht). Any ideas and suggestions? For the agenda I think we additionally have to further discuss = improvements of the existing WG draft explaining the use of multicast in = PMIPv6 = http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-base-solution/= (which has also been due last month) ... Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Freitag, 7. Mai 2010 17:43 An: multimob@ietf.org Betreff: [multimob] Request for agenda items The chairs have requested a meeting slot for the Maastricht IETF. If you have items you wish to discuss during the face-to-face meeting, please send the chairs an email. For Maastricht, -00 drafts must be posted by July 5th and revised drafts posted by July 12th. =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From sunseawq@huawei.com Tue May 11 04:50:38 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2722C28C0E7 for ; Tue, 11 May 2010 04:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.858 X-Spam-Level: *** X-Spam-Status: No, score=3.858 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53hf-38aNaNv for ; Tue, 11 May 2010 04:50:37 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id CCBB228C11E for ; Tue, 11 May 2010 04:50:29 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2900HZG7JKQV@szxga01-in.huawei.com> for multimob@ietf.org; Tue, 11 May 2010 19:50:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2900K4A7JKWK@szxga01-in.huawei.com> for multimob@ietf.org; Tue, 11 May 2010 19:50:08 +0800 (CST) Received: from 756BFB16836341A ([220.114.93.18]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2900GX87J1D6@szxml01-in.huawei.com>; Tue, 11 May 2010 19:50:08 +0800 (CST) Date: Tue, 11 May 2010 19:49:58 +0800 From: Qin Wu To: Dirk.von-Hugo@telekom.de, sarikaya@ieee.org, multimob@ietf.org Message-id: <008301caf100$201595e0$2101a8c0@756BFB16836341A> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 11:50:38 -0000 SGksIGNoYWlyczoNCldlIGFyZSB3b3JraW5nIG9uIHVwZGF0aW5nIGRyYWZ0LXd1LW11bHRpbW9i LWlnbXAtbWxkLXR1bmluZyBiYXNlZCBvbiB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBBbmFo ZWltIG1lZXRpbmcuIFRoZSBwcm9ncmVzcyB3ZSBoYXZlIGlzIHdlIHJlLWV2YWx1YXRlIGRpZmZl cmVudCBkaWZmZXJlbnQgd2lyZWxlc3MgbGluayBtb2RlbHMgYW5kIGFuYWx5emUgdGhlaXIgaW1w YWN0IG9uIElHTVAvTUxEIGFuZCBhbHNvIHdlIGhhdmUgZGlzY291cGxlZCB0aGUgcHJvdG9jb2wg Y2hhbmdlIGZyb20gSUdNUC9NTEQgdHVuaW5nIG9wZXJhdGlvbiwgZXNwZWNpYWxseSB0aGUgY2hh bmdlIHRvIHRoZSBob3N0IHN0YWNrIGlzIHJlbW92ZWQuIFRoZSBuZXcgdmVyc2lvbiBJLUQgd2ls bCBiZSByZWFkeSBzb29uLg0KQXMgcmVnYXJkaW5nIHRoZSBxdWVzdGlvbiBvbiBpZGVudGlmeWlu ZyB3aGljaCBwYXJ0cyBvZiBvcHRpbWl6YXRpb24gc2hvdWxkIGJlIHNlZW4gYXMgcHJvdG9jb2wg Y2hhbmdlLCB0aGUgYW53ZXIgd2lsbCBiZSBhZGRyZXNzZWQgbGF0ZXIgaW4gdGhlIHNlcGFyYXRl IGVtYWlsLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206IDxEaXJrLnZvbi1IdWdvQHRlbGVrb20uZGU+DQpUbzogPHNhcmlrYXlhQGllZWUub3Jn PjsgPG11bHRpbW9iQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTWF5IDExLCAyMDEwIDQ6NTYg UE0NClN1YmplY3Q6IFJlOiBbbXVsdGltb2JdIFJlcXVlc3QgZm9yIGFnZW5kYSBpdGVtcw0KDQoN CkRlYXIgYWxsLA0KRnJvbSB0aGUgb2ZmaWNpYWwgY2hhcnRlciB3ZSBzaG91bGQgaGF2ZSBhY2hp ZXZlZCBhIG1pbGVzdG9uZSBpbiANCg0KQXByIDIwMTAgIFN1Ym1pdCBhIGRvY3VtZW50IG9uIGhv dyB0byB0dW5lIElHTVB2My9NTER2MiBmb3IgbW9iaWxpdHksIGZvciBwdWJsaWNhdGlvbiBhcyBl aXRoZXIgSW5mb3JtYXRpb25hbCBvciBCZXN0IEN1cnJlbnQgUHJhY3RpY2UgIA0KDQpIZXJlIHdl IHN0aWxsIGhhdmUgbm8gV0cgZHJhZnQgYXBwcm92ZWQgYnV0IGhhZCBhIGRpc2N1c3Npb24gb24g dGhlIHR1bmluZyBhbmQvb3Igb3B0aW1pemF0aW9uIGlzc3VlcyBhZnRlciBBbmFoZWltIG1lZXRp bmcuIEFjY29yZGluZyB0byBtZWV0aW5nIG1pbnV0ZXMgYSBjb29wZXJhdGlvbiBiZXR3ZWVuIGJv dGggZHJhZnQgYXV0aG9ycyB3YXMgcHJvcG9zZWQgLSBoYXZlIHlvdSBhbHJlYWR5IGFjaGlldmVk IHByb2dyZXNzIGhlcmU/IFJlYXNvbiBmb3IgdGhlIHF1ZXN0aW9uIGlzIGFsc28gdG8gaWRlbnRp Znkgd2hpY2ggcGFydHMgb2Ygb3B0aW1pemF0aW9uIHNob3VsZCBiZSBzZWVuIGFzIHByb3RvY29s IGNoYW5nZSAgLSBzbyBpdCB3b3VsZCBmaXQgdG8gZnV0dXJlIHdvcmsgaXRlbXMgKHdoaWNoIHNo b3VsZCBhbHNvIGJlIGRpc2N1c3NlZCBpbiBNYWFzdHJpY2h0KS4NCkFueSBpZGVhcyBhbmQgc3Vn Z2VzdGlvbnM/DQoNCkZvciB0aGUgYWdlbmRhIEkgdGhpbmsgd2UgYWRkaXRpb25hbGx5IGhhdmUg dG8gZnVydGhlciBkaXNjdXNzIGltcHJvdmVtZW50cyBvZiB0aGUgZXhpc3RpbmcgV0cgZHJhZnQg ZXhwbGFpbmluZyB0aGUgdXNlIG9mIG11bHRpY2FzdCBpbiBQTUlQdjYgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW11bHRpbW9iLXBtaXB2Ni1iYXNlLXNvbHV0aW9u LyAod2hpY2ggaGFzIGFsc28gYmVlbiBkdWUgbGFzdCBtb250aCkgLi4uDQoNCg0KQmVzdCByZWdh cmRzDQpEaXJrIA0KDQotLS0tLVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogbXVs dGltb2ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm11bHRpbW9iLWJvdW5jZXNAaWV0Zi5vcmdd IEltIEF1ZnRyYWcgdm9uIEJlaGNldCBTYXJpa2F5YQ0KR2VzZW5kZXQ6IEZyZWl0YWcsIDcuIE1h aSAyMDEwIDE3OjQzDQpBbjogbXVsdGltb2JAaWV0Zi5vcmcNCkJldHJlZmY6IFttdWx0aW1vYl0g UmVxdWVzdCBmb3IgYWdlbmRhIGl0ZW1zDQoNClRoZSBjaGFpcnMgaGF2ZSByZXF1ZXN0ZWQgYSBt ZWV0aW5nIHNsb3QgZm9yIHRoZSBNYWFzdHJpY2h0IElFVEYuDQpJZiB5b3UgaGF2ZSBpdGVtcyB5 b3Ugd2lzaCB0byBkaXNjdXNzIGR1cmluZyB0aGUgZmFjZS10by1mYWNlIG1lZXRpbmcsDQpwbGVh c2Ugc2VuZCB0aGUgY2hhaXJzIGFuIGVtYWlsLg0KDQpGb3IgTWFhc3RyaWNodCwgLTAwIGRyYWZ0 cw0KbXVzdCBiZSBwb3N0ZWQgYnkgSnVseSA1dGggYW5kIHJldmlzZWQgZHJhZnRzIHBvc3RlZCBi eSBKdWx5IDEydGguDQoNCg0KDQogICAgICANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptdWx0aW1vYiBtYWlsaW5nIGxpc3QNCm11bHRpbW9iQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9iDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXVsdGltb2IgbWFp bGluZyBsaXN0DQptdWx0aW1vYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tdWx0aW1vYg0K From Dirk.von-Hugo@telekom.de Tue May 11 08:26:31 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E40F3A68FE for ; Tue, 11 May 2010 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvUUiFzjWmOw for ; Tue, 11 May 2010 08:26:30 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id A9A3C3A68E8 for ; Tue, 11 May 2010 08:25:58 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 11 May 2010 17:23:34 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 17:23:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 17:23:26 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC80278480225CBA7@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20100511.235944.239993847.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Request for agenda items Thread-Index: AcrxGp39k5+gHHriQwCTmx+EqvosJQAArlsQ References: <345664.28770.qm@web111415.mail.gq1.yahoo.com><643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> <20100511.235944.239993847.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 11 May 2010 15:23:33.0985 (UTC) FILETIME=[EB709510:01CAF11D] Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:26:31 -0000 Hi all, Forwarding Hitoshis mail below... So we can expect updated drafts on IGMP/MLD tuning by both Hitoshi and = Qin before IETF-78 - sounds great, thanks a lot!=20 Regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp]=20 Gesendet: Dienstag, 11. Mai 2010 17:00 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: [multimob] Request for agenda items Hi Dirk, There was the discussion that the important thing for igmp/mld tuning draft is to provide more concrete analysis about various timers. It requires mathematical or feasible simulation basis analysis. I and my coleagues have been developing simulation code for such analytic approach and hope we'd be able to give some improvement for our draft before the next meeting. Regards, -- Hitoshi Asaeda From Akbar.Rahman@InterDigital.com Tue May 11 08:47:13 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99543A69EE for ; Tue, 11 May 2010 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhrPku-1pVk2 for ; Tue, 11 May 2010 08:47:12 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id C09A93A68C7 for ; Tue, 11 May 2010 08:47:12 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 11:47:01 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 May 2010 11:47:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 11:47:01 -0400 Message-ID: In-Reply-To: <345664.28770.qm@web111415.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Request for agenda items Thread-Index: Acrt/ADfekMVm2hCQouE2rF/Ib30OwDJONDw References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> From: "Rahman, Akbar" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 11 May 2010 15:47:01.0659 (UTC) FILETIME=[327A96B0:01CAF121] Cc: multimob@ietf.org Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:47:13 -0000 Hi Behcet/Stig, We would like to request a slot at the IETF 78 meeting to discuss our draft for enhancing multicast operation using the Dedicated Multicast LMA approach. Please note that we will have an update of our draft shortly. Also, after that update we will contact some of the other authors working on related multicast enhancements to see if they would like to merge with our draft (as per the suggestion from Anaheim). Sincerely, Akbar/Juan-Carlos/Guang -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, May 07, 2010 11:43 AM To: multimob@ietf.org Subject: [multimob] Request for agenda items The chairs have requested a meeting slot for the Maastricht IETF. If you have items you wish to discuss during the face-to-face meeting, please send the chairs an email. For Maastricht, -00 drafts must be posted by July 5th and revised drafts posted by July 12th. =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Tue May 11 08:49:58 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553A23A69EE for ; Tue, 11 May 2010 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP9Bz5OIVuH8 for ; Tue, 11 May 2010 08:49:57 -0700 (PDT) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id A427D3A6958 for ; Tue, 11 May 2010 08:49:57 -0700 (PDT) Received: (qmail 59116 invoked by uid 60001); 11 May 2010 15:49:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273592984; bh=+kQqmuyPqvFDR7vweOEV+U3HtZemJ8vV+21Ol6bypMc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H2/u4TJg1H3qFlVAn7P3QbCFdCTbBaDU9AsQMW5XiabGVuseDz1GoisPa4LA5gVzqZXuwaGpnenEvqv1sATPXNudkYDZVBXObx2JlfgEHWG7Zvb5bKEU7aFiNI2nwy7fRvqgr7KUzsHsOjPPprsZZ3blwUhMzMCJlj6aUXjeyvo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qtt/L3OgQuj+E25j1VxK0xFTPJRzwcE28l4qnYyyA47ZkSCQyZH4L849LlQa8pKfEHUJzbk4q5pkE4Y+fyIYU8AhsmsyjYYmceeexef7BZh0EnE+Lc/jKUqoRMzlGyO04QuJfUTdn/wCsMm7pw9YCZ2go/c/H5rdkozCY+fiPTI=; Message-ID: <603425.58781.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: VSaeg0MVM1kKYnHjyoBV7IINfQc.QpLJBayuCUJtMGuQ0_d .A70cskMkLcCZ1gILI9CEUsbLfQF.4CWCQ78BufWro_F7JVQivFHBL6El8Qn JheARSN4tH3gStelLbL8TqFTU_ZfWp7AAlKCAzrVDkznJjQ_N3BbfjtsLRRF RV8_GEbG_oIQBeuXoA_3LPMJkum1gqg3jsfzv2tEzbWXw8dOy6a5C_bV5qU9 B6OVgoWfPgesk9FNhs9sZY.oj3bW6QLxJB.zIB4s.vTdOtcy9cBcGlkzzQYI taFdDJVW8yZ7GTwB3cx8pO3fZj9IPU5gcV398TmZlsWuR8CtFdpezpdOwk9Y oLfsbCX7_MH23 Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 11 May 2010 08:49:44 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <345664.28770.qm@web111415.mail.gq1.yahoo.com><643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> <20100511.235944.239993847.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC80278480225CBA7@S4DE8PSAAQC.mitte.t-com.de> Date: Tue, 11 May 2010 08:49:44 -0700 (PDT) From: Behcet Sarikaya To: Dirk.von-Hugo@telekom.de, multimob@ietf.org In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480225CBA7@S4DE8PSAAQC.mitte.t-com.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:49:58 -0000 Hi Dirk,=0A=A0 This is good news.=0A=0AWe would like to see the revised dra= fts submitted soon rather than later to make good progress on MLD/IGMP base= solution charter item.=0ASimulations may continue and more results can be = reported later on.=0A=0ARegards,=0ABehcet=0A=0A=0A----- Original Message --= --=0A> From: "Dirk.von-Hugo@telekom.de" =0A> To: = multimob@ietf.org=0A> Sent: Tue, May 11, 2010 10:23:26 AM=0A> Subject: Re: = [multimob] Request for agenda items=0A> =0A> Hi all,=0AForwarding Hitoshis = mail below...=0ASo we can expect updated drafts =0A> on IGMP/MLD tuning by = both Hitoshi and Qin before IETF-78 - sounds great, thanks =0A> a lot! =0A= =0ARegards=0ADirk =0A=0A-----Urspr=FCngliche Nachricht-----=0AVon: =0A> Hit= oshi Asaeda [mailto:> href=3D"mailto:asaeda@sfc.wide.ad.jp">asaeda@sfc.wide= .ad.jp] =0AGesendet: =0A> Dienstag, 11. Mai 2010 17:00=0AAn: von Hugo, Dirk= =0ACc: > ymailto=3D"mailto:multimob@ietf.org" =0A> href=3D"mailto:multimob@= ietf.org">multimob@ietf.org=0ABetreff: Re: [multimob] =0A> Request for agen= da items=0A=0AHi Dirk,=0A=0AThere was the discussion that =0A> the importan= t thing for igmp/mld tuning=0Adraft is to provide more concrete =0A> analys= is about various timers. It=0Arequires mathematical or feasible =0A> simula= tion basis analysis.=0AI and my coleagues have been developing simulation = =0A> code for such=0Aanalytic approach and hope we'd be able to give some = =0A> improvement for=0Aour draft before the next =0A> meeting.=0A=0ARegards= ,=0A--=0AHitoshi =0A> Asaeda=0A____________________________________________= ___=0Amultimob mailing =0A> list=0A> href=3D"mailto:multimob@ietf.org">mult= imob@ietf.org=0A> href=3D"https://www.ietf.org/mailman/listinfo/multimob" t= arget=3D_blank =0A> >https://www.ietf.org/mailman/listinfo/multimob=0A=0A= =0A From shares@huawei.com Wed May 12 07:46:04 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530B228C27F for ; Wed, 12 May 2010 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft5TqPi2bpOp for ; Wed, 12 May 2010 07:46:03 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2DAD728C326 for ; Wed, 12 May 2010 07:30:05 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2B001EZ9LTJK@usaga04-in.huawei.com> for multimob@ietf.org; Wed, 12 May 2010 09:29:54 -0500 (CDT) Received: from H00901778 ([10.124.12.66]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2B002II9LPCU@usaga04-in.huawei.com> for multimob@ietf.org; Wed, 12 May 2010 09:29:53 -0500 (CDT) Date: Wed, 12 May 2010 07:29:49 -0700 From: Hares Susan In-reply-to: <345664.28770.qm@web111415.mail.gq1.yahoo.com> To: 'Behcet Sarikaya' , multimob@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acrt/CKCdIl8Nn+mRYa9kHZ7n01ExgD41DBQ References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:46:04 -0000 Behcet: I'd like to have you play with the routing demons prior to the IETF this time. Let's chat about how this can be done. Best wishes, Sue -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, May 07, 2010 8:43 AM To: multimob@ietf.org Subject: [multimob] Request for agenda items The chairs have requested a meeting slot for the Maastricht IETF. If you have items you wish to discuss during the face-to-face meeting, please send the chairs an email. For Maastricht, -00 drafts must be posted by July 5th and revised drafts posted by July 12th. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Fri May 14 08:52:55 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64A53A6B48 for ; Fri, 14 May 2010 08:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtTjwt9q5mYE for ; Fri, 14 May 2010 08:52:55 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id E37323A6B43 for ; Fri, 14 May 2010 08:52:54 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.45.120.245] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OCxBs-0005o2-5Y for multimob@ietf.org; Fri, 14 May 2010 17:52:44 +0200 Message-ID: <4BED71C7.2080405@informatik.haw-hamburg.de> Date: Fri, 14 May 2010 17:52:39 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:52:56 -0000 Hi Dirk, On 11.05.2010 10:56, Dirk.von-Hugo@telekom.de wrote: > For the agenda I think we additionally have to further discuss improvements of the existing WG draft explaining the use of multicast in PMIPv6 http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-base-solution/ (which has also been due last month) ... I guess the final steps to put in this draft have been discussed in Anaheim ... anyway, sorry for the delay ... we're about to update. Best regards, Thomas > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya > Gesendet: Freitag, 7. Mai 2010 17:43 > An: multimob@ietf.org > Betreff: [multimob] Request for agenda items > > The chairs have requested a meeting slot for the Maastricht IETF. > If you have items you wish to discuss during the face-to-face meeting, > please send the chairs an email. > > For Maastricht, -00 drafts > must be posted by July 5th and revised drafts posted by July 12th. > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Fri May 14 08:56:14 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB1E3A6B4D for ; Fri, 14 May 2010 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtyhySuQDkDU for ; Fri, 14 May 2010 08:56:13 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 5B9703A63EB for ; Fri, 14 May 2010 08:56:13 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.45.120.245] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OCxF5-0006Ln-3t for multimob@ietf.org; Fri, 14 May 2010 17:56:03 +0200 Message-ID: <4BED7292.2080705@informatik.haw-hamburg.de> Date: Fri, 14 May 2010 17:56:02 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> In-Reply-To: <345664.28770.qm@web111415.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:56:14 -0000 Hi Behcet, this is still very early to ask for agenda items. We will have an update on http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast (in particular, as pfmipv6 is in RFC editor queue) and would like to present this. There might also be an additional (new) draft ... but we should talk about this in June. Best regards, Thomas On 07.05.2010 17:43, Behcet Sarikaya wrote: > The chairs have requested a meeting slot for the Maastricht IETF. > If you have items you wish to discuss during the face-to-face meeting, > please send the chairs an email. > > For Maastricht, -00 drafts > must be posted by July 5th and revised drafts posted by July 12th. > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Fri May 14 09:05:11 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BDD53A6B4C for ; Fri, 14 May 2010 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM3UsJYbuZtu for ; Fri, 14 May 2010 09:05:10 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B79B73A6B22 for ; Fri, 14 May 2010 09:05:09 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.45.120.245] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OCxNj-0007kf-Hb for multimob@ietf.org; Fri, 14 May 2010 18:04:59 +0200 Message-ID: <4BED74AA.5050305@informatik.haw-hamburg.de> Date: Fri, 14 May 2010 18:04:58 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <674681.1458.qm@web111405.mail.gq1.yahoo.com> In-Reply-To: <674681.1458.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] PMIPv6 base solution draft - NAT issue X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:05:11 -0000 Hi Behcet, I don't think we have to address NAT issues here: NAT issues would only apply if present at the MAG. But RFC 5844 states: " o A deployment where a mobile access gateway uses an IPv4 private address with NAT [RFC3022] translation devices in the path to a local mobility anchor is not supported by this specification. " NATs outside the PMIP domain are beyond the scope of the document ... and RFC 5135 solutions could be applied fully independent of mobility management. Best, Thomas On 05.05.2010 17:55, Behcet Sarikaya wrote: > Hi Thomas, all, > Regarding draft-ietf-multimob-pmipv6-base-solution-00, Section 4.4, I was wondering if we should discuss NAT issues? > > When we deal with IPv4, IESG I think cares a lot about what happens with any NAT boxes in the path. > > Recently I came to know RFC 5135 and I think this RFC could provide some help on this issue. > > Regards, > > Behcet > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Mon May 17 07:34:05 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B6228C0EB for ; Mon, 17 May 2010 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_60=1, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCZs1ssRx28F for ; Mon, 17 May 2010 07:34:04 -0700 (PDT) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id A4F3E3A67EA for ; Mon, 17 May 2010 07:31:40 -0700 (PDT) Received: (qmail 31979 invoked by uid 60001); 17 May 2010 14:31:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274106689; bh=8QtW/ei5AS+i1Mw5QEi6T2tgtlTaRMkilLICOB1plLI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zAOWcBF2gAcHjgm7bchqF4Sc6q53aKlbXR8p5Nfcwby3crzuzDmW+Gza9MwjA8rqxRVV2WRzsGhuO0aueq1wKBjCsug/geKugefaPQ6d2A24QbMz1JSInWd21+guuRGgOkuFABC0Uc6DQi0Sv81fZEENGbqYWEWNdUR21Mda7YY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eeGdc26HzR7pgpor2N5Zpgs7QUaATxhQ8DNGR6T0Vw1yWNNbJ1syKZB+b8tA17oNU5006318oV3IUS9iWCuOLxzMm6HYgctLT+srZ6dxtnqNtGi5phCNhIzPrOYi9l9Jgu2m/bte1DcDOWlUv1Wmxx83vY/2LL5DLjMwFpwwSzA=; Message-ID: <304691.28565.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: 1_eJxPYVM1lMaw5by44Ly9iR3ZCNNHNRWSXU7fwW1J6bYu2 CdXMlDevOVY8mJHNylwoKoO8o.hsX0yOR1y7XxqpSeUWYNtvIV9j7rCigpyU kv.fGsy1jof503pKxn48g1DBlmqyia_UPQTYLEo.eGwb6Qug2lI3ENWkzh2u 5TvQqZkRgRorw4ZvLfhkkqQ0YfyOb.lR9BKDnoVQ0RdEkR05HDkP8dG4w2KE OV4yoCF5GOmrYqQqkh3Sj0pZVDZm3GB2wOvyMNjCOv62AJXRhrjaYEwsutr6 E7s.I9iafjZe01R_rgJVDegTDrBFjL3SOUjqnNF7z Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Mon, 17 May 2010 07:31:28 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <674681.1458.qm@web111405.mail.gq1.yahoo.com> <4BED74AA.5050305@informatik.haw-hamburg.de> Date: Mon, 17 May 2010 07:31:28 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , multimob@ietf.org In-Reply-To: <4BED74AA.5050305@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] PMIPv6 base solution draft - NAT issue X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:34:05 -0000 =0A=0A=0A=0A=0A> I don't think we have to address NAT issues here:=0ANAT = =0A> issues would only apply if present at the MAG. But RFC 5844 states:=0A= =0A" =0A> o=A0 A deployment where a mobile access gateway uses an IPv4 =0A>= private=0A=A0 =A0 =A0 address with NAT [RFC3022] translation devices =0A> = in the path to a=0A=A0 =A0 =A0 local mobility anchor is not supported =0A> = by this specification.=0A"=0A=0A> NATs outside the PMIP domain are beyond t= he =0A> scope of the document ... =0Aand RFC 5135 solutions could be applie= d fully =0A> independent of mobility =0Amanagement.=0A=0AIf RFC 5135 could = be applied then we have to have the proxy at the NAT device which means at = the MAG. Having NAT device at the MAG is probably not singled out by draft-= ietf-netlmm-pmip6-ipv4-support-18? =0A=0AWe should discuss these issues, ha= ving the NAT device at the MAG or after LMA. A short discussion might help.= =0A=0ARegards,=0A=0ABehcet=0A=0A=0A From sunseawq@huawei.com Mon May 17 20:34:22 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7943A6BD8 for ; Mon, 17 May 2010 20:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.648 X-Spam-Level: ** X-Spam-Status: No, score=2.648 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyOIR29cqidk for ; Mon, 17 May 2010 20:34:21 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 982643A6B5D for ; Mon, 17 May 2010 20:34:20 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2L00GBVJ90J7@szxga05-in.huawei.com> for multimob@ietf.org; Tue, 18 May 2010 11:34:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2L00285J8ZG8@szxga05-in.huawei.com> for multimob@ietf.org; Tue, 18 May 2010 11:34:11 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2L00A18J8Y03@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 18 May 2010 11:34:11 +0800 (CST) Date: Tue, 18 May 2010 11:34:10 +0800 From: Qin Wu To: Behcet Sarikaya , Dirk.von-Hugo@telekom.de, multimob@ietf.org Message-id: <019201caf63a$fac4fbb0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_F8mAB2dx2oWZf0gvpOX5mA)" X-Priority: 3 X-MSMail-priority: Normal References: <345664.28770.qm@web111415.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC80278480225C969@S4DE8PSAAQC.mitte.t-com.de> <20100511.235944.239993847.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC80278480225CBA7@S4DE8PSAAQC.mitte.t-com.de> <603425.58781.qm@web111411.mail.gq1.yahoo.com> Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 03:34:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_F8mAB2dx2oWZf0gvpOX5mA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksIGFsbDoNCkFzIHJlcXVlc3RlZCBieSBjaGFpcnMsIHdlIGhhdmUgbWFkZSBhIG5ldyB2ZXJz aW9uIG9mIGRyYWZ0LXd1LW11bHRpbW9iLWlnbXAtbWxkLXR1bmluZyhpLmUuLDAxLXZlcnNpb24p IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgcmVjaWV2ZWQgZnJvbSBBbmFoZWltIG1lZXRpbmcu IFRoZSBVUkwgbGluayBmb3IgdGhpcyBJLUQgaXMgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtd3UtbXVsdGltb2ItaWdtcC1tbGQtdHVuaW5nLTAxLnR4dA0KVGhlIG1h aW4gY2hhbmdlcyB3ZSBoYXZlIGFyZToNCmEpIFJlbW92ZSB0aGUgcmVwb3J0IG9wdGltaXphdGlv biBpbiB0aGUgc2VjdGlvbiAzLjEgYmFzZWQgb24gR29ycnkgYW5kIFN0aWcncyBzdWdnZXN0aW9u Lg0KDQpiKSBSZW1vdmUgdGhlIG9wdGltaXphdGlvbiBmb3IgbGluayB0eXBlIGluIHRoZSBzZWN0 aW9uIDMuMyBiYXNlZCBvbiBNYXJzaGFsbCBhbmQgU3VyZXNoLCBpbnN0ZWFkLCANCmFkZCB0d28g bmV3IHN1Yi1zZWN0aW9ucyB0byBkaXNjdXNzIGhvdyB0byB0dW5lIElHTVAvTUxEIGJlaGF2aW9y IGluIHRlcm1zIG9mIGRpZmZlcmVudCBsaW5rIHR5cGUgYXMgZm9sbG93czoNCjQuNy44OiBGaWx0 ZXJpbmcgdW53YW50ZWQgbXVsdGljYXN0IHBhY2tldHMgYmFzZWQgb24gbGluayB0eXBlDQo0Ljcu OTogVHVuaW5nIFJlc3BvbnNlIERlbGF5IGFjY29yZGluZyB0byBsaW5rIHR5cGUgYW5kIHN0YXR1 cw0KDQpjKSBBZGQgdHdvIG5ldyBzdWItc2VjdGlvbnMgaW4gc2VjdGlvbiAzIHRvIGRpc2N1c3MN CjMuMSBDb21wYXJpc29uIGFuYWx5c2lzIGJldHdlZW4gd2lyZWQgYW5kIHdpcmVsZXNzIG11bHRp Y2FzdCANCjMuMiAgTGluayBtb2RlbHMgYW5hbHlzaXMgZm9yIHdpcmVsZXNzIG11bHRpY2FzdA0K DQpkKSBBZGQgdGhyZWUgbmV3IHN1Yi1zZWN0aW9ucyBpbiBzZWN0aW9uIDQuMSB0byBkaXNjdXNz IA0KNC4xLjEuIEhvdyBkb2VzIEV4cGxpY2l0IHRyYWNraW5nIHdvcms/DQo0LjEuMiAgSG93IGRv ZXMgUmVwb3J0IFN1cHByZXNzaW9uIHdvcms/DQo0LjEuMyAgSG93IGRvZXMgUXVlcnkgU3VwcHJl c3Npb24gd29yaz8NCg0KZSkgQWxsIHRoZSBvdGhlciBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgY2hh bmdlcyBiYXNlZCBvbiBjb21tZW50cyBmcm9tIEltZWQsIEdvcnJ5LCBTY2htaWR0LCBXZWVzYW4g TGVlLFdpbGxpYW0uIA0KVGhhbmsgdGhlbSBmb3IgYnJpbmdpbmcgbWUgdGhvdWd0ZnVsIGRpc2N1 c3Npb24uDQoNCkFzIHJlZ2FyZGluZyB3aGljaCBwYXJ0cyBvZiBvcHRpbWl6YXRpb24gc2hvdWxk IGJlIHNlZW4gYXMgcHJvdG9jb2wgY2hhbmdlLCBJIGJlbGlldmUNCnRoZSBBY2sgbWVjaGFuaXNt IGZvciByZWxpYWJpbGl0eSBtZW50aW9uZWQgaW4gZHJhZnQtbGl1LW11bHRpbW9iLXJlbGlhYmxl LWlnbXAtbWxkLTAwDQphbmQgdGhpcyBkcmFmdCBzaG91bGQgYmUgdGFrZW4gYXMgcHJvdG9jb2wg ZXh0ZW5zaW9uIGZvciBvcHRpbWl6YXRpb24uICBUaGF0IGlzIHdoeSB3ZSByZW1vdmUgYWxsDQp0 aGUgcmVwb3J0IG9wdGltaXphdGlvbiBwYXJ0IGF0IHRoZSBob3N0IHNpZGUgZnJvbSB0aGlzIEkt RC4gQWxzbyB0aGVyZSBhcmUgc29tZQ0KZXhpc3Rpbmcgd29yayByZWxhdGVkIHRvIHRoaXMgQWNr IG1lY2hhbmlzbSBlLmcuLDoNCiINCk5pa2FlaW4sIE4uIGFuZCBCb25uZXQsIEMuICJXaXJlbGVz cyBtdWx0aWNhc3RpbmcgaW4gYW4gSVAgZW52aXJvbm1lbnQiIEluIFByb2NlZWRpbmdzIG9mIHRo ZSA1dGggSW50ZXJuYXRpb25hbCBXb3Jrc2hvcCBvbiBNb2JpbGUgTXVsdGltZWRpYSBDb21tdW5p Y2F0aW9uIE1vTXVjJzk4IChCZXJsaW4sIEdlcm1hbnksIE9jdC4gMTItMTQpLiBJRUVFIENvbXB1 dGVyIFNvY2lldHkgUHJlc3MsIDE5OTguDQoiDQpJIHdvdWxkIGxpa2UgdG8gYXNrIGFsbCB0aGUg Zm9sa3Mgd2hvIGNvbW1lbnRlZCBvbiB0aGlzIGRyYWZ0IGJlZm9yZSB0byBjaGVjaw0Kd2hldGhl ciB0aGV5IGZlZWwgc2F0aXNmYWN0b3J5IHdpdGggdGhlIGNvbnRlbnQuIENvbW1lbnRzIGZyb20g dGhlIG1hbnkgDQpjb250cmlidXRvcnMgYXMgd2VsbCBhcyBhbnlib2R5IGVsc2UgYXJlIGhpZ2hs eSBhcHByZWNpYXRlZC4gSXQgd291bGQgYmUgDQpncmVhdCB0byBnZXQgYSBkaXNjdXNzaW9uIGdv aW5nIGJlZm9yZSB0aGUgbmV4dCBtZWV0aW5nLg0KDQpSZWdhcmRzIQ0KLVFpbg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkJlaGNldCBTYXJpa2F5YSIgPGJlaGNldHNh cmlrYXlhQHlhaG9vLmNvbT4NClRvOiA8RGlyay52b24tSHVnb0B0ZWxla29tLmRlPjsgPG11bHRp bW9iQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTWF5IDExLCAyMDEwIDExOjQ5IFBNDQpTdWJq ZWN0OiBSZTogW211bHRpbW9iXSBSZXF1ZXN0IGZvciBhZ2VuZGEgaXRlbXMNCg0KDQpIaSBEaXJr LA0KVGhpcyBpcyBnb29kIG5ld3MuDQoNCldlIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSByZXZpc2Vk IGRyYWZ0cyBzdWJtaXR0ZWQgc29vbiByYXRoZXIgdGhhbiBsYXRlciB0byBtYWtlIGdvb2QgcHJv Z3Jlc3Mgb24gTUxEL0lHTVAgYmFzZSBzb2x1dGlvbiBjaGFydGVyIGl0ZW0uDQpTaW11bGF0aW9u cyBtYXkgY29udGludWUgYW5kIG1vcmUgcmVzdWx0cyBjYW4gYmUgcmVwb3J0ZWQgbGF0ZXIgb24u DQoNClJlZ2FyZHMsDQpCZWhjZXQNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0NCj4g RnJvbTogIkRpcmsudm9uLUh1Z29AdGVsZWtvbS5kZSIgPERpcmsudm9uLUh1Z29AdGVsZWtvbS5k ZT4NCj4gVG86IG11bHRpbW9iQGlldGYub3JnDQo+IFNlbnQ6IFR1ZSwgTWF5IDExLCAyMDEwIDEw OjIzOjI2IEFNDQo+IFN1YmplY3Q6IFJlOiBbbXVsdGltb2JdIFJlcXVlc3QgZm9yIGFnZW5kYSBp dGVtcw0KPiANCj4gSGkgYWxsLA0KRm9yd2FyZGluZyBIaXRvc2hpcyBtYWlsIGJlbG93Li4uDQpT byB3ZSBjYW4gZXhwZWN0IHVwZGF0ZWQgZHJhZnRzIA0KPiBvbiBJR01QL01MRCB0dW5pbmcgYnkg Ym90aCBIaXRvc2hpIGFuZCBRaW4gYmVmb3JlIElFVEYtNzggLSBzb3VuZHMgZ3JlYXQsIHRoYW5r cyANCj4gYSBsb3QhIA0KDQpSZWdhcmRzDQpEaXJrIA0KDQotLS0tLVVyc3By/G5nbGljaGUgTmFj aHJpY2h0LS0tLS0NClZvbjogDQo+IEhpdG9zaGkgQXNhZWRhIFttYWlsdG86PiBocmVmPSJtYWls dG86YXNhZWRhQHNmYy53aWRlLmFkLmpwIj5hc2FlZGFAc2ZjLndpZGUuYWQuanBdIA0KR2VzZW5k ZXQ6IA0KPiBEaWVuc3RhZywgMTEuIE1haSAyMDEwIDE3OjAwDQpBbjogdm9uIEh1Z28sIERpcmsN CkNjOiA+IHltYWlsdG89Im1haWx0bzptdWx0aW1vYkBpZXRmLm9yZyIgDQo+IGhyZWY9Im1haWx0 bzptdWx0aW1vYkBpZXRmLm9yZyI+bXVsdGltb2JAaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbbXVs dGltb2JdIA0KPiBSZXF1ZXN0IGZvciBhZ2VuZGEgaXRlbXMNCg0KSGkgRGlyaywNCg0KVGhlcmUg d2FzIHRoZSBkaXNjdXNzaW9uIHRoYXQgDQo+IHRoZSBpbXBvcnRhbnQgdGhpbmcgZm9yIGlnbXAv bWxkIHR1bmluZw0KZHJhZnQgaXMgdG8gcHJvdmlkZSBtb3JlIGNvbmNyZXRlIA0KPiBhbmFseXNp cyBhYm91dCB2YXJpb3VzIHRpbWVycy4gSXQNCnJlcXVpcmVzIG1hdGhlbWF0aWNhbCBvciBmZWFz aWJsZSANCj4gc2ltdWxhdGlvbiBiYXNpcyBhbmFseXNpcy4NCkkgYW5kIG15IGNvbGVhZ3VlcyBo YXZlIGJlZW4gZGV2ZWxvcGluZyBzaW11bGF0aW9uIA0KPiBjb2RlIGZvciBzdWNoDQphbmFseXRp YyBhcHByb2FjaCBhbmQgaG9wZSB3ZSdkIGJlIGFibGUgdG8gZ2l2ZSBzb21lIA0KPiBpbXByb3Zl bWVudCBmb3INCm91ciBkcmFmdCBiZWZvcmUgdGhlIG5leHQgDQo+IG1lZXRpbmcuDQoNClJlZ2Fy ZHMsDQotLQ0KSGl0b3NoaSANCj4gQXNhZWRhDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXVsdGltb2IgbWFpbGluZyANCj4gbGlzdA0KPiBocmVmPSJt YWlsdG86bXVsdGltb2JAaWV0Zi5vcmciPm11bHRpbW9iQGlldGYub3JnDQo+IGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2IiIHRhcmdldD1fYmxhbmsg DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRpbW9iDQoNCg0K ICAgICAgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXVsdGltb2IgbWFpbGluZyBsaXN0DQptdWx0aW1vYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYg0K --Boundary_(ID_F8mAB2dx2oWZf0gvpOX5mA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkwNCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZPg0KPERJVj5IaSwgYWxsOjwvRElWPg0KPERJVj5BcyByZXF1ZXN0ZWQgYnkgY2hh aXJzLCB3ZSBoYXZlIG1hZGUmbmJzcDthIG5ldyB2ZXJzaW9uJm5ic3A7b2YgDQpkcmFmdC13dS1t dWx0aW1vYi1pZ21wLW1sZC10dW5pbmcoaS5lLiwwMS12ZXJzaW9uKSBhY2NvcmRpbmcgdG8gdGhl IGNvbW1lbnRzIA0KcmVjaWV2ZWQgZnJvbSBBbmFoZWltIG1lZXRpbmcuIFRoZSBVUkwgbGluayBm b3IgdGhpcyBJLUQgaXMgPEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC13dS1tdWx0aW1vYi1pZ21wLW1sZC10dW5pbmctMDEudHh0Ij5odHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1tdWx0aW1vYi1pZ21wLW1sZC10dW5p bmctMDEudHh0PC9BPjwvRElWPg0KPERJVj5UaGUgbWFpbiBjaGFuZ2VzIHdlIGhhdmUgYXJlOjwv RElWPg0KPERJVj5hKSZuYnNwO1JlbW92ZSB0aGUgcmVwb3J0IG9wdGltaXphdGlvbiBpbiB0aGUg c2VjdGlvbiAzLjEmbmJzcDtiYXNlZCBvbiANCkdvcnJ5IGFuZCBTdGlnJ3Mgc3VnZ2VzdGlvbi48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmIpIFJlbW92ZSB0aGUgb3B0aW1pemF0aW9u IGZvciBsaW5rIHR5cGUgaW4gdGhlIHNlY3Rpb24gMy4zIGJhc2VkIG9uIA0KTWFyc2hhbGwgYW5k IFN1cmVzaCwgaW5zdGVhZCwgPC9ESVY+DQo8RElWPmFkZCZuYnNwO3R3byBuZXcgc3ViLXNlY3Rp b25zIHRvIGRpc2N1c3MgaG93IHRvIHR1bmUgSUdNUC9NTEQgYmVoYXZpb3IgaW4gDQp0ZXJtcyBv ZiBkaWZmZXJlbnQgbGluayB0eXBlIGFzIGZvbGxvd3M6PC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4t VVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB IiANCmxhbmc9RU4tVVM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj40LjcuODogRmlsdGVy aW5nIHVud2FudGVkIG11bHRpY2FzdCANCnBhY2tldHMgYmFzZWQgb24gbGluayB0eXBlPEJSPjQu Ny45OiBUdW5pbmcgUmVzcG9uc2UgRGVsYXkgYWNjb3JkaW5nIHRvIGxpbmsgDQp0eXBlIGFuZCBz dGF0dXM8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVT PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CjxESVY+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0la RTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1h bnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5jKSBBZGQmbmJzcDt0d28gbmV3IHN1Yi1zZWN0aW9ucyBpbiBzZWN0aW9uIDMg DQp0byBkaXNjdXNzPC9GT05UPjwvRElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWls eTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4zLjEgQ29tcGFyaXNvbiBhbmFseXNpcyBiZXR3ZWVuIHdpcmVk IA0KYW5kIHdpcmVsZXNzIG11bHRpY2FzdCA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiAN Cmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP TlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBt c28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9OVCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjMuMiZuYnNwOyBMaW5rIG1vZGVscyBhbmFseXNpcyBmb3IgDQp3aXJlbGVzcyBt dWx0aWNhc3Q8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gDQpzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVT PjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEy cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFu Z3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD48L1NQQU4+PC9TUEFOPiZuYnNwOzwvRElWPjwvU1BBTj48L0RJVj4NCjxESVY+ZCkg QWRkIHRocmVlIG5ldyBzdWItc2VjdGlvbnMgaW4gc2VjdGlvbiA0LjEgdG8gZGlzY3VzcyA8L0RJ Vj4NCjxESVY+NC4xLjEuIEhvdyBkb2VzIEV4cGxpY2l0IHRyYWNraW5nIHdvcms/PC9ESVY+DQo8 RElWPjQuMS4yJm5ic3A7IEhvdyBkb2VzIFJlcG9ydCBTdXBwcmVzc2lvbiB3b3JrPzwvRElWPg0K PERJVj40LjEuMyZuYnNwOyBIb3cgZG9lcyBRdWVyeSBTdXBwcmVzc2lvbiB3b3JrPzwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFu ZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxh bmc9RU4tVVM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5lKSBBbGwgdGhlIG90aGVyIGNo YW5nZXMgYXJlIGVkaXRvcmlhbCANCmNoYW5nZXMgYmFzZWQgb24gY29tbWVudHMgZnJvbSBJbWVk LCBHb3JyeSwgU2NobWlkdCwgV2Vlc2FuIExlZSxXaWxsaWFtLiANCjwvRk9OVD48L1NQQU4+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28t YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1V Uz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoYW5rIHRoZW0gZm9yIGJyaW5naW5nIG1l IHRob3VndGZ1bCANCmRpc2N1c3Npb24uPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElW PjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEy cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt U0EiIA0KbGFuZz1FTi1VUz48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIw MzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgt Q047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxGT05UIHNpemU9MiBm YWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjwvU1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6 IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTog QVItU0EiIA0KbGFuZz1FTi1VUz48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsm IzIwMzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog WkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+QXMgcmVnYXJkaW5nIHdoaWNoIHBhcnRzIG9mIG9wdGltaXphdGlv biANCnNob3VsZCBiZSBzZWVuIGFzIHByb3RvY29sIGNoYW5nZSwgSSBiZWxpZXZlPC9GT05UPjwv U1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRh bmc7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNO OyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48U1BBTiANCnN0eWxlPSJG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQps YW5nPUVOLVVTPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+dGhlIEFjayBtZWNoYW5pc20g Zm9yIHJlbGlhYmlsaXR5IA0KbWVudGlvbmVkIGluIGRyYWZ0LWxpdS1tdWx0aW1vYi1yZWxpYWJs ZS1pZ21wLW1sZC0wMDwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiANCnN0 eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9 RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0la RTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1h bnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPmFuZCB0aGlzIGRyYWZ0IHNob3VsZCBiZSB0YWtlbiBhcyANCnByb3RvY29sIGV4dGVuc2lv biBmb3Igb3B0aW1pemF0aW9uLiZuYnNwOyBUaGF0IGlzIHdoeSB3ZSByZW1vdmUgDQphbGw8L0ZP TlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog WkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4t VVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB IiANCmxhbmc9RU4tVVM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj50aGUgcmVwb3J0IG9w dGltaXphdGlvbiBwYXJ0IGF0IHRoZSBob3N0IA0Kc2lkZSBmcm9tIHRoaXMgSS1ELiBBbHNvIHRo ZXJlIGFyZSBzb21lPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1F Ti1VUz48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpF OiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWFu c2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+ZXhpc3Rpbmcgd29yayByZWxhdGVkIHRvIHRoaXMmbmJzcDtBY2sgDQptZWNoYW5pc20mbmJz cDtlLmcuLDo8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gDQpzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVT PjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEy cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFu Z3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4i PC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48U1BBTiAN CnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBB Ui1TQSIgDQpsYW5nPUVOLVVTPk5pa2FlaW4sIE4uIGFuZCBCb25uZXQsIEMuICJXaXJlbGVzcyBt dWx0aWNhc3RpbmcgaW4gYW4gSVAgDQplbnZpcm9ubWVudCIgSW4gUHJvY2VlZGluZ3Mgb2YgdGhl IDV0aCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIE1vYmlsZSANCk11bHRpbWVkaWEgQ29tbXVu aWNhdGlvbiBNb011Yyc5OCAoQmVybGluLCBHZXJtYW55LCBPY3QuIDEyljE0KS4gSUVFRSBDb21w dXRlciANClNvY2lldHkgUHJlc3MsIDE5OTguPC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIg DQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBG T05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7 OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+IjwvU1BBTj48L1NQQU4+PC9E SVY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05U LVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5n dWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMy MzQzNTsmIzIwMzA3OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjwvU1BB Tj48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQt U0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIz NDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIHdvdWxkIGxpa2UgdG8gYXNrIGFsbCB0aGUgZm9sa3Mg d2hvIA0KY29tbWVudGVkIG9uIHRoaXMmbmJzcDtkcmFmdCBiZWZvcmUgdG8gY2hlY2s8QlI+d2hl dGhlciB0aGV5IA0KZmVlbCZuYnNwO3NhdGlzZmFjdG9yeSB3aXRoIHRoZSZuYnNwO2NvbnRlbnQu IENvbW1lbnRzIGZyb20gdGhlIA0KbWFueSZuYnNwOzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1T SVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5n dWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0 MzU7JiMyMDMwNzs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPmNvbnRyaWJ1dG9ycyBhcyB3ZWxsIGFzIGFueWJvZHkgZWxz ZSBhcmUgDQpoaWdobHkgYXBwcmVjaWF0ZWQuIEl0IHdvdWxkIGJlIDwvRk9OVD48L1NQQU4+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28t YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1V Uz48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmdyZWF0IHRvIGdldCBhIGRpc2N1c3Npb24g Z29pbmcgYmVmb3JlIA0KdGhlIG5leHQgbWVldGluZy48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJ Vj4NCjxESVY+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQt U0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291 cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIz NDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQg c2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+PC9TUEFOPjwvU1BBTj4mbmJzcDs8 L0RJVj4NCjxESVY+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP TlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxh bmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn Q291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm IzIzNDM1OyYjMjAzMDc7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzITwvRk9OVD48L1NQQU4+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9O VC1TSVpFOiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFu Z3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYj MjM0MzU7JiMyMDMwNzs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPi1RaW48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+LS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSA8L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7 JiMyMDMwNzs+RnJvbTogIkJlaGNldCBTYXJpa2F5YSIgJmx0OzwvRk9OVD48QSANCmhyZWY9Im1h aWx0bzpiZWhjZXRzYXJpa2F5YUB5YWhvby5jb20iPjxGT05UIHNpemU9MiANCmZhY2U9JiMyMzQz NTsmIzIwMzA3Oz5iZWhjZXRzYXJpa2F5YUB5YWhvby5jb208L0ZPTlQ+PC9BPjxGT05UIHNpemU9 MiANCmZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PlRvOiAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFp bHRvOkRpcmsudm9uLUh1Z29AdGVsZWtvbS5kZSI+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1 OyYjMjAzMDc7PkRpcmsudm9uLUh1Z29AdGVsZWtvbS5kZTwvRk9OVD48L0E+PEZPTlQgc2l6ZT0y IGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4mZ3Q7OyANCiZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRv Om11bHRpbW9iQGlldGYub3JnIj48Rk9OVCBzaXplPTIgDQpmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ bXVsdGltb2JAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMy MDMwNzs+Jmd0OzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsm IzIwMzA3Oz5TZW50OiBUdWVzZGF5LCBNYXkgMTEsIDIwMTAgMTE6NDkgUE08L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+U3ViamVjdDogUmU6IFtt dWx0aW1vYl0gUmVxdWVzdCBmb3IgYWdlbmRhIA0KaXRlbXM8L0ZPTlQ+PC9ESVY+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48QlI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0ZPTlQ+PC9ESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5IaSANCkRpcmss PEJSPlRoaXMgaXMgZ29vZCBuZXdzLjxCUj48QlI+V2Ugd291bGQgbGlrZSB0byBzZWUgdGhlIHJl dmlzZWQgZHJhZnRzIA0Kc3VibWl0dGVkIHNvb24gcmF0aGVyIHRoYW4gbGF0ZXIgdG8gbWFrZSBn b29kIHByb2dyZXNzIG9uIE1MRC9JR01QIGJhc2Ugc29sdXRpb24gDQpjaGFydGVyIGl0ZW0uPEJS PlNpbXVsYXRpb25zIG1heSBjb250aW51ZSBhbmQgbW9yZSByZXN1bHRzIGNhbiBiZSByZXBvcnRl ZCBsYXRlciANCm9uLjxCUj48QlI+UmVnYXJkcyw8QlI+QmVoY2V0PEJSPjxCUj48QlI+LS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tPEJSPiZndDsgDQpGcm9tOiAiPC9GT05UPjxBIGhyZWY9Im1h aWx0bzpEaXJrLnZvbi1IdWdvQHRlbGVrb20uZGUiPjxGT05UIHNpemU9MiANCmZhY2U9JiMyMzQz NTsmIzIwMzA3Oz5EaXJrLnZvbi1IdWdvQHRlbGVrb20uZGU8L0ZPTlQ+PC9BPjxGT05UIHNpemU9 MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+IiAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOkRp cmsudm9uLUh1Z29AdGVsZWtvbS5kZSI+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1OyYjMjAz MDc7PkRpcmsudm9uLUh1Z29AdGVsZWtvbS5kZTwvRk9OVD48L0E+PEZPTlQgc2l6ZT0yIGZhY2U9 JiMyMzQzNTsmIzIwMzA3Oz4mZ3Q7PEJSPiZndDsgVG86IA0KPC9GT05UPjxBIGhyZWY9Im1haWx0 bzptdWx0aW1vYkBpZXRmLm9yZyI+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7 Pm11bHRpbW9iQGlldGYub3JnPC9GT05UPjwvQT48QlI+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz4mZ3Q7IFNlbnQ6IFR1ZSwgTWF5IA0KMTEsIDIwMTAgMTA6MjM6MjYgQU08QlI+ Jmd0OyBTdWJqZWN0OiBSZTogW211bHRpbW9iXSBSZXF1ZXN0IGZvciBhZ2VuZGEgDQppdGVtczxC Uj4mZ3Q7IDxCUj4mZ3Q7IEhpIGFsbCw8QlI+Rm9yd2FyZGluZyBIaXRvc2hpcyBtYWlsIGJlbG93 Li4uPEJSPlNvIHdlIGNhbiANCmV4cGVjdCB1cGRhdGVkIGRyYWZ0cyA8QlI+Jmd0OyBvbiBJR01Q L01MRCB0dW5pbmcgYnkgYm90aCBIaXRvc2hpIGFuZCBRaW4gYmVmb3JlIA0KSUVURi03OCAtIHNv dW5kcyBncmVhdCwgdGhhbmtzIDxCUj4mZ3Q7IGEgbG90ISA8QlI+PEJSPlJlZ2FyZHM8QlI+RGly ayANCjxCUj48QlI+LS0tLS1VcnNwcvxuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPEJSPlZvbjogPEJS PiZndDsgSGl0b3NoaSBBc2FlZGEgDQpbbWFpbHRvOiZndDsgaHJlZj0iPC9GT05UPjxBIA0KaHJl Zj0nbWFpbHRvOmFzYWVkYUBzZmMud2lkZS5hZC5qcCI+YXNhZWRhQHNmYy53aWRlLmFkLmpwJz48 Rk9OVCBzaXplPTIgDQpmYWNlPSYjMjM0MzU7JiMyMDMwNzs+bWFpbHRvOmFzYWVkYUBzZmMud2lk ZS5hZC5qcCImZ3Q7YXNhZWRhQHNmYy53aWRlLmFkLmpwPC9GT05UPjwvQT48Rk9OVCANCnNpemU9 MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+XSA8QlI+R2VzZW5kZXQ6IDxCUj4mZ3Q7IERpZW5zdGFn LCAxMS4gTWFpIDIwMTAgMTc6MDA8QlI+QW46IHZvbiANCkh1Z28sIERpcms8QlI+Q2M6ICZndDsg eW1haWx0bz0iPC9GT05UPjxBIGhyZWY9Im1haWx0bzptdWx0aW1vYkBpZXRmLm9yZyI+PEZPTlQg DQpzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pm1haWx0bzptdWx0aW1vYkBpZXRmLm9yZzwv Rk9OVD48L0E+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4iIA0KPEJSPiZndDsg aHJlZj0iPC9GT05UPjxBIA0KaHJlZj0nbWFpbHRvOm11bHRpbW9iQGlldGYub3JnIj5tdWx0aW1v YkBpZXRmLm9yZyc+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pm1haWx0bzpt dWx0aW1vYkBpZXRmLm9yZyImZ3Q7bXVsdGltb2JAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9O VCANCnNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+QmV0cmVmZjogUmU6IFttdWx0aW1vYl0g PEJSPiZndDsgUmVxdWVzdCBmb3IgYWdlbmRhIA0KaXRlbXM8QlI+PEJSPkhpIERpcmssPEJSPjxC Uj5UaGVyZSB3YXMgdGhlIGRpc2N1c3Npb24gdGhhdCA8QlI+Jmd0OyB0aGUgDQppbXBvcnRhbnQg dGhpbmcgZm9yIGlnbXAvbWxkIHR1bmluZzxCUj5kcmFmdCBpcyB0byBwcm92aWRlIG1vcmUgY29u Y3JldGUgDQo8QlI+Jmd0OyBhbmFseXNpcyBhYm91dCB2YXJpb3VzIHRpbWVycy4gSXQ8QlI+cmVx dWlyZXMgbWF0aGVtYXRpY2FsIG9yIGZlYXNpYmxlIA0KPEJSPiZndDsgc2ltdWxhdGlvbiBiYXNp cyBhbmFseXNpcy48QlI+SSBhbmQgbXkgY29sZWFndWVzIGhhdmUgYmVlbiBkZXZlbG9waW5nIA0K c2ltdWxhdGlvbiA8QlI+Jmd0OyBjb2RlIGZvciBzdWNoPEJSPmFuYWx5dGljIGFwcHJvYWNoIGFu ZCBob3BlIHdlJ2QgYmUgYWJsZSB0byANCmdpdmUgc29tZSA8QlI+Jmd0OyBpbXByb3ZlbWVudCBm b3I8QlI+b3VyIGRyYWZ0IGJlZm9yZSB0aGUgbmV4dCA8QlI+Jmd0OyANCm1lZXRpbmcuPEJSPjxC Uj5SZWdhcmRzLDxCUj4tLTxCUj5IaXRvc2hpIDxCUj4mZ3Q7IA0KQXNhZWRhPEJSPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm11bHRpbW9iIG1haWxp bmcgDQo8QlI+Jmd0OyBsaXN0PEJSPiZndDsgaHJlZj0iPC9GT05UPjxBIA0KaHJlZj0nbWFpbHRv Om11bHRpbW9iQGlldGYub3JnIj5tdWx0aW1vYkBpZXRmLm9yZyc+PEZPTlQgc2l6ZT0yIA0KZmFj ZT0mIzIzNDM1OyYjMjAzMDc7Pm1haWx0bzptdWx0aW1vYkBpZXRmLm9yZyImZ3Q7bXVsdGltb2JA aWV0Zi5vcmc8L0ZPTlQ+PC9BPjxCUj48Rk9OVCANCnNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMw Nzs+Jmd0OyBocmVmPSI8L0ZPTlQ+PEEgDQpocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL211bHRpbW9iIj48Rk9OVCBzaXplPTIgDQpmYWNlPSYjMjM0MzU7JiMyMDMw Nzs+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYjwvRk9OVD48 L0E+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7PiIgdGFyZ2V0PV9ibGFuayA8 QlI+Jmd0OyANCiZndDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL211bHRp bW9iPEJSPjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm11bHRpbW9iIG1h aWxpbmcgDQpsaXN0PEJSPjwvRk9OVD48QSBocmVmPSJtYWlsdG86bXVsdGltb2JAaWV0Zi5vcmci PjxGT05UIHNpemU9MiANCmZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5tdWx0aW1vYkBpZXRmLm9yZzwv Rk9OVD48L0E+PEJSPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tdWx0aW1vYiI+PEZPTlQgc2l6ZT0yIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2I8L0ZPTlQ+PC9BPjxCUj48 L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_F8mAB2dx2oWZf0gvpOX5mA)-- From root@core3.amsl.com Tue May 25 12:45:01 2010 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E676E3A6970; Tue, 25 May 2010 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100525194501.E676E3A6970@core3.amsl.com> Date: Tue, 25 May 2010 12:45:01 -0700 (PDT) Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-01.txt Pages : 19 Date : 2010-05-25 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25123404.I-D@ietf.org> --NextPart-- From schmidt@informatik.haw-hamburg.de Tue May 25 12:54:44 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F073A6980 for ; Tue, 25 May 2010 12:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18O62Ey1PQ7y for ; Tue, 25 May 2010 12:54:42 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3216A3A6943 for ; Tue, 25 May 2010 12:54:42 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OH0Cu-000FnZ-IV for multimob@ietf.org; Tue, 25 May 2010 21:54:32 +0200 Message-ID: <4BFC2AF4.90001@informatik.haw-hamburg.de> Date: Tue, 25 May 2010 21:54:28 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100525194501.E676E3A6970@core3.amsl.com> In-Reply-To: <20100525194501.E676E3A6970@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 19:54:44 -0000 Hi all, we just submitted the updated version of draft-ietf-multimob-pmipv6-base-solution as discussed in Anaheim. From the change log: 1. Added section on multihoming. 2. Updated security section. 3. Several editorial improvements and minor extensions. Please have a firm look ;) so that we can finalize the document. Thanks, Thomas On 25.05.2010 21:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multicast Mobility Working Group of the IETF. > > > Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains > Author(s) : T. Schmidt, et al. > Filename : draft-ietf-multimob-pmipv6-base-solution-01.txt > Pages : 19 > Date : 2010-05-25 > > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast > subscription anchor points, while Mobile Access Gateways provide MLD > proxy functions. In this scenario, Mobile Nodes remain agnostic of > multicast mobility operations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Tue May 25 17:34:52 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462513A6BA9 for ; Tue, 25 May 2010 17:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.834 X-Spam-Level: *** X-Spam-Status: No, score=3.834 tagged_above=-999 required=5 tests=[BAYES_99=3.5, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wnJpi7gFPKO for ; Tue, 25 May 2010 17:34:50 -0700 (PDT) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id C12C73A7791 for ; Tue, 25 May 2010 15:41:30 -0700 (PDT) Received: (qmail 41113 invoked by uid 60001); 25 May 2010 22:41:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274827279; bh=80Lf1Z/ZAuM2r9+dxquVAdeqXh7bhCj8+VKZulkSZmU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f31//W2IiKV2nSPBUb4v0f03hmphDE6yWuDkugN1IqCFT2N5yaIFWrNaR8W3XJGS+ybR50exDvx1A/6dqzBXnSADZeV8Y+k/fVaNc1j6lqHU+4gwcM5OdFg9dbsRdTbNSF1IWUV/bVruxNi9cFROlScUmafXyrwz066xzzuYC5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=c8EfAj5OEx7gBiUBxTLyvF5g9FEkJO9mbova6ANRauq2ieCm5hcp34BJT7MgWMYx82RP7rU2Kew7WTyeSZrk1qbe6mghCMi71IiNr3J03/aQr3rqStm3k+3AkVK6ifdlKcZ+x5zjZnaOLiz15Dm468sZBNFd/B1lKvQ4phWXzQM=; Message-ID: <617906.39969.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: Hc.aUQUVM1mE5fmXsohw3myM5Psctqo8EPPfnTOgzDlwlsc skpoFI7dkr6Kgu4iTmwVANG8F_oSReJYru0qrvfLSeLbcx7JNTBGuPaA6XKW vXtB07mpnxrrreH_GdVSLEgL2xyfJnKQZchf.s7OLJ8nekQbSDuw5lgDiS0p irVpJth9ZXnp2ioYW.WufXEjUMDBoAihV6kCjAQTGgYbgLzS31WfsoE75dht vPud5g1wQlXBrcbPA8D5IQP6VJPGkEvi7it8GkQpmRbo2VyFmug68JSOEttg gypOH.PESOkhOU3gd5LxX0Mk3RlmThv8Q5lq.vdELV6IZcf3CoRXN8jRcU0b uMZvVEXJj1fLlNXE- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Tue, 25 May 2010 15:41:19 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <20100525194501.E676E3A6970@core3.amsl.com> Date: Tue, 25 May 2010 15:41:19 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: <20100525194501.E676E3A6970@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:34:52 -0000 Hi Thomas,=0A=A0 My comments below.=0A=0ARegards,=0A=0ABehcet=0A=0AAbstract= =0A=A0=A0 This document describes deployment options for activating multica= st=0A=A0=A0 listener functions in Proxy Mobile IPv6 domains without modifyi= ng=0A=A0=A0 mobility and multicast protocol standards.=A0 Similar to Home A= gents in=0A=A0=A0 Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multi= cast=0As/PMIPv6/Proxy Mobile IPv6=0A=A0=A0 subscription anchor points, whil= e Mobile Access Gateways provide MLD=0As/MLD/Multicast Listener Discovery= =0A=A0=A0 proxy functions.=A0 In this scenario, Mobile Nodes remain agnosti= c of=0A=A0=A0 multicast mobility operations.=0A=0A1.=A0 Introduction=0A=A0= =A0 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by= =0A=A0=A0 network-based management functions that enable IP mobility for a = host=0A=A0=A0 without requiring its participation in any mobility-related= =0A=A0=A0 signaling.=A0 Additional network entities called the Local Mobili= ty=0A=A0=A0 Anchor (LMA), and Mobile Access Gateways (MAGs), are responsibl= e for=0A=A0=A0 managing IP mobility on behalf of the mobile node (MN).=0A= =A0=A0 With these entities in place, the mobile node looses transparent end= -=0A=A0=A0 to-end connectivity to the static Internet, and in the particula= r=0A=A0=A0 case of multicast communication, group membership management as= =0A=A0=A0 signaled by the Multicast Listener Discovery protocol [RFC3810],= =0A=A0=A0 [RFC2710] requires dedicated treatment at the network side, see= =0A=A0=A0 [I-D.deng-multimob-pmip6-requirement].=0A[Behcet] Replace this re= f with a more recent draft, e.g. draft-von-hugo-multimob-future-work=0A=A0= =A0 Multicast routing functions need to be placed carefully within the=0A= =A0=A0 PMIPv6 domain to augment unicast transmission with group=0As/PMIPv6/= Proxy Mobile IPv6=0A=A0=A0 communication services.=A0 [RFC5213] does not ex= plicitly address=0A=A0=A0 multicast communication and relies on the minimal= multicast support=0A=A0=A0 provided by MIPv6.=A0 But unfortunately bi-dire= ctional home tunneling,=0A=A0=A0 the minimal multicast support arranged by = MIPv6, cannot be applied in=0A=A0=A0 network-based management scenarios, si= nce a mobility-unaware node=0A=A0=A0 will not initiate such a tunnel after = movement.=0A[behcet] The above paragraph needs to be rewritten to state tha= t PMIPv6 does not explicitly address multicast communication. =0AIt was a c= hoice to design multicast extension for PMIPv6 similar to MIPv6 but due to = the inefficiencies=0Ainvolved in bi-directional home tunneling a proxy base= d solution described in this document has=0Ainstead been opted for. =0A[beh= cet] please add several sentences on why proxy approach is better (as has b= een discussed on ML).=0A=A0=A0 This document describes options for deployin= g multicast listener=0A=A0=A0 functions in Proxy Mobile IPv6 domains withou= t modifying mobility and=0A=A0=A0 multicast protocol standards.=A0 Similar = to Home Agents in Mobile IPv6,=0A=A0=A0 PMIPv6 Local Mobility Anchors serve= as multicast subscription anchor=0As/PMIPv6/Proxy Mobile IPv6 (everywhere)= =0A=A0=A0 points, while Mobile Access Gateways provide MLD proxy functions.= =0As/MLD/Multicast Listener Discovery (everywhere)=0A=A0=A0 Mobile Nodes in= this scenario remain agnostic of multicast mobility=0A=A0=A0 operations.= =A0 This document does not address specific optimizations=0A=A0=A0 and effi= ciency improvements of multicast routing for network-based=0A=A0=A0 mobilit= y discussed in [RFC5757], as such solutions would require=0A=A0=A0 changes = to the base PMIPv6 protocol [RFC5213].=0As/PMIPv6/Proxy Mobile IPv6=0A=0A2.= =A0 Terminology=0A=A0=A0 This document uses the terminology as defined for = the mobility=0A=A0=A0 protocols [RFC3775] and [RFC5213], as well as the mul= ticast edge=0A=A0=A0 related protocols [RFC3810] and [RFC4605].=0A[behcet] = add RFC 5844 and IGMP RFCs=0A3.=A0 Overview=0A=A0=A0 The reference scenario= for multicast deployment in Proxy Mobile IPv6=0As/scenario/network=0A=A0= =A0 domains is illustrated in Figure 1.=0A=0A=A0=A0 An MN in a PMIPv6 domai= n will decide on multicast group membership=0As/MN/mobile node (everywhere)= =0A=A0=A0 management completely independent of its current mobility conditi= ons.=0A=A0=A0 It will submit MLD Report and Done messages, based on applica= tion=0A=A0=A0 triggers, using its link-local source address and multicast= =0A=A0=A0 destination addresses according to [RFC3810], or [RFC2710].=A0 Th= ese=0A=A0=A0 link-local signaling messages will arrive at the currently act= ive MAG=0A=A0=A0 via one of its downstream local (wireless) links.=A0 A mul= ticast=0A=A0=A0 unaware MAG would simply discard these MLD messages.=0A=A0= =A0 To facilitate multicast in a PMIPv6 domain, an MLD proxy function=0A=A0= =A0 [RFC4605] needs to be deployed on the MAG that selects the tunnel=0A=A0= =A0 interface corresponding to the MN's LMA for its upstream interface=0As/= LMA/Local Mobility Anchor (everywhere)=0A=A0=A0 (cf., section 6 of [RFC5213= ]).=A0 Thereby, each MAG-to-LMA tunnel=0As/MAG/Mobile Access Gateway (every= where)=0A=A0=A0 interface defines an MLD proxy domain at the MAG, and it co= ntains all=0A=0A=A0=A0 downstream links to MNs that share this specific LMA= .=A0 According to=0A=A0=A0 standard proxy operations, MLD Report messages w= ill be forwarded=0A=A0=A0 under aggregation up the tunnel interface to its = corresponding LMA.=0A=A0=A0 Serving as the designated multicast router or a= n additional MLD=0A=A0=A0 proxy, the LMA will transpose any MLD message fro= m a MAG into the=0A=A0=A0 multicast routing infrastructure.=A0 Correspondin= gly, the LMA will=0A=A0=A0 create appropriate multicast forwarding states a= t its tunnel=0A=A0=A0 interface.=A0 Traffic arriving for subscribed groups = will arrive at the=0A=A0=A0 LMA, and the LMA will forward this traffic acco= rding to its group/=0A=A0=A0 source states.=A0 In addition, the LMA will ac= t as an MLD querier,=0A=A0=A0 seeing its downstream tunnel interfaces as mu= lticast enabled links.=0A=A0=A0 At the MAG, MLD queries and multicast data = will arrive on the=0A=A0=A0 (tunnel) interface that is assigned to a group = of access links as=0A=A0=A0 identified by its Binding Update List (cf., sec= tion 6 of [RFC5213]).=0A=A0=A0 As specified for MLD proxies, the MAG will f= orward multicast traffic=0A=A0=A0 and initiate related signaling down the a= ppropriate access links to=0A=A0=A0 the MNs.=A0 Hence all multicast-related= signaling and the data traffic=0A=A0=A0 will transparently flow from the L= MA to the MN on an LMA-specific=0A=A0=A0 tree, which is shared among the mu= lticast sources.=0A=A0=A0 In case of a handover, the MN (unaware of IP mobi= lity) will not send=0A=A0=A0 unsolicited MLD reports.=A0 Instead, the MAG i= s required to maintain=0A=A0=A0 group memberships in the following way.=A0 = On observing a new MN on a=0A=A0=A0 downstream access link, the MAG sends a= General MLD Query.=A0 Based on=0A=A0=A0 its outcome and the multicast grou= p states previously maintained at=0A=A0=A0 the MAG, a corresponding Report = will be sent to the LMA aggregating=0A=A0=A0 group membership states accord= ing to the proxy function.=A0 Additional=0A=A0=A0 Reports can be omitted wh= en the previously established multicast=0A=A0=A0 forwarding states at the n= ew MAG already cover the subscriptions of=0A=A0=A0 the MN.=0A=A0=A0 In summ= ary, the following steps are executed on handover:=0A=A0=A0 1.=A0 The MAG-M= N link comes up and the MAG discovers the new MN.=0A=A0=A0 2.=A0 Unicast ad= dress configuration and PMIPv6 binding are performed=0A=A0=A0=A0=A0=A0=A0 a= fter the MAG determines the corresponding LMA.=0A=A0=A0 3.=A0 Following IPv= 6 address configuration, the MAG SHOULD send an=0A=A0=A0=A0=A0=A0=A0 (early= ) MLD General Query to the new downstream link as part of=0A=A0=A0=A0=A0=A0= =A0 its standard multicast-enabled router operations.=0A=A0=A0 4.=A0 The MA= G SHOULD determine whether the MN is admissible to=0A=A0=A0=A0=A0=A0=A0 mul= ticast services, and stop here otherwise.=0A=0A=A0=A0 5.=A0 The MAG adds th= e new downstream link to the MLD proxy instance=0A=A0=A0=A0=A0=A0=A0 with u= p-link to the corresponding LMA.=0A=A0=A0 6.=A0 The corresponding Proxy ins= tance triggers an MLD General Query on=0A=A0=A0=A0=A0=A0=A0 the new downstr= eam link.=0A=A0=A0 7.=A0 The MN Membership Reports arrive at the MAG, eithe= r in response=0A=A0=A0=A0=A0=A0=A0 to the early Query or to that of the Pro= xy instance.=0A=A0=A0 8.=A0 The Proxy processes the MLD Report, updates sta= tes and reports=0A=A0=A0=A0=A0=A0=A0 upstream if necessary.=0A=A0=A0 After = Re-Binding, the LMA is not required to issue a General MLD=0A=A0=A0 Query o= n the tunnel link to refresh forwarding states=0A[behcet]unless there was a= change in the aggregate state.=A0 =0A=A0=A0 Multicast=0A=A0=A0 state updat= es SHOULD be triggered by the MAG, which aggregates=0A=A0=A0 subscriptions = of all its MNs (see the call flow in Figure 2).=0A=0A=A0=A0 These multicast= deployment considerations likewise apply for mobile=0A=A0=A0 nodes that op= erate with their IPv4 stack enabled in a PMIPv6 domain.=0A=A0=A0 PMIPv6 can= provide IPv4 home address mobility support [RFC5844].=0A=A0=A0 Such mobile= nodes will use IGMP [RFC2236],[RFC3376] signaling for=0A=A0=A0 multicast, = which is handled by an IGMP proxy function at the MAG in=0A=A0=A0 an analog= ous way.=0A=A0=A0 Following these deployment steps, multicast management tr= ansparently=0A=0A=A0=A0 inter-operates with PMIPv6.=A0 It is worth noting t= hat multicast=0A=A0=A0 streams can possibly be distributed on redundant pat= hs that lead to=0A=A0=A0 duplicate traffic arriving from different LMAs at = one MAG, and can=0A=A0=A0 cause multiple data transmissions from an MAG ove= r one wireless=0A=A0=A0 domain to different MNs.=0A[behcet] This is called = tunnel convergence problem, see Appendix C for further considerations.=0A= =A0=A0=A0 (see Appendix C for further considerations).=0A[behcet] maybe rem= ove=0A4.=A0 Deployment Details=0A=A0=A0 Multicast activation in a PMIPv6 do= main requires to deploy general=0A=A0=A0 multicast functions at PMIPv6 rout= ers and to define its interaction=0A=A0=A0 with the PMIPv6 protocol in the = following way:=0A4.1.=A0 Operations of the Mobile Node=0A=A0=A0 A Mobile No= de willing to manage multicast traffic will join, maintain=0A=A0=A0 and lea= ve groups as if located in the fixed Internet.=A0 No specific=0A=A0=A0 mobi= lity actions nor implementations are required at the MN.=0A4.2.=A0 Operatio= ns of the Mobile Access Gateway=0A=A0=A0 A Mobility Access Gateway is requi= red to assist in MLD signaling and=0As/Mobility Access Gateway/Mobile Acces= s Gateway=0A=A0=A0 data forwarding between the MNs which it serves, and the= =0A=A0=A0 corresponding LMAs associated to each MN.=A0 It therefore needs t= o=0A=A0=A0 implement an instance of the MLD proxy function [RFC4605] for ea= ch=0A=A0=A0 upstream tunnel interface that has been established with an LMA= .=A0 The=0A=A0=A0 MAG decides on the mapping of downstream links to a proxy= instance=0A=A0=A0 (and hence an upstream link to an LMA) based on the regu= lar Binding=0A=A0=A0 Update List as maintained by PMIPv6 standard operation= s (cf., section=0A=A0=A0 6.1 of [RFC5213]).=A0 As links connecting MNs and = MAGs change under=0A=A0=A0 mobility, MLD proxies at MAGs MUST be able to dy= namically add and=0A=A0=A0 remove downstream interfaces in its configuratio= n.=0A=A0=A0 On the reception of MLD reports from an MN, the MAG MUST identi= fy the=0A=A0=A0 corresponding proxy instance from the incoming interface an= d perform=0A=A0=A0 regular MLD proxy operations: it will insert/update/remo= ve multicast=0A=A0=A0 forwarding state on the incoming interface, and will = merge state=0A=A0=A0 updates into the MLD proxy membership database.=A0 It = will then send an=0A=A0=A0 aggregated Report to the upstream tunnel to the = LMA when the=0A=A0=A0 membership database (cf., section 4.1 of [RFC4605]) c= hanges.=0A=A0=A0 Conversely, on the reception of MLD Queries, the MAG proxy= instance=0A=A0=A0 will answer the Queries on behalf of all active downstre= am receivers=0A=A0=A0 maintained in its membership database.=A0 Queries sen= t by the LMA do=0A=A0=A0 not force the MAG to trigger corresponding message= s immediately=0A=A0=A0 towards MNs.=A0 Multicast traffic arriving at the MA= G on an upstream=0A=A0=A0 interface will be forwarded according to the grou= p/source-specific=0A=A0=A0 forwarding states as acquired for each downstrea= m interface within=0A=A0=A0 the MLD proxy instance.=A0 At this stage, it is= important to note that=0A=0A=0A=A0=A0 IGMP/MLD proxy implementations capab= le of multiple instances are=0A=A0=A0 expected to closely follow the specif= ications of section 4.2 in=0A=A0=A0 [RFC4605], i.e., treat proxy instances = in isolation of each other=0A=A0=A0 while forwarding.=0A=A0=A0 After a hand= over, the MAG will continue to manage upstream tunnels=0A=A0=A0 and downstr= eam interfaces as specified in the PMIPv6 specification.=0A=A0=A0 It MUST d= ynamically associate new access links to proxy instances=0A=A0=A0 that incl= ude the upstream connection to the corresponding LMA.=A0 The=0A=A0=A0 MAG d= etects the arrival of a new MN by receiving a router=0A=A0=A0 solicitation = message and by an upcoming link.=A0 To learn about=0A=A0=A0 multicast group= s subscribed by a newly attaching MN, the MAG SHOULD=0A=A0=A0 send a Genera= l Query to the MN's link.=A0 Querying an upcoming=0A=A0=A0 interface is a s= tandard operation of MLD queriers (see Appendix A)=0A=A0=A0 and is performe= d immediately after address configuration.=A0 In=0A=A0=A0 addition, an MLD = query SHOULD be initiated by the proxy instance, as=0A=A0=A0 soon as a new = interface has been configured for downstream.=A0 In case,=0A=A0=A0 the acce= ss link between MN and MAG goes down, interface-specific=0A=A0=A0 multicast= states change.=A0 Both cases may alter the composition of the=0A=A0=A0 mem= bership database and this will trigger corresponding Reports=0A=A0=A0 towar= ds the LMA.=A0 Note that the actual observable state depends on=0A=A0=A0 th= e access link model in use.=0A=A0=A0 An MN may be unable to answer MAG mult= icast membership queries due to=0A=A0=A0 handover procedures, or its report= may arrive before the MAG has=0A=A0=A0 configured its link as proxy downst= ream interface.=A0 Such occurrences=0A=A0=A0 are equivalent to a General Qu= ery loss.=A0 To prevent erroneous query=0A=A0=A0 timeouts at the MAG, MLD p= arameters SHOULD be carefully adjusted to=0A=A0=A0 the mobility regime.=A0 = In particular, MLD timers and the Robustness=0A=A0=A0 Variable (see section= 9 of [RFC3810]) MUST be chosen to be compliant=0A=A0=A0 with the time scal= e of handover operations and proxy configurations=0A=A0=A0 in the PMIPv6 do= main.=0A=A0=A0 In proceeding this way, the MAG is able to aggregate multica= st=0A=A0=A0 subscriptions for each of its MLD proxy instances.=A0 However, = this=0A=A0=A0 deployment approach does not prevent multiple identical strea= ms=0A=A0=A0 arriving from different LMA upstream interfaces.Furthermore, a= =0A=A0=A0 multipoint channel forwarding into the wireless domain is prevent= ed=0A=A0=A0 by the point-to-point link model in use.=0A4.3.=A0 Operations o= f the Local Mobility Anchor=0A=A0=A0 For any MN, the Local Mobility Anchor = acts as the persistent Home=0A=A0=A0 Agent and at the same time as the defa= ult multicast querier for the=0A=A0=A0 corresponding MAG.=A0 It implements = the function of the designated=0A=A0=A0 multicast router or a further MLD p= roxy.=A0 According to MLD reports=0A=A0=A0 received from a MAG (on behalf o= f the MNs), it establishes/maintains/=0A=A0=A0 removes group/source-specifi= c multicast forwarding states at its=0A=0A=A0=A0 corresponding downstream t= unnel interfaces.=A0 At the same time, it=0A=A0=A0 procures for aggregated = multicast membership maintenance at its=0A=A0=A0 upstream interface.=A0 Bas= ed on the multicast-transparent operations of=0A=A0=A0 the MAGs, the LMA tr= eats its tunnel interfaces as multicast enabled=0A=A0=A0 downstream links, = serving zero to many listening nodes.=A0 Multicast=0A=A0=A0 traffic arrivin= g at the LMA is transparently forwarded according to=0A=A0=A0 its multicast= forwarding information base.=0As/information base/database (?)=0A=A0=A0 Af= ter a handover, the LMA will receive Binding De-Registrations and=0A=A0=A0 = Binding Lifetime Extensions that will cause a re-mapping of home=0A=A0=A0 n= etwork prefix(es) to a new Proxy-CoA in its Binding Cache (see=0A=A0=A0 sec= tion 5.3 of [RFC5213]).=A0 The multicast forwarding states require=0A=A0=A0= updating, as well, if the MN within an MLD proxy domain is the only=0A=A0= =A0 receiver of a multicast group.=A0 Two different cases need to be=0A=A0= =A0 considered:=0A=A0=A0 1.=A0 The mobile node is the only receiver of a gr= oup behind the=0A=A0=A0=A0=A0=A0=A0 interface at which a De-Registration wa= s received: The membership=0A=A0=A0=A0=A0=A0=A0 database of the MAG changes= , which will trigger a Report/Done=0A=A0=A0=A0=A0=A0=A0 sent via the MAG-to= -LMA interface to remove this group.=A0 The LMA=0A=A0=A0=A0=A0=A0=A0 thus t= erminates multicast forwarding.=0A=A0=A0 2.=A0 The mobile node is the only = receiver of a group behind the=0A=A0=A0=A0=A0=A0=A0 interface at which a Li= fetime Extension was received: The=0A=A0=A0=A0=A0=A0=A0 membership database= of the MAG changes, which will trigger a=0A=A0=A0=A0=A0=A0=A0 Report sent = via the MAG-to-LMA interface to add this group.=A0 The=0A=A0=A0=A0=A0=A0=A0= LMA thus starts multicast distribution.=0A=A0=A0 In proceeding this way, e= ach LMA will provide transparent multicast=0A=A0=A0 support for the group o= f MNs it serves.=A0 It will perform traffic=0A=A0=A0 aggregation at the MN-= group level and will assure that multicast data=0A=A0=A0 streams are unique= ly forwarded per individual LMA-to-MAG tunnel.=0A4.4.=A0 IPv4 Support=0A=A0= =A0 An MN in a PMIPv6 domain may use an IPv4 address transparently for=0A= =A0=A0 communication as specified in [RFC5844].=A0 For this purpose, LMAs c= an=0A=A0=A0 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can pro= vide=0A=A0=A0 IPv4 support in access networks.=A0 Correspondingly, multicas= t=0A=A0=A0 membership management will be performed by the MN using IGMP.=A0= For=0A=A0=A0 multicast support on the network side, an IGMP proxy function= needs=0A=A0=A0 to be deployed at MAGs in exactly the same way as for IPv6.= =0A=A0=A0 [RFC4605] defines IGMP proxy behaviour in full agreement with IPv= 6/=0A=A0=A0 MLD.=A0 Thus IPv4 support can be transparently provided followi= ng the=0A=A0=A0 obvious deployment analogy.=0A=A0=A0 For a dual-stack IPv4/= IPv6 access network, the MAG proxy instances=0A=A0=A0 SHOULD choose multica= st signaling according to address configurations=0A=A0=A0 on the link, but = MAY submit IGMP and MLD queries in parallel, if=0A=A0=A0 needed.=A0 It shou= ld further be noted that the infrastructure cannot=0A=A0=A0 identify two da= ta streams as identical when distributed via an IPv4=0A=A0=A0 and IPv6 mult= icast group.=A0 Thus duplicate data may be forwarded on a=0A=A0=A0 heteroge= neous network layer.=0A[behcet] Add here one paragraph on NAT issue and a= =A0 reference to RFC 5135=0A4.5.=A0 Multihoming Support=0A=A0=A0 An MN can = connect to a PMIPv6 domain through multiple interfaces and=0A=A0=A0 experie= nce transparent unicast handovers at all interfaces (cf.,=0A=A0=A0 section = 5.4 of [RFC5213]).=A0 In such simultaneous access scenario, it=0A=A0=A0 can= autonomously assign multicast channel subscriptions to individual=0A=A0=A0= interfaces.=A0 While doing so, multicast mobility operations described=0A= =A0=A0 in this document will transparently preserve the association of=0A= =A0=A0 channels to interfaces in the following way.=0A=A0=A0 Multicast list= ener states are kept per interface in the MLD state=0A=A0=A0 table.=A0 An M= N will answer to an MLD General Query received on a=0A=A0=A0 specific (re-a= ttaching) interface according to the specific=0A=A0=A0 interface's state ta= ble.=A0 Thereafter, multicast forwarding is resumed=0A=A0=A0 for channels i= dentical to those under subscription prior to handover.=0A=A0=A0 Consequent= ly, an MN in a PMIPv6 domain MAY use multiple interfaces to=0A=A0=A0 facili= tate load balancing or redundancy, but cannot follow a 'make-=0A=A0=A0 befo= re-break' approach to service continuation on handovers.=0A4.6.=A0 Multicas= t Availability throughout the Access Network=0A=A0=A0 There may be deployme= nt scenarios, where multicast services are=0A=A0=A0 available throughout th= e access network independent of the PMIPv6=0A=A0=A0 infrastructure.=A0 Dire= ct multicast access at MAGs may be supported=0A=A0=A0 through native multic= ast routing, within a flat access network that=0A=A0=A0 includes a multicas= t router, via dedicated (tunnel or VPN) links=0A=A0=A0 between MAGs and des= ignated multicast routers, or by deploying AMT=0A=A0=A0 [I-D.ietf-mboned-au= to-multicast].=0A=A0=A0 Multicast deployment can be simplified in these sce= narios.=A0 A single=0A=A0=A0 proxy instance at MAGs with up-link into the m= ulticast cloud, for=0A=A0=A0 instance, could serve group communication purp= oses.=A0 MAGs could=0A=A0=A0 operate as general multicast routers or AMT ga= teways, as well.=0A=A0=A0 Common to these solutions is that mobility manage= ment is covered by=0A=A0=A0 the dynamics of multicast routing, as initially= foreseen in the=0A=A0=A0 Remote Subscription approach sketched in [RFC3775= ].=A0 Care must be=0A=A0=A0 taken to avoid service disruptions due to tardy= multicast routing=0A=A0=A0 operations, and to adapt to different link-laye= r technologies=0A=A0=A0 [RFC5757].=A0 The different possible approaches sho= uld be carefully=0A=A0=A0 investigated.=A0 Such work is beyond the scope of= this document.=0A=0A4.7.=A0 A Note on Explicit Tracking=0A=A0=A0 IGMPv3/ML= Dv2 [RFC3376], [RFC3810] may operate in combination with=0A=A0=A0 explicit = tracking, which allows routers to monitor each multicast=0A=A0=A0 receiver.= =A0 This mechanism is not standardized yet, but widely=0A=A0=A0 implemented= by vendors as it supports faster leave latencies and=0A=A0=A0 reduced sign= aling.=0A=A0=A0 Enabling explicit tracking on downstream interfaces of the = LMA and=0A=A0=A0 MAG would track a single MAG and MN respectively per inter= face.=A0 It=0A=A0=A0 may be used to preserve bandwidth on the MAG-MN link.= =0A=0A5.=A0 Message Source and Destination Address=0A=A0=A0 This section de= scribes source and destination addresses of MLD=0A=A0=A0 messages.=A0 The i= nterface identifier A-B denotes an interface on node=0A=A0=A0 A, which is c= onnected to node B. This includes tunnel interfaces.=0A5.1.=A0 Query=0A=A0= =A0=A0=A0=A0=A0=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=0A=A0=A0=A0=A0=A0=A0= =A0 | Interface | Source Address | Destination Address=A0 | Header=A0=A0 |= =0A=A0=A0=A0=A0=A0=A0=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=0A=A0=A0=A0=A0= =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | LMAA=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 | Proxy-CoA=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | outer=A0=A0=A0 |=0A=A0= =A0=A0=A0=A0=A0=A0 + LMA-MAG=A0=A0 +----------------+----------------------= +----------+=0A=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | LMA-= link-local | [RFC2710], [RFC3810] | inner=A0=A0=A0 |=0A=A0=A0=A0=A0=A0=A0= =A0 +-----------+----------------+----------------------+----------+=0A=A0= =A0=A0=A0=A0=A0=A0 | MAG-MN=A0=A0=A0 | MAG-link-local | [RFC2710], [RFC3810= ] |=A0=A0 --=A0=A0=A0=A0 |=0A=A0=A0=A0=A0=A0=A0=A0 +-----------+-----------= -----+----------------------+----------+=0A[behcet] add IGMP case as well w= ith IPv4-LMAA, etc.=0As/[RFC2710], [RFC3810]/multicast group address=0A5.2.= =A0 Report/Done=0A=A0=A0=A0=A0=A0=A0=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =0A=A0=A0=A0=A0=A0=A0=A0 | Interface | Source Address | Destination Address= =A0 | Header=A0=A0 |=0A=A0=A0=A0=A0=A0=A0=A0 +=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=0A=A0=A0=A0=A0=A0=A0=A0 | MN-MAG=A0=A0=A0 | MN-link-local=A0 | [RFC= 2710], [RFC3810] |=A0=A0 --=A0=A0=A0=A0 |=0A=A0=A0=A0=A0=A0=A0=A0 +--------= ---+----------------+----------------------+----------+=0A=A0=A0=A0=A0=A0= =A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Proxy-CoA=A0=A0=A0=A0=A0 | LMAA=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | outer=A0=A0=A0 |=0A=A0=A0= =A0=A0=A0=A0=A0 + MAG-LMA=A0=A0 +----------------+----------------------+--= --------+=0A=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | MAG-lin= k-local | [RFC2710], [RFC3810] | inner=A0=A0=A0 |=0A=A0=A0=A0=A0=A0=A0=A0 += -----------+----------------+----------------------+----------+=0A[behcet] = add IGMP case as well with IPv4-LMAA, etc.=0As/[RFC2710], [RFC3810]/multica= st group address=0A=0A7.=A0 Security Considerations=0A=A0=A0 This draft doe= s not introduce additional messages or novel protocol=0A=A0=A0 operations.= =A0 Consequently, no new threats are introduced by this=0A=A0=A0 document i= n addition to those identified as security concerns of=0A=A0=A0 [RFC3810], = [RFC4605], [RFC5213], and [RFC5844].=0A=A0=A0 However, particular attention= should be paid to implications of=0A=A0=A0 combining multicast and mobilit= y management at network entities.=A0 As=0A=A0=A0 this specification allows = mobile nodes to initiate the creation of=0A=A0=A0 multicast forwarding stat= es at MAGs and LMAs while changing=0A=A0=A0 attachments, threats of resourc= e exhaustion at PMIP routers and=0As/PMIP/Proxy Mobile IPv6=0A=A0=A0 access= networks arrive from rapid state changes, as well as from high=0A=A0=A0 vo= lume data streams routed into access networks of limited=0A=A0=A0 capacitie= s.=A0 In addition to proper authorization checks of MNs, rate=0A=A0=A0 cont= rols at replicators MAY be required to protect the agents and the=0A=A0=A0 = downstream networks.=A0 In particular, MLD proxy implementations at=0A=A0= =A0 MAGs SHOULD carefully procure for automatic multicast state=0A=A0=A0 ex= tinction on the departure of MNs, as mobile multicast listeners in=0A=A0=A0= the PMIPv6 domain will not actively terminate group membership prior=0A=A0= =A0 to departure.=0A=0A8.=A0 Acknowledgements=0A=A0=A0 This memo is the out= come of extensive previous discussions and a=0A=A0=A0 follow-up of several = initial drafts on the subject.=A0 The authors=0A=A0=A0 would like to thank = (in alphabetical order) Luis Contreras, Greg=0A=A0=A0 Daley, Gorry Fairhurs= t, Dirk von Hugo, Seil Jeon, Jouni Korhonen,=0A=A0=A0 Guang Lu, Sebastian M= eiling, Liu Hui, Imed Romdhani, Behcet Sarikaya,=0A=A0=A0 Stig Venaas, and = Juan Carlos Zuniga for advice, help and reviews of=0A=A0=A0 the document.= =A0 Funding by the German Federal Ministry of Education=0A=A0=A0 and Resear= ch within the G-LAB Initiative is gratefully acknowledged.=0A=0AAppendix C.= =A0 Comparative Evaluation of Different Approaches=0A=A0=A0 In this section= , we briefly evaluate two basic PMIP concepts for=0As/PMIP concepts/Proxy M= obile IPv6 scenarios=0A=A0=A0 multicast traffic organization at LMAs: In sc= enario A, multicast is=0A=A0=A0 provided by combined unicast/multicast LMAs= as described in this=0A=A0=A0 document.=A0 Scenario B directs traffic via = a dedicated multicast LMA=0A=A0=A0 as proposed in [I-D.zuniga-multimob-smsp= mip], for example.=0A=0A=0A From schmidt@informatik.haw-hamburg.de Wed May 26 05:32:51 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76FE3A6912 for ; Wed, 26 May 2010 05:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY1lQWdef36x for ; Wed, 26 May 2010 05:32:47 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 0651B3A68EB for ; Wed, 26 May 2010 05:32:46 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OHFmm-000DjD-5e; Wed, 26 May 2010 14:32:36 +0200 Message-ID: <4BFD14DC.9010602@informatik.haw-hamburg.de> Date: Wed, 26 May 2010 14:32:28 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stig Venaas References: <20100525194501.E676E3A6970@core3.amsl.com> <4BFC2AF4.90001@informatik.haw-hamburg.de> <146567.68819.qm@web111404.mail.gq1.yahoo.com> <4BFC316F.9090809@informatik.haw-hamburg.de> <4BFC5177.8000402@venaas.com> In-Reply-To: <4BFC5177.8000402@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: "multimob@ietf.org" Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 12:32:52 -0000 Hi Stig, section 4.5 tries to clarify the interplay between PMIPv6 multihoming and multicast operations. The first observation is that transparency is preserved, so the use of multiple interfaces is as in a static regime. Second observation is that multihoming cannot be used to smoothen mobility handovers. That's about it. Thomas On 26.05.2010 00:38, Stig Venaas wrote: > Looks good to me. I had a look at the changes. It's a bit hard to > understand what the new multihoming section really says though... > > I assume nothing is stopping a MN from joining the same group on > multiple interfaces. > > Stig >>> >>> ----- Original Message ---- >>>> From: Thomas C. Schmidt >>>> To: multimob@ietf.org >>>> Sent: Tue, May 25, 2010 2:54:28 PM >>>> Subject: Re: [multimob] I-D >>>> Action:draft-ietf-multimob-pmipv6-base-solution-01.txt >>>> >>>> Hi all, >>> >>> we just submitted the updated version of >>>> >>> draft-ietf-multimob-pmipv6-base-solution as discussed in Anaheim. >>> >>> >>>> From the change log: >>> >>> 1. Added section on >>>> multihoming. >>> >>> 2. Updated security >>>> section. >>> >>> 3. Several editorial improvements and minor >>>> extensions. >>> >>> >>> Please have a firm look ;) so that we can finalize the >>>> document. >>> >>> Thanks, >>> >>> Thomas >>> >>> >>> On 25.05.2010 21:45,> ymailto="mailto:Internet-Drafts@ietf.org" >>>> href="mailto:Internet-Drafts@ietf.org">Internet-Drafts@ietf.org >>>> wrote: >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> This draft is a work item of the Multicast >>>> Mobility Working Group of the IETF. >>>> >>>> >>>> >>>> Title : Base Deployment for Multicast Listener >>>> Support in PMIPv6 Domains >>>> Author(s) >>>> : T. Schmidt, et al. >>>> Filename >>>> : draft-ietf-multimob-pmipv6-base-solution-01.txt >>>> >>>> Pages : 19 >>>> >>>> Date : >>>> 2010-05-25 >>>> >>>> This document describes deployment options for >>>> activating multicast >>>> listener functions in Proxy Mobile IPv6 domains >>>> without modifying >>>> mobility and multicast protocol standards. >>>> Similar to Home Agents in >>>> Mobile IPv6, PMIPv6 Local Mobility Anchors >>>> serve as multicast >>>> subscription anchor points, while Mobile Access >>>> Gateways provide MLD >>>> proxy functions. In this scenario, Mobile >>>> Nodes remain agnostic of >>>> multicast mobility operations. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-01.txt >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>>> href="ftp://ftp.ietf.org/internet-drafts/" >>>> target=_blank>ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is >>>> the data which will enable a MIME compliant mail reader >>>> implementation >>>> to automatically retrieve the ASCII version of the >>>> >>>> Internet-Draft. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> multimob mailing >>>> list >>>>> href="mailto:multimob@ietf.org">multimob@ietf.org >>>>> href="https://www.ietf.org/mailman/listinfo/multimob" target=_blank >>>>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From stig@venaas.com Fri May 28 00:26:16 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD6F3A69FD for ; Fri, 28 May 2010 00:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abtNrPmijKJt for ; Fri, 28 May 2010 00:25:54 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id C54203A69F6 for ; Fri, 28 May 2010 00:23:52 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-159-44-226.dsl.pltn13.sbcglobal.net [99.159.44.226]) by ufisa.uninett.no (Postfix) with ESMTPSA id 062FB8067; Fri, 28 May 2010 09:23:30 +0200 (CEST) Message-ID: <4BFF6F0A.1070602@venaas.com> Date: Fri, 28 May 2010 00:21:46 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Behcet Sarikaya References: <20100525194501.E676E3A6970@core3.amsl.com> <617906.39969.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <617906.39969.qm@web111411.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 07:26:16 -0000 Behcet Sarikaya wrote: [...] > inter-operates with PMIPv6. It is worth noting that multicast > streams can possibly be distributed on redundant paths that lead to > duplicate traffic arriving from different LMAs at one MAG, and can > cause multiple data transmissions from an MAG over one wireless > domain to different MNs. What are you saying here? Duplicate traffic may arrive at the MAG, but what do you mean by multiple transmissions from a MAG? And what do you mean by multiple transmissions to different MNs? Are you saying that a single MN may get multiple transmissions? It could be interpreted that way. Is your point that say two MNs in the same wireless domain, might be receiving multicast from different LMAs so that it appears as different streams even though it might really be the same. I guess whether that is an issue depends on how the multicast and the MAG-MN link is implemented. That is, whether you can use multicast when sending to multiple MNs. > [behcet] This is called tunnel convergence problem, see Appendix C for further considerations. > (see Appendix C for further considerations). [...] > 4.4. IPv4 Support > An MN in a PMIPv6 domain may use an IPv4 address transparently for > communication as specified in [RFC5844]. For this purpose, LMAs can > register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide > IPv4 support in access networks. Correspondingly, multicast > membership management will be performed by the MN using IGMP. For > multicast support on the network side, an IGMP proxy function needs > to be deployed at MAGs in exactly the same way as for IPv6. > [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ > MLD. Thus IPv4 support can be transparently provided following the > obvious deployment analogy. > For a dual-stack IPv4/IPv6 access network, the MAG proxy instances > SHOULD choose multicast signaling according to address configurations > on the link, but MAY submit IGMP and MLD queries in parallel, if > needed. It should further be noted that the infrastructure cannot > identify two data streams as identical when distributed via an IPv4 > and IPv6 multicast group. Thus duplicate data may be forwarded on a > heterogeneous network layer. > [behcet] Add here one paragraph on NAT issue and a reference to RFC 5135 What is the NAT issue? Stig From schmidt@informatik.haw-hamburg.de Fri May 28 01:04:25 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7606E3A6895 for ; Fri, 28 May 2010 01:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDPQycBZME7s for ; Fri, 28 May 2010 01:04:24 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 213043A680A for ; Fri, 28 May 2010 01:04:23 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from f053079195.adsl.alicedsl.de ([78.53.79.195] helo=[192.168.178.100]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OHuY7-000Id4-4T for multimob@ietf.org; Fri, 28 May 2010 10:04:12 +0200 Message-ID: <4BFF78F7.4090701@informatik.haw-hamburg.de> Date: Fri, 28 May 2010 10:04:07 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100525194501.E676E3A6970@core3.amsl.com> <617906.39969.qm@web111411.mail.gq1.yahoo.com> <4BFF6F0A.1070602@venaas.com> In-Reply-To: <4BFF6F0A.1070602@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 08:04:25 -0000 Hi Stig, sorry for being brief & in a hurry: On 28.05.2010 09:21, Stig Venaas wrote: > Behcet Sarikaya wrote: > [...] >> inter-operates with PMIPv6. It is worth noting that multicast >> streams can possibly be distributed on redundant paths that lead to >> duplicate traffic arriving from different LMAs at one MAG, and can >> cause multiple data transmissions from an MAG over one wireless >> domain to different MNs. > > What are you saying here? Duplicate traffic may arrive at the MAG, but > what do you mean by multiple transmissions from a MAG? And what do you > mean by multiple transmissions to different MNs? Are you saying that a > single MN may get multiple transmissions? It could be interpreted that > way. > This says two things: (i) A MAG may receive duplicate streams, because it is serving MN that joined the same group via multiple LMAs (ii) A MAG may distribute data multiple times over the air (in the point-to-point) link model, but an MN always only receives data once (on one interface). > Is your point that say two MNs in the same wireless domain, might be > receiving multicast from different LMAs so that it appears as different > streams even though it might really be the same. I guess whether that is > an issue depends on how the multicast and the MAG-MN link is > implemented. That is, whether you can use multicast when sending to > multiple MNs. > Yes, this is a pointer to the link model. >> [behcet] This is called tunnel convergence problem, see Appendix C for >> further considerations. >> (see Appendix C for further considerations). > [...] >> 4.4. IPv4 Support >> An MN in a PMIPv6 domain may use an IPv4 address transparently for >> communication as specified in [RFC5844]. For this purpose, LMAs can >> register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide >> IPv4 support in access networks. Correspondingly, multicast >> membership management will be performed by the MN using IGMP. For >> multicast support on the network side, an IGMP proxy function needs >> to be deployed at MAGs in exactly the same way as for IPv6. >> [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ >> MLD. Thus IPv4 support can be transparently provided following the >> obvious deployment analogy. >> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances >> SHOULD choose multicast signaling according to address configurations >> on the link, but MAY submit IGMP and MLD queries in parallel, if >> needed. It should further be noted that the infrastructure cannot >> identify two data streams as identical when distributed via an IPv4 >> and IPv6 multicast group. Thus duplicate data may be forwarded on a >> heterogeneous network layer. >> [behcet] Add here one paragraph on NAT issue and a reference to RFC 5135 > > What is the NAT issue? > I've responded to the NAT topic a while ago: actually, there are no NAT issues within the PMIP domain, as PMIP does not support a NAT on the MAG. NAT issues may arrive outside the PMIP domain, but that is beyond the scope of the document. So, all one could say in the draft is: There are no NAT issues, but this is already stated in RFC 5213. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Fri May 28 07:54:31 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037F23A6914 for ; Fri, 28 May 2010 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.918 X-Spam-Level: X-Spam-Status: No, score=0.918 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXc2Y+2ZdvZl for ; Fri, 28 May 2010 07:54:30 -0700 (PDT) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 3B8863A696A for ; Fri, 28 May 2010 07:54:30 -0700 (PDT) Received: (qmail 57162 invoked by uid 60001); 28 May 2010 14:54:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275058457; bh=g+hh5mqn7v6bIiRoX/Mw9VFul7SXew2LfM3Z+fbxFuM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mnftIIbTjfuihGldWh+am5exZxFskjTqa2B/b6w/ogmbyxRX42+YZ51xgg4kK3YC8yqrIEoK+7VJwmykKUSf88JjBGone0I/MJB//rGN4XcOk6a4U6ZJjEyH5RytxCBnVRL5zJnmtdXiMySKFw4SUEHIU4lpWUHW3AZxLIGCOjA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vRQsv0zxBO2Q0JerOdU2hUbjCHXy+gOFvT9dI1Mt0/0DXllH4z7EpoVlDchu0gBgSFu5Aqe2aRcXimXxdFgTtkjQu1wZf1nDyqHz9gnjxbdIlu59XGu0/FUZuNKasdJAIMFYhnQqhVOKwZwShbLsXUL4JSGyEjE5U9qVu6sva9c=; Message-ID: <596734.56400.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: wrAa3FsVM1mcQzBiTAaNcETF_T4h9gxiTLuvsHtK.GmfbQ3 A7hkSrHvmpKu3iTEm.u6RYbVaqn9__GeQiIg6bvmj9g9DYyJbZzUPYH.UGZS j4oAwivXrTzKAqnJBUM2cXCGWDg92q7XL2wLTDzGtb6DjX5QQsnHqW6k29Fy SFV42Izc4mVQDWj4aiFguFlN266VY43kku57lxu1gyNoUkODdAI_KGcE3rF4 AdSLziMOPsRF7vIy6lJOrFPbn4WIbquUzLf8qYdZYrkd1589XcaZTAR4z1Jy LCJjanZp1bfrGTuArmzPOkBbQBDyy.JSLwLq5Kwmx Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 28 May 2010 07:54:17 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 Date: Fri, 28 May 2010 07:54:17 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 14:54:31 -0000 Thomas,=0A=0ARegarding the tunnel convergence problem, let's define it like= :=0A=0ATunnel convergence =A0=0Aoccurs when different MNs =0Aconnected to t= he same MAG belong to different LMA. Then if they =0Asubscribe to the same = multicast group, multicast data from several =0ALMAs are replicated at the = MAG to MNs and thus MN receives duplicate multicast data.=0A=0A=0Aand then = clarify if MN receives duplicate data packets if not why?=0A=0A>> [behcet] = Add here one paragraph on NAT =0A> issue and a reference to RFC 5135=0A> = =0A> What is the NAT =0A> issue?=0A> =0A=0A> I've responded to the NAT topi= c a while ago: actually, =0A> there are no NAT issues within the PMIP domai= n, as PMIP does not support a NAT =0A> on the MAG. NAT issues may arrive ou= tside the PMIP domain, but that is beyond =0A> the scope of the document.= =0A=0A> So, all one could say in the draft is: There =0A> are no NAT issues= , but this is already stated in RFC 5213.=0A=0AWhat do you mean there are n= o NAT issues? =0AIGMP uses source (public or private) IPv4 addresses unlike= MLD which uses link local=A0and NAT changes the source address and port nu= mber. What are the implications of that?=0ARFC 5135 recommends IGMP Proxy t= o be placed at the NAT device. What are the implications of this for the dr= aft? =0AAlso requirements stated in RFC 5135?=0A=0ARFC 5844 assumes:=0AA de= ployment where a mobile access gateway uses an IPv4 private=0A=A0=A0=A0=A0= =A0=A0address with NAT [RFC3022] translation devices in the path to a=0A=A0= =A0=A0=A0=A0=A0local mobility anchor is not supported by this specification= .=0A=0AI don't think this precludes NAT at the MAG.=0A=0ARegards,=0A=0ABehc= et=0A=0A=0A From stig@venaas.com Fri May 28 08:51:06 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1626E3A6A2F for ; Fri, 28 May 2010 08:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Udz1Oc2TRtu1 for ; Fri, 28 May 2010 08:51:04 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 8EB323A6A2A for ; Fri, 28 May 2010 08:51:03 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-159-44-226.dsl.pltn13.sbcglobal.net [99.159.44.226]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6A1318161; Fri, 28 May 2010 17:50:50 +0200 (CEST) Message-ID: <4BFFE5F8.5080801@venaas.com> Date: Fri, 28 May 2010 08:49:12 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Behcet Sarikaya References: <596734.56400.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <596734.56400.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 15:51:07 -0000 Behcet Sarikaya wrote: > Thomas, > > Regarding the tunnel convergence problem, let's define it like: > > Tunnel convergence > occurs when different MNs > connected to the same MAG belong to different LMA. Then if they > subscribe to the same multicast group, multicast data from several > LMAs are replicated at the MAG to MNs and thus MN receives duplicate multicast data. > > > and then clarify if MN receives duplicate data packets if not why? I think it's good to clarify this. >>> [behcet] Add here one paragraph on NAT >> issue and a reference to RFC 5135 >> >> What is the NAT >> issue? >> > >> I've responded to the NAT topic a while ago: actually, >> there are no NAT issues within the PMIP domain, as PMIP does not support a NAT >> on the MAG. NAT issues may arrive outside the PMIP domain, but that is beyond >> the scope of the document. > >> So, all one could say in the draft is: There >> are no NAT issues, but this is already stated in RFC 5213. I don't think it is an issue either, unless we expect NAT to be deployed in this scenario. Do we? > What do you mean there are no NAT issues? > IGMP uses source (public or private) IPv4 addresses unlike MLD which uses link local and NAT changes the source address and port number. What are the implications of that? > RFC 5135 recommends IGMP Proxy to be placed at the NAT device. What are the implications of this for the draft? > Also requirements stated in RFC 5135? There are of course some issues with deploying NAT, but nothing particular to this solution. Anyway, here is what happens if NAT is used at the proxy. Usually multicast addresses are not changed, just unicast addresses. For IGMP/MLD reports it is not a problem since you are doing proxying. The proxy receives reports with say private IPv4 addresses, and then the proxy sends its own IGMP report based on the aggregate state, using its public address. This is exactly as when NAT is not used though. For any multicast received from the outside, you would usually not do any translation. So NAT does not have much impact. But I don't think we should discuss this unless we think NAT will be deployed together with this solution. Stig > RFC 5844 assumes: > A deployment where a mobile access gateway uses an IPv4 private > address with NAT [RFC3022] translation devices in the path to a > local mobility anchor is not supported by this specification. > > I don't think this precludes NAT at the MAG. > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Fri May 28 15:55:02 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21593A6813 for ; Fri, 28 May 2010 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ft6vGzRTfCT for ; Fri, 28 May 2010 15:55:01 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 5EB733A695E for ; Fri, 28 May 2010 15:55:00 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from f053079195.adsl.alicedsl.de ([78.53.79.195] helo=[192.168.178.100]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OI8S1-000G3A-8J for multimob@ietf.org; Sat, 29 May 2010 00:54:49 +0200 Message-ID: <4C0049B4.7030606@informatik.haw-hamburg.de> Date: Sat, 29 May 2010 00:54:44 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <596734.56400.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <596734.56400.qm@web111413.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 22:55:02 -0000 Hi Behcet, On 28.05.2010 16:54, Behcet Sarikaya wrote: > Regarding the tunnel convergence problem, let's define it like: > > Tunnel convergence > occurs when different MNs > connected to the same MAG belong to different LMA. Then if they > subscribe to the same multicast group, multicast data from several > LMAs are replicated at the MAG to MNs and thus MN receives duplicate multicast data. > I'm not exactly sure what you're heading at, here: the traditional "tunnel convergence problem" is from MIPv4 when multiple (many) identical data arrive in tunnels at a foreign agent. The corresponding picture in PMIPv6 is that data arrives in multiple tunnels at the MAG (from different LMAs). In draft-ietf-multimob-pmipv6-base-solution duplicate data do not arrive at an MN because of the PtP link model: A MAG will sort LMA -> MAG tunnels to individual downlinks and no MN will receive data from different LMAs. The discussion in Appendix C is only on scaling efficiency at LMA, MAG and the network in between these agents. > > and then clarify if MN receives duplicate data packets if not why? > Yes, see above: we will stress this in the draft. >>> [behcet] Add here one paragraph on NAT >> issue and a reference to RFC 5135 >> >> What is the NAT >> issue? >> > >> I've responded to the NAT topic a while ago: actually, >> there are no NAT issues within the PMIP domain, as PMIP does not support a NAT >> on the MAG. NAT issues may arrive outside the PMIP domain, but that is beyond >> the scope of the document. > >> So, all one could say in the draft is: There >> are no NAT issues, but this is already stated in RFC 5213. > > What do you mean there are no NAT issues? I guess the NAT-things have been discussed. This is really not a subject of an "inner" PMIPv6 domain, even though I agree that many providers use NATs (at their edges). They are "invisible" though to an internal mobility management. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Sat May 29 02:15:23 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2273A68A0 for ; Sat, 29 May 2010 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoomvObjL0Vo for ; Sat, 29 May 2010 02:15:16 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id DDEE53A6874 for ; Sat, 29 May 2010 02:15:10 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178135127.adsl.alicedsl.de ([85.178.135.127] helo=[192.168.178.100]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OII8A-0008Dv-TY for multimob@ietf.org; Sat, 29 May 2010 11:14:59 +0200 Message-ID: <4C00DB0F.6030705@informatik.haw-hamburg.de> Date: Sat, 29 May 2010 11:14:55 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <596734.56400.qm@web111413.mail.gq1.yahoo.com> <4BFFE5F8.5080801@venaas.com> In-Reply-To: <4BFFE5F8.5080801@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 09:15:23 -0000 Hi Stig, On 28.05.2010 17:49, Stig Venaas wrote: > Behcet Sarikaya wrote: >> and then clarify if MN receives duplicate data packets if not why? > > I think it's good to clarify this. > Yes, we'll do. >>>> [behcet] Add here one paragraph on NAT >>> issue and a reference to RFC 5135 >>> >>> What is the NAT issue? >>> >> >>> I've responded to the NAT topic a while ago: actually, there are no >>> NAT issues within the PMIP domain, as PMIP does not support a NAT on >>> the MAG. NAT issues may arrive outside the PMIP domain, but that is >>> beyond the scope of the document. >> >>> So, all one could say in the draft is: There are no NAT issues, but >>> this is already stated in RFC 5213. > > I don't think it is an issue either, unless we expect NAT to be > deployed in this scenario. Do we? > >> What do you mean there are no NAT issues? IGMP uses source (public or >> private) IPv4 addresses unlike MLD which uses link local and NAT >> changes the source address and port number. What are the implications >> of that? >> RFC 5135 recommends IGMP Proxy to be placed at the NAT device. What >> are the implications of this for the draft? Also requirements stated >> in RFC 5135? > > There are of course some issues with deploying NAT, but nothing > particular to this solution. > > Anyway, here is what happens if NAT is used at the proxy. Usually > multicast addresses are not changed, just unicast addresses. For > IGMP/MLD reports it is not a problem since you are doing proxying. > The proxy receives reports with say private IPv4 addresses, and then > the proxy sends its own IGMP report based on the aggregate state, using > its public address. This is exactly as when NAT is not used though. > > For any multicast received from the outside, you would usually not do > any translation. So NAT does not have much impact. But I don't think we > should discuss this unless we think NAT will be deployed together with > this solution. > As quoted earlier: RFCs 5213/5844 explicitly exclude scenarios with a NAT deployed on MAGs. So I don't think we need to provide a discussion on NATs at the MAG, since we clearly stick to the set up defined in RFCs 5213/5844. Best wishes, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Akbar.Rahman@InterDigital.com Mon May 31 13:40:09 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED653A68C3 for ; Mon, 31 May 2010 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojg6lX6Wt2EU for ; Mon, 31 May 2010 13:40:07 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 429E53A689A for ; Mon, 31 May 2010 13:40:06 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 16:39:53 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 May 2010 16:39:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB0101.6C442968" Date: Mon, 31 May 2010 16:35:08 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-zuniga-multimob-smspmip-03.txt Thread-Index: AcsBABS5YXRefh50Q4CMPQBltDH53gAAA0LQ From: "Rahman, Akbar" To: "Behcet Sarikaya" , "Stig Venaas" X-OriginalArrivalTime: 31 May 2010 20:39:53.0647 (UTC) FILETIME=[6C762BF0:01CB0101] Cc: multimob@ietf.org Subject: [multimob] FW: I-D Action:draft-zuniga-multimob-smspmip-03.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 20:40:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0101.6C442968 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet/Stig, Here is the update of our contribution as per our earlier email (in response to Behcet's request for IETF #78 agenda items). We have updated to address all the comments that we received at the Anaheim meeting. We look forward to any comments on the mailing list and/or when we present in Maastricht. Sincerely, Akbar, Juan-Carlos, Guang -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, May 31, 2010 4:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-zuniga-multimob-smspmip-03.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Support Multicast Services Using Proxy Mobile IPv6 Author(s) : J. Zuniga, et al. Filename : draft-zuniga-multimob-smspmip-03.txt Pages : 13 Date : 2010-05-31 The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base- solution]. In this document, an enhancement is proposed to the base solution to use a dedicated multicast LMA as the topological anchor point for multicast traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement provides benefits such as reducing multicast traffic replication and reducing complexity of PMIPv6 deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zuniga-multimob-smspmip-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CB0101.6C442968 Content-Type: application/octet-stream; name="draft-zuniga-multimob-smspmip-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zuniga-multimob-smspmip-03.URL Content-Disposition: attachment; filename="draft-zuniga-multimob-smspmip-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16dW5pZ2EtbXVsdGltb2Itc21zcG1pcC0wMy50eHQNCg== ------_=_NextPart_001_01CB0101.6C442968 Content-Type: text/plain; name="ATT346009.txt" Content-Transfer-Encoding: base64 Content-Description: ATT346009.txt Content-Disposition: attachment; filename="ATT346009.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CB0101.6C442968-- From root@core3.amsl.com Mon May 31 15:00:02 2010 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3D5D33A691B; Mon, 31 May 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100531220002.3D5D33A691B@core3.amsl.com> Date: Mon, 31 May 2010 15:00:02 -0700 (PDT) Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-02.txt Pages : 20 Date : 2010-05-31 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-31145655.I-D@ietf.org> --NextPart-- From schmidt@informatik.haw-hamburg.de Mon May 31 15:13:43 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D423A6901 for ; Mon, 31 May 2010 15:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL27kQdwnNvC for ; Mon, 31 May 2010 15:13:41 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 0BEDD3A6851 for ; Mon, 31 May 2010 15:13:41 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.197.167.14] (helo=[10.20.4.175]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OJDEd-000G1L-9P for multimob@ietf.org; Tue, 01 Jun 2010 00:13:28 +0200 Message-ID: <4C04347D.3080001@informatik.haw-hamburg.de> Date: Tue, 01 Jun 2010 01:13:17 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100531220002.3D5D33A691B@core3.amsl.com> In-Reply-To: <20100531220002.3D5D33A691B@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 22:13:43 -0000 Hi all, following the comments on the list, we just updated the draft. There have been a number of editorial changes, but the core content remains stable. Please find the updated version at http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-02 and drop us your feedback. Thanks, Thomas On 01.06.2010 01:00, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multicast Mobility Working Group of the IETF. > > > Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains > Author(s) : T. Schmidt, et al. > Filename : draft-ietf-multimob-pmipv6-base-solution-02.txt > Pages : 20 > Date : 2010-05-31 > > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °