From luisc@it.uc3m.es Tue Feb 2 14:06:39 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 99F2A3A69B2 for ; Tue, 2 Feb 2010 14:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DXAMg07Epm+K for ; Tue, 2 Feb 2010 14:06:38 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8B8973A67A6 for ; Tue, 2 Feb 2010 14:06:38 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 38D94BAB06F; Tue, 2 Feb 2010 23:07:16 +0100 (CET) Received: from 217.pool85-54-50.dynamic.orange.es (217.pool85-54-50.dynamic.orange.es [85.54.50.217]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 02 Feb 2010 23:07:13 +0100 Message-ID: <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> Date: Tue, 02 Feb 2010 23:07:13 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> In-Reply-To: <4B64B2E6.8040908@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 02 Feb 2010 22:06:39 -0000 Hi Thomas, of course, you explain well. Nevertheless you assume that the scenario I provide requires new mobility-related signalling, but I think this is not necessary the case. For instance, following the mechanism you describe in your draft for the MN handover (figure 2), once the MN attaches to MAG2 in your picture, this MAG2 would bind the LMA which serves unicast taffic to MN. The next step would be to send an MLD Query to MN, and, after receiving the corresponding MLD report, according to the scenario I propose, the MAG2 would send the multicast Join message (if the multicast content is not already subscribed by any other MN attached to MAG2) towards the LMA which serves the multicast traffic to all the MAGs in the PMIPv6 domain (called LMA2 in my example in the previous mail). As consequence, the LMA2 would start forwarding the content to MAG2. The reception of the multicast content by the previous MAG, lets call it MAG1, would be finished according to the periodic messages of the multicast protocols. The LMA designated to forward the multicast traffic remains always the same along the PMIPv6 domain, and the MAGs configure their MLD proxy upstream interface towards that LMA. This LMA, apart of acting as normal LMA for a subset of the MNs in the domain, becomes the Multicast Mobility Anchor for all the MNs in the domain. In other words, the multicast protocols (MLD in this case) could do the job for following the MN's movement. I think that no new mobility signalling is necessary needed. So, this scenario could cover the two objectives that you highlighted (no additional infrastructure for multicast, and no additional mobility management procedures for multicast). Do you agree? Regards, Luis From behcetsarikaya@yahoo.com Tue Feb 2 14:58: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 E7DE53A6B84 for ; Tue, 2 Feb 2010 14:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 PDfFbECBW+7Y for ; Tue, 2 Feb 2010 14:58:31 -0800 (PST) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id E55B83A69C7 for ; Tue, 2 Feb 2010 14:58:30 -0800 (PST) Received: (qmail 19577 invoked by uid 60001); 2 Feb 2010 22:32:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265149931; bh=ILl9xBXwBOlO5Rx1h0ERD3msWVlNzN2Ww2D45r/3Ijc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FlVVej/pQUi7gjUXfIXV/LllPxIQSKNyAip1JqecOHwDKgP2WMboaXAfGXWN9kq49Td+q3XBYuI6PpRgiKAF49+kIGxH7e3XGZYxLvzqFPDXne9hr9+2Ry+SS8Jkd0HAfJwYBOw1Jpjek620uF7ryT5dYMboqxxLoMVWbWj+9s8= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=PIFg3A6xl1dAxZgW5q4PnCzvtVI91OIc1IYLrol13jidFIjfgwRz7bEARm+znSWTAFzgeQyqoVE87kiBekO6rEEFmhw4bgna2SX9sr5y8rg7NBB3uOTg7FkcvU+EEQTL2hrB6msvb2Di+JMmhjy8N0zktvYySx+5armnD4KRmyM=; Message-ID: <283254.18799.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: 1gW3IrAVM1mrjDL79ASwQttVlppHP.a3FbkHUXShHsicLefHN39PeC7ajdqGWxXYJ.ETog6hW7xnyyDQFH5JotvrPOEKMwSvRXY8m9vqVLHyT_1JAGqbadca_C142WjNy_j9JF_LUg7gaW9DBMfnntmG.kOSR8IG8ndlkxJINlxAL07wblW7gI0vCWcLuMUgrPPRFC8RAaaW8cfSEQUs59hh81dIF.bvmpiyXIov6XaVyu3WDUW6PFjC9mN3Oi0gpmskX9BDnhMpVSuMJmQuQr7M.avJF4Othf2XirbeHUI1MazjLYbMXp1g0Gp1q2Tr_qY830zRseVx6TXmmexgcceZdZAMxOaMwprZHHAl Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 02 Feb 2010 14:32:11 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> Date: Tue, 2 Feb 2010 14:32:11 -0800 (PST) From: Behcet Sarikaya To: "Luis M. Contreras" , "Thomas C. Schmidt" In-Reply-To: <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 02 Feb 2010 22:58:32 -0000 ----- Original Message ---- > From: Luis M. Contreras > To: Thomas C. Schmidt > Cc: multimob@ietf.org > Sent: Tue, February 2, 2010 4:07:13 PM > Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 > > Hi Thomas, > > of course, you explain well. Nevertheless you assume that the scenario I provide > requires new mobility-related signalling, but I think this is not necessary the > case. > > For instance, following the mechanism you describe in your draft for the MN > handover (figure 2), once the MN attaches to MAG2 in your picture, this MAG2 > would bind the LMA which serves unicast taffic to MN. The next step would be to > send an MLD Query to MN, and, after receiving the corresponding MLD report, > according to the scenario I propose, the MAG2 would send the multicast Join > message (if the multicast content is not already subscribed by any other MN > attached to MAG2) towards the LMA which serves the multicast traffic to all the > MAGs in the PMIPv6 domain (called LMA2 in my example in the previous mail). As > consequence, the LMA2 would start forwarding the content to MAG2. The reception > of the multicast content by the previous MAG, lets call it MAG1, would be > finished according to the periodic messages of the multicast protocols. The LMA > designated to forward the multicast traffic remains always the same along the > PMIPv6 domain, and the MAGs configure their MLD proxy upstream interface towards > that LMA. This LMA, apart of acting as normal LMA for a subset of the MNs in the > domain, becomes the Multicast Mobility Anchor for all the MNs in the domain. > Sorry but this is getting repetitive. Can you please refer to the conversation we had with Juan Carlos, Stig and myself on Multicast LMA? > In other words, the multicast protocols (MLD in this case) could do the job for > following the MN's movement. I think that no new mobility signalling is > necessary needed. So, this scenario could cover the two objectives that you > highlighted (no additional infrastructure for multicast, and no additional > mobility management procedures for multicast). Let me quote Stig here: Looking at other solutions is interesting, but it is outside the current charter. Hopefully it is something we can look at in the future. Regards, Behcet From luisc@it.uc3m.es Wed Feb 3 01:50: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 2697D3A6BE1 for ; Wed, 3 Feb 2010 01:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 j7r8yI6rDvah for ; Wed, 3 Feb 2010 01:50:22 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 499E03A6BE0 for ; Wed, 3 Feb 2010 01:50:22 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 585ABBA8346; Wed, 3 Feb 2010 10:51:00 +0100 (CET) Received: from 85.62.13.196.static.abi.uni2.es (85.62.13.196.static.abi.uni2.es [85.62.13.196]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 03 Feb 2010 10:50:59 +0100 Message-ID: <20100203105059.jqa7xsod34wkgw04@webcartero01.uc3m.es> Date: Wed, 03 Feb 2010 10:50:59 +0100 From: "Luis M. Contreras" To: Behcet Sarikaya , Behcet Sarikaya References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> <283254.18799.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <283254.18799.qm@web111406.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 09:50:23 -0000 Behcet Sarikaya dijo: > > Sorry but this is getting repetitive. > Can you please refer to the conversation we had with Juan Carlos, > Stig and myself on Multicast LMA? > Hi Behcet, I personally think that your dual role of carter chair and co-author of one of the proposed solutions is not the best position to moderate this technical discussion. Regards, Luis From schmidt@informatik.haw-hamburg.de Wed Feb 3 08:11: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 35F313A68FA for ; Wed, 3 Feb 2010 08:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 lY8Rm11vKSw2 for ; Wed, 3 Feb 2010 08:11:22 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 538D128C155 for ; Wed, 3 Feb 2010 08:11:15 -0800 (PST) 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 1Nchpc-0005xR-KU; Wed, 03 Feb 2010 17:11:56 +0100 Message-ID: <4B69A03F.8000103@informatik.haw-hamburg.de> Date: Wed, 03 Feb 2010 17:11:43 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> In-Reply-To: <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> 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] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 16:11:24 -0000 Hi Luis, first of all I agree that the solution commonly called "dedicated multicast LMA" does not require mobility-specific signaling for multicast, provided there is only a single "dedicated multicast LMA". There is nothing but multicast joins initiated by queries of the MAGs, "mobility" is handled by the dynamics of multicast routing. This is actually what was meant by "Remote Subscription" in the original RFC3775 ;) This is due to a separate multicast delivery layer (provided via separate tunnels and the "dedicated multicast LMA" ) which is responsible to provide multicast at "the access routers" (called MAGs). The solution is in parallel to, but not integrated with PMIPv6. Thus we previously had this discussion about the name "dedicated multicast LMA": actually, this cannot be an LMA with PMIP-specific binding states (it could not even maintain them correctly), but rather is a multicast Designated Router with some tunnel interfaces. Correspondingly, I'm personally not convinced about this as an independent approach to PMIP multicast, but rather believe that a special case is presented, being part of a generic scenario I would call "multicast infrastructure present at the access routers" (e.g., MAGs). IMHO, such a scenario looks like a multicast routing infrastructure that reaches MAGs either * directly (as presented by Seil), or * via MLD proxies (as proposed by Zuniga et al. and by you), or * via some Mcast routing protocol (e.g., PIM) that is possibly extended by tunnels, or * by a (possibly dynamic) mixture using AMT in region without native routing Thus, I would rather look at this range of solutions in a broader sense, and may be identify characteristics and implications a native multicast infrastructure imposes on PMIPv6 mobility handover performance of multicast listeners. Cheers, Thomas Luis M. Contreras wrote: > Hi Thomas, > > of course, you explain well. Nevertheless you assume that the scenario I > provide requires new mobility-related signalling, but I think this is > not necessary the case. > > For instance, following the mechanism you describe in your draft for the > MN handover (figure 2), once the MN attaches to MAG2 in your picture, > this MAG2 would bind the LMA which serves unicast taffic to MN. The next > step would be to send an MLD Query to MN, and, after receiving the > corresponding MLD report, according to the scenario I propose, the MAG2 > would send the multicast Join message (if the multicast content is not > already subscribed by any other MN attached to MAG2) towards the LMA > which serves the multicast traffic to all the MAGs in the PMIPv6 domain > (called LMA2 in my example in the previous mail). As consequence, the > LMA2 would start forwarding the content to MAG2. The reception of the > multicast content by the previous MAG, lets call it MAG1, would be > finished according to the periodic messages of the multicast protocols. > The LMA designated to forward the multicast traffic remains always the > same along the PMIPv6 domain, and the MAGs configure their MLD proxy > upstream interface towards that LMA. This LMA, apart of acting as normal > LMA for a subset of the MNs in the domain, becomes the Multicast > Mobility Anchor for all the MNs in the domain. > > In other words, the multicast protocols (MLD in this case) could do the > job for following the MN's movement. I think that no new mobility > signalling is necessary needed. So, this scenario could cover the two > objectives that you highlighted (no additional infrastructure for > multicast, and no additional mobility management procedures for multicast). > > Do you agree? > > Regards, > > Luis > -- 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 Wed Feb 3 08:31:53 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 B13F028C0ED for ; Wed, 3 Feb 2010 08:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 XbP-Rwg9tmRJ for ; Wed, 3 Feb 2010 08:31:53 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 0C0C028C179 for ; Wed, 3 Feb 2010 08:31:53 -0800 (PST) Received: (qmail 83975 invoked by uid 60001); 3 Feb 2010 16:29:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265214557; bh=dUZoWoiDZGakhmKrewd3FWyAJ8tZ4ykjB0TyKgLqXus=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1Svg5OfF/KytrdFVcj4X8IBz1KMWux3jjFDpXKIsBl/1+6XSfgd2/S/ZTtMvPM3wbSXfaR2T/kpuopGWZwFFRwPeDrglt+SR4egmSla46jzIBknfHqyfgAXhyNDrUS/J+nvlVGYIe7SMZdfFvPDvaQ0qScZZLmhTdRaKy/064eU= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=gqw2fsAL1zMvKkt/nIleXxACV1hI7hQ0OD7k3cYY3mmGdDPoZWZ+wJc2+uPPwr/lhIQqx70OvwQ5EJV6ru9RVONFbnQlYdQ4ydKHjwJgymxOr4SOsSZoMw9aE773wm5khR64SGuaSihHQG+T1G6Bty3oabTBP+tLZcNTQCNasdk=; Message-ID: <874361.82954.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: t1PARIwVM1kODGgvP_NfN_oH_smb_sMQf0jM7hi7.WnzDwDc_ORQrdvC2TnkBvkLhcHZeCdzQqEgm7BKGYMwXmip1h4dSe4NIP6FzorZ1sqrFp9MAnmOkG_zc9RkkkzwImnfBqN3QYlyxiWdX9U9W1gwJ55OD5Af3azXhsCTIWqkJbxCUIsH3h9z.Vdy08LT4ZYVqjoYw1SDlI8bbljiDMZBly0vvUYEGVGXG9uFtcqoAPSzrTJPex87ZCErweYxmjQw6dTX1dAUhbhn3YH0Wck0sOQ2EPTjlWsvcMPRKL7L6Middc9CDk630TA7UrH1wcu0YLY6p2v9U8w16KHGISSXm8.kRqpOQjW1IRSs Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 03 Feb 2010 08:29:17 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> <283254.18799.qm@web111406.mail.gq1.yahoo.com> <20100203105059.jqa7xsod34wkgw04@webcartero01.uc3m.es> Date: Wed, 3 Feb 2010 08:29:17 -0800 (PST) From: Behcet Sarikaya To: "Luis M. Contreras" , Thomas C Schmidt In-Reply-To: <20100203105059.jqa7xsod34wkgw04@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 16:31:53 -0000 I hereby would like to ask Thomas to remove my name from his draft. Thank you. Behcet ----- Original Message ---- > From: Luis M. Contreras > To: Behcet Sarikaya ; Behcet Sarikaya > Cc: multimob@ietf.org; cjbc@it.uc3m.es; isoto@it.uc3m.es > Sent: Wed, February 3, 2010 3:50:59 AM > Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 > > Behcet Sarikaya dijo: > > > > > Sorry but this is getting repetitive. > > Can you please refer to the conversation we had with Juan Carlos, Stig and > myself on Multicast LMA? > > > > Hi Behcet, > > I personally think that your dual role of carter chair and co-author of one of > the proposed solutions is not the best position to moderate this technical > discussion. > > Regards, > > Luis From stig@venaas.com Wed Feb 3 13:00: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 133693A6B46 for ; Wed, 3 Feb 2010 13:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 k5TqkR91Z3bj for ; Wed, 3 Feb 2010 13:00:15 -0800 (PST) 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 08DCC3A6B4F for ; Wed, 3 Feb 2010 13:00:14 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 7AC8222671; Wed, 3 Feb 2010 22:00:55 +0100 (CET) Message-ID: <4B69E3FD.5090509@venaas.com> Date: Wed, 03 Feb 2010 13:00:45 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> In-Reply-To: <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 21:00:16 -0000 Luis M. Contreras wrote: > Hi Thomas, > > of course, you explain well. Nevertheless you assume that the scenario I > provide requires new mobility-related signalling, but I think this is > not necessary the case. > > For instance, following the mechanism you describe in your draft for the > MN handover (figure 2), once the MN attaches to MAG2 in your picture, > this MAG2 would bind the LMA which serves unicast taffic to MN. The next > step would be to send an MLD Query to MN, and, after receiving the > corresponding MLD report, according to the scenario I propose, the MAG2 > would send the multicast Join message (if the multicast content is not > already subscribed by any other MN attached to MAG2) towards the LMA > which serves the multicast traffic to all the MAGs in the PMIPv6 domain > (called LMA2 in my example in the previous mail). As consequence, the > LMA2 would start forwarding the content to MAG2. The reception of the > multicast content by the previous MAG, lets call it MAG1, would be > finished according to the periodic messages of the multicast protocols. > The LMA designated to forward the multicast traffic remains always the > same along the PMIPv6 domain, and the MAGs configure their MLD proxy > upstream interface towards that LMA. This LMA, apart of acting as normal > LMA for a subset of the MNs in the domain, becomes the Multicast > Mobility Anchor for all the MNs in the domain. > > In other words, the multicast protocols (MLD in this case) could do the > job for following the MN's movement. I think that no new mobility > signalling is necessary needed. So, this scenario could cover the two > objectives that you highlighted (no additional infrastructure for > multicast, and no additional mobility management procedures for multicast). As I see it there are two aspects here. If we just look at mobility, MLD, state on MAG etc. then I think the above describes pretty well both the "multicast from (unicast) LMA" case, and the "multicast-specific LMA" case. In fact, I think that if we ignore the upstream interface, the multicast aspects are identical. The difference as I see it, is what is the upstream interface. Based on what the charter says, we should have a solution where it is the tunnel to the (unicast) LMA of the MN. However, it is only a minor difference, and I think quite easy, to optionally say that the upstream could be something else (another LMA (the (unicast) LMA of some other MNs) or a link to some other multicast router. I think maybe we could say that it is the same solution, just with a non-standard/non-default choice of upstream interface. Regarding multicast LMA, I find it a bit confusing using that name. The signalling would I think, not be the same as for unicast. E.g., you wouldn't have a binding for each of the multicast MNs I think. I certainly see benefits in using a single upstream interface for all MNs (as in a single multicast LMA if using that term). Again, referring to the charter, we should have a basic solution where we use the LMAs and have same path for unicast and multicast. But as I wrote above, it is a very minor difference to allow something else. The only difference I see when implementing it, is how you choose the upstream interface. And, that you only need one MLD proxy instance if you have the same upstream interface for all MNs. Personally I don't see a problem with briefly saying in the basic solution spec that it may be useful to allow a different choice of upstream interface or something like that. But it may be better to have a separate document for a more thorough discussion, like different alternatives, pros and cons etc. The basic solution should be according to the charter, and not have any unnecessary complexity. Stig > Do you agree? > > Regards, > > Luis > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Wed Feb 3 14:03: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 AFD613A6950 for ; Wed, 3 Feb 2010 14:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Dqm403OQN0ps for ; Wed, 3 Feb 2010 14:03:54 -0800 (PST) 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 543133A6876 for ; Wed, 3 Feb 2010 14:03:54 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 4A9C2221C3; Wed, 3 Feb 2010 23:04:35 +0100 (CET) Message-ID: <4B69F2F0.2010909@venaas.com> Date: Wed, 03 Feb 2010 14:04:32 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Zuniga, Juan Carlos" , Guang.Lu@InterDigital.com, Akbar.Rahman@InterDigital.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: [multimob] Some comments on draft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 22:03:55 -0000 Hi I've read through your draft and got some comments. The discussion in 3.2 on multicast establishment could need some more details, and may also be a bit inaccurate. Some of this is clarified and explained better in 3.3. Regarding MLD. MLD signaling will take place also when multicast service is not needed, at least for link-local groups. If the MN needs multicast services (as in receiving non link-local groups), it will send reports for those. That may also happen before the MN sends router solicitation. I think after the arrow for "Unicast Traffic" you should add an arrow for MLD General Query. Then the node will send MLD Report (also if it does not need multicast services). Any reports for non-link local (site-local, global etc) multicast groups should then be aggregated. You say the aggregated MLD Report is sent before establishing the multicast tunnel. But shouldn't this report go through the multicast tunnel? A multicast router (the LMA here), should receive the report on the interface where it is to send multicast. Regarding establishing the multicast tunnel. This tunnel would I think be created either when the first MN that needs multicast service arrives, or if it is dedicated for multicast it might make sense to set it up initially, even before there are any MNs. 3.3 looks fine. In 3.4 it says: One of the main advantages of the proposed architecture of a dedicated multicast LMA, and MAGs acting as a Proxy MLD, is that it allows a PMIPv6 domain to closely follow a simple multicast tree topology for Proxy MLD forwarding (cf., sections 1.1 and 1.2 of [RFC4605]). I guess I agree with this. Alternatively with multiple upstreams, you would basically have a set of trees. And in our case, the sum of those would still be a tree... You would then still do 4605, but multiple instances to handle the different upstreams. I think the main advantage is that you save bandwidth by having a dedicated multicast LMA when MNs using different LMAs join the same group. You may also say that the total of the resources required on the LMAs is reduced, at least the total amount of state in the LMAs may be reduced. The dedicated multicast LMA may get more state than if it was not dedicated though. Another big advantage is that not all the LMAs need multicast capability and connectivity. I have one question though. With more and more use of VPNs, private addressing (RFC 1918) etc, and also site-local multicast. Is it obvious that all MNs should get the same content on the same group address? As an example, could it be that one MN (subscribing to a particular service, or belonging to some other operator whatever) joins the group 239.255.1.1 to join some specific content, while another MN should be able to join the same group to receive something else? I don't know enough of PMIP usage to say whether that is a valid scenario or not. But if it is, then I think you need different LMAs for the two MNs. Stig From schmidt@informatik.haw-hamburg.de Wed Feb 3 14:57: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 9770B3A685D for ; Wed, 3 Feb 2010 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.423, 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 0aXAsegOCzjS for ; Wed, 3 Feb 2010 14:57:16 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 6CCAE3A680D for ; Wed, 3 Feb 2010 14:57:14 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178143007.adsl.alicedsl.de ([85.178.143.7] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NcoAX-0001wW-3T; Wed, 03 Feb 2010 23:57:57 +0100 Message-ID: <4B69FF67.6070506@informatik.haw-hamburg.de> Date: Wed, 03 Feb 2010 23:57:43 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: In-Reply-To: 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] FW: New Version Notification for draft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 22:57:24 -0000 Dear Juan Carlos, Guang and Akbar, only today I found time to read and review your draft - sorry for being late. Regarding the general solution of a "dedicated multicast LMA", please see my comments sent to Luis today. A couple comments on section 3.4: You solely adopted the view of the one extremal case presented in http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment , namely the case of MNs subscribed to the same multicast group, but associated to different LMAs. This is only the one side of the coin. In this case, it already was acknowledged that a single, common upstream router (the DR misleadingly called "dedicated multicast LMA") is optimal, provided multicast is tunneled to the MAGs. However, your wording "In general, it can be seen that the extra multiplication of packets in the combined unicast/multicast LMA topology will be proportional to the number of LMAs, and the number of MNs (in a given MAG) associated to different LMAs." is misleadingly imprecise: In fact, the extra replication of traffic is proportional to the number of LMAs that MNs are associated with while attached to the same MAG, and while being subscribed to the same multicast group. This number should typically be small, as an LMA is a highly aggregated entity. Correspondingly, the multicast tree structure is indeed simplified for a single group, but for multiple groups, different trees are in use anyway, and the root at multiple LMAs may lead to a better balance of multicast traffic in the access network. A similar argument holds of course for the scaling and avalanche problems at the "multicast tunnel router" (LMA2) as already outlined in draft-schmidt-multimob-pmipv6-mcast-deployment. Scaling or efficiency arguments between the two solutions IMHO always break down to the question about the ratio of MNs : MAGs : LMAs. draft-zuniga-multimob-smspmip reduces the dependency on LMA multiplicities, while draft-schmidt-multimob-pmipv6-mcast-deployment reduces the dependency on MAG multiplicities. But the common understanding of PMIP expects the number of LMAs to be small, while MAGs (access routers) may be deployed at higher numbers. Doesn't it make sense to regard the full picture? Best regards, Thomas Zuniga, Juan Carlos wrote: > Dear all, > > We have just submitted a new version of draft-zuniga-multimob-smspmip > including the feedback received from the group at the IETF76 Hiroshima > meeting and the mailing list. > > http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt > > We look forward to receiving your comments. > > Best regards, > > Juan Carlos, Guang and Akbar > > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, January 14, 2010 5:14 PM > To: Rahman, Akbar > Cc: Zuniga, Juan Carlos; Lu, Guang > Subject: New Version Notification for draft-zuniga-multimob-smspmip-01 > > > A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been > successfuly submitted by Akbar Rahman and posted to the IETF repository. > > Filename: draft-zuniga-multimob-smspmip > Revision: 01 > Title: Support Multicast Services Using Proxy Mobile IPv6 > Creation_date: 2010-01-14 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This document describes how multicast mobility services can be > supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener > Discovery (MLD) [RFC3810], and Internet Group Management Protocol > (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for > multicast listener mobility. It proposes the use of a dedicated Local > Mobility Anchor as the topological anchor point for multicast > traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. > There are no impacts to the Mobile Node to support multicast listener > mobility. > > > > > The IETF Secretariat. > > > _______________________________________________ > 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 Wed Feb 3 15:58:01 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 C208C3A69AB for ; Wed, 3 Feb 2010 15:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 zF3OTwUainYv for ; Wed, 3 Feb 2010 15:58:00 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id 8A75A3A6984 for ; Wed, 3 Feb 2010 15:58:00 -0800 (PST) Received: (qmail 62620 invoked by uid 60001); 3 Feb 2010 23:58:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265241521; bh=hiMEMbrnQaIFAk3ZGnLFulqm+04zJLadRWxEfs662rU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C4Vu3E60RCYWWPJMxxd/RVphYVkjV05xJqvYN2xeWJALBUVdsGxZ8XE1YwhAJvLMvAFghfXMItH5KJ0pxTp4VS40lsb5whYvMlFzXOIxvJe0J6E/r+BC/XtoFujqe4OVthp2lT0DS4OtAaGq7bPWe8C1fHM16+xyRAM5NeyINSA= 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XKV29FUplCX2TK9lkbphLFGlWMIOMzeeGI+tF970vpzBaZBAMcIzKN0oY3L1eIyLdwJEtTnxSqPSFfYIQZkJSIJDK+edEosZph+HbYxxzWMgYLn/VVMztYdabxKp9YDSYa1CnhKDq+rFYytBlsgZ+ZfDzddS3pCVw/DkvoymrN0=; Message-ID: <784692.62586.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: aTj0hMUVM1nTx18fuoMEO4nnZtFwG5J2mNtBjxv1qf3jcyuJxCkBAoDz2PDJiwYfRLRjA3jWIcrhvkYVeo4pLBjbpFSIAF..igp3bO_6Uz0qlJjLz.mtDZxCcXvjjpUxNJ.bSONDbrf3ZILOG2AgRHLB00m4i6XxOWlD4ihlhoJlHuEeuh7_sgR8rhiwNJkTmqO2Jx_QP5dYnm8Dwn00zQWPyCrIIztD1BqqgnibReyytAS1fzWNwmSzpIxPH_4quQ89DMPNbGh_JmRI2fzn7u_qiQSM_ahZ_uzEgNU7waUclznFSdSiwFQ.6LmM9AAHU1vgSt_wD9y3Yy_oA578Zd4PILfBcv15ayQxQyQsjRrRN53eeHa93MIqM3hvMJG2NVs_vQ3kiQpvihF46fzK14hGx6GJpkWh7j5M0CY_DXhjfYcSznp4eA-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 03 Feb 2010 15:58:41 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B69FF67.6070506@informatik.haw-hamburg.de> Date: Wed, 3 Feb 2010 15:58:41 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" , "Zuniga, Juan Carlos" In-Reply-To: <4B69FF67.6070506@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01 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, 03 Feb 2010 23:58:01 -0000 Hello folks,=0A=0A=A0 Multicast LMA, Local MR or variations of these aim to= support the multicast service=A0independent of mobility. From MN point of = view Multicast LMA is not a Local Mobility Anchor. =0A=A0 =0A=A0 Remote sub= scription as defined in the current charter requires the LMA (certainly the= LMA with which MN is registered) to provide the multicast service. This pr= ovides a capability to provide unicast and multicast mobility support.=0A= =0A=A0 We are not looking for an optimal solution, just a base solution. In= the next steps we might need to identify what is not optimal in the base s= olution and look for optimizing things. That will come next. Can multicast = mobility be not supported some other ways in the above "locally available m= ulticast" approaches (and Many other questions that might come to your mind= or my mind)? Maybe so but again that will come next. =0A=0A=A0 That said, = the base solution may already be providing some good=A0optimizations like a= voiding avalanche problem=A0as Jari said in his message. =0A=0A=A0 =0ARegar= ds,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0A> From: Thomas C. Sch= midt =0A> To: "Zuniga, Juan Carlos" =0A> Cc: multimob@ietf.org=0A> Sent: Wed, F= ebruary 3, 2010 4:57:43 PM=0A> Subject: Re: [multimob] FW: New Version Noti= fication for draft-zuniga-multimob-smspmip-01=0A> =0A> Dear Juan Carlos, Gu= ang and Akbar,=0A> =0A> only today I found time to read and review your dra= ft - sorry for being late.=0A> =0A> Regarding the general solution of a "de= dicated multicast LMA", please see my =0A> comments sent to Luis today.=0A>= =0A> A couple comments on section 3.4:=0A> =0A> You solely adopted the vie= w of the one extremal case presented in =0A> http://tools.ietf.org/html/dra= ft-schmidt-multimob-pmipv6-mcast-deployment , =0A> namely the case of MNs s= ubscribed to the same multicast group, but associated to =0A> different LMA= s. This is only the one side of the coin.=0A> =0A> In this case, it already= was acknowledged that a single, common upstream router =0A> (the DR mislea= dingly called "dedicated multicast LMA") is optimal, provided =0A> multicas= t is tunneled to the MAGs.=0A> =0A> However, your wording=0A> =A0 "In gener= al, it can be seen that the extra multiplication of packets=0A> =A0 in the = combined unicast/multicast LMA topology will be proportional=0A> =A0 to the= number of LMAs, and the number of MNs (in a given MAG)=0A> =A0 associated = to different LMAs."=0A> is misleadingly imprecise: In fact, the extra repli= cation of traffic is =0A> proportional to the number of LMAs that MNs are a= ssociated with while attached =0A> to the same MAG, and while being subscri= bed to the same multicast group. This =0A> number should typically be small= , as an LMA is a highly aggregated entity.=0A> =0A> Correspondingly, the mu= lticast tree structure is indeed simplified for a single =0A> group, but fo= r multiple groups, different trees are in use anyway, and the root =0A> at = multiple LMAs may lead to a better balance of multicast traffic in the acce= ss =0A> network.=0A> =0A> A similar argument holds of course for the scalin= g and avalanche problems at the =0A> "multicast tunnel router" (LMA2) as al= ready outlined in =0A> draft-schmidt-multimob-pmipv6-mcast-deployment.=0A> = =0A> Scaling or efficiency arguments between the two solutions IMHO always = break down =0A> to the question about the ratio of MNs : MAGs : LMAs. =0A> = draft-zuniga-multimob-smspmip reduces the dependency on LMA multiplicities,= =0A> while draft-schmidt-multimob-pmipv6-mcast-deployment reduces the depe= ndency on =0A> MAG multiplicities. But the common understanding of PMIP exp= ects the number of =0A> LMAs to be small, while MAGs (access routers) may b= e deployed at higher numbers.=0A> =0A> Doesn't it make sense to regard the = full picture?=0A> =0A> Best regards,=0A> =0A> Thomas=0A> =0A> Zuniga, Juan = Carlos wrote:=0A> > Dear all,=0A> > =0A> > We have just submitted a new ver= sion of draft-zuniga-multimob-smspmip=0A> > including the feedback received= from the group at the IETF76 Hiroshima=0A> > meeting and the mailing list.= =0A> > =0A> > http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt= =0A> > =0A> > We look forward to receiving your comments.=0A> > =0A> > Best= regards,=0A> > =0A> > Juan Carlos, Guang and Akbar=0A> > =0A> > =0A> > =0A= > > -----Original Message-----=0A> > From: IETF I-D Submission Tool [mailto= :idsubmission@ietf.org] Sent: Thursday, =0A> January 14, 2010 5:14 PM=0A> >= To: Rahman, Akbar=0A> > Cc: Zuniga, Juan Carlos; Lu, Guang=0A> > Subject: = New Version Notification for draft-zuniga-multimob-smspmip-01 =0A> > =0A> >= A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been=0A> > = successfuly submitted by Akbar Rahman and posted to the IETF repository.=0A= > > =0A> > Filename:=A0=A0=A0 draft-zuniga-multimob-smspmip=0A> > Revision:= =A0=A0=A0 01=0A> > Title:=A0=A0=A0 =A0=A0=A0 Support Multicast Services Usi= ng Proxy Mobile IPv6=0A> > Creation_date:=A0=A0=A0 2010-01-14=0A> > WG ID:= =A0=A0=A0 =A0=A0=A0 Independent Submission=0A> > Number_of_pages: 12=0A> > = =0A> > Abstract:=0A> > This document describes how multicast mobility servi= ces can be=0A> > supported with Proxy Mobile IPv6 [RFC5213], Multicast List= ener=0A> > Discovery (MLD) [RFC3810], and Internet Group Management Protoco= l=0A> > (IGMP) [RFC3376]. Specifically, this document analyzes scenarios fo= r=0A> > multicast listener mobility. It proposes the use of a dedicated Loc= al=0A> > Mobility Anchor as the topological anchor point for multicast=0A> = > traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy.=0A>= > There are no impacts to the Mobile Node to support multicast listener=0A= > > mobility.=0A> >=A0 =0A> > =0A> > =0A> > The IETF Secretariat.=0A> > =0A= > > =0A> > _______________________________________________=0A> > multimob m= ailing list=0A> > multimob@ietf.org=0A> > https://www.ietf.org/mailman/list= info/multimob=0A> =0A> -- =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0 Hamburg = University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berliner = Tor 7 =B0=0A> =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 2009= 9 Hamburg, Germany =B0=0A> =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42875-8452 =B0=0A> =B0 http://www.infor= matik.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =B0=0A> _______= ________________________________________=0A> multimob mailing list=0A> mult= imob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A= =0A From luisc@it.uc3m.es Thu Feb 4 06:46: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 A2FA73A6C09 for ; Thu, 4 Feb 2010 06:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 U2RR35MH7+Id for ; Thu, 4 Feb 2010 06:46:15 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9CA413A6927 for ; Thu, 4 Feb 2010 06:46:15 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 9943BBAB259; Thu, 4 Feb 2010 15:46:59 +0100 (CET) Received: from 85.62.13.196.static.abi.uni2.es (85.62.13.196.static.abi.uni2.es [85.62.13.196]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Thu, 04 Feb 2010 15:46:57 +0100 Message-ID: <20100204154657.zw5nuuf54ow0k4wg@webcartero01.uc3m.es> Date: Thu, 04 Feb 2010 15:46:57 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> <4B64B2E6.8040908@informatik.haw-hamburg.de> <20100202230713.pptaiazstycc40ww@webcartero01.uc3m.es> <4B69A03F.8000103@informatik.haw-hamburg.de> In-Reply-To: <4B69A03F.8000103@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 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: Thu, 04 Feb 2010 14:46:16 -0000 Hi Thomas, just for clarification > > This is due to a separate multicast delivery layer (provided via > separate tunnels and the "dedicated multicast LMA" ) which is it can be considered that the same tunnel is used to transport both unicast traffic (for the MN subset served by "dedicated multicast LMA") and multicast one. This maybe could need a tunnel pre-configuration, of course (to prevent that the tunnel is already established even if any MN of the subset served by that LMA is present in the network). Regards, Luis From stig@venaas.com Thu Feb 4 08:32:18 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 D05D43A6C57 for ; Thu, 4 Feb 2010 08:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=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 x1uf6kcpUSGV for ; Thu, 4 Feb 2010 08:32:14 -0800 (PST) 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 E16EE3A6C22 for ; Thu, 4 Feb 2010 08:32:13 -0800 (PST) Received: from [192.168.1.101] (adsl-76-254-8-57.dsl.pltn13.sbcglobal.net [76.254.8.57]) by ufisa.uninett.no (Postfix) with ESMTP id D58BC33B81; Thu, 4 Feb 2010 17:32:58 +0100 (CET) Message-ID: <4B6AF660.409@venaas.com> Date: Thu, 04 Feb 2010 08:31:28 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <4B69FF67.6070506@informatik.haw-hamburg.de> <784692.62586.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <784692.62586.qm@web111407.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org, "Thomas C. Schmidt" , "Zuniga, Juan Carlos" Subject: Re: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01 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: Thu, 04 Feb 2010 16:32:19 -0000 Behcet Sarikaya wrote: > Hello folks, > > Multicast LMA, Local MR or variations of these aim to support the multicast service independent of mobility. From MN point of view Multicast LMA is not a Local Mobility Anchor. > > Remote subscription as defined in the current charter requires the LMA (certainly the LMA with which MN is registered) to provide the multicast service. This provides a capability to provide unicast and multicast mobility support. > > We are not looking for an optimal solution, just a base solution. In the next steps we might need to identify what is not optimal in the base solution and look for optimizing things. That will come next. Can multicast mobility be not supported some other ways in the above "locally available multicast" approaches (and Many other questions that might come to your mind or my mind)? Maybe so but again that will come next. FWIW, this is how I interpret the charter as well. I wrote something along these lines a week ago or something. Stig > That said, the base solution may already be providing some good optimizations like avoiding avalanche problem as Jari said in his message. > > > Regards, > > Behcet > > > ----- Original Message ---- >> From: Thomas C. Schmidt >> To: "Zuniga, Juan Carlos" >> Cc: multimob@ietf.org >> Sent: Wed, February 3, 2010 4:57:43 PM >> Subject: Re: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01 >> >> Dear Juan Carlos, Guang and Akbar, >> >> only today I found time to read and review your draft - sorry for being late. >> >> Regarding the general solution of a "dedicated multicast LMA", please see my >> comments sent to Luis today. >> >> A couple comments on section 3.4: >> >> You solely adopted the view of the one extremal case presented in >> http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment , >> namely the case of MNs subscribed to the same multicast group, but associated to >> different LMAs. This is only the one side of the coin. >> >> In this case, it already was acknowledged that a single, common upstream router >> (the DR misleadingly called "dedicated multicast LMA") is optimal, provided >> multicast is tunneled to the MAGs. >> >> However, your wording >> "In general, it can be seen that the extra multiplication of packets >> in the combined unicast/multicast LMA topology will be proportional >> to the number of LMAs, and the number of MNs (in a given MAG) >> associated to different LMAs." >> is misleadingly imprecise: In fact, the extra replication of traffic is >> proportional to the number of LMAs that MNs are associated with while attached >> to the same MAG, and while being subscribed to the same multicast group. This >> number should typically be small, as an LMA is a highly aggregated entity. >> >> Correspondingly, the multicast tree structure is indeed simplified for a single >> group, but for multiple groups, different trees are in use anyway, and the root >> at multiple LMAs may lead to a better balance of multicast traffic in the access >> network. >> >> A similar argument holds of course for the scaling and avalanche problems at the >> "multicast tunnel router" (LMA2) as already outlined in >> draft-schmidt-multimob-pmipv6-mcast-deployment. >> >> Scaling or efficiency arguments between the two solutions IMHO always break down >> to the question about the ratio of MNs : MAGs : LMAs. >> draft-zuniga-multimob-smspmip reduces the dependency on LMA multiplicities, >> while draft-schmidt-multimob-pmipv6-mcast-deployment reduces the dependency on >> MAG multiplicities. But the common understanding of PMIP expects the number of >> LMAs to be small, while MAGs (access routers) may be deployed at higher numbers. >> >> Doesn't it make sense to regard the full picture? >> >> Best regards, >> >> Thomas >> >> Zuniga, Juan Carlos wrote: >>> Dear all, >>> >>> We have just submitted a new version of draft-zuniga-multimob-smspmip >>> including the feedback received from the group at the IETF76 Hiroshima >>> meeting and the mailing list. >>> >>> http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt >>> >>> We look forward to receiving your comments. >>> >>> Best regards, >>> >>> Juan Carlos, Guang and Akbar >>> >>> >>> >>> -----Original Message----- >>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Thursday, >> January 14, 2010 5:14 PM >>> To: Rahman, Akbar >>> Cc: Zuniga, Juan Carlos; Lu, Guang >>> Subject: New Version Notification for draft-zuniga-multimob-smspmip-01 >>> >>> A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been >>> successfuly submitted by Akbar Rahman and posted to the IETF repository. >>> >>> Filename: draft-zuniga-multimob-smspmip >>> Revision: 01 >>> Title: Support Multicast Services Using Proxy Mobile IPv6 >>> Creation_date: 2010-01-14 >>> WG ID: Independent Submission >>> Number_of_pages: 12 >>> >>> Abstract: >>> This document describes how multicast mobility services can be >>> supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener >>> Discovery (MLD) [RFC3810], and Internet Group Management Protocol >>> (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for >>> multicast listener mobility. It proposes the use of a dedicated Local >>> Mobility Anchor as the topological anchor point for multicast >>> traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. >>> There are no impacts to the Mobile Node to support multicast listener >>> mobility. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> _______________________________________________ >>> 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 ° >> _______________________________________________ >> 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 From schmidt@informatik.haw-hamburg.de Mon Feb 8 06:21:39 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 492AA3A73D8 for ; Mon, 8 Feb 2010 06:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.366, 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 lxzCqlco-sC2 for ; Mon, 8 Feb 2010 06:21:38 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 0A7973A73DE for ; Mon, 8 Feb 2010 06:21:37 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178132053.adsl.alicedsl.de ([85.178.132.53] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NeUVZ-00017p-Cx for multimob@ietf.org; Mon, 08 Feb 2010 15:22:37 +0100 Message-ID: <4B701E1D.3090301@informatik.haw-hamburg.de> Date: Mon, 08 Feb 2010 15:22:21 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org 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] State of IGMP/MLD Proxy Implementations 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, 08 Feb 2010 14:21:39 -0000 Folks, in previous technical discussions concerned with 'ready-to-deploy' solutions for a proxy-based solution as proposed in http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-mcast-deployment , the question arose on current proxy implementations. As promised, we have tested a couple of them (including quick code reviews in the open source world) and found that all required features are splattered around, none of them combined in one implementation. In detail: Cisco Edge Router Software-based commodity edge routers (test device from the 26xx-Series) implement IGMPv2/v3 proxy functions only in combination with PIM-SM. There is no support of MLD Proxy. Interfaces are dynamically configurable at runtime via the CLI, but multiple proxy instances are not supported. Linux igmpproxy IGMPv2 Proxy implementation that permits a static configuration of downstream interfaces (simple bug fix required). Multiple instances are prevented by a lock (corresponding code re- used from a previous DVMRP implementation). IPv6/MLD is unsupported. Project page: http://sourceforge.net/projects/igmpproxy/. Linux gproxy IGMPv3 Proxy implementation that permits configuration of the upstream interface, only. Downstream interfaces are collected at startup without dynamic extension of this list. No support of multiple instances or MLD. Project page: http:// potiron.loria.fr/projects/madynes/internals/perso/lahmadi/ igmpv3proxy/. Linux ecmh MLDv1/2 Proxy implementation without IGMP support that inspects IPv4 tunnels and detects entcapsulated MLD messages. Allows for dynamic addition of interfaces at runtime and multiple instances. However, downstream interfaces cannot be configured. Project page: http://sourceforge.net/projects/ecmh/ We are now thinking about re-working and maturing one of the Linux-based open source implementations. Is anybody willing to contribute? This and more details will be part of the next version of the draft to be released soon. 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 schmidt@informatik.haw-hamburg.de Mon Feb 8 13:01:18 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 788C528C185 for ; Mon, 8 Feb 2010 13:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.284, 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 WhI2WXlZeSlX for ; Mon, 8 Feb 2010 13:01:17 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 48D8E28C182 for ; Mon, 8 Feb 2010 13:01:17 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178132053.adsl.alicedsl.de ([85.178.132.53] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NeakN-000PF6-J4 for multimob@ietf.org; Mon, 08 Feb 2010 22:02:19 +0100 Message-ID: <4B707BCB.2020805@informatik.haw-hamburg.de> Date: Mon, 08 Feb 2010 22:02:03 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-04] 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, 08 Feb 2010 21:01:18 -0000 Hi, we have submitted a revised version of the PMIPv6 deployment draft. This version includes all contributions from the extensive and fruitful discussions since the last update in December. From the Change Log The following changes have been made from draft-schmidt-multimob-pmipv6-mcast-deployment-03. 1. Detailed outline of multicast reconfiguration steps on handovers added in protocol overview (section 3). 2. Clarified the details of proxy operations at the MAG along with the expected features of IGMP/MLD Proxy implementations (section 4.2). 3. Clarified querying in dual-stack scenarios (section 4.4). 4. Subsection added on the special case, where multicast is available throughout the access network (section 4.5). 5. Appendix on IGMP/MLD behaviour added with test reports on current Proxy implementations. We now believe the approach has been thoroughly discussed and the document is mature enough to be considered as a WG item. Best wishes, Thomas -------- Original Message -------- Subject: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-04 Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC: schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-mcast-deployment Revision: 04 Title: A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains Creation_date: 2010-02-08 WG ID: Independent Submission Number_of_pages: 19 Abstract: 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. The IETF Secretariat. -- 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 Feb 8 13:22:20 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 8A5D43A7490 for ; Mon, 8 Feb 2010 13:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 nE1fYWVJyTpi for ; Mon, 8 Feb 2010 13:22:19 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 6C01C3A73A6 for ; Mon, 8 Feb 2010 13:22:19 -0800 (PST) Received: (qmail 47042 invoked by uid 60001); 8 Feb 2010 21:23:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265664200; bh=EgmmvOGLzRuVHPdzTy9r7+wHIf7erQlnmyhVgAbkbzo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r7TYPJ6xZmMAtrFmEWQN+8KZ3EMcYVCJrKsC5M4OEFNmcR9E4/82b1zwyRJH3pYNkbyLOhnNjPjPH/f8luvquQEz6iJTJKi8v8csMI4XOsHyvWFnpUdpK8pztncPbdKq7QNTbxL9p5QTFDDRyzJtp6wxqiG0UI47XpAJwLci5Yc= 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=BIamjcBRDOCxVchF56zFwhmnJkaPFAiBKUhEnrJaXEp8i4HyZ/eFNqlurneorzwloBuhZfDgbR3++zlDczRPrCSd+xRrhC6ScJs3U3j8Xh7ujKGvL7Zeih5SYWC4lAyaVhsvV01/AFowmb4wd6pkhKHkOV5rRCtLrGnzXQRXris=; Message-ID: <647440.46250.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: VwFwfpIVM1lEnmQfkuhGUICi.2tJcTzX4kwCMcp0No1JesMMH.u23aaU1D2JV6rwzxSEr5ome1SBJpaOdw37AkS_o5jlKxNDvvgRtfsRe8Shuc2i_z6ryJeXN6JlLfULlz.a6ByaJXPTD5_OKrVo4519ZoKpPyzYae3Oi4dqo.Hs3Syv8AIdoW9AA3Up4Efzj2KPVeDX26O8wXTssBIAg9SfygyByiY57wRaEIMUMtMnd8W.bU6.9e7U3KOiIv6zjPb6Q80SVHEV1aKF6T6jHQBHXB8D.UP2246JDvlZVJJskvGZpDbKr2BfsBpkUNz1mBAqU.d0t_V8jm8YYVuS5W2eQU1WGxcuzcXpcfT18RjYK.Cc65qmpSzv_tPKSQ7QEquZMBYO.KzN.TbeeIf89lYz6Bx0j.CtjY8okMSLwHYuKv_nto8xnwbZ9THdpW.FvTWxUDDl Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Mon, 08 Feb 2010 13:23:20 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 Date: Mon, 8 Feb 2010 13:23:20 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 08 Feb 2010 21:22:20 -0000 This mail starts a WG adoption call on this draft.=0A=0AThe intended status= for this document is BCP.=0AIf adopted, the draft will be named:=0A=0Adraf= t-ietf-multimob-pmipv6-base-solution.=0A=0APlease respond if you=A0are for = ADOPTING=A0or=0A=0Ayou are NOT for ADOPTING it by February 21, 2010.=0A=0AR= egards,=0A=0ABehcet=0A=0A=0A=0A----- Forwarded Message ----=0A> From: Thoma= s C. Schmidt =0A> To: multimob@ietf.org= =0A> Sent: Mon, February 8, 2010 3:02:03 PM=0A> Subject: [multimob] [Fwd: N= ew Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-= 04]=0A> =0A> Hi,=0A> =0A> we have submitted a revised version of the PMIPv6= deployment draft.=0A> This version includes all contributions from the ext= ensive and fruitful =0A> discussions since the last update in December.=0A>= =0A> From the Change Log=0A> =0A> =A0 The following changes have been made= from=0A> =A0 draft-schmidt-multimob-pmipv6-mcast-deployment-03.=0A> =0A> = =A0 1.=A0 Detailed outline of multicast reconfiguration steps on handovers= =0A> =A0 =A0 =A0 added in protocol overview (section 3).=0A> =0A> =A0 2.=A0= Clarified the details of proxy operations at the MAG along with=0A> =A0 = =A0 =A0 the expected features of IGMP/MLD Proxy implementations (section=0A= > =A0 =A0 =A0 4.2).=0A> =0A> =A0 3.=A0 Clarified querying in dual-stack sce= narios (section 4.4).=0A> =0A> =A0 4.=A0 Subsection added on the special ca= se, where multicast is=0A> =A0 =A0 =A0 available throughout the access netw= ork (section 4.5).=0A> =0A> =A0 5.=A0 Appendix on IGMP/MLD behaviour added = with test reports on current=0A> =A0 =A0 =A0 Proxy implementations.=0A> =0A= > =0A> We now believe the approach has been thoroughly discussed and the do= cument is =0A> mature enough to be considered as a WG item.=0A> =0A> Best w= ishes,=0A> =0A> Thomas=0A> =0A> -------- Original Message --------=0A> Subj= ect: New Version Notification for =0A> draft-schmidt-multimob-pmipv6-mcast-= deployment-04=0A> Date: Mon,=A0 8 Feb 2010 12:53:11 -0800 (PST)=0A> From: I= ETF I-D Submission Tool =0A> To: Schmidt@informatik.haw-hamburg.de=0A> CC: = =0A> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eric= sson.com=0A> =0A> =0A> A new version of I-D, draft-schmidt-multimob-pmipv6-= mcast-deployment-04.txt has =0A> been successfuly submitted by Thomas Schmi= dt and posted to the IETF repository.=0A> =0A> Filename:=A0=A0=A0 draft-sch= midt-multimob-pmipv6-mcast-deployment=0A> Revision:=A0=A0=A0 04=0A> Title:= =A0=A0=A0 =A0=A0=A0 A Minimal Deployment Option for Multicast Listeners in = PMIPv6 =0A> Domains=0A> Creation_date:=A0=A0=A0 2010-02-08=0A> WG ID:=A0=A0= =A0 =A0=A0=A0 Independent Submission=0A> Number_of_pages: 19=0A> =0A> Abstr= act:=0A> This document describes deployment options for activating multicas= t=0A> listener functions in Proxy Mobile IPv6 domains without modifying=0A>= mobility and multicast protocol standards.=A0 Similar to Home Agents in=0A= > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast=0A> subscri= ption anchor points, while Mobile Access Gateways provide MLD=0A> proxy fun= ctions.=A0 In this scenario, Mobile Nodes remain agnostic of=0A> multicast = mobility operations.=0A> =0A> =0A> =0A> =0A> The IETF Secretariat.=0A> =0A>= =0A> =0A> -- =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0 Hamburg University o= f Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berliner Tor 7 =B0=0A= > =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 Hamburg, G= ermany =B0=0A> =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Fon: +49-40-42875-8452 =B0=0A> =B0 http://www.informatik.haw-ha= mburg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =B0=0A> ___________________= ____________________________=0A> multimob mailing list=0A> multimob@ietf.or= g=0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A From I.Romdhani@napier.ac.uk Tue Feb 9 09:31: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 56F5928C159 for ; Tue, 9 Feb 2010 09:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qV8Af8DcbUhs for ; Tue, 9 Feb 2010 09:31:41 -0800 (PST) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by core3.amsl.com (Postfix) with ESMTP id A8BEB28C125 for ; Tue, 9 Feb 2010 09:31:40 -0800 (PST) Received: from mail75-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 8.1.340.0; Tue, 9 Feb 2010 17:32:47 +0000 Received: from mail75-va3 (localhost [127.0.0.1]) by mail75-va3-R.bigfish.com (Postfix) with ESMTP id 08CC51940256; Tue, 9 Feb 2010 17:32:47 +0000 (UTC) X-SpamScore: -118 X-BigFish: VPS-118(z4201hz13feK542N2e57K154dM1432R1417J936eM1370I8f9KJaf6La2dbK9371P8c8aizz1202hz4fhz1033ILz2ei6bh61h) X-Spam-TCS-SCL: 0:0 Received: from mail75-va3 (localhost.localdomain [127.0.0.1]) by mail75-va3 (MessageSwitch) id 1265736766289179_7513; Tue, 9 Feb 2010 17:32:46 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.250]) by mail75-va3.bigfish.com (Postfix) with ESMTP id 283473E0055; Tue, 9 Feb 2010 17:32:46 +0000 (UTC) Received: from crl-hub-1.napier-mail.napier.ac.uk (146.176.222.89) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.0.482.39; Tue, 9 Feb 2010 17:32:43 +0000 Received: from E2K7MBX.napier-mail.napier.ac.uk ([146.176.250.56]) by crl-hub-1.napier-mail.napier.ac.uk ([146.176.222.17]) with mapi; Tue, 9 Feb 2010 17:33:09 +0000 From: "Romdhani, Imed" To: Behcet Sarikaya , "multimob@ietf.org" Date: Tue, 9 Feb 2010 17:32:40 +0000 Thread-Topic: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: AcqpBPeuak7MtFpCRZWpaDB+5eR6YAAqLL4A Message-ID: <78F1C759D89E1C44A6DD4C06B9A4B270BA741370BB@E2K7MBX.napier-mail.napier.ac.uk> References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> In-Reply-To: <647440.46250.qm@web111410.mail.gq1.yahoo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Reverse-DNS: crl-hub-1.napier-mail.napier.ac.uk Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 09 Feb 2010 17:31:43 -0000 Dear all, I am for ADOPTING this solution. Regards, Imed -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of Behcet Sarikaya Sent: 08 February 2010 21:23 To: multimob@ietf.org Subject: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast= -deployment-04 This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you=A0are for ADOPTING=A0or you are NOT for ADOPTING it by February 21, 2010. Regards, Behcet ----- Forwarded Message ---- > From: Thomas C. Schmidt > To: multimob@ietf.org > Sent: Mon, February 8, 2010 3:02:03 PM > Subject: [multimob] [Fwd: New Version Notification for draft-schmidt-mult= imob-pmipv6-mcast-deployment-04] > = > Hi, > = > we have submitted a revised version of the PMIPv6 deployment draft. > This version includes all contributions from the extensive and fruitful = > discussions since the last update in December. > = > From the Change Log > = > =A0 The following changes have been made from > =A0 draft-schmidt-multimob-pmipv6-mcast-deployment-03. > = > =A0 1.=A0 Detailed outline of multicast reconfiguration steps on handover= s > =A0 =A0 =A0 added in protocol overview (section 3). > = > =A0 2.=A0 Clarified the details of proxy operations at the MAG along with= > =A0 =A0 =A0 the expected features of IGMP/MLD Proxy implementations (sect= ion > =A0 =A0 =A0 4.2). > = > =A0 3.=A0 Clarified querying in dual-stack scenarios (section 4.4). > = > =A0 4.=A0 Subsection added on the special case, where multicast is > =A0 =A0 =A0 available throughout the access network (section 4.5). > = > =A0 5.=A0 Appendix on IGMP/MLD behaviour added with test reports on curre= nt > =A0 =A0 =A0 Proxy implementations. > = > = > We now believe the approach has been thoroughly discussed and the documen= t is = > mature enough to be considered as a WG item. > > Best wishes, > = > Thomas > = > -------- Original Message -------- > Subject: New Version Notification for = > draft-schmidt-multimob-pmipv6-mcast-deployment-04 > Date: Mon,=A0 8 Feb 2010 12:53:11 -0800 (PST) > From: IETF I-D Submission Tool = > To: Schmidt@informatik.haw-hamburg.de > CC: = > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsso= n.com > = > = > A new version of I-D, draft-schmidt-multimob-pmipv6-mcast-deployment-04.t= xt has = > been successfuly submitted by Thomas Schmidt and posted to the IETF repos= itory. > = > Filename:=A0=A0=A0 draft-schmidt-multimob-pmipv6-mcast-deployment > Revision:=A0=A0=A0 04 > Title:=A0=A0=A0 =A0=A0=A0 A Minimal Deployment Option for Multicast Liste= ners in PMIPv6 = > Domains > Creation_date:=A0=A0=A0 2010-02-08 > WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission > Number_of_pages: 19 > = > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards.=A0 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.=A0 In this scenario, Mobile Nodes remain agnostic of > multicast mobility operations. > = > = > = > = > The IETF Secretariat. > = > = > = > -- = > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 Berliner Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 Hamburg, G= ermany =B0 > =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon= : +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-4287= 5-8409 =B0 > _______________________________________________ > 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 On 25 February 2009, the University launched its new name, Edinburgh Napier= University. = For more information please visit our website. Edinburgh Napier University is one of the top 10 universities in the UK for= graduate employability (HESA 2009) This message is intended for the addressee(s) only and should not be read, = copied or disclosed to anyone else out-with the University without the perm= ission of the sender. It is your responsibility to ensure that this message and any attachments a= re scanned for viruses or other defects. Edinburgh Napier University does n= ot accept liability for any loss or damage which may result from this email= or any attachment, or for errors or omissions arising after it was sent. E= mail is not a secure medium. Email entering the University's system is subj= ect to routine monitoring and filtering by the University. Edinburgh Napier University is a registered Scottish charity. Registration = number SC018373 From sijeon79@gmail.com Tue Feb 9 18:58: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 724453A6E02 for ; Tue, 9 Feb 2010 18:58:11 -0800 (PST) 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 d6JnfSi4XYTL for ; Tue, 9 Feb 2010 18:58:09 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 935F63A6D06 for ; Tue, 9 Feb 2010 18:58:09 -0800 (PST) Received: by ywh15 with SMTP id 15so2086304ywh.5 for ; Tue, 09 Feb 2010 18:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=yWyp5f+8InJPb+0ssyCE36gIB632ER6ZwecYNH3XfiQ=; b=DET1iNFERs6FL6IwElyCUgJOY3d86HEzrhHVKHVW2c1SywlZRTcrQrjHipdhl32uQf Er4tOI7HL0B7cDWk3JU3+YDD6T+pRvkM/ez3u64YNB6CMiHT9ssk0Bub5FvhrPS/oYem p6VRKLDbSLd8I5D122pCOWfxea+GjHUxb9ru8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:in-reply-to:x-mimeole; b=DZ2+JdrfN7b5uWD6xsHlRGbYNbtDd7zZkWSEAH/66H/gY4cgrG/9fx2k5f8CzDMC2b VsZjWjAjMBkB+ru1pGoISMMF9VMoooG3aPE5G+8Af2KlA7TTpXCzqmx9DDvIrD2hdgdn bOlvOYk6pPNTm9Uj/xPoMi3alSEZMrDPPiqqM= Received: by 10.150.238.4 with SMTP id l4mr1411999ybh.128.1265770755227; Tue, 09 Feb 2010 18:59:15 -0800 (PST) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id 9sm274492ywf.50.2010.02.09.18.59.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Feb 2010 18:59:14 -0800 (PST) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> Date: Wed, 10 Feb 2010 11:59:12 +0900 Organization: dcn Message-ID: <7A995DEDAD7A49CA8752D887F4771E9B@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqpBPgMLo1E3+XGSfGZVooOJJEzCAA94MZA In-Reply-To: <647440.46250.qm@web111410.mail.gq1.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: multimob@ietf.org Subject: Re: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 02:58:11 -0000 Dear all, I think that this draft is in accordance with this charter among = tunneling mode approach. I am for ADOPTING this draft. Best Regards, Seil Jeon =20 -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Tuesday, February 09, 2010 6:23 AM To: multimob@ietf.org Subject: [multimob] WG Adoption call = ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you are for ADOPTING or you are NOT for ADOPTING it by February 21, 2010. Regards, Behcet ----- Forwarded Message ---- > From: Thomas C. Schmidt > To: multimob@ietf.org > Sent: Mon, February 8, 2010 3:02:03 PM > Subject: [multimob] [Fwd: New Version Notification for=20 > draft-schmidt-multimob-pmipv6-mcast-deployment-04] >=20 > Hi, >=20 > we have submitted a revised version of the PMIPv6 deployment draft. > This version includes all contributions from the extensive and=20 > fruitful discussions since the last update in December. >=20 > From the Change Log >=20 > The following changes have been made from > draft-schmidt-multimob-pmipv6-mcast-deployment-03. >=20 > 1. Detailed outline of multicast reconfiguration steps on handovers > added in protocol overview (section 3). >=20 > 2. Clarified the details of proxy operations at the MAG along with > the expected features of IGMP/MLD Proxy implementations (section > 4.2). >=20 > 3. Clarified querying in dual-stack scenarios (section 4.4). >=20 > 4. Subsection added on the special case, where multicast is > available throughout the access network (section 4.5). >=20 > 5. Appendix on IGMP/MLD behaviour added with test reports on=20 > current > Proxy implementations. >=20 >=20 > We now believe the approach has been thoroughly discussed and the=20 > document is mature enough to be considered as a WG item. >=20 > Best wishes, >=20 > Thomas >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-schmidt-multimob-pmipv6-mcast-deployment-04 > Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC:=20 > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eric > sson.com >=20 >=20 > A new version of I-D,=20 > draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been = successfuly submitted by Thomas Schmidt and posted to the IETF = repository. >=20 > Filename: draft-schmidt-multimob-pmipv6-mcast-deployment > Revision: 04 > Title: A Minimal Deployment Option for Multicast Listeners in=20 > PMIPv6 Domains > Creation_date: 2010-02-08 > WG ID: Independent Submission > Number_of_pages: 19 >=20 > Abstract: > This document describes deployment options for activating multicast=20 > listener functions in Proxy Mobile IPv6 domains without modifying=20 > mobility and multicast protocol standards. Similar to Home Agents in=20 > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast=20 > subscription anchor points, while Mobile Access Gateways provide MLD=20 > proxy functions. In this scenario, Mobile Nodes remain agnostic of=20 > multicast mobility operations. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > -- > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences = Berliner Tor=20 > 7 =C2=B0 =C2=B0 Dept. Informatik, Internet Technologies Group 20099 = Hamburg,=20 > Germany =C2=B0 =C2=B0 http://www.haw-hamburg.de/inet = Fon:=20 > +49-40-42875-8452 =C2=B0 =C2=B0 = http://www.informatik.haw-hamburg.de/~schmidt =20 > Fax: +49-40-42875-8409 =C2=B0=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Wed Feb 17 04:14:50 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 2279C3A7CE1 for ; Wed, 17 Feb 2010 04:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YOAgYThQDhhd for ; Wed, 17 Feb 2010 04:14:48 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 2A2673A7DE7 for ; Wed, 17 Feb 2010 04:14:40 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 17 Feb 2010 13:16:10 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 13:16:09 +0100 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: Wed, 17 Feb 2010 13:16:08 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <647440.46250.qm@web111410.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 thread-index: AcqpBPSo7p9KZRrDQnWpKwjIVIET+wGxUgbw References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 17 Feb 2010 12:16:09.0968 (UTC) FILETIME=[FD327F00:01CAAFCA] Subject: Re: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 17 Feb 2010 12:14:50 -0000 Dear all, Following the latest discussions on basic solutions for PMIP-multimob I = am convinced that this draft will serve as a good basis for the further = WG discussion, so I am in favour of adopting the document. I also think the more detailed exlanations and Appendix on = implementations is quite useful.=20 Best regards Dirk PS: The only very minor nit I found was in Appendix B: 'encapsulated' = instead of 'entcapsulated' ;-) -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Montag, 8. Februar 2010 22:23 An: multimob@ietf.org Betreff: [multimob] WG Adoption call = ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you=A0are for ADOPTING=A0or you are NOT for ADOPTING it by February 21, 2010. Regards, Behcet ----- Forwarded Message ---- > From: Thomas C. Schmidt > To: multimob@ietf.org > Sent: Mon, February 8, 2010 3:02:03 PM > Subject: [multimob] [Fwd: New Version Notification for = draft-schmidt-multimob-pmipv6-mcast-deployment-04] >=20 > Hi, >=20 > we have submitted a revised version of the PMIPv6 deployment draft. > This version includes all contributions from the extensive and = fruitful=20 > discussions since the last update in December. >=20 > From the Change Log >=20 > =A0 The following changes have been made from > =A0 draft-schmidt-multimob-pmipv6-mcast-deployment-03. >=20 > =A0 1.=A0 Detailed outline of multicast reconfiguration steps on = handovers > =A0 =A0 =A0 added in protocol overview (section 3). >=20 > =A0 2.=A0 Clarified the details of proxy operations at the MAG along = with > =A0 =A0 =A0 the expected features of IGMP/MLD Proxy implementations = (section > =A0 =A0 =A0 4.2). >=20 > =A0 3.=A0 Clarified querying in dual-stack scenarios (section 4.4). >=20 > =A0 4.=A0 Subsection added on the special case, where multicast is > =A0 =A0 =A0 available throughout the access network (section 4.5). >=20 > =A0 5.=A0 Appendix on IGMP/MLD behaviour added with test reports on = current > =A0 =A0 =A0 Proxy implementations. >=20 >=20 > We now believe the approach has been thoroughly discussed and the = document is=20 > mature enough to be considered as a WG item. >=20 > Best wishes, >=20 > Thomas >=20 > -------- Original Message -------- > Subject: New Version Notification for=20 > draft-schmidt-multimob-pmipv6-mcast-deployment-04 > Date: Mon,=A0 8 Feb 2010 12:53:11 -0800 (PST) > From: IETF I-D Submission Tool=20 > To: Schmidt@informatik.haw-hamburg.de > CC:=20 > = schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsso= n.com >=20 >=20 > A new version of I-D, = draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has=20 > been successfuly submitted by Thomas Schmidt and posted to the IETF = repository. >=20 > Filename:=A0=A0=A0 draft-schmidt-multimob-pmipv6-mcast-deployment > Revision:=A0=A0=A0 04 > Title:=A0=A0=A0 =A0=A0=A0 A Minimal Deployment Option for Multicast = Listeners in PMIPv6=20 > Domains > Creation_date:=A0=A0=A0 2010-02-08 > WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission > Number_of_pages: 19 >=20 > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards.=A0 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.=A0 In this scenario, Mobile Nodes remain agnostic of > multicast mobility operations. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > --=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Berliner Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 = Hamburg, Germany =B0 > =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Fon: +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: = +49-40-42875-8409 =B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From Guang.Lu@InterDigital.com Wed Feb 17 13:46:15 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 A2B433A7BC5 for ; Wed, 17 Feb 2010 13:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 jW-ZtW-1sbtG for ; Wed, 17 Feb 2010 13:46:14 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 1AE303A7353 for ; Wed, 17 Feb 2010 13:46:13 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 16:47:53 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 16:47:17 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 17 Feb 2010 16:47:15 -0500 Message-ID: In-Reply-To: <4B707BCB.2020805@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] [Fwd: New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-04] Thread-Index: AcqpAg9ysEk+DaKEQLmmIIYQxSvMzQHF30JQ References: <4B707BCB.2020805@informatik.haw-hamburg.de> From: "Lu, Guang" To: X-OriginalArrivalTime: 17 Feb 2010 21:47:17.0336 (UTC) FILETIME=[C623E580:01CAB01A] Subject: Re: [multimob] [Fwd: New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-04] 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, 17 Feb 2010 21:46:15 -0000 SGkgVGhvbWFzLCANCg0KV2UgcmV2aWV3ZWQgeW91ciBkcmFmdCAoZHJhZnQtc2NobWlkdC1tdWx0 aW1vYi1wbWlwdjYtbWNhc3QtZGVwbG95bWVudC0wNCkuIEl0IGlzIGluIGdvb2Qgc2hhcGUuIFBs ZWFzZSBzZWUgYmVsb3cgc29tZSBjb21tZW50cyB3ZSBoYXZlLiANCg0KKGEpIEFwcGVuZGl4IEMu IENvbXBhcmF0aXZlIEV2YWx1YXRpb24gb2YgRGlmZmVyZW50IEFwcHJvYWNoZXMNCg0KSW4gdGhl IHRhYmxlcywgeW91IHByb3ZpZGVkIGNvbXBhcmlzb24gb2YgIiMgb2YgcmVkdW5kYW50IHN0cmVh bXMgYXQgTUFHIiBhbmQgIiMgb2Ygc2ltLiBTdHJlYW1zIGF0IExNQSAvIExNQS1NIi4gU2hvd2lu ZyB0aGUgc3RyZWFtcyBhdCBlYWNoIExNQSBpcyBnb29kIGJ1dCBub3QgZW5vdWdoIHRob3VnaCBz aW5jZSBpdCBvbmx5IHNob3dzIHRoZSBsb2FkIG9mIG9uZSBub2RlLiBJTUhPIGl0IGlzIGFsc28g ZXNzZW50aWFsIHRvIHByb3ZpZGUgdG90YWwgbnVtYmVyIG9mIHNpbXVsdGFuZW91cyBzdHJlYW1z IG5ldHdvcmsgd2lzZSB0byBzaG93IHRoZSB3aG9sZSBwaWN0dXJlLiBOb3RlIHRoYXQgdGhpcyBw b2ludCB3YXMgcmFpc2VkIGJlZm9yZSBpbiB0aGUgbWFpbGluZyBsaXN0IChodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbXVsdGltb2IvY3VycmVudC9tc2cwMDc0MS5odG1sKS4g DQoNClBsZWFzZSBzZWUgYmVsb3cgdGhlIGV4dGVuZGVkIHRhYmxlcyB3aXRoIGEgbmV3IGNvbHVt biBzaG93aW5nICIjIG9mIHNpbS4gU3RyZWFtcyBpbiBuZXR3b3JrIGZvciBhbGwgTE1BcyIuIFRo aXMgaW5mb3JtYXRpb24gY2FuIGNsZWFybHkgYW5zd2VyIHNvbWUgcXVlc3Rpb25zIHJhaXNlZCBi eSB0aGUgZ3JvdXAgcmVnYXJkaW5nIHRoZSB0cmFmZmljIHByb2ZpbGUgaW4gdmFyaW91cyBzY2Vu YXJpb3MuDQoNClNldHRpbmcgMTogIDEsMDAwLDAwMCBNTnMgYXJlIHN1YnNjcmliZWQgdG8gZGlz dGluY3QgbXVsdGljYXN0IGdyb3Vwcw0KDQpUaGUgY29tYmluZWQgVW5pY2FzdC9NdWx0aWNhc3Qg TE1BIHNjaGVtZSBoYXMgNCBMTUFzLCBlYWNoIHdpdGggMjUwLDAwMCBzdHJlYW1zLiBTbyBpbiB0 aGUgbmV0d29yaywgYm90aCBzb2x1dGlvbnMgaGF2ZSB0aGUgc2FtZSBudW1iZXIgb2Ygc2ltdWx0 YW5lb3VzIHN0cmVhbXMuIA0KIA0KKz09PT09PT09PT09PT0rPT09PT09PT09PT0rPT09PT09PT09 PT09PT09PSs9PT09PT09PT09PT09PT09PT09DQp8ICAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCnwgICBQTUlQICAgICAgfCAjIG9m ICAgICAgfCAjIG9mIHNpbS4gICAgICB8IyBvZiBzaW0uIHN0cmVhbXMgfA0KfCBNdWx0aWNhc3Qg ICB8IHJlZHVuZGFudCB8IHN0cmVhbXMgYXQgICAgIHxpbiBuZXR3b3JrICAgICAgICB8DQp8IHNj aGVtZSAgICAgIHwgc3RyZWFtcyAgIHwgZWFjaCBMTUEvTE1BLU0gfGZvciBhbGwgTE1BcyAgICAg IHwNCnwgICAgICAgICAgICAgfCBhdCBNQUcgICAgfCBMTUEvTE1BLU0gICAgICB8ICAgICAgICAg ICAgICAgICAgfCAgICAgICANCis9PT09PT09PT09PT09Kz09PT09PT09PT09Kz09PT09PT09PT09 PT09PT0rPT09PT09PT09PT09PT09PT09fA0KfCBDb21iaW5lZCAgICB8ICAgICAgICAgICB8ICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQp8IFVuaWNhc3QvICAgIHwgICAgIDAg ICAgIHwgICAyNTAsMDAwICAgICAgfCAgICAxLDAwMCwwMDAgICAgIHwNCnwgTWNhc3QgTE1BICAg fCAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfA0KKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0r DQp8IERlZGljYXRlZCAgIHwgICAgIDAgICAgIHwgICAxLDAwMCwwMDAgICAgfCAgICAxLDAwMCww MDAgICAgIHwNCnwgTWNhc3QgTE1BICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgfA0KKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KU2V0dGluZyAyOiAgMSwwMDAsMDAwIE1OcyBh cmUgc3Vic2NyaWJlZCB0byB0aGUgc2FtZSBtdWx0aWNhc3QgZ3JvdXAgDQoNCkR1ZSB0byB0aGUg dHJhZmZpYyByZXBsaWNhdGlvbiBhdCBNQUcsIHRoZSBjb21iaW5lZCB1bmljYXN0L211bHRpY2Fz dCBMTUEgc2NoZW1lIHByb2R1Y2VzIGEgdG90YWwgb2YgODAwIHN0cmVhbXMgYmV0d2VlbiBhbGwg TE1BcyBhbmQgTUFHcy4gVGhlIGRlZGljYXRlZCBMTUEgY29uZmlndXJhdGlvbiByZXF1aXJlcyAy MDAgc3RyZWFtcywgbGVzcyB0aGFuIHRoZSBjb21iaW5lZCBzb2x1dGlvbi4gVGhpcyBzY2VuYXJp byBjbGVhcmx5IHNob3dzIHRoZSBhZHZhbnRhZ2Ugb2Ygc2F2aW5nIGJhbmR3aWR0aCB3aXRoIHRo ZSBkZWRpY2F0ZWQgbXVsdGljYXN0IExNQSB3aGVuIE1OcyB1c2luZyBkaWZmZXJlbnQgTE1BcyBq b2luIHRoZSBzYW1lIGdyb3VwLiANCiANCis9PT09PT09PT09PT09Kz09PT09PT09PT09Kz09PT09 PT09PT09PT09PT0rPT09PT09PT09PT09PT09PT09PQ0KfCAgICAgICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQp8ICAgUE1JUCAgICAgIHwg IyBvZiAgICAgIHwgIyBvZiBzaW0uICAgICAgfCMgb2Ygc2ltLiBzdHJlYW1zIHwNCnwgTXVsdGlj YXN0ICAgfCByZWR1bmRhbnQgfCBzdHJlYW1zIGF0ICAgICB8aW4gbmV0d29yayAgICAgICAgfA0K fCBzY2hlbWUgICAgICB8IHN0cmVhbXMgICB8IGVhY2ggTE1BL0xNQS1NIHxmb3IgYWxsIExNQXMg ICAgICB8DQp8ICAgICAgICAgICAgIHwgYXQgTUFHICAgIHwgTE1BL0xNQS1NICAgICAgfCAgICAg ICAgICAgICAgICAgIHwgICAgICAgDQorPT09PT09PT09PT09PSs9PT09PT09PT09PSs9PT09PT09 PT09PT09PT09Kz09PT09PT09PT09PT09PT09PXwNCnwgQ29tYmluZWQgICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfA0KfCBVbmljYXN0LyAgICB8ICAg ICA0ICAgICB8ICAgICAgNTAgICAgICAgIHwgICAgICAgODAwICAgICAgICB8DQp8IE1jYXN0IExN QSAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCist LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tKw0KfCBEZWRpY2F0ZWQgICB8ICAgICAwICAgICB8ICAgICAgMjAwICAgICAgIHwgICAgICAg MjAwICAgICAgICB8DQp8IE1jYXN0IExNQSAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQooYikgRmlndXJlIDINClRoZSBGaWd1cmUg c2VlbXMgdG8gbWl4IElHTVAgYW5kIE1MRCB0ZXJtcyAoYW5kIGlzIG5vdCBjb25zaXN0ZW50IHdp dGggdGhlIHRleHQgaW4gc2VjdGlvbiAzKS4gIFRvIGJlIGNvbnNpc3RlbnQsIHRoZSBJR01QIHRl cm0gIkpvaW4iIHNob3VsZCBiZSByZXBsYWNlZCBieSB0aGUgTUxEIHRlcm0gIlJlcG9ydCIgaW4g dGhlIEZpZ3VyZS4gIA0KDQoNCihjKSBTZWN0aW9uIDQuNSAoTXVsdGljYXN0IEF2YWlsYWJpbGl0 eSB0aHJvdWdob3V0IHRoZSBBY2Nlc3MgTmV0d29yaykgRG8geW91IHRoaW5rIGFuIGFpciBpbnRl cmZhY2UgcHJvdG9jb2wgbGlrZSAzR1BQIE1CTVMgcXVhbGlmaWVzIGFzIGEgYWNjZXNzIG5ldHdv cmsgbXVsdGljYXN0IHN1cHBvcnQ/IElmIHNvLCBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGFuZCB0 aGlzIHNlY3Rpb24gdG8gaW5jbHVkZSB0aGUgYWlyIGludGVyZmFjZSBzdXBwb3J0IG9mIG11bHRp Y2FzdC4NCg0KDQooZCkgU2VjdGlvbiA3IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykNClRoZXJl IGFyZSBzb21lIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIGR1YWwgbW9k ZSAoSVB2NC9JUHY2KSByYWlzZWQgaW4gW0ktRC5pZXRmLW5ldGxtbS1wbWlwNi1pcHY0LXN1cHBv cnRdLiAgU2hvdWxkIHRoaXMgYmUgYWNrbm93bGVkZ2VkIGluIHRoaXMgc2VjdGlvbj8NCg0KDQoo ZSkgQXBwZW5kaXggQiAoU3RhdGUgb2YgSUdNUC9NTEQgUHJveHkgSW1wbGVtZW50YXRpb25zKToN Ckl0IHdhcyBnb29kIHRoYXQgQ2lzY28gZWRnZSByb3V0ZXIgd2FzIHRlc3RlZC4gIERvIHlvdSBp bnRlbmQgdG8gdGVzdCB0aGUgSnVuaXBlciBOZXR3b3JrcyBFLXNlcmllcyBwbGF0Zm9ybSBhcyB3 ZWxsIGFzIGl0IHNlZW1zIHRvIGhhdmUgZ29vZCBtdWx0aWNhc3Qgc3VwcG9ydCAoaHR0cDovL3d3 dy5qdW5pcGVyLm5ldC9zb2x1dGlvbnMvbGl0ZXJhdHVyZS93aGl0ZV9wYXBlcnMvMjAwMTg4LnBk ZikgPw0KDQpCZXN0IHJlZ2FyZHMsDQpHdWFuZw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG11bHRpbW9iLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptdWx0aW1vYi1i b3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgVGhvbWFzIEMuIFNjaG1pZHQNCj4gU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAwOCwgMjAxMCA0OjAyIFBNDQo+IFRvOiBtdWx0aW1vYkBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBbbXVsdGltb2JdIFtGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3JkcmFmdC1zY2htaWR0LQ0KPiBtdWx0aW1vYi1wbWlwdjYtbWNhc3QtZGVwbG95bWVudC0w NF0NCj4gDQo+IEhpLA0KPiANCj4gd2UgaGF2ZSBzdWJtaXR0ZWQgYSByZXZpc2VkIHZlcnNpb24g b2YgdGhlIFBNSVB2NiBkZXBsb3ltZW50IGRyYWZ0Lg0KPiBUaGlzIHZlcnNpb24gaW5jbHVkZXMg YWxsIGNvbnRyaWJ1dGlvbnMgZnJvbSB0aGUgZXh0ZW5zaXZlIGFuZCBmcnVpdGZ1bA0KPiBkaXNj dXNzaW9ucyBzaW5jZSB0aGUgbGFzdCB1cGRhdGUgaW4gRGVjZW1iZXIuDQo+IA0KPiAgRnJvbSB0 aGUgQ2hhbmdlIExvZw0KPiANCj4gICAgIFRoZSBmb2xsb3dpbmcgY2hhbmdlcyBoYXZlIGJlZW4g bWFkZSBmcm9tDQo+ICAgICBkcmFmdC1zY2htaWR0LW11bHRpbW9iLXBtaXB2Ni1tY2FzdC1kZXBs b3ltZW50LTAzLg0KPiANCj4gICAgIDEuICBEZXRhaWxlZCBvdXRsaW5lIG9mIG11bHRpY2FzdCBy ZWNvbmZpZ3VyYXRpb24gc3RlcHMgb24NCj4gaGFuZG92ZXJzDQo+ICAgICAgICAgYWRkZWQgaW4g cHJvdG9jb2wgb3ZlcnZpZXcgKHNlY3Rpb24gMykuDQo+IA0KPiAgICAgMi4gIENsYXJpZmllZCB0 aGUgZGV0YWlscyBvZiBwcm94eSBvcGVyYXRpb25zIGF0IHRoZSBNQUcgYWxvbmcgd2l0aA0KPiAg ICAgICAgIHRoZSBleHBlY3RlZCBmZWF0dXJlcyBvZiBJR01QL01MRCBQcm94eSBpbXBsZW1lbnRh dGlvbnMNCj4gKHNlY3Rpb24NCj4gICAgICAgICA0LjIpLg0KPiANCj4gICAgIDMuICBDbGFyaWZp ZWQgcXVlcnlpbmcgaW4gZHVhbC1zdGFjayBzY2VuYXJpb3MgKHNlY3Rpb24gNC40KS4NCj4gDQo+ ICAgICA0LiAgU3Vic2VjdGlvbiBhZGRlZCBvbiB0aGUgc3BlY2lhbCBjYXNlLCB3aGVyZSBtdWx0 aWNhc3QgaXMNCj4gICAgICAgICBhdmFpbGFibGUgdGhyb3VnaG91dCB0aGUgYWNjZXNzIG5ldHdv cmsgKHNlY3Rpb24gNC41KS4NCj4gDQo+ICAgICA1LiAgQXBwZW5kaXggb24gSUdNUC9NTEQgYmVo YXZpb3VyIGFkZGVkIHdpdGggdGVzdCByZXBvcnRzIG9uDQo+IGN1cnJlbnQNCj4gICAgICAgICBQ cm94eSBpbXBsZW1lbnRhdGlvbnMuDQo+IA0KPiANCj4gV2Ugbm93IGJlbGlldmUgdGhlIGFwcHJv YWNoIGhhcyBiZWVuIHRob3JvdWdobHkgZGlzY3Vzc2VkIGFuZCB0aGUNCj4gZG9jdW1lbnQgaXMg bWF0dXJlIGVub3VnaCB0byBiZSBjb25zaWRlcmVkIGFzIGEgV0cgaXRlbS4NCj4gDQo+IEJlc3Qg d2lzaGVzLA0KPiANCj4gVGhvbWFzDQo+IA0KPiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tLS0tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQt c2NobWlkdC1tdWx0aW1vYi1wbWlwdjYtbWNhc3QtZGVwbG95bWVudC0wNA0KPiBEYXRlOiBNb24s ICA4IEZlYiAyMDEwIDEyOjUzOjExIC0wODAwIChQU1QpDQo+IEZyb206IElFVEYgSS1EIFN1Ym1p c3Npb24gVG9vbCA8aWRzdWJtaXNzaW9uQGlldGYub3JnPg0KPiBUbzogU2NobWlkdEBpbmZvcm1h dGlrLmhhdy1oYW1idXJnLmRlDQo+IENDOg0KPiBzY2htaWR0QGluZm9ybWF0aWsuaGF3LWhhbWJ1 cmcuZGUsbXdAbGluay0NCj4gbGFiLm5ldCxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tDQo+ IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+IGRyYWZ0LXNjaG1pZHQtbXVsdGltb2It cG1pcHY2LW1jYXN0LWRlcGxveW1lbnQtMDQudHh0IGhhcyBiZWVuDQo+IHN1Y2Nlc3NmdWx5IHN1 Ym1pdHRlZCBieSBUaG9tYXMgU2NobWlkdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9z aXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LXNjaG1pZHQtbXVsdGltb2ItcG1pcHY2LW1j YXN0LWRlcGxveW1lbnQNCj4gUmV2aXNpb246CSAwNA0KPiBUaXRsZToJCSBBIE1pbmltYWwgRGVw bG95bWVudCBPcHRpb24gZm9yIE11bHRpY2FzdCBMaXN0ZW5lcnMNCj4gaW4gUE1JUHY2DQo+IERv bWFpbnMNCj4gQ3JlYXRpb25fZGF0ZToJIDIwMTAtMDItMDgNCj4gV0cgSUQ6CQkgSW5kZXBlbmRl bnQgU3VibWlzc2lvbg0KPiBOdW1iZXJfb2ZfcGFnZXM6IDE5DQo+IA0KPiBBYnN0cmFjdDoNCj4g VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZGVwbG95bWVudCBvcHRpb25zIGZvciBhY3RpdmF0aW5n IG11bHRpY2FzdA0KPiBsaXN0ZW5lciBmdW5jdGlvbnMgaW4gUHJveHkgTW9iaWxlIElQdjYgZG9t YWlucyB3aXRob3V0IG1vZGlmeWluZw0KPiBtb2JpbGl0eSBhbmQgbXVsdGljYXN0IHByb3RvY29s IHN0YW5kYXJkcy4gIFNpbWlsYXIgdG8gSG9tZSBBZ2VudHMgaW4NCj4gTW9iaWxlIElQdjYsIFBN SVB2NiBMb2NhbCBNb2JpbGl0eSBBbmNob3JzIHNlcnZlIGFzIG11bHRpY2FzdA0KPiBzdWJzY3Jp cHRpb24gYW5jaG9yIHBvaW50cywgd2hpbGUgTW9iaWxlIEFjY2VzcyBHYXRld2F5cyBwcm92aWRl IE1MRA0KPiBwcm94eSBmdW5jdGlvbnMuICBJbiB0aGlzIHNjZW5hcmlvLCBNb2JpbGUgTm9kZXMg cmVtYWluIGFnbm9zdGljIG9mDQo+IG11bHRpY2FzdCBtb2JpbGl0eSBvcGVyYXRpb25zLg0KPiAN Cj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+IA0KPiANCj4gDQo+IC0tDQo+ IA0KPiBQcm9mLiBEci4gVGhvbWFzIEMuIFNjaG1pZHQNCj4gwrAgSGFtYnVyZyBVbml2ZXJzaXR5 IG9mIEFwcGxpZWQgU2NpZW5jZXMgICAgICAgICAgICAgICAgICAgQmVybGluZXIgVG9yDQo+IDcg wrANCj4gwrAgRGVwdC4gSW5mb3JtYXRpaywgSW50ZXJuZXQgVGVjaG5vbG9naWVzIEdyb3VwICAg IDIwMDk5IEhhbWJ1cmcsDQo+IEdlcm1hbnkgwrANCj4gwrAgaHR0cDovL3d3dy5oYXctaGFtYnVy Zy5kZS9pbmV0ICAgICAgICAgICAgICAgICAgIEZvbjogKzQ5LTQwLTQyODc1LQ0KPiA4NDUyIMKw DQo+IMKwIGh0dHA6Ly93d3cuaW5mb3JtYXRpay5oYXctaGFtYnVyZy5kZS9+c2NobWlkdCAgICBG YXg6ICs0OS00MC00Mjg3NS0NCj4gODQwOSDCsA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBtdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj4gbXVsdGlt b2JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0 aW1vYg0K From JuanCarlos.Zuniga@InterDigital.com Thu Feb 18 14:07: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 0D7223A7F20 for ; Thu, 18 Feb 2010 14:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 QANLBfDbZR0Q for ; Thu, 18 Feb 2010 14:07:09 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 61D8E3A8043 for ; Thu, 18 Feb 2010 14:07:09 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 17:08:52 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Feb 2010 17:08:23 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 18 Feb 2010 17:09:32 -0500 Message-ID: In-Reply-To: <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG Adoption callondraft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: AcqpBPSo7p9KZRrDQnWpKwjIVIET+wGxUgbwAEbj4GA= References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> From: "Zuniga, Juan Carlos" To: "Stig Venaas" , , X-OriginalArrivalTime: 18 Feb 2010 22:08:23.0567 (UTC) FILETIME=[E34929F0:01CAB0E6] Subject: Re: [multimob] WG Adoption callondraft-schmidt-multimob-pmipv6-mcast-deployment-04 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: Thu, 18 Feb 2010 22:07:11 -0000 Behcet, Stig, I'd like to understand if you believe the group has reached agreement = that it is worth looking at optimizations on top of the base solution. It has been discussed in the list that there are scenarios where the = solution detailed in draft-schmidt could have limitations, for instance = when different MNs using different LMAs join the same group. In such a = case we can save bandwidth by having a dedicated multicast LMA. Also, = another advantage of a dedicated LMA is to avoid the need for all LMAs = to have multicast capability and connectivity. I believe that draft-schmidt is a very good document and if it addresses = the open comments sent on the list it can become the base solution. = However, I also believe that we have enough interest in the group to = pursue further enhancements on top of this base solution. Please let me know your views. Regards, Juan Carlos > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Dirk.von-Hugo@telekom.de > Sent: Wednesday, 17 February, 2010 7:16 AM > To: sarikaya@ieee.org; multimob@ietf.org > Subject: Re: [multimob] WG Adoption callondraft-schmidt-multimob- > pmipv6-mcast-deployment-04 >=20 > Dear all, > Following the latest discussions on basic solutions for PMIP-multimob = I > am convinced that this draft will serve as a good basis for the = further > WG discussion, so I am in favour of adopting the document. >=20 > I also think the more detailed exlanations and Appendix on > implementations is quite useful. >=20 > Best regards > Dirk >=20 > PS: The only very minor nit I found was in Appendix B: 'encapsulated' > instead of 'entcapsulated' ;-) >=20 > -----Urspr=FCngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im > Auftrag von Behcet Sarikaya > Gesendet: Montag, 8. Februar 2010 22:23 > An: multimob@ietf.org > Betreff: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6- > mcast-deployment-04 >=20 > This mail starts a WG adoption call on this draft. >=20 > The intended status for this document is BCP. > If adopted, the draft will be named: >=20 > draft-ietf-multimob-pmipv6-base-solution. >=20 > Please respond if you=A0are for ADOPTING=A0or >=20 > you are NOT for ADOPTING it by February 21, 2010. >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Forwarded Message ---- > > From: Thomas C. Schmidt > > To: multimob@ietf.org > > Sent: Mon, February 8, 2010 3:02:03 PM > > Subject: [multimob] [Fwd: New Version Notification for = draft-schmidt- > multimob-pmipv6-mcast-deployment-04] > > > > Hi, > > > > we have submitted a revised version of the PMIPv6 deployment draft. > > This version includes all contributions from the extensive and > fruitful > > discussions since the last update in December. > > > > From the Change Log > > > > =A0 The following changes have been made from > > =A0 draft-schmidt-multimob-pmipv6-mcast-deployment-03. > > > > =A0 1.=A0 Detailed outline of multicast reconfiguration steps on > handovers > > =A0 =A0 =A0 added in protocol overview (section 3). > > > > =A0 2.=A0 Clarified the details of proxy operations at the MAG along = with > > =A0 =A0 =A0 the expected features of IGMP/MLD Proxy implementations > (section > > =A0 =A0 =A0 4.2). > > > > =A0 3.=A0 Clarified querying in dual-stack scenarios (section 4.4). > > > > =A0 4.=A0 Subsection added on the special case, where multicast is > > =A0 =A0 =A0 available throughout the access network (section 4.5). > > > > =A0 5.=A0 Appendix on IGMP/MLD behaviour added with test reports on > current > > =A0 =A0 =A0 Proxy implementations. > > > > > > We now believe the approach has been thoroughly discussed and the > document is > > mature enough to be considered as a WG item. > > > > Best wishes, > > > > Thomas > > > > -------- Original Message -------- > > Subject: New Version Notification for > > draft-schmidt-multimob-pmipv6-mcast-deployment-04 > > Date: Mon,=A0 8 Feb 2010 12:53:11 -0800 (PST) > > From: IETF I-D Submission Tool > > To: Schmidt@informatik.haw-hamburg.de > > CC: > > schmidt@informatik.haw-hamburg.de,mw@link- > lab.net,suresh.krishnan@ericsson.com > > > > > > A new version of I-D, = draft-schmidt-multimob-pmipv6-mcast-deployment- > 04.txt has > > been successfuly submitted by Thomas Schmidt and posted to the IETF > repository. > > > > Filename:=A0=A0=A0 draft-schmidt-multimob-pmipv6-mcast-deployment > > Revision:=A0=A0=A0 04 > > Title:=A0=A0=A0 =A0=A0=A0 A Minimal Deployment Option for Multicast = Listeners in > PMIPv6 > > Domains > > Creation_date:=A0=A0=A0 2010-02-08 > > WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission > > Number_of_pages: 19 > > > > Abstract: > > This document describes deployment options for activating multicast > > listener functions in Proxy Mobile IPv6 domains without modifying > > mobility and multicast protocol standards.=A0 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.=A0 In this scenario, Mobile Nodes remain agnostic = of > > multicast mobility operations. > > > > > > > > > > The IETF Secretariat. > > > > > > > > -- > > Prof. Dr. Thomas C. Schmidt > > =B0 Hamburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Berliner > Tor 7 =B0 > > =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 = Hamburg, > Germany =B0 > > =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Fon: +49-40-42875- > 8452 =B0 > > =B0 http://www.informatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: = +49-40-42875- > 8409 =B0 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 >=20 >=20 >=20 > _______________________________________________ > 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 From behcetsarikaya@yahoo.com Thu Feb 18 16:43:59 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 B8A6128C172 for ; Thu, 18 Feb 2010 16:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 KVu1R1+zrAIF for ; Thu, 18 Feb 2010 16:43:59 -0800 (PST) Received: from web111405.mail.gq1.yahoo.com (web111405.mail.gq1.yahoo.com [67.195.15.156]) by core3.amsl.com (Postfix) with SMTP id 072F428C0FE for ; Thu, 18 Feb 2010 16:43:58 -0800 (PST) Received: (qmail 17208 invoked by uid 60001); 19 Feb 2010 00:45:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1266540340; bh=L2Q6LXyHZnZIBpFEHIH+dfN0m/FDHA4wPh+7PzXcMhQ=; 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=T7AGHqMLUIqa8i73DN/aiGmYptAllVIY5nJxdebuiSDcOHg+fO7ADN3OtrrDWnnQbgSoC1Nwj31HSF+4ROMPrmkHzNEfbqu9IiZsDuyCGD0n5F8J51YdaNELi5vZtAbZZUMrnVYKx0TFwf7z/CxrzCHZ55XLllS5fDx2k+DHf3s= 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=j7L7BlyOs4Uwh0Z2YjhY1AWShySIYojLNeWlYtRDWSX064yj+ImCIIP5Uf3CdBcvTLYBw7NdT6iPqlrd9L5H/Ev2GsGtVROXNMvpcZRTHhiJDHL8HUFxMzuiB09pVsFxtAIQGskDpMReyvLbzqLx6Of3+BBYc9mCKyb33MEzyCM=; Message-ID: <822998.17108.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: eic7KP8VM1kpS7cuQth0kohJd22LWhmPBIXJCNLRODHg0Tcb1FTZWbNkc7s6Tz9kKhpJYLZs9U5UM_rFhMUDOaRWlGhgD2u2amHd03K3vTtC4ps30FTKkgq1IayKnL9XTBpYgK1J2skbZptCQYmmQwwc7G_mKFMm1j4sXXD0_Z.5mdB3csF3vGH6qrpHMkuG9AaEyimMgNExoPSBFR3jgDok7eTGjnM713SwDIiTG69pnovk4HYtVPGnX6bMuVisbCuzmgA6uWWrar_pIC59UYqBeW_MC2CDljuCnWKWqxg.OCySoifMeQeTd3lm34guBlVeT9VyGsj8OLuoen8OPXEUCbhnbFtwiYVyQjnh Received: from [66.114.246.14] by web111405.mail.gq1.yahoo.com via HTTP; Thu, 18 Feb 2010 16:45:40 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> Date: Thu, 18 Feb 2010 16:45:40 -0800 (PST) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" , multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 19 Feb 2010 00:43:59 -0000 Hi Carlos,=0A=A0 This current adoption call is aimed at establishing if the= re is consensus that this draft is the base solution. You are saying it is.= =0A=0A=A0 Let's discuss other issues next week.=0A=0A=0ARegards=0A=0A=0A--= --- Original Message ----=0A> From: "Zuniga, Juan Carlos" =0A> To: Stig Venaas ; sarikaya@ieee.or= g; multimob@ietf.org=0A> Sent: Thu, February 18, 2010 4:09:32 PM=0A> Subjec= t: RE: [multimob] WG Adoption callondraft-schmidt-multimob-pmipv6-mcast-dep= loyment-04=0A> =0A> Behcet, Stig,=0A=0AI'd like to understand if you believ= e the group has reached =0A> agreement that it is worth looking at optimiza= tions on top of the base =0A> solution.=0A=0AIt has been discussed in the l= ist that there are scenarios =0A> where the solution detailed in draft-schm= idt could have limitations, for =0A> instance when different MNs using diff= erent LMAs join the same group. In such a =0A> case we can save bandwidth b= y having a dedicated multicast LMA. Also, another =0A> advantage of a dedic= ated LMA is to avoid the need for all LMAs to have multicast =0A> capabilit= y and connectivity.=0A=0AI believe that draft-schmidt is a very good =0A> d= ocument and if it addresses the open comments sent on the list it can becom= e =0A> the base solution. However, I also believe that we have enough inter= est in the =0A> group to pursue further enhancements on top of this base so= lution.=0A=0APlease =0A> let me know your views.=0A=0ARegards,=0A=0AJuan Ca= rlos=0A=0A=0A From luisc@it.uc3m.es Fri Feb 19 00:56: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 0D0653A7F1E for ; Fri, 19 Feb 2010 00:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 xX3ijOfDmICM for ; Fri, 19 Feb 2010 00:56:23 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6BE5C3A7BD4 for ; Fri, 19 Feb 2010 00:56:22 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 6C032BAAEF9; Fri, 19 Feb 2010 09:58:06 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Fri, 19 Feb 2010 09:58:05 +0100 Message-ID: <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> Date: Fri, 19 Feb 2010 09:58:05 +0100 From: "Luis M. Contreras" To: Behcet Sarikaya , Behcet Sarikaya References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> In-Reply-To: <647440.46250.qm@web111410.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: multimob@ietf.org Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 19 Feb 2010 08:56:25 -0000 Hi all, I vote for ADOPTING this draft as the base document for a basic solution. However I have some further comments on it because I think some points need some clarification. I will send them to the list after adoption process deadline. Regards, Luis Behcet Sarikaya dijo: > This mail starts a WG adoption call on this draft. > > The intended status for this document is BCP. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-base-solution. > > Please respond if you=A0are for ADOPTING=A0or > > you are NOT for ADOPTING it by February 21, 2010. > > Regards, > > Behcet > > > > ----- Forwarded Message ---- >> From: Thomas C. Schmidt >> To: multimob@ietf.org >> Sent: Mon, February 8, 2010 3:02:03 PM >> Subject: [multimob] [Fwd: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04] >> >> Hi, >> >> we have submitted a revised version of the PMIPv6 deployment draft. >> This version includes all contributions from the extensive and fruitful >> discussions since the last update in December. >> >> From the Change Log >> >> =A0 The following changes have been made from >> =A0 draft-schmidt-multimob-pmipv6-mcast-deployment-03. >> >> =A0 1.=A0 Detailed outline of multicast reconfiguration steps on handove= rs >> =A0 =A0 =A0 added in protocol overview (section 3). >> >> =A0 2.=A0 Clarified the details of proxy operations at the MAG along wit= h >> =A0 =A0 =A0 the expected features of IGMP/MLD Proxy implementations (sec= tion >> =A0 =A0 =A0 4.2). >> >> =A0 3.=A0 Clarified querying in dual-stack scenarios (section 4.4). >> >> =A0 4.=A0 Subsection added on the special case, where multicast is >> =A0 =A0 =A0 available throughout the access network (section 4.5). >> >> =A0 5.=A0 Appendix on IGMP/MLD behaviour added with test reports on curr= ent >> =A0 =A0 =A0 Proxy implementations. >> >> >> We now believe the approach has been thoroughly discussed and the >> document is >> mature enough to be considered as a WG item. >> >> Best wishes, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04 >> Date: Mon,=A0 8 Feb 2010 12:53:11 -0800 (PST) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC: >> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericss= on.com >> >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has >> been successfuly submitted by Thomas Schmidt and posted to the IETF >> repository. >> >> Filename:=A0=A0=A0 draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision:=A0=A0=A0 04 >> Title:=A0=A0=A0 =A0=A0=A0 A Minimal Deployment Option for Multicast List= eners in PMIPv6 >> Domains >> Creation_date:=A0=A0=A0 2010-02-08 >> WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission >> Number_of_pages: 19 >> >> Abstract: >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards.=A0 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.=A0 In this scenario, Mobile Nodes remain agnostic of >> multicast mobility operations. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Berliner Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group=A0 =A0 20099 Hamburg, = Germany =B0 >> =B0 http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fo= n: +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt=A0 =A0 Fax: +49-40-428= 75-8409 =B0 >> _______________________________________________ >> 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Luis M. Contreras Profesor Asociado Dpto. de Ingenier=EDa Telem=E1tica Universidad Carlos III de Madrid ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From behcetsarikaya@yahoo.com Fri Feb 19 14:06: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 C95123A7B78 for ; Fri, 19 Feb 2010 14:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 HP-bgvWO9drS for ; Fri, 19 Feb 2010 14:06:44 -0800 (PST) Received: from web111410.mail.gq1.yahoo.com (web111410.mail.gq1.yahoo.com [67.195.15.186]) by core3.amsl.com (Postfix) with SMTP id 229AA3A7B77 for ; Fri, 19 Feb 2010 14:06:44 -0800 (PST) Received: (qmail 94080 invoked by uid 60001); 19 Feb 2010 22:08:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1266617309; bh=dsAyi/BQMeidm4VXidfml5uNhti3fU6kr8HYvKx6Dgk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q7pSl5deqzJbAJEZF/qOGiPHrAlDVZW09R0yhwP4fMOiZraslhlZLdLEGgL2n9iojBSeyUIbMUHSARz7LEn8KSE+iP8eg1i1dgpbEOMe2rO/Fh5uY2pA1Dg0XrtkWVbf7J/ovqhnRRMeYsXlNQu6MXqNLL7GpeNmi89EW+Wr8ck= 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=qmaayJf1ItDYrdIS+Sti/SxUo8NthdLmNgLuauj4DH2DhC3QTAdFV9EZAP1cO5i0bSXkGUJK2jkZA2XEDfc6oW26D8uTzaxAAg59gcorPyvXJDJCAUvtCWe3VLnlbomMXU1ZU98QVj0ndcf1hQ2sABCiv6pqSUvQvoHgS5fZsEk=; Message-ID: <361364.94061.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: P0MBwNoVM1k3DZzy8scJrHVBhgH8A.iRrbi1e0ovl5Oat7BsPdyC6tejUIfxe8VAMPV2uG6Mcg2DbPmyLyEmYHOcJICTBJ5eO6jwTTvyrUIoNIngRQuDxoVEbHb4KX4O5ixSruyctZHGpZlKhnXnZmSmzPdFYKlDFeuCI.qgIuUemx4y_0s5NNvOwRxkEEGx78sLRKCifr4PngcCSG5jaOlV45CsnLPjBRMBDz0t1HN9Uw6bvLw5MCH_maxRruHWrB9FWTJIQiv.ab4KPsw7dLUzsYcYw2GbziyS9R_jG3wRhjDsaItIpLM5bzMbfQzR.RlmOkcKuoVR7RoA5gnuSw-- Received: from [66.114.246.14] by web111410.mail.gq1.yahoo.com via HTTP; Fri, 19 Feb 2010 14:08:29 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 Date: Fri, 19 Feb 2010 14:08:29 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Session at IETF 77 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, 19 Feb 2010 22:06:44 -0000 Hello all,=0A=A0 We are scheduled to meet on Thursday, March 25 at the next= IETF meeting for a two and a half hour session.=0A=A0 Please send your ses= sion requests to the chairs.=0A=0ARegards,=0A=0AChairs=0A=0A=0A From sijeon79@gmail.com Sun Feb 21 22:08:42 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 A852128C205 for ; Sun, 21 Feb 2010 22:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 TKQNyOaiY5UE for ; Sun, 21 Feb 2010 22:08:40 -0800 (PST) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by core3.amsl.com (Postfix) with ESMTP id 4C32028C0E7 for ; Sun, 21 Feb 2010 22:08:40 -0800 (PST) Received: by qyk10 with SMTP id 10so1029616qyk.19 for ; Sun, 21 Feb 2010 22:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc:subject :date:organization:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:x-mimeole:thread-index; bh=ulC3e839gDVzZF9X+wdAfFBpxFDi8JJ88EV9hU5pVHQ=; b=E2Rt1mIjqxSgp/WAGWRUQSwP357028u3xFjXFWHjMKIpZzoOQZDemDxDSgEhF4kF9V ZLpGxgJsPAsxV0DMrmjdk9jfRwyIiia9CQ6VzvkyzNlsdUQykKq3GkqGKQqZgv3noLGb zM2HJY9Qw/ApBkuk+FPCtMIXtx1g+YkY74CGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :x-mimeole:thread-index; b=hK7s3Z9yF6TerqHnjloZlj9gYAmBKBaa98nB2SC7Lwh3Tr0T0azkOJ8uAq2KhpD8WK y5r2AeIwcN1Zp6ad1R2iIvRgLsZUH6n7iyMAMjSQ/Xzd8f5/fF20QyWQG/UlbABlgdoY vPXVR3ADpSQrQmD3WhcFHlH7r0ZiOtr2kEAcE= Received: by 10.224.43.225 with SMTP id x33mr5644727qae.57.1266819029032; Sun, 21 Feb 2010 22:10:29 -0800 (PST) Received: from dcn2c060bed2b9 ([203.253.14.241]) by mx.google.com with ESMTPS id 8sm8523377qwj.41.2010.02.21.22.10.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Feb 2010 22:10:26 -0800 (PST) From: "Seil Jeon" To: "'Thomas C. Schmidt'" Date: Mon, 22 Feb 2010 15:10:24 +0900 Organization: dcn Message-ID: <600E9E8E8C4B423A855A5BB3DCD3D4BA@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 thread-index: AcqpBPgMLo1E3+XGSfGZVooOJJEzCAA94MZAAmGt9PA= Cc: multimob@ietf.org Subject: [multimob] FW: WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 06:08:43 -0000 As I revealed my opinion, I am for ADOPTING this draft. But I have some questions for this draft. 1. aggregated join could reduce redundant MLD signal but earlier arrived = node should wait for aggregating periodic time. So, it can lead to handover latency. MLD signaling would be trivial = compared to redundant multicast traffic. 2. "On the occurrence of a mobility handover, the LMA will receive Binding Lifetime De-Registrations and Binding Lifetime Extensions that will cause a re-mapping of home network prefixes to Proxy-CoAs in its Binding Cache. Correspondingly, the multicast forwarding states require updating, as well. In the absence of explicit tracking, the LMA MUST proceed as follows" But, how LMA can know these event of MNs? LMA uses link-local address = and performs MN-specific management? IMHO, if it is true, multicast router (LMA) performs not group member = management but group management. how can it be? And link-local address can be identified for MN in LMA? because a LMA = has a lot of MAGs that consists of each link-local. Best your regards, Seil Jeon -----Original Message----- From: Seil Jeon [mailto:sijeon79@gmail.com]=20 Sent: Wednesday, February 10, 2010 11:59 AM To: 'Behcet Sarikaya' Cc: 'multimob@ietf.org' Subject: RE: [multimob] WG Adoption call = ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 Dear all, I think that this draft is in accordance with this charter among = tunneling mode approach. I am for ADOPTING this draft. Best Regards, Seil Jeon =20 -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Tuesday, February 09, 2010 6:23 AM To: multimob@ietf.org Subject: [multimob] WG Adoption call = ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 This mail starts a WG adoption call on this draft. The intended status for this document is BCP. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-base-solution. Please respond if you are for ADOPTING or you are NOT for ADOPTING it by February 21, 2010. Regards, Behcet ----- Forwarded Message ---- > From: Thomas C. Schmidt > To: multimob@ietf.org > Sent: Mon, February 8, 2010 3:02:03 PM > Subject: [multimob] [Fwd: New Version Notification for=20 > draft-schmidt-multimob-pmipv6-mcast-deployment-04] >=20 > Hi, >=20 > we have submitted a revised version of the PMIPv6 deployment draft. > This version includes all contributions from the extensive and=20 > fruitful discussions since the last update in December. >=20 > From the Change Log >=20 > The following changes have been made from > draft-schmidt-multimob-pmipv6-mcast-deployment-03. >=20 > 1. Detailed outline of multicast reconfiguration steps on handovers > added in protocol overview (section 3). >=20 > 2. Clarified the details of proxy operations at the MAG along with > the expected features of IGMP/MLD Proxy implementations (section > 4.2). >=20 > 3. Clarified querying in dual-stack scenarios (section 4.4). >=20 > 4. Subsection added on the special case, where multicast is > available throughout the access network (section 4.5). >=20 > 5. Appendix on IGMP/MLD behaviour added with test reports on=20 > current > Proxy implementations. >=20 >=20 > We now believe the approach has been thoroughly discussed and the=20 > document is mature enough to be considered as a WG item. >=20 > Best wishes, >=20 > Thomas >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-schmidt-multimob-pmipv6-mcast-deployment-04 > Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC:=20 > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eric > sson.com >=20 >=20 > A new version of I-D, > draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been = successfuly submitted by Thomas Schmidt and posted to the IETF = repository. >=20 > Filename: draft-schmidt-multimob-pmipv6-mcast-deployment > Revision: 04 > Title: A Minimal Deployment Option for Multicast Listeners in > PMIPv6 Domains > Creation_date: 2010-02-08 > WG ID: Independent Submission > Number_of_pages: 19 >=20 > Abstract: > This document describes deployment options for activating multicast=20 > listener functions in Proxy Mobile IPv6 domains without modifying=20 > mobility and multicast protocol standards. Similar to Home Agents in=20 > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast=20 > subscription anchor points, while Mobile Access Gateways provide MLD=20 > proxy functions. In this scenario, Mobile Nodes remain agnostic of=20 > multicast mobility operations. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > -- > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences = Berliner Tor > 7 =C2=B0 =C2=B0 Dept. Informatik, Internet Technologies Group 20099 = Hamburg,=20 > Germany =C2=B0 =C2=B0 http://www.haw-hamburg.de/inet = Fon: > +49-40-42875-8452 =C2=B0 =C2=B0 = http://www.informatik.haw-hamburg.de/~schmidt > Fax: +49-40-42875-8409 =C2=B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Mon Feb 22 02:46:53 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 EF9993A7C40 for ; Mon, 22 Feb 2010 02:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.33 X-Spam-Level: X-Spam-Status: No, score=0.33 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 KNM3bskwSjuJ for ; Mon, 22 Feb 2010 02:46:52 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 78E553A7CD2 for ; Mon, 22 Feb 2010 02:46:52 -0800 (PST) Envelope-to: multimob@ietf.org Received: from gateway05.m3-connect.de ([88.79.237.15] helo=[10.25.103.154]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NjVqK-000D3l-GE; Mon, 22 Feb 2010 11:48:48 +0100 Message-ID: <4B826108.3010001@informatik.haw-hamburg.de> Date: Mon, 22 Feb 2010 11:48:40 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sijeon79@gmail.com References: <600E9E8E8C4B423A855A5BB3DCD3D4BA@dcn2c060bed2b9> In-Reply-To: <600E9E8E8C4B423A855A5BB3DCD3D4BA@dcn2c060bed2b9> Content-Type: text/plain; charset=UTF-8; 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] FW: WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 10:46:54 -0000 Dear Seil, thanks for your comments. Please see inline: Seil Jeon wrote: > As I revealed my opinion, I am for ADOPTING this draft. > > But I have some questions for this draft. > > > 1. aggregated join could reduce redundant MLD signal but earlier arrived node should wait for aggregating periodic time. > > So, it can lead to handover latency. MLD signaling would be trivial compared to redundant multicast traffic. > The aggregation on an MLD proxy is equivalent to the local maintenance of its membership database. This comes basically at no delay. The delays on handover experienced by the first node that arrives for a given group (first subscriber) are composed of 1. Unicast handover management, unicast address(prefix) configuration ... 2. MLD query by MAG (MLD proxy) 3. MLD report from MAG to LMA (LMA already is subscribed to the multicast group) 4. Traffic forwarding from LMA to MN. Steps 1 and 2 can partly be operated in parallel. > > 2. "On the occurrence of a mobility handover, the LMA will receive > Binding Lifetime De-Registrations and Binding Lifetime Extensions > that will cause a re-mapping of home network prefixes to Proxy-CoAs > in its Binding Cache. Correspondingly, the multicast forwarding > states require updating, as well. In the absence of explicit > tracking, the LMA MUST proceed as follows" > > But, how LMA can know these event of MNs? LMA uses link-local address and performs MN-specific management? > The steps you point at here are part of the unicast handover - this section of the draft just tries to generate coherence with RFC 5213. > IMHO, if it is true, multicast router (LMA) performs not group member management but group management. > > how can it be? > > And link-local address can be identified for MN in LMA? because a LMA has a lot of MAGs that consists of each link-local. Group members as seen by the LMA are MAGs (the proxies that aggregate MNs). Is it that what you are pointing at? Best regard Thomas > > -----Original Message----- > From: Seil Jeon [mailto:sijeon79@gmail.com] > Sent: Wednesday, February 10, 2010 11:59 AM > To: 'Behcet Sarikaya' > Cc: 'multimob@ietf.org' > Subject: RE: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 > > > Dear all, > > I think that this draft is in accordance with this charter among tunneling mode approach. > > I am for ADOPTING this draft. > > > Best Regards, > > Seil Jeon > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Tuesday, February 09, 2010 6:23 AM > To: multimob@ietf.org > Subject: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 > > This mail starts a WG adoption call on this draft. > > The intended status for this document is BCP. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-base-solution. > > Please respond if you are for ADOPTING or > > you are NOT for ADOPTING it by February 21, 2010. > > Regards, > > Behcet > > > > ----- Forwarded Message ---- >> From: Thomas C. Schmidt >> To: multimob@ietf.org >> Sent: Mon, February 8, 2010 3:02:03 PM >> Subject: [multimob] [Fwd: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04] >> >> Hi, >> >> we have submitted a revised version of the PMIPv6 deployment draft. >> This version includes all contributions from the extensive and >> fruitful discussions since the last update in December. >> >> From the Change Log >> >> The following changes have been made from >> draft-schmidt-multimob-pmipv6-mcast-deployment-03. >> >> 1. Detailed outline of multicast reconfiguration steps on handovers >> added in protocol overview (section 3). >> >> 2. Clarified the details of proxy operations at the MAG along with >> the expected features of IGMP/MLD Proxy implementations (section >> 4.2). >> >> 3. Clarified querying in dual-stack scenarios (section 4.4). >> >> 4. Subsection added on the special case, where multicast is >> available throughout the access network (section 4.5). >> >> 5. Appendix on IGMP/MLD behaviour added with test reports on >> current >> Proxy implementations. >> >> >> We now believe the approach has been thoroughly discussed and the >> document is mature enough to be considered as a WG item. >> >> Best wishes, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04 >> Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC: >> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eric >> sson.com >> >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. >> >> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision: 04 >> Title: A Minimal Deployment Option for Multicast Listeners in >> PMIPv6 Domains >> Creation_date: 2010-02-08 >> WG ID: Independent Submission >> Number_of_pages: 19 >> >> Abstract: >> 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. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> 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 ° >> _______________________________________________ >> 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 sijeon79@gmail.com Mon Feb 22 05:12:56 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 576903A7B3D for ; Mon, 22 Feb 2010 05:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 QP-0umQZ+Ghi for ; Mon, 22 Feb 2010 05:12:48 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 0BFBC28C2DD for ; Mon, 22 Feb 2010 05:12:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so585106qwb.31 for ; Mon, 22 Feb 2010 05:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :x-mimeole:thread-index; bh=K1YNN0ufsiVfdOtLiVFCBs8wjLoX2xkBhL0vQheavxA=; b=u8ceaJqAn52DU2+0Hn15KMyL/kKzH/AiMYe4bmYt5WMepSUa2IxVwvuYnoLeMtV9hA j94xd0Z56CSYb5yW9YJZiY1YOW6DQa6XB/r0fc981l7wiS3IRn98KHe0qkyaoacJxJnY FL1X1HHgiIlKcVZeOCfmaSN1X/WO/zq62ZU9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :in-reply-to:x-mimeole:thread-index; b=q19o8EMP9TBWoFAJ/fBD3krZJrELWps22OhN+2quyNLBqupH0k+lWfikAd93qQPAng KKBfokLU+SDl336YBmh47rbXnqr9YHXyDVnufQ9H20QYXPvCBKfeQ7mqBOGPsACs7lJ3 IcP8mdrdHQ7rogTVZQ4wmU5/g4SV9PVNsrKOQ= Received: by 10.224.72.1 with SMTP id k1mr5959791qaj.282.1266844482330; Mon, 22 Feb 2010 05:14:42 -0800 (PST) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id 4sm9589359qwe.3.2010.02.22.05.14.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 05:14:33 -0800 (PST) From: "Seil Jeon" To: "'Thomas C. Schmidt'" References: <600E9E8E8C4B423A855A5BB3DCD3D4BA@dcn2c060bed2b9> <4B826108.3010001@informatik.haw-hamburg.de> Date: Mon, 22 Feb 2010 22:14:31 +0900 Organization: dcn Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B826108.3010001@informatik.haw-hamburg.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 thread-index: AcqzrJ3/+onUp4RmQL2rOeuldaNpcwADCsBw Cc: multimob@ietf.org Subject: Re: [multimob] FW: WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:12:56 -0000 =20 Dear Thomas, My response is as follows. Please see this mark "=3D>" -----Original Message----- From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20 Sent: Monday, February 22, 2010 7:49 PM To: sijeon79@gmail.com Cc: multimob@ietf.org Subject: Re: FW: [multimob] WG Adoption call ondraft-schmidt-multimob- pmipv6-mcast-deployment-04 Dear Seil, thanks for your comments. Please see inline: Seil Jeon wrote: > As I revealed my opinion, I am for ADOPTING this draft. >=20 > But I have some questions for this draft. >=20 >=20 > 1. aggregated join could reduce redundant MLD signal but earlier = arrived node should wait for aggregating periodic time. >=20 > So, it can lead to handover latency. MLD signaling would be trivial compared to redundant multicast traffic. >=20 The aggregation on an MLD proxy is equivalent to the local maintenance = of its membership database. This comes basically at no delay. The delays on handover experienced by the first node that arrives for a given group (first subscriber) are composed of 1. Unicast handover management, unicast address(prefix) configuration = ... 2. MLD query by MAG (MLD proxy) 3. MLD report from MAG to LMA (LMA already is subscribed to the = multicast group) 4. Traffic forwarding from LMA to MN. Steps 1 and 2 can partly be operated in parallel. =3D> Thank you for detailed description but I didn't point out it. In your handover scenario in Figure 2, there are two MNs (MN1, MN2). When there is no "G" channel multicast stream from LMA, the MN1 arrived earlier than MN2 in MAG1,=20 but the MN1 sended "join (G)" message to the MAG1 but MAG1 directly do = not send the "join (G)" message=20 to the LMA because the MAG performs "aggregated Join" report process In that case, I mentioned that handover latency may happen. >=20 > 2. "On the occurrence of a mobility handover, the LMA will receive > Binding Lifetime De-Registrations and Binding Lifetime Extensions > that will cause a re-mapping of home network prefixes to Proxy-CoAs > in its Binding Cache. Correspondingly, the multicast forwarding > states require updating, as well. In the absence of explicit > tracking, the LMA MUST proceed as follows" >=20 > But, how LMA can know these event of MNs? LMA uses link-local address = and performs MN-specific management? >=20 The steps you point at here are part of the unicast handover - this = section of the draft just tries to generate coherence with RFC 5213. =3D> Yes, of course. I did not intend the question. My question is, when a LMA receives the de-registration message from MAG for specific MN, how can LMA know whether this MN is last node belong to specific = multicast group or not? Now I can understand through next paragraph. > IMHO, if it is true, multicast router (LMA) performs not group member management but group management. >=20 > how can it be? >=20 > And link-local address can be identified for MN in LMA? because a LMA = has a lot of MAGs that consists of each link-local. Group members as seen by the LMA are MAGs (the proxies that aggregate = MNs). Is it that what you are pointing at? =3D> My question is whether link-local address is used for maintaining multicast group? Because a link-local address is not unique identifier. Best regard Seil Jeon >=20 > -----Original Message----- > From: Seil Jeon [mailto:sijeon79@gmail.com] > Sent: Wednesday, February 10, 2010 11:59 AM > To: 'Behcet Sarikaya' > Cc: 'multimob@ietf.org' > Subject: RE: [multimob] WG Adoption call=20 > ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 >=20 >=20 > Dear all, >=20 > I think that this draft is in accordance with this charter among tunneling mode approach. >=20 > I am for ADOPTING this draft. >=20 >=20 > Best Regards, >=20 > Seil Jeon > =20 >=20 > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On=20 > Behalf Of Behcet Sarikaya > Sent: Tuesday, February 09, 2010 6:23 AM > To: multimob@ietf.org > Subject: [multimob] WG Adoption call=20 > ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 >=20 > This mail starts a WG adoption call on this draft. >=20 > The intended status for this document is BCP. > If adopted, the draft will be named: >=20 > draft-ietf-multimob-pmipv6-base-solution. >=20 > Please respond if you are for ADOPTING or >=20 > you are NOT for ADOPTING it by February 21, 2010. >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > ----- Forwarded Message ---- >> From: Thomas C. Schmidt >> To: multimob@ietf.org >> Sent: Mon, February 8, 2010 3:02:03 PM >> Subject: [multimob] [Fwd: New Version Notification for=20 >> draft-schmidt-multimob-pmipv6-mcast-deployment-04] >> >> Hi, >> >> we have submitted a revised version of the PMIPv6 deployment draft. >> This version includes all contributions from the extensive and=20 >> fruitful discussions since the last update in December. >> >> From the Change Log >> >> The following changes have been made from >> draft-schmidt-multimob-pmipv6-mcast-deployment-03. >> >> 1. Detailed outline of multicast reconfiguration steps on = handovers >> added in protocol overview (section 3). >> >> 2. Clarified the details of proxy operations at the MAG along with >> the expected features of IGMP/MLD Proxy implementations = (section >> 4.2). >> >> 3. Clarified querying in dual-stack scenarios (section 4.4). >> >> 4. Subsection added on the special case, where multicast is >> available throughout the access network (section 4.5). >> >> 5. Appendix on IGMP/MLD behaviour added with test reports on=20 >> current >> Proxy implementations. >> >> >> We now believe the approach has been thoroughly discussed and the=20 >> document is mature enough to be considered as a WG item. >> >> Best wishes, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04 >> Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC:=20 >> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eri >> c >> sson.com >> >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF = repository. >> >> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision: 04 >> Title: A Minimal Deployment Option for Multicast Listeners in >> PMIPv6 Domains >> Creation_date: 2010-02-08 >> WG ID: Independent Submission >> Number_of_pages: 19 >> >> Abstract: >> This document describes deployment options for activating multicast=20 >> listener functions in Proxy Mobile IPv6 domains without modifying=20 >> mobility and multicast protocol standards. Similar to Home Agents in = >> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast=20 >> subscription anchor points, while Mobile Access Gateways provide MLD=20 >> proxy functions. In this scenario, Mobile Nodes remain agnostic of=20 >> multicast mobility operations. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> Prof. Dr. Thomas C. Schmidt >> =A1=C6 Hamburg University of Applied Sciences = Berliner Tor >> 7 =A1=C6 =A1=C6 Dept. Informatik, Internet Technologies Group = 20099 Hamburg,=20 >> Germany =A1=C6 =A1=C6 http://www.haw-hamburg.de/inet = Fon: >> +49-40-42875-8452 =A1=C6 =A1=C6 = http://www.informatik.haw-hamburg.de/~schmidt >> Fax: +49-40-42875-8409 =A1=C6 >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >=20 >=20 >=20 > =20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob >=20 --=20 Prof. Dr. Thomas C. Schmidt =A1=C6 Hamburg University of Applied Sciences Berliner = Tor 7 =A1=C6 =A1=C6 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =A1=C6 =A1=C6 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =A1=C6 =A1=C6 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =A1=C6 From behcetsarikaya@yahoo.com Mon Feb 22 07:21:56 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 B777A3A83EB for ; Mon, 22 Feb 2010 07:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 ZYIz7h9iBVCf for ; Mon, 22 Feb 2010 07:21:55 -0800 (PST) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id A469528C1D8 for ; Mon, 22 Feb 2010 07:21:55 -0800 (PST) Received: (qmail 13432 invoked by uid 60001); 22 Feb 2010 15:23:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1266852231; bh=hIUiqOL6dWu6pgdM19E7c+gh9Bhaa9oLiNhbG+cuMnU=; 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=btvLCChHKBMpOEmbGcApEjkejtbCNaBJGAGsq/lIBNQVJ9TLsFJjDxkVXW7qKRpUTX1e3ivtvn7KSg9HZ4Zhan1yaMYPZiJaOxM4HwwSJ5SjMqc+/Uh5PWcxZ9KuRmRdhwe7NhlFbeFWqjbNcWBddbxC+Jpco6bwXZT2YEpoyhE= 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=ieB92XAM9aYUd4EHxRHwZTzQl+IQReI387hg5xq6PZuS1pOIjoJ/MIsyHs81DTijxq5OI+u3/93hosgHxonJK/dtOlwKYE5/Unvv1ikHPBkE87B7gbyJActKjnl86k7V/FkKyQ+9aJ1BHJe6FHDdVDLAwzHaEjE1LqTpZjDxHA8=; Message-ID: <781334.12290.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: 1AOVdVsVM1lsVCzjU5uqUHyltMjptpxa9Uj_FdhlyZ..lnVbJjmHWNrQvYNIx375WV0.DHVKieRtsWjVuz3hEHtuewqT1ls6zyMRWOUHduJldR3ktPcBbbUzSuJVX_mEv2OmJYLRoqF3uiZrjMKOP46An4eXk4h8fsFiY8Quh2f733yRCDLtSvlS4Z6nzqPKqjzmuOGBAuoft_jaGMMqdWHZTGE3Xckb0IcDsle95SgXHgnT_lZTFjjclpmINvnSvDOuQxmAsBwZQtQ53DEbcTsno0N_EPR1PGn6s9rw8evpZv7FOeBgYDaqId8GrcOQ7Fz6GrZWsHSsW9l66Er_O8iKRDt31jH4EwlYixbwEzLYHfgLpHqBat8sUXg- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Mon, 22 Feb 2010 07:23:51 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> Date: Mon, 22 Feb 2010 07:23:51 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: <647440.46250.qm@web111410.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 15:21:56 -0000 Hi all,=0A=A0 The call has ended and consensus has been established.=0A=0AA= uthors, please submit your draft as draft-ietf-multimob-pmipv6-base-solutio= n-00.txt.=0A=0ARegards,=0A=0AChairs=0A=0A=0A=0A----- Original Message ----= =0A> From: Behcet Sarikaya =0A> To: multimob@ietf= .org=0A> Sent: Mon, February 8, 2010 3:23:20 PM=0A> Subject: [multimob] WG = Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04=0A> =0A>= This mail starts a WG adoption call on this draft.=0A=0AThe intended statu= s =0A> for this document is BCP.=0AIf adopted, the draft will be =0A> named= :=0A=0Adraft-ietf-multimob-pmipv6-base-solution.=0A=0APlease respond if =0A= > you=A0are for ADOPTING=A0or=0A=0Ayou are NOT for ADOPTING it by February = 21, =0A> 2010.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Forwarded Message= =0A> ----=0A> From: Thomas C. Schmidt <> ymailto=3D"mailto:schmidt@informa= tik.haw-hamburg.de" =0A> href=3D"mailto:schmidt@informatik.haw-hamburg.de">= schmidt@informatik.haw-hamburg.de>=0A> =0A> To: > href=3D"mailto:multimob@i= etf.org">multimob@ietf.org=0A> Sent: Mon, =0A> February 8, 2010 3:02:03 PM= =0A> Subject: [multimob] [Fwd: New Version =0A> Notification for draft-schm= idt-multimob-pmipv6-mcast-deployment-04]=0A> =0A> =0A> Hi,=0A> =0A> we have= submitted a revised version of the PMIPv6 =0A> deployment draft.=0A> This = version includes all contributions from the =0A> extensive and fruitful =0A= > discussions since the last update in =0A> December.=0A> =0A> From the Cha= nge Log=0A> =0A> =A0 The following =0A> changes have been made from=0A> =A0= =0A> draft-schmidt-multimob-pmipv6-mcast-deployment-03.=0A> =0A> =A0 1.=A0= =0A> Detailed outline of multicast reconfiguration steps on handovers=0A> = =A0 =A0 =A0 =0A> added in protocol overview (section 3).=0A> =0A> =A0 2.=A0= Clarified the =0A> details of proxy operations at the MAG along with=0A> = =A0 =A0 =A0 the expected =0A> features of IGMP/MLD Proxy implementations (s= ection=0A> =A0 =A0 =A0 4.2).=0A> =0A> =0A> =A0 3.=A0 Clarified querying in = dual-stack scenarios (section 4.4).=0A> =0A> =0A> =A0 4.=A0 Subsection adde= d on the special case, where multicast is=0A> =0A> =A0 =A0 =A0 available th= roughout the access network (section 4.5).=0A> =0A> =A0 =0A> 5.=A0 Appendix= on IGMP/MLD behaviour added with test reports on current=0A> =A0 =0A> =A0 = =A0 Proxy implementations.=0A> =0A> =0A> We now believe the approach =0A> h= as been thoroughly discussed and the document is =0A> mature enough to be = =0A> considered as a WG item.=0A> =0A> Best wishes,=0A> =0A> =0A> Thomas=0A= > =0A> -------- Original Message --------=0A> Subject: New =0A> Version Not= ification for =0A> =0A> draft-schmidt-multimob-pmipv6-mcast-deployment-04= =0A> Date: Mon,=A0 8 Feb 2010 =0A> 12:53:11 -0800 (PST)=0A> From: IETF I-D = Submission Tool =0A> To: > ymailto=3D"mailto:Schmidt@informatik.haw-hamburg= .de" =0A> href=3D"mailto:Schmidt@informatik.haw-hamburg.de">Schmidt@informa= tik.haw-hamburg.de=0A> =0A> CC: =0A> > href=3D"mailto:schmidt@informatik.ha= w-hamburg.de">schmidt@informatik.haw-hamburg.de,> ymailto=3D"mailto:mw@link= -lab.net" =0A> href=3D"mailto:mw@link-lab.net">mw@link-lab.net,> ymailto=3D= "mailto:suresh.krishnan@ericsson.com" =0A> href=3D"mailto:suresh.krishnan@e= ricsson.com">suresh.krishnan@ericsson.com=0A> =0A> =0A> =0A> A new version = of I-D, =0A> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has =0A>= been =0A> successfuly submitted by Thomas Schmidt and posted to the IETF = =0A> repository.=0A> =0A> Filename:=A0=A0=A0 =0A> draft-schmidt-multimob-pm= ipv6-mcast-deployment=0A> Revision:=A0=A0=A0 04=0A> =0A> Title:=A0=A0=A0 = =A0=A0=A0 A Minimal Deployment Option for Multicast Listeners in PMIPv6 =0A= > =0A> Domains=0A> Creation_date:=A0=A0=A0 2010-02-08=0A> WG ID:=A0=A0=A0 = =A0=A0=A0 =0A> Independent Submission=0A> Number_of_pages: 19=0A> =0A> =0A>= Abstract:=0A> This document describes deployment options for activating = =0A> multicast=0A> listener functions in Proxy Mobile IPv6 domains without = =0A> modifying=0A> mobility and multicast protocol standards.=A0 Similar to= Home =0A> Agents in=0A> Mobile IPv6, PMIPv6 Local Mobility Anchors serve a= s =0A> multicast=0A> subscription anchor points, while Mobile Access Gatewa= ys =0A> provide MLD=0A> proxy functions.=A0 In this scenario, Mobile Nodes = remain =0A> agnostic of=0A> multicast mobility operations.=0A> =0A> =0A> = =0A> =0A> =0A> The IETF Secretariat.=0A> =0A> =0A> =0A> -- =0A> =0A> Prof. = Dr. Thomas C. Schmidt=0A> =B0 Hamburg University of Applied =0A> Sciences= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berliner Tor 7 =B0=0A> =B0 Dept. Inform= atik, Internet =0A> Technologies Group=A0 =A0 20099 Hamburg, Germany =B0=0A= > =B0 =0A> http://www.haw-hamburg.de/inet=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Fon: +49-40-42875-8452 =B0=0A> =0A> =B0 http://www.informatik.haw-hambu= rg.de/~schmidt=A0 =A0 Fax: +49-40-42875-8409 =0A> =B0=0A> _________________= ______________________________=0A> multimob =0A> mailing list=0A> > href=3D= "mailto:multimob@ietf.org">multimob@ietf.org=0A> > href=3D"https://www.ietf= .org/mailman/listinfo/multimob" target=3D_blank =0A> >https://www.ietf.org/= mailman/listinfo/multimob=0A=0A=0A=0A=A0 =A0 =0A> =A0 =0A__________________= _____________________________=0Amultimob mailing =0A> list=0A> href=3D"mail= to:multimob@ietf.org">multimob@ietf.org=0A> href=3D"https://www.ietf.org/ma= ilman/listinfo/multimob" target=3D_blank =0A> >https://www.ietf.org/mailman= /listinfo/multimob=0A=0A=0A From schmidt@informatik.haw-hamburg.de Mon Feb 22 07:43:57 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 2F9C03A7F6A for ; Mon, 22 Feb 2010 07:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.468 X-Spam-Level: * X-Spam-Status: No, score=1.468 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 O21YVGsVRGwN for ; Mon, 22 Feb 2010 07:43:55 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 7C8AA3A7F61 for ; Mon, 22 Feb 2010 07:43:55 -0800 (PST) Envelope-to: multimob@ietf.org Received: from gateway05.m3-connect.de ([88.79.237.15] helo=[10.25.103.154]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NjaTo-000NIx-Qj; Mon, 22 Feb 2010 16:45:53 +0100 Message-ID: <4B82A6AC.3000501@informatik.haw-hamburg.de> Date: Mon, 22 Feb 2010 16:45:48 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sijeon79@gmail.com References: <600E9E8E8C4B423A855A5BB3DCD3D4BA@dcn2c060bed2b9> <4B826108.3010001@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] FW: WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 15:43:57 -0000 Dear Seil, please see my comments marked with Thomas>> Seil Jeon wrote: > > Dear Thomas, > > My response is as follows. Please see this mark "=>" > > -----Original Message----- > From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Sent: Monday, February 22, 2010 7:49 PM > To: sijeon79@gmail.com > Cc: multimob@ietf.org > Subject: Re: FW: [multimob] WG Adoption call ondraft-schmidt-multimob- > pmipv6-mcast-deployment-04 > > Dear Seil, > > thanks for your comments. Please see inline: > > Seil Jeon wrote: >> As I revealed my opinion, I am for ADOPTING this draft. >> >> But I have some questions for this draft. >> >> >> 1. aggregated join could reduce redundant MLD signal but earlier arrived > node should wait for aggregating periodic time. >> So, it can lead to handover latency. MLD signaling would be trivial > compared to redundant multicast traffic. > > The aggregation on an MLD proxy is equivalent to the local maintenance of > its membership database. This comes basically at no delay. The delays on > handover experienced by the first node that arrives for a given group > (first subscriber) are composed of > > 1. Unicast handover management, unicast address(prefix) configuration ... > 2. MLD query by MAG (MLD proxy) > 3. MLD report from MAG to LMA (LMA already is subscribed to the multicast > group) > 4. Traffic forwarding from LMA to MN. > > Steps 1 and 2 can partly be operated in parallel. > > => Thank you for detailed description but I didn't point out it. > > In your handover scenario in Figure 2, there are two MNs (MN1, MN2). > > When there is no "G" channel multicast stream from LMA, the MN1 arrived > earlier than MN2 in MAG1, > Thomas>> This seems like a misunderstanding. In Fig., MN2 moves from MAG1 to MAG2, but MN1 stays with MAG1. > but the MN1 sended "join (G)" message to the MAG1 but MAG1 directly do not > send the "join (G)" message > > to the LMA because the MAG performs "aggregated Join" report process > > In that case, I mentioned that handover latency may happen. > Thomas>> Each MAG sends a join to its upstream interface, whenever a first join for G is received on one of its downstream interfaces. As mentioned, the aggregation will not cause a dedicated latency apart from the normal signaling delay. > >> 2. "On the occurrence of a mobility handover, the LMA will receive >> Binding Lifetime De-Registrations and Binding Lifetime Extensions >> that will cause a re-mapping of home network prefixes to Proxy-CoAs >> in its Binding Cache. Correspondingly, the multicast forwarding >> states require updating, as well. In the absence of explicit >> tracking, the LMA MUST proceed as follows" >> >> But, how LMA can know these event of MNs? LMA uses link-local address and > performs MN-specific management? > > The steps you point at here are part of the unicast handover - this section > of the draft just tries to generate coherence with RFC 5213. > > => Yes, of course. I did not intend the question. > > My question is, when a LMA receives the de-registration message from MAG > for specific MN, > > how can LMA know whether this MN is last node belong to specific multicast > group or not? > Thomas>> Unicast deregistration will not cause multicast group leaves. Multicast group management is done via the proxies, so LMA will hear a Done Report from the MAG after the last MN has left. > => My question is whether link-local address is used for maintaining > multicast group? > > Because a link-local address is not unique identifier. > Thomas>> As said before, the LMA will not keep record of MN-specific multicast states. It will only know about forwarding states per LMA-MAG tunnel as learned from the MAGs / Multicast Proxies. Does this answer your question? Best regards, Thomas > >> -----Original Message----- >> From: Seil Jeon [mailto:sijeon79@gmail.com] >> Sent: Wednesday, February 10, 2010 11:59 AM >> To: 'Behcet Sarikaya' >> Cc: 'multimob@ietf.org' >> Subject: RE: [multimob] WG Adoption call >> ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 >> >> >> Dear all, >> >> I think that this draft is in accordance with this charter among > tunneling mode approach. >> I am for ADOPTING this draft. >> >> >> Best Regards, >> >> Seil Jeon >> >> >> -----Original Message----- >> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On >> Behalf Of Behcet Sarikaya >> Sent: Tuesday, February 09, 2010 6:23 AM >> To: multimob@ietf.org >> Subject: [multimob] WG Adoption call >> ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 >> >> This mail starts a WG adoption call on this draft. >> >> The intended status for this document is BCP. >> If adopted, the draft will be named: >> >> draft-ietf-multimob-pmipv6-base-solution. >> >> Please respond if you are for ADOPTING or >> >> you are NOT for ADOPTING it by February 21, 2010. >> >> Regards, >> >> Behcet >> >> >> >> ----- Forwarded Message ---- >>> From: Thomas C. Schmidt >>> To: multimob@ietf.org >>> Sent: Mon, February 8, 2010 3:02:03 PM >>> Subject: [multimob] [Fwd: New Version Notification for >>> draft-schmidt-multimob-pmipv6-mcast-deployment-04] >>> >>> Hi, >>> >>> we have submitted a revised version of the PMIPv6 deployment draft. >>> This version includes all contributions from the extensive and >>> fruitful discussions since the last update in December. >>> >>> From the Change Log >>> >>> The following changes have been made from >>> draft-schmidt-multimob-pmipv6-mcast-deployment-03. >>> >>> 1. Detailed outline of multicast reconfiguration steps on handovers >>> added in protocol overview (section 3). >>> >>> 2. Clarified the details of proxy operations at the MAG along with >>> the expected features of IGMP/MLD Proxy implementations (section >>> 4.2). >>> >>> 3. Clarified querying in dual-stack scenarios (section 4.4). >>> >>> 4. Subsection added on the special case, where multicast is >>> available throughout the access network (section 4.5). >>> >>> 5. Appendix on IGMP/MLD behaviour added with test reports on >>> current >>> Proxy implementations. >>> >>> >>> We now believe the approach has been thoroughly discussed and the >>> document is mature enough to be considered as a WG item. >>> >>> Best wishes, >>> >>> Thomas >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-schmidt-multimob-pmipv6-mcast-deployment-04 >>> Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) >>> From: IETF I-D Submission Tool >>> To: Schmidt@informatik.haw-hamburg.de >>> CC: >>> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@eri >>> c >>> sson.com >>> >>> >>> A new version of I-D, >>> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been > successfuly submitted by Thomas Schmidt and posted to the IETF repository. >>> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >>> Revision: 04 >>> Title: A Minimal Deployment Option for Multicast Listeners in >>> PMIPv6 Domains >>> Creation_date: 2010-02-08 >>> WG ID: Independent Submission >>> Number_of_pages: 19 >>> >>> Abstract: >>> 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. >>> >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> >>> -- >>> 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 ¡Æ >>> _______________________________________________ >>> 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 JuanCarlos.Zuniga@InterDigital.com Mon Feb 22 08:25:33 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 8B5E43A72EC for ; Mon, 22 Feb 2010 08:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 XTFc85en9nKD for ; Mon, 22 Feb 2010 08:25:32 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 420103A7C18 for ; Mon, 22 Feb 2010 08:25:32 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 11:27:31 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 11:27:31 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 22 Feb 2010 11:28:46 -0500 Message-ID: In-Reply-To: <822998.17108.qm@web111405.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: Acqw/N7jofb9rTdmR8mFlBZQxedOaQC2dFAA References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> <822998.17108.qm@web111405.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 22 Feb 2010 16:27:31.0053 (UTC) FILETIME=[EE4A31D0:01CAB3DB] Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 16:25:33 -0000 Hi Behcet, It is now "next week".=20 While the base solution is cleaned up, I guess we are ready to discuss = about protocol enhancements. Do you agree? Juan Carlos > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Thursday, 18 February, 2010 7:46 PM > To: Zuniga, Juan Carlos; multimob@ietf.org > Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob- > pmipv6-mcast-deployment-04 >=20 > Hi Carlos, > =A0 This current adoption call is aimed at establishing if there is > consensus that this draft is the base solution. You are saying it is. >=20 > =A0 Let's discuss other issues next week. >=20 >=20 > Regards >=20 >=20 > ----- Original Message ---- > > From: "Zuniga, Juan Carlos" > > To: Stig Venaas ; sarikaya@ieee.org; > multimob@ietf.org > > Sent: Thu, February 18, 2010 4:09:32 PM > > Subject: RE: [multimob] WG Adoption callondraft-schmidt-multimob- > pmipv6-mcast-deployment-04 > > > > Behcet, Stig, >=20 > I'd like to understand if you believe the group has reached > > agreement that it is worth looking at optimizations on top of the > base > > solution. >=20 > It has been discussed in the list that there are scenarios > > where the solution detailed in draft-schmidt could have limitations, > for > > instance when different MNs using different LMAs join the same = group. > In such a > > case we can save bandwidth by having a dedicated multicast LMA. = Also, > another > > advantage of a dedicated LMA is to avoid the need for all LMAs to > have multicast > > capability and connectivity. >=20 > I believe that draft-schmidt is a very good > > document and if it addresses the open comments sent on the list it > can become > > the base solution. However, I also believe that we have enough > interest in the > > group to pursue further enhancements on top of this base solution. >=20 > Please > > let me know your views. >=20 > Regards, >=20 > Juan Carlos >=20 >=20 >=20 From behcetsarikaya@yahoo.com Mon Feb 22 08:41:42 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 099E63A81FC for ; Mon, 22 Feb 2010 08:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, 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 gUNAPT6Vicjc for ; Mon, 22 Feb 2010 08:41:41 -0800 (PST) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 2FA263A7B28 for ; Mon, 22 Feb 2010 08:41:41 -0800 (PST) Received: (qmail 53002 invoked by uid 60001); 22 Feb 2010 16:43:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1266857017; bh=kgF7bVGINw3PICBuOxw5qr5hvFjpgpsomgo1dgLzmn0=; 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=B5kNaEKin3MgBc83SezE8GLku0mLYtvf4SUcTugIyKHDG5gjjn6CYfhaQ/H7AK+YZmf01lCJGpCncg+xSWC1GaqOKROuN27ZmljNl97q9qIuZkAS61ZA4qmJcuYpKmGn9UyggBIeHeMwQugaKhiJeULRNZpIZYAzxynh8CV6XX8= 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=Tvmfn1gGACC44I5PFkU2OH0nG7rrGjVQDa5401PmNW7vvyBRDNCCKQBVNVXbC5Z7FyT5zmjqiqoZvEb3r7bCTJsNo+oCWL59zAJYwXC5JRboshd0/2QBmNtLoXKHtw5Qq1SPjsBA//FU8hxmh3+yhCicms9KSYw5L68eEhzkIms=; Message-ID: <865604.51728.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: 30ls9xUVM1l4FAcOlXN9ulbv8.YKrXA2T.UsrOYetWUoGFOZn2rmTu_gYiNsuvpmMTfAabdXthOCy0x5EteKEyxBa9ErSImEszMhtWQncdBzIrhQ4ttOSZvja50KOnmBK8AkkWD0AMYmwNdtyhP3Ykc2QxS_KLo.6zHywBiw36MtXlvYViBpKZz3jBIr8NprcCxrSSOjcRZ0YQgAymLm6WNzYYYUxlstHdZKPGIPbYYhIzU8Y4MdMM8ILEnfZ2B56DDLzX08FEMgCgs0TJkjJOmOWK_VywfteJhWVv4ggTkQUbOtfSieEgl7zM9jEi4vzsAqNKZVFc2dQpdylJRWRAViwnKvv8P29gIyFecZ Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 22 Feb 2010 08:43:37 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de> <822998.17108.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 22 Feb 2010 08:43:37 -0800 (PST) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" , multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 16:41:42 -0000 Sure.=0A=0A--b=0A=0A=0A=0A----- Original Message ----=0A> From: "Zuniga, Ju= an Carlos" =0A> To: Behcet Sarikaya ; multimob@ietf.org=0A> Sent: Mon, February 22, 2010 10:28:= 46 AM=0A> Subject: RE: [multimob] WG Adoption call on draft-schmidt-multimo= b-pmipv6-mcast-deployment-04=0A> =0A> Hi Behcet,=0A=0AIt is now "next week"= . =0A=0AWhile the base solution is =0A> cleaned up, I guess we are ready to= discuss about protocol =0A> enhancements.=0A=0ADo you agree?=0A=0AJuan Car= los=0A=0A> -----Original =0A> Message-----=0A> From: Behcet Sarikaya [mailt= o:> ymailto=3D"mailto:behcetsarikaya@yahoo.com" =0A> href=3D"mailto:behcets= arikaya@yahoo.com">behcetsarikaya@yahoo.com]=0A> =0A> Sent: Thursday, 18 Fe= bruary, 2010 7:46 PM=0A> To: Zuniga, Juan Carlos; > ymailto=3D"mailto:multi= mob@ietf.org" =0A> href=3D"mailto:multimob@ietf.org">multimob@ietf.org=0A> = Subject: Re: =0A> [multimob] WG Adoption call on draft-schmidt-multimob-=0A= > =0A> pmipv6-mcast-deployment-04=0A> =0A> Hi Carlos,=0A> =A0 This current = =0A> adoption call is aimed at establishing if there is=0A> consensus that = this =0A> draft is the base solution. You are saying it is.=0A> =0A> =A0 Le= t's =0A> discuss other issues next week.=0A> =0A> =0A> Regards=0A> =0A> =0A= > =0A> ----- Original Message ----=0A> > From: "Zuniga, Juan =0A> Carlos" <= > href=3D"mailto:JuanCarlos.Zuniga@InterDigital.com">JuanCarlos.Zuniga@Inte= rDigital.com>=0A> =0A> > To: Stig Venaas <> href=3D"mailto:stig@venaas.com"= >stig@venaas.com>; > ymailto=3D"mailto:sarikaya@ieee.org" =0A> href=3D"mail= to:sarikaya@ieee.org">sarikaya@ieee.org;=0A> > ymailto=3D"mailto:multimob@i= etf.org" =0A> href=3D"mailto:multimob@ietf.org">multimob@ietf.org=0A> > Sen= t: Thu, =0A> February 18, 2010 4:09:32 PM=0A> > Subject: RE: [multimob] WG = Adoption =0A> callondraft-schmidt-multimob-=0A> pmipv6-mcast-deployment-04= =0A> =0A> >=0A> > Behcet, Stig,=0A> =0A> I'd like to understand if you =0A>= believe the group has reached=0A> > agreement that it is worth looking at = =0A> optimizations on top of the=0A> base=0A> > solution.=0A> =0A> =0A> It = has been discussed in the list that there are scenarios=0A> > where =0A> th= e solution detailed in draft-schmidt could have limitations,=0A> =0A> for= =0A> > instance when different MNs using different LMAs join the same =0A> = group.=0A> In such a=0A> > case we can save bandwidth by having a =0A> dedi= cated multicast LMA. Also,=0A> another=0A> > advantage of a =0A> dedicated = LMA is to avoid the need for all LMAs to=0A> have =0A> multicast=0A> > capa= bility and connectivity.=0A> =0A> I believe =0A> that draft-schmidt is a ve= ry good=0A> > document and if it addresses the =0A> open comments sent on t= he list it=0A> can become=0A> > the base =0A> solution. However, I also bel= ieve that we have enough=0A> interest in =0A> the=0A> > group to pursue fur= ther enhancements on top of this base =0A> solution.=0A> =0A> Please=0A> > = let me know your views.=0A> =0A> =0A> Regards,=0A> =0A> Juan Carlos=0A> =0A= > =0A> =0A=0A=0A From luisc@it.uc3m.es Mon Feb 22 08:59: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 ACADA3A797E for ; Mon, 22 Feb 2010 08:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.232 X-Spam-Level: X-Spam-Status: No, score=-4.232 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 wJYSJgGtxJO5 for ; Mon, 22 Feb 2010 08:59:42 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5A9C83A711D for ; Mon, 22 Feb 2010 08:59:42 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id C76646C5EFE; Mon, 22 Feb 2010 18:01:39 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 22 Feb 2010 18:01:37 +0100 Message-ID: <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> Date: Mon, 22 Feb 2010 18:01:37 +0100 From: "Luis M. Contreras" To: multimob@ietf.org References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> In-Reply-To: <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 22 Feb 2010 16:59:43 -0000 Hi all, Here are the comments I promised once finished the draft adoption process. Thomas et al., on page 6 and 7 of your draft you describe the steps to be followed in case of MN handover. I include here such list for rerence: ------ 1. The MAG-MN link comes up and the MAG discovers the new MN. 2. Unicast address configuration and PMIPv6 binding are performed,the MAG can determine the corresponding LMA. 3. Following IPv6 address configuration, the MAG SHOULD send an (early) MLD General Query to the new downstream link as part of its standard multicast-enabled router operations. 4. The MAG SHOULD determine whether the MN is admissible to multicast services, and stop here otherwise. 5. The MAG adds the new downstream link to the MLD proxy instance with up-link to the corresponding LMA. 6. The corresponding Proxy instance triggers an MLD General Query on the new downstream link. 7. The MN Membership Reports arrive at the MAG, either in response to the early Query or to that of the Proxy instance. 8. The Proxy processes the MLD Report, updates states and reports upstream if necessary. ----- Comment number 1 ================ The step number 4 states that "The MAG SHOULD determine whether the MN is admissible to multicast services, and stop here otherwise". How can the MAG determine if the MN is allowed to subscribe to multicast contents? At this stage, with current charter definition, it is not possible to handle or keep multicast specific information in binding cache nor signaling messages, so I think that the only way to know this is by means of receiving an MLD Report message to the MLD Query sent in step 3. If so, I suggest to change the text in order to highlighht this dependency at this stage (for instance, something like: <>). This would force to wait for the reception of the MLD report before adding the downstream interface to the corresponding proxy instance. Comment number 2 ============== As far as I understand from your proposal, the MLD General Query in step number 3 is automatically sent by the MAG kernel. In this way the kernel expects to receive an MLD Report answering that Query. Nevertheless, if the MLD report sent by the MN arrives once the MAG-MN point-to-point has been added to the MLD proxy instance, that MLD Report is directly passed to the proxy instance, not to the kernel, according to step 7. In that case, Could the kernel assume that the first Query was lost (because the Report has not been delivered to it) and, in consequence, send Queries repeatedly (governed by the MLD's timers)? (the MLD reports to that queries would be continuosly passed to the proxy instance, not to the kernel which originates such messages) If so, again, it is needed to add the MAG-MN point-to-point to the proxy instance once the MAG receives the first MLD report coming from the MN, not before. Thanks in advance for clarification on these doubts, Regards, Luis From Dirk.von-Hugo@telekom.de Tue Feb 23 00:27:27 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 844DC3A8360 for ; Tue, 23 Feb 2010 00:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yH+ymWWRaEMY for ; Tue, 23 Feb 2010 00:27:26 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 0A6363A7D94 for ; Tue, 23 Feb 2010 00:27:25 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 23 Feb 2010 09:29:21 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 09:29:22 +0100 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, 23 Feb 2010 09:29:21 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801E4F055@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <865604.51728.qm@web111413.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: Acqz3jntFqWdR2uRRsWwZQkyTx6yPAAHEceQ References: <647440.46250.qm@web111410.mail.gq1.yahoo.com><643B0A1D1A13AB498304E0BBC802784801E0C770@S4DE8PSAAQC.mitte.t-com.de><822998.17108.qm@web111405.mail.gq1.yahoo.com> <865604.51728.qm@web111413.mail.gq1.yahoo.com> From: To: , , X-OriginalArrivalTime: 23 Feb 2010 08:29:22.0345 (UTC) FILETIME=[4CE68190:01CAB462] Subject: Re: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 23 Feb 2010 08:27:27 -0000 Dear Carlos, all, Following the agreed adoption of the basic Multimob protocol we can and = should revive and extend the discussion on further enhancements for = protocol optimization as you suggested, Carlos. For that we have = submitted the next version of the "future work" draft to exchange on = potential range for those issues. Although by far not all possible = topics have been covered we would like to base the design on this = document. The I-D can be found at = http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-future-work-0= 1.txt What do you think? Please feel free to comment! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Montag, 22. Februar 2010 17:44 An: Zuniga, Juan Carlos; multimob@ietf.org Betreff: Re: [multimob] WG Adoption call = ondraft-schmidt-multimob-pmipv6-mcast-deployment-04 Sure. --b ----- Original Message ---- > From: "Zuniga, Juan Carlos" > To: Behcet Sarikaya ; multimob@ietf.org > Sent: Mon, February 22, 2010 10:28:46 AM > Subject: RE: [multimob] WG Adoption call on = draft-schmidt-multimob-pmipv6-mcast-deployment-04 >=20 > Hi Behcet, It is now "next week".=20 While the base solution is=20 > cleaned up, I guess we are ready to discuss about protocol=20 > enhancements. Do you agree? Juan Carlos > -----Original=20 > Message----- > From: Behcet Sarikaya [mailto:> = ymailto=3D"mailto:behcetsarikaya@yahoo.com"=20 > href=3D"mailto:behcetsarikaya@yahoo.com">behcetsarikaya@yahoo.com] >=20 > Sent: Thursday, 18 February, 2010 7:46 PM > To: Zuniga, Juan Carlos; > ymailto=3D"mailto:multimob@ietf.org"=20 > href=3D"mailto:multimob@ietf.org">multimob@ietf.org > Subject: Re:=20 > [multimob] WG Adoption call on draft-schmidt-multimob- >=20 > pmipv6-mcast-deployment-04 >=20 > Hi Carlos, > =A0 This current=20 > adoption call is aimed at establishing if there is > consensus that this=20 > draft is the base solution. You are saying it is. >=20 > =A0 Let's=20 > discuss other issues next week. >=20 >=20 > Regards >=20 >=20 >=20 > ----- Original Message ---- > > From: "Zuniga, Juan=20 > Carlos" <> = href=3D"mailto:JuanCarlos.Zuniga@InterDigital.com">JuanCarlos.Zuniga@Inte= rDigital.com> >=20 > > To: Stig Venaas <> href=3D"mailto:stig@venaas.com">stig@venaas.com>; = > ymailto=3D"mailto:sarikaya@ieee.org"=20 > href=3D"mailto:sarikaya@ieee.org">sarikaya@ieee.org; > > ymailto=3D"mailto:multimob@ietf.org"=20 > href=3D"mailto:multimob@ietf.org">multimob@ietf.org > > Sent: Thu,=20 > February 18, 2010 4:09:32 PM > > Subject: RE: [multimob] WG Adoption=20 > callondraft-schmidt-multimob- > pmipv6-mcast-deployment-04 >=20 > > > > Behcet, Stig, >=20 > I'd like to understand if you=20 > believe the group has reached > > agreement that it is worth looking at=20 > optimizations on top of the > base > > solution. >=20 >=20 > It has been discussed in the list that there are scenarios > > where=20 > the solution detailed in draft-schmidt could have limitations, >=20 > for > > instance when different MNs using different LMAs join the same=20 > group. > In such a > > case we can save bandwidth by having a=20 > dedicated multicast LMA. Also, > another > > advantage of a=20 > dedicated LMA is to avoid the need for all LMAs to > have=20 > multicast > > capability and connectivity. >=20 > I believe=20 > that draft-schmidt is a very good > > document and if it addresses the=20 > open comments sent on the list it > can become > > the base=20 > solution. However, I also believe that we have enough > interest in=20 > the > > group to pursue further enhancements on top of this base=20 > solution. >=20 > Please > > let me know your views. >=20 >=20 > Regards, >=20 > Juan Carlos >=20 >=20 >=20 =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From JuanCarlos.Zuniga@InterDigital.com Tue Feb 23 07:58:56 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 9594628C2DA for ; Tue, 23 Feb 2010 07:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 qucAvwwx7n1o for ; Tue, 23 Feb 2010 07:58:55 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 1E6C828C226 for ; Tue, 23 Feb 2010 07:58:54 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 11:00:57 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 11:00:14 -0500 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, 23 Feb 2010 11:01:31 -0500 Message-ID: In-Reply-To: <361364.94061.qm@web111410.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Session at IETF 77 Thread-Index: AcqxsB99ic2xfurjQGSwoTd0YHyoJgC8NlnA References: <361364.94061.qm@web111410.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" , "Stig Venaas" X-OriginalArrivalTime: 23 Feb 2010 16:00:14.0440 (UTC) FILETIME=[49349E80:01CAB4A1] Cc: multimob@ietf.org Subject: Re: [multimob] Session at IETF 77 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, 23 Feb 2010 15:58:56 -0000 Behcet, Stig, We would like to request a slot to present the latest revision of our = draft as an optimization to the baseline solution. Regards, Juan Carlos, Guang and Akbar > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Friday, 19 February, 2010 5:08 PM > To: multimob@ietf.org > Subject: [multimob] Session at IETF 77 >=20 > Hello all, > =A0 We are scheduled to meet on Thursday, March 25 at the next IETF > meeting for a two and a half hour session. > =A0 Please send your session requests to the chairs. >=20 > Regards, >=20 > Chairs >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Wed Feb 24 02:00:32 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 5FFC53A8384; Wed, 24 Feb 2010 02:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.297, 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 z-X9n7dZTeJL; Wed, 24 Feb 2010 02:00:31 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D4ED33A836C; Wed, 24 Feb 2010 02:00:30 -0800 (PST) Envelope-to: mobopts@irtf.org, multimob@ietf.org, sam@irtf.org Received: from e178132153.adsl.alicedsl.de ([85.178.132.153] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NkE4g-000EA7-SA; Wed, 24 Feb 2010 11:02:35 +0100 Message-ID: <4B84F92B.60403@informatik.haw-hamburg.de> Date: Wed, 24 Feb 2010 11:02:19 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mobopts@irtf.org" 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) Cc: sam , multimob@ietf.org Subject: [multimob] RFC 5757 on Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey 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, 24 Feb 2010 10:00:32 -0000 Hi all, FYI: eventually, things come to an end ... once in a while ;) Cheers, Thomas A new Request for Comments is now available in online RFC libraries. RFC 5757 Title: Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey Author: T. Schmidt, M. Waehlisch, G. Fairhurst Status: Informational Date: February 2010 Mailbox: schmidt at informatik.haw-hamburg.de, mw at link-lab.net, gorry at erg.abdn.ac.uk Pages: 37 Characters: 92632 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-mobopts-mmcastv6-ps-09.txt URL: http://www.rfc-editor.org/rfc/rfc5757.txt This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IRTF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC -- 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 root@core3.amsl.com Wed Feb 24 07:00: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 7D5E228C1BF; Wed, 24 Feb 2010 07:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100224150001.7D5E228C1BF@core3.amsl.com> Date: Wed, 24 Feb 2010 07:00:01 -0800 (PST) X-Mailman-Approved-At: Wed, 24 Feb 2010 07:12:47 -0800 Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-00.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, 24 Feb 2010 15:00:01 -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-00.txt Pages : 19 Date : 2010-02-24 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-24064826.I-D@ietf.org> --NextPart-- From behcetsarikaya@yahoo.com Wed Feb 24 12:34: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 0076A28C133 for ; Wed, 24 Feb 2010 12:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 Ab7-oIQ5QFlj for ; Wed, 24 Feb 2010 12:34:05 -0800 (PST) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 4940128C12F for ; Wed, 24 Feb 2010 12:34:05 -0800 (PST) Received: (qmail 22734 invoked by uid 60001); 24 Feb 2010 20:36:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1267043770; bh=DzYqf3qqulPuVP8SYxJGh7x/GRFAIPFoVsN8a0VGtQ0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Ot3QJ0+96asHcFDwBHKZHiZZ8ET7OV6wsAa0rVeBXXRl3L6rlCRdWV5O0+9Xd+rBcFCOe0PZOvuHKJq+0G2yyszZDLm/nVcdXlAgbWKlXHKtcD1AYxYQbBDIq6MtcCtt5hhQv73lZUBzBzrV6I8+DwVyNuTJeCLrnTswx00Dnsw= 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=CufKZFbufw9bzhls6YHNLZRth4Hofsevhx/l6DjzKhOEOxm3MNPHWFtHEzWqqQ6ZlC1OvSv+EabLuEmNu8qXdbY2Vyo2GGlUmVy+sNme+PZ5KRhiNyBEiqsn0bSWpvv4If58ie4jvMclJB6QsJTixySJkqPg42CpO3jQxpgNHsg=; Message-ID: <665139.16526.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: XfIVZekVM1laIpcH9nZVYJvViczB3ZVid5vuQJDLzqgkof_ xnCstouqMd9_Lujly.vVuRsAv75rZg9qE.aSKDYpj78aymASTnT0O4tEbJ6v TUiOwCvnZh65cJUFj7YJZ0Nnp9gCt_6GxxKfMbjmz_AFppKhki_y3xh8mDwx SaRdIxkL3OhHLDY2LN.KZqEfbUFLhKlOfXRK7VRKTa6tB3KudY4GCFJpRauu _n_jdy351czWMF84MlCnd79dLNQPkVKc4QfWTmcyFui6IeyI_.jw.gjy_XzQ OWREuiU39RpsoPxFej6OArEPp0t6lwR6tI6YlR_JCST7CVgk9q_TJVQXmha1 ntBJJY9p2Ds3qsOmguTEiX94SBw-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 24 Feb 2010 12:36:10 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 Date: Wed, 24 Feb 2010 12:36:10 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] I-D submission cut-off dates for IETF 77 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, 24 Feb 2010 20:34:06 -0000 > > The initial draft (version -00) cut-off date is Monday, March 1, 2010. > These submissions are due by 17:00 PST (01:00 Tuesday, March 2 UTC). > > The Internet Draft final submission (version -01 and up) cut-off is > Monday, March 8, 2010 at 17:00 PST (01:00 Tuesday, March 2 UTC). > > All drafts can be uploaded using the ID submission tool located here: > https://datatracker.ietf.org/idst/upload.cgi From JuanCarlos.Zuniga@InterDigital.com Wed Feb 24 13:15:29 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 25B6B3A85C4 for ; Wed, 24 Feb 2010 13:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 QDpV5+K6WTlx for ; Wed, 24 Feb 2010 13:15:22 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 2F5583A738C for ; Wed, 24 Feb 2010 13:15:21 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:17:29 -0500 Received: from VIPER.InterDigital.com ([10.10.2.36]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:16:55 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by VIPER.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 16:16:55 -0500 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: Wed, 24 Feb 2010 16:15:49 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Session at IETF 77 Thread-Index: AcqxsB99ic2xfurjQGSwoTd0YHyoJgC8NlnAAD1bkMA= References: <361364.94061.qm@web111410.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 24 Feb 2010 21:16:55.0443 (UTC) FILETIME=[B1195630:01CAB596] Subject: Re: [multimob] Session at IETF 77 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, 24 Feb 2010 21:15:29 -0000 Dear all, FYI we have submitted a new version of draft-zuniga-multimob-smspmip = addressing the comments we received on the list. http://www.ietf.org/id/draft-zuniga-multimob-smspmip-02.txt =20 We look forward to discussing the draft with you. Best regards, Juan Carlos, Guang and Akbar > -----Original Message----- > From: Zuniga, Juan Carlos > Sent: Tuesday, 23 February, 2010 11:02 AM > To: 'Behcet Sarikaya'; 'Stig Venaas' > Cc: multimob@ietf.org > Subject: RE: [multimob] Session at IETF 77 >=20 > Behcet, Stig, >=20 > We would like to request a slot to present the latest revision of our > draft as an optimization to the baseline solution. >=20 > Regards, >=20 > Juan Carlos, Guang and Akbar >=20 >=20 > > -----Original Message----- > > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] = On > > Behalf Of Behcet Sarikaya > > Sent: Friday, 19 February, 2010 5:08 PM > > To: multimob@ietf.org > > Subject: [multimob] Session at IETF 77 > > > > Hello all, > > =A0 We are scheduled to meet on Thursday, March 25 at the next IETF > > meeting for a two and a half hour session. > > =A0 Please send your session requests to the chairs. > > > > Regards, > > > > Chairs > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob From schmidt@fhtw-berlin.de Wed Feb 24 13:50:57 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 6030028C0E1 for ; Wed, 24 Feb 2010 13:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=0.6] 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 SR6fAqzdfYzN for ; Wed, 24 Feb 2010 13:50:56 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 556BF28C166 for ; Wed, 24 Feb 2010 13:50:56 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178132153.adsl.alicedsl.de ([85.178.132.153] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NkPAE-000NHo-K9; Wed, 24 Feb 2010 22:53:02 +0100 Message-ID: <4B859FBA.6030300@fhtw-berlin.de> Date: Wed, 24 Feb 2010 22:52:58 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> In-Reply-To: <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 24 Feb 2010 21:50:57 -0000 Hi Luis, thanks again for your critical comments: this is highly appreciated! Please see my answers inline: Luis M. Contreras wrote: > Hi all, > > Here are the comments I promised once finished the draft adoption process. > > Thomas et al., on page 6 and 7 of your draft you describe the steps to > be followed in case of MN handover. I include here such list for rerence: > ------ > 1. The MAG-MN link comes up and the MAG discovers the new MN. > > 2. Unicast address configuration and PMIPv6 binding are performed,the > MAG can determine the corresponding LMA. > > 3. Following IPv6 address configuration, the MAG SHOULD send an (early) > MLD General Query to the new downstream link as part of its standard > multicast-enabled router operations. > > 4. The MAG SHOULD determine whether the MN is admissible to multicast > services, and stop here otherwise. > > 5. The MAG adds the new downstream link to the MLD proxy instance with > up-link to the corresponding LMA. > > 6. The corresponding Proxy instance triggers an MLD General Query on the > new downstream link. > > 7. The MN Membership Reports arrive at the MAG, either in response to > the early Query or to that of the Proxy instance. > > 8. The Proxy processes the MLD Report, updates states and reports > upstream if necessary. > ----- > > Comment number 1 > ================ > The step number 4 states that "The MAG SHOULD determine whether the MN > is admissible to multicast services, and stop here otherwise". How can > the MAG determine if the MN is allowed to subscribe to multicast > contents? At this stage, with current charter definition, it is not > possible to handle or keep multicast specific information in binding > cache nor signaling messages, so I think that the only way to know this > is by means of receiving an MLD Report message to the MLD Query sent in > step 3. > > If so, I suggest to change the text in order to highlighht this > dependency at this stage (for instance, something like: < determine whether the MN is admissible to multicast services ""if an MLD > Report is received as response to the previously sent MLD General > Query"", and stop here otherwise>>). This would force to wait for the > reception of the MLD report before adding the downstream interface to > the corresponding proxy instance. > The part of "Multicast group allowance" is typically included in AAA, which indeed is out of scope of the current charter. However, the option that certain services are rejected will confirm to the charter. So it is fair to mention this issue, even though it remains out of scope how this knowledge reaches the entities (such as MAGs). > Comment number 2 > ============== > As far as I understand from your proposal, the MLD General Query in step > number 3 is automatically sent by the MAG kernel. In this way the kernel > expects to receive an MLD Report answering that Query. Nevertheless, if > the MLD report sent by the MN arrives once the MAG-MN point-to-point has > been added to the MLD proxy instance, that MLD Report is directly passed > to the proxy instance, not to the kernel, according to step 7. In that > case, Could the kernel assume that the first Query was lost (because the > Report has not been delivered to it) and, in consequence, send Queries > repeatedly (governed by the MLD's timers)? (the MLD reports to that > queries would be continuosly passed to the proxy instance, not to the > kernel which originates such messages) > > If so, again, it is needed to add the MAG-MN point-to-point to the proxy > instance once the MAG receives the first MLD report coming from the MN, > not before. > Yes and no: Indeed, the kernel does initiate the general queries (at least in the test cases we examined), but MLD messaging is not transactional. So even if a kernel query was issued, the reply could be interpreted by an additional process like an MLD proxy. As stated in the draft, it would be desirable to have the proxy downstream link configured at the time the MLD report arrives as an answer to the general query. However, the proxy would query by itself, so downlink configurations would sooner or later become part of the distribution tree. Best regards, Thomas From Guang.Lu@InterDigital.com Wed Feb 24 15:01:37 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 CD3AD28C138 for ; Wed, 24 Feb 2010 15:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 yNB-B6T7AWwN for ; Wed, 24 Feb 2010 15:01:36 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id A646528C0EB for ; Wed, 24 Feb 2010 15:01:36 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 18:03:44 -0500 Received: from VIPER.InterDigital.com ([10.10.2.36]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 17:56:56 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by VIPER.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 17:56:56 -0500 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: Wed, 24 Feb 2010 17:52:24 -0500 Message-ID: In-Reply-To: <4B859FBA.6030300@fhtw-berlin.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG Adoptioncall on draft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: Acq1m8hXM0UaAeUUQhadF5gFauPUpQABkZtw References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es><20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> From: "Lu, Guang" To: X-OriginalArrivalTime: 24 Feb 2010 22:56:56.0150 (UTC) FILETIME=[A9CC8F60:01CAB5A4] Subject: Re: [multimob] WG Adoptioncall on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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, 24 Feb 2010 23:01:37 -0000 Hi Thomas,=20 We posted some comments on draft-schmidt-multimob-pmipv6-mcast-deployment-04.=20 http://www.ietf.org/mail-archive/web/multimob/current/msg00774.html Have you got a chance to look at them? Please let us know your opinions. Best Regards, Guang > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Wednesday, February 24, 2010 4:53 PM > To: Luis M. Contreras > Cc: multimob@ietf.org > Subject: Re: [multimob] WG Adoptioncall on draft-schmidt-multimob- > pmipv6-mcast-deployment-04 >=20 > Hi Luis, >=20 > thanks again for your critical comments: this is highly appreciated! >=20 > Please see my answers inline: >=20 > Luis M. Contreras wrote: > > Hi all, > > > > Here are the comments I promised once finished the draft adoption > process. > > > > Thomas et al., on page 6 and 7 of your draft you describe the steps > to > > be followed in case of MN handover. I include here such list for > rerence: > > ------ > > 1. The MAG-MN link comes up and the MAG discovers the new MN. > > > > 2. Unicast address configuration and PMIPv6 binding are performed,the > > MAG can determine the corresponding LMA. > > > > 3. Following IPv6 address configuration, the MAG SHOULD send an > (early) > > MLD General Query to the new downstream link as part of its standard > > multicast-enabled router operations. > > > > 4. The MAG SHOULD determine whether the MN is admissible to multicast > > services, and stop here otherwise. > > > > 5. The MAG adds the new downstream link to the MLD proxy instance > with > > up-link to the corresponding LMA. > > > > 6. The corresponding Proxy instance triggers an MLD General Query on > the > > new downstream link. > > > > 7. The MN Membership Reports arrive at the MAG, either in response to > > the early Query or to that of the Proxy instance. > > > > 8. The Proxy processes the MLD Report, updates states and reports > > upstream if necessary. > > ----- > > > > Comment number 1 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The step number 4 states that "The MAG SHOULD determine whether the > MN > > is admissible to multicast services, and stop here otherwise". How > can > > the MAG determine if the MN is allowed to subscribe to multicast > > contents? At this stage, with current charter definition, it is not > > possible to handle or keep multicast specific information in binding > > cache nor signaling messages, so I think that the only way to know > this > > is by means of receiving an MLD Report message to the MLD Query sent > in > > step 3. > > > > If so, I suggest to change the text in order to highlighht this > > dependency at this stage (for instance, something like: < SHOULD > > determine whether the MN is admissible to multicast services ""if an > MLD > > Report is received as response to the previously sent MLD General > > Query"", and stop here otherwise>>). This would force to wait for the > > reception of the MLD report before adding the downstream interface to > > the corresponding proxy instance. > > >=20 > The part of "Multicast group allowance" is typically included in AAA, > which indeed is out of scope of the current charter. However, the > option > that certain services are rejected will confirm to the charter. So it > is > fair to mention this issue, even though it remains out of scope how > this > knowledge reaches the entities (such as MAGs). >=20 > > Comment number 2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > As far as I understand from your proposal, the MLD General Query in > step > > number 3 is automatically sent by the MAG kernel. In this way the > kernel > > expects to receive an MLD Report answering that Query. Nevertheless, > if > > the MLD report sent by the MN arrives once the MAG-MN point-to-point > has > > been added to the MLD proxy instance, that MLD Report is directly > passed > > to the proxy instance, not to the kernel, according to step 7. In > that > > case, Could the kernel assume that the first Query was lost (because > the > > Report has not been delivered to it) and, in consequence, send > Queries > > repeatedly (governed by the MLD's timers)? (the MLD reports to that > > queries would be continuosly passed to the proxy instance, not to the > > kernel which originates such messages) > > > > If so, again, it is needed to add the MAG-MN point-to-point to the > proxy > > instance once the MAG receives the first MLD report coming from the > MN, > > not before. > > > Yes and no: Indeed, the kernel does initiate the general queries (at > least in the test cases we examined), but MLD messaging is not > transactional. So even if a kernel query was issued, the reply could be > interpreted by an additional process like an MLD proxy. As stated in > the > draft, it would be desirable to have the proxy downstream link > configured at the time the MLD report arrives as an answer to the > general query. However, the proxy would query by itself, so downlink > configurations would sooner or later become part of the distribution > tree. >=20 > Best regards, >=20 > Thomas > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From gdaley@netstarnetworks.com Wed Feb 24 19:15:35 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 5ADFC3A8618 for ; Wed, 24 Feb 2010 19:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RELAY_IS_203=0.994] 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 gGhazyty2CvM for ; Wed, 24 Feb 2010 19:15:34 -0800 (PST) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id 120C328C2C1 for ; Wed, 24 Feb 2010 19:15:33 -0800 (PST) Received: from sdcexchht.netstarnetworks.com ([10.18.193.63]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id o1P3HWE0031520 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Thu, 25 Feb 2010 14:17:33 +1100 Received: from sdcexch.netstarnetworks.com ([fe80::cccf:1c5b:c46b:c7b1]) by sdcexchht.netstarnetworks.com ([fe80::a92b:b7d5:8094:5e10%10]) with mapi; Thu, 25 Feb 2010 14:17:24 +1100 From: Greg Daley To: "Thomas C. Schmidt" , "Luis M. Contreras" Date: Thu, 25 Feb 2010 14:17:20 +1100 Thread-Topic: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 Thread-Index: Acq1m8CMYi1u52n/QR2UO5iB6P6TyQAKkgOA Message-ID: References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> In-Reply-To: <4B859FBA.6030300@fhtw-berlin.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "multimob@ietf.org" Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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: Thu, 25 Feb 2010 03:15:35 -0000 Hi Thomas and Luis,=20 > Hi Luis, >=20 > thanks again for your critical comments: this is highly appreciated! >=20 > Please see my answers inline: >=20 > Luis M. Contreras wrote: ... > >=20 > > 3. Following IPv6 address configuration, the MAG SHOULD send an > > (early) MLD General Query to the new downstream link as part of > > its standard multicast-enabled router operations. Forgive me for my long hiatus, and perhaps the scope of the PMIPv6 system precludes this being an issue. Does anyone have an idea of the impact that a downstream multicast General Query would have on an 802.11 Network each time a device arrives on the cell? The message transmitted unacknowledged on one of the rates in the BasicRatesSet. BasicRatesSet defines the common rates all devices accessible by an AP must support. Past behaviour on Wireless LAN defaults this to be low throughput rates, and on 2.4GHz systems, this has typically been either 1Mbps, or 2Mbps (or 3Mbps for 5GHz). This takes potentially 54 times as long for transmission of the data component than a comparable packet delivered over MAC unicast. With General Queries, there is no Robustness value (transmissions occur once), so there's a possibility that a downstream multicast=20 could also be lost, and no report received from the Listener. Given that there is a MAG which is keeping track of unicast addressing and configuration, would it not be appropriate to direct the General Query to a unicast address of the arriving device in compliance with S5.1.15 of RFC3810? This would allow unicast packet delivery at Link-Layer, which incorporates higher data rates, and MAC retransmission. This may also be useful for other media. (You could readily determine if it is better to send a Multicast or=20 multiple unicasts based on the outstanding number of devices which are Unicast configured, but not MLD Reporters). The unicast/multicast ratio could be configured on a per-interface basis. Sincerely, Greg Daley= From schmidt@informatik.haw-hamburg.de Thu Feb 25 00:04: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 4BAE228C0DF for ; Thu, 25 Feb 2010 00:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.224, 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 a34BXlvrst2d for ; Thu, 25 Feb 2010 00:04:22 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 2129328C276 for ; Thu, 25 Feb 2010 00:04:20 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178129113.adsl.alicedsl.de ([85.178.129.113] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NkYjt-000Lqy-1R; Thu, 25 Feb 2010 09:06:29 +0100 Message-ID: <4B862F81.3020804@informatik.haw-hamburg.de> Date: Thu, 25 Feb 2010 09:06:25 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Greg Daley References: <647440.46250.qm@web111410.mail.gq1.yahoo.com> <20100219095805.ltg5rqmigwkwggss@webcartero01.uc3m.es> <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> In-Reply-To: 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] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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: Thu, 25 Feb 2010 08:04:23 -0000 Hi Greg, good to hear from you! The issue you are raising is under debate in "the other" core objective of Multimob, the MLD tuning. Actually, Hitoshi Asaeda has proposed to use MLD by unicast in his presentation at the last IETF (Hiroshima), I believe for the exact same arguments you follow. In the basic PMIPv6 context, this is not so much an issue, as RFC5213 restricts downstream links to be point-to-point. In case of 802.11 wireless access, this would lead to unicast tunnels anyway (possibly GRE - see http://tools.ietf.org/html/draft-ietf-netlmm-grekey-option-09). So in brief: we agree, but the issue seems more related to the MLD tuning in wireless domains rather than to PMIP at its current spec. Cheers, Thomas Greg Daley wrote: > > Hi Thomas and Luis, > >> Hi Luis, >> >> thanks again for your critical comments: this is highly appreciated! >> >> Please see my answers inline: >> >> Luis M. Contreras wrote: > ... >>> 3. Following IPv6 address configuration, the MAG SHOULD send an >>> (early) MLD General Query to the new downstream link as part of >>> its standard multicast-enabled router operations. > > Forgive me for my long hiatus, and perhaps the scope of the PMIPv6 > system precludes this being an issue. > > Does anyone have an idea of the impact that a downstream multicast > General Query would have on an 802.11 Network each time a device > arrives on the cell? > > The message transmitted unacknowledged on one of the rates in the > BasicRatesSet. BasicRatesSet defines the common rates all devices > accessible by an AP must support. > > Past behaviour on Wireless LAN defaults this to be low throughput > rates, and on 2.4GHz systems, this has typically been either 1Mbps, > or 2Mbps (or 3Mbps for 5GHz). This takes potentially 54 times as > long for transmission of the data component than a comparable packet > delivered over MAC unicast. > > With General Queries, there is no Robustness value (transmissions > occur once), so there's a possibility that a downstream multicast > could also be lost, and no report received from the Listener. > > Given that there is a MAG which is keeping track of unicast addressing > and configuration, would it not be appropriate to direct the General Query > to a unicast address of the arriving device in compliance with S5.1.15 of > RFC3810? > > This would allow unicast packet delivery at Link-Layer, which incorporates > higher data rates, and MAC retransmission. > > This may also be useful for other media. > > (You could readily determine if it is better to send a Multicast or > multiple unicasts based on the outstanding number of devices which are > Unicast configured, but not MLD Reporters). The unicast/multicast > ratio could be configured on a per-interface basis. > > > Sincerely, > > Greg Daley -- 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 asaeda@sfc.wide.ad.jp Thu Feb 25 00:54: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 2C28228C0D7 for ; Thu, 25 Feb 2010 00:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 eQsMCDzs5Tlg for ; Thu, 25 Feb 2010 00:54:45 -0800 (PST) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 55FAC3A8666 for ; Thu, 25 Feb 2010 00:54:45 -0800 (PST) Received: from localhost (dhcp-143-189.sfc.wide.ad.jp [203.178.143.189]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id D65B913D06CA; Thu, 25 Feb 2010 17:56:53 +0900 (JST) Date: Thu, 25 Feb 2010 17:56:53 +0900 (JST) Message-Id: <20100225.175653.108627834.asaeda@sfc.wide.ad.jp> To: gdaley@netstarnetworks.com From: Hitoshi Asaeda In-Reply-To: References: <20100222180137.bhg55kngqosg4800@webcartero01.uc3m.es> <4B859FBA.6030300@fhtw-berlin.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] WG Adoption call on draft-schmidt-multimob-pmipv6-mcast-deployment-04 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: Thu, 25 Feb 2010 08:54:46 -0000 Hi Greg, > Does anyone have an idea of the impact that a downstream multicast > General Query would have on an 802.11 Network each time a device > arrives on the cell? I think your question is related to my IGMP/MLD optimization draft. Please take a look at; http://tools.ietf.org/html/draft-asaeda-multimob-igmp-mld-optimization-01 > The message transmitted unacknowledged on one of the rates in the > BasicRatesSet. BasicRatesSet defines the common rates all devices > accessible by an AP must support. > > Past behaviour on Wireless LAN defaults this to be low throughput > rates, and on 2.4GHz systems, this has typically been either 1Mbps, > or 2Mbps (or 3Mbps for 5GHz). This takes potentially 54 times as > long for transmission of the data component than a comparable packet > delivered over MAC unicast. > > With General Queries, there is no Robustness value (transmissions > occur once), so there's a possibility that a downstream multicast > could also be lost, and no report received from the Listener. > > Given that there is a MAG which is keeping track of unicast addressing > and configuration, would it not be appropriate to direct the General Query > to a unicast address of the arriving device in compliance with S5.1.15 of > RFC3810? > > This would allow unicast packet delivery at Link-Layer, which incorporates > higher data rates, and MAC retransmission. As you said it is difficult for coordinating the timing of general query because each wireless link MAC has its different signaling mechanism. Unicast query discussed in the above draft is not perfect for every condition. Our draft aims to clarify the issues for mobile multicast and describe the considerable way of tuning protocol timers and behavior. I've been revising the draft. (I hope I finish it before this cut-off date) If you have comments, please tell me. Your input would be valuable. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Thu Feb 25 05:18:53 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 D4B8028C102 for ; Thu, 25 Feb 2010 05:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.191, 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 KyKKlPKRKNrP for ; Thu, 25 Feb 2010 05:18:47 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 74ADB3A82D5 for ; Thu, 25 Feb 2010 05:18:46 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178129113.adsl.alicedsl.de ([85.178.129.113] helo=[192.168.178.25]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NkdeB-000I5K-Qt; Thu, 25 Feb 2010 14:20:56 +0100 Message-ID: <4B867934.9000807@informatik.haw-hamburg.de> Date: Thu, 25 Feb 2010 14:20:52 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Lu, Guang" References: <4B707BCB.2020805@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] [Fwd: New Version Notification fordraft-schmidt-multimob-pmipv6-mcast-deployment-04] 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: Thu, 25 Feb 2010 13:18:54 -0000 Hi Guang, many thanks for your comments - sorry for missing your mail at first. Please see answers inline (marked with "Thomas >>>>"): Lu, Guang wrote: > (a) Appendix C. Comparative Evaluation of Different Approaches > > In the tables, you provided comparison of "# of redundant streams at MAG" and "# of sim. Streams at LMA / LMA-M". Showing the streams at each LMA is good but not enough though since it only shows the load of one node. IMHO it is also essential to provide total number of simultaneous streams network wise to show the whole picture. Note that this point was raised before in the mailing list (http://www.ietf.org/mail-archive/web/multimob/current/msg00741.html). > > Please see below the extended tables with a new column showing "# of sim. Streams in network for all LMAs". This information can clearly answer some questions raised by the group regarding the traffic profile in various scenarios. > > Setting 1: 1,000,000 MNs are subscribed to distinct multicast groups > > The combined Unicast/Multicast LMA scheme has 4 LMAs, each with 250,000 streams. So in the network, both solutions have the same number of simultaneous streams. > > +=============+===========+================+=================== > | | | | | > | PMIP | # of | # of sim. |# of sim. streams | > | Multicast | redundant | streams at |in network | > | scheme | streams | each LMA/LMA-M |for all LMAs | > | | at MAG | LMA/LMA-M | | > +=============+===========+================+==================| > | Combined | | | | > | Unicast/ | 0 | 250,000 | 1,000,000 | > | Mcast LMA | | | | > +-------------+-----------+----------------+------------------+ > | Dedicated | 0 | 1,000,000 | 1,000,000 | > | Mcast LMA | | | | > +-------------+-----------+----------------+------------------+ > > > Setting 2: 1,000,000 MNs are subscribed to the same multicast group > > Due to the traffic replication at MAG, the combined unicast/multicast LMA scheme produces a total of 800 streams between all LMAs and MAGs. The dedicated LMA configuration requires 200 streams, less than the combined solution. This scenario clearly shows the advantage of saving bandwidth with the dedicated multicast LMA when MNs using different LMAs join the same group. > > +=============+===========+================+=================== > | | | | | > | PMIP | # of | # of sim. |# of sim. streams | > | Multicast | redundant | streams at |in network | > | scheme | streams | each LMA/LMA-M |for all LMAs | > | | at MAG | LMA/LMA-M | | > +=============+===========+================+==================| > | Combined | | | | > | Unicast/ | 4 | 50 | 800 | > | Mcast LMA | | | | > +-------------+-----------+----------------+------------------+ > | Dedicated | 0 | 200 | 200 | > | Mcast LMA | | | | > +-------------+-----------+----------------+------------------+ > Thomas >>>> Yes, that sounds correct, in fact it's just multiplying it out. Looking at the table more closely, there are arithmetic mistakes anyway. It should be: +=============+===========+================+=================== | | | | | | PMIP | # of | # of sim. |# of sim. streams | | Multicast | redundant | streams at |in network | | scheme | streams | each LMA/LMA-M |for all LMAs | | | at MAG | LMA/LMA-M | | +=============+===========+================+==================| | Combined | | | | | Unicast/ | 3 | 200 | 800 | | Mcast LMA | | | | +-------------+-----------+----------------+------------------+ | Dedicated | 0 | 200 | 200 | | Mcast LMA | | | | +-------------+-----------+----------------+------------------+ Thomas >>>> We can add this, even though it's just two sides of the same coin ... > (b) Figure 2 > The Figure seems to mix IGMP and MLD terms (and is not consistent with the text in section 3). To be consistent, the IGMP term "Join" should be replaced by the MLD term "Report" in the Figure. > Thomas >>>> Yes ... rather it's IGMPv2 language, which bears the beauty of simplicity and brevity. IGMPv2 JOIN corresponds to a specific IGMPv3/MLDv2 REPORT message (exclude no sources for group G). We should re-think presentation, but keep it intuitive. > > (c) Section 4.5 (Multicast Availability throughout the Access Network) Do you think an air interface protocol like 3GPP MBMS qualifies as a access network multicast support? If so, it would be good to expand this section to include the air interface support of multicast. Thomas >>>> I don't get your point here. IMHO, 3GPP/MBMS is a particularly striking example of multicast unavailability at the network layer ... however, this section is just a pointer to future work on optimization. I suppose, this should rest as a pointer and future documents (like your work ?) should elaborate on it/ work out optimizing set ups, e.g., for 3GPP or emerging architectures. > > > (d) Section 7 (Security Considerations) > There are some additional security considerations for dual mode (IPv4/IPv6) raised in [I-D.ietf-netlmm-pmip6-ipv4-support]. Should this be acknowledged in this section? Thomas >>>> Thanks for the pointer: The security section should be carefully revised anyway, I believe. We don't want to repeat the issues of PMIP or MLD, but should re-consider what arises from the combination chosen in the draft. > > > (e) Appendix B (State of IGMP/MLD Proxy Implementations): > It was good that Cisco edge router was tested. Do you intend to test the Juniper Networks E-series platform as well as it seems to have good multicast support (http://www.juniper.net/solutions/literature/white_papers/200188.pdf) ? Thomas >>>> We would love to, but we don't have one in our lab. May be someone who has easy access to Juniper test equipment volunteers to do this? Cheers, Thomas >> -----Original Message----- >> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On >> Behalf Of Thomas C. Schmidt >> Sent: Monday, February 08, 2010 4:02 PM >> To: multimob@ietf.org >> Subject: [multimob] [Fwd: New Version Notification fordraft-schmidt- >> multimob-pmipv6-mcast-deployment-04] >> >> Hi, >> >> we have submitted a revised version of the PMIPv6 deployment draft. >> This version includes all contributions from the extensive and fruitful >> discussions since the last update in December. >> >> From the Change Log >> >> The following changes have been made from >> draft-schmidt-multimob-pmipv6-mcast-deployment-03. >> >> 1. Detailed outline of multicast reconfiguration steps on >> handovers >> added in protocol overview (section 3). >> >> 2. Clarified the details of proxy operations at the MAG along with >> the expected features of IGMP/MLD Proxy implementations >> (section >> 4.2). >> >> 3. Clarified querying in dual-stack scenarios (section 4.4). >> >> 4. Subsection added on the special case, where multicast is >> available throughout the access network (section 4.5). >> >> 5. Appendix on IGMP/MLD behaviour added with test reports on >> current >> Proxy implementations. >> >> >> We now believe the approach has been thoroughly discussed and the >> document is mature enough to be considered as a WG item. >> >> Best wishes, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-schmidt-multimob-pmipv6-mcast-deployment-04 >> Date: Mon, 8 Feb 2010 12:53:11 -0800 (PST) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC: >> schmidt@informatik.haw-hamburg.de,mw@link- >> lab.net,suresh.krishnan@ericsson.com >> >> >> A new version of I-D, >> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been >> successfuly submitted by Thomas Schmidt and posted to the IETF >> repository. >> >> Filename: draft-schmidt-multimob-pmipv6-mcast-deployment >> Revision: 04 >> Title: A Minimal Deployment Option for Multicast Listeners >> in PMIPv6 >> Domains >> Creation_date: 2010-02-08 >> WG ID: Independent Submission >> Number_of_pages: 19 >> >> Abstract: >> 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. >> >> >> >> >> The IETF Secretariat. >> >> >> >> -- >> >> 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 ° >> _______________________________________________ >> 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 Dirk.von-Hugo@telekom.de Fri Feb 26 07:18:56 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 96DBA3A87D3 for ; Fri, 26 Feb 2010 07:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jYy7fqg6tPsc for ; Fri, 26 Feb 2010 07:18:55 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 2FF633A8191 for ; Fri, 26 Feb 2010 07:18:55 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 26 Feb 2010 16:21:04 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 16:21:04 +0100 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: Fri, 26 Feb 2010 16:21:04 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801E994DC@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <361364.94061.qm@web111410.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Session at IETF 77 Thread-Index: AcqxsBjgCzpSp1kAReyRe4UAti2QEwFRkWGA References: <361364.94061.qm@web111410.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 26 Feb 2010 15:21:04.0571 (UTC) FILETIME=[4FD050B0:01CAB6F7] Subject: Re: [multimob] Session at IETF 77 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, 26 Feb 2010 15:18:56 -0000 Dear chairs, all, I would like to request a slot for presentation of future work - also = beyond the currently proposed optimization enhancements to the basic WG = MultiMob protocol draft. I expect 15 min will be enough.=20 But this also depends on the discussion of our recently updated document = at = http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-future-work-0= 1.txt Best regards Dirk on behalf of the team -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Behcet Sarikaya Gesendet: Freitag, 19. Februar 2010 23:08 An: multimob@ietf.org Betreff: [multimob] Session at IETF 77 Hello all, =A0 We are scheduled to meet on Thursday, March 25 at the next IETF = meeting for a two and a half hour session. =A0 Please send your session requests to the chairs. Regards, Chairs =20 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob