From Dirk.von-Hugo@telekom.de Wed Mar 2 04:18:36 2011 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 901E53A67EC for ; Wed, 2 Mar 2011 04:18:36 -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 bSLhjEQ+0OjC for ; Wed, 2 Mar 2011 04:18:35 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 5B4F83A6C3C for ; Wed, 2 Mar 2011 04:18:17 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail81.telekom.de with ESMTP; 02 Mar 2011 13:19:17 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 13:19:17 +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, 2 Mar 2011 13:19:16 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <176899.13118.qm@web111411.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OFFLIST: [multimob] Charter and draft submission deadlines Thread-Index: AcvXiv6Wp9ZjHJUWTYmJ+DmH9d1KZABRgAWg References: <4D5D9054.9030901@venaas.com> <643B0A1D1A13AB498304E0BBC8027848030A34AF@S4DE8PSAAQC.mitte.t-com.de> <176899.13118.qm@web111411.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 02 Mar 2011 12:19:17.0861 (UTC) FILETIME=[0D563150:01CBD8D4] Subject: Re: [multimob] OFFLIST: Charter and draft submission deadlines 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, 02 Mar 2011 12:18:36 -0000 Dear all, Hopefully I understand the AMT draft well enough - currently I think = that an enhancement of PMIP entities with AMT functionality would allow = for similar optimizations as proposed: Each MAG with multicast subscribing MNs attached behaves as an AMT Gateway which has already established via a three way handshake a tunnel to AMT Relay or does so on subcription of a MN - similar to an M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extension]. Since between MAG and LMA already a security association may be already established according to RFC5213, the handshake mechanism may be not required. =20 A dedicated multicast LMA or a local MR with native multicast support behaves like an AMT Relay in that join messages are forwarded within the native Multicast environment and on the other hand received multicast traffic is subsequently forwarded via the AMT interface to the MAG/AMT Gateway. Such a dedicated multicast DM-LMA is proposed = by [I-D.zuniga- multimob-smspmip] =20 The AMT relay can also provide direct local routing of traffic to the requesting MAG independent of any LMA as proposed in = [I-D.sijeon-multimob-mms-pmip6]. Does that make sense? Please comment! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Gesendet: Montag, 28. Februar 2011 22:04 An: von Hugo, Dirk; multimob@ietf.org Betreff: OFFLIST: [multimob] Charter and draft submission deadlines Hi Dirk, >=20 > Dear Stig, all > Thanks for the reminder! AFAIAAO for the first new WI on PMIPv6 = routing=20 >optimizations to avoid tunnel convergence problem we have at least 4 = different=20 >drafts available tackling a potential solution such as >=20 > I-D.ietf-mboned-auto-multicast: > WG MBONED (Multicast Backbone Deployment) describes an approach = which=20 >allows > for automatic multicast communication without explicit tunnels. = This=20 >procedure > may be applied to isolated multicast-enabled sites or hosts which = are =20 >attached > to a network without native multicast support and removes the need = for=20 >manual > configuration. If you think this draft applies to our charter item then maybe we need a = short=20 draft explaining how. Regards, Behcet =20 From asaeda@sfc.wide.ad.jp Wed Mar 2 05:37:16 2011 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 D28A13A67F1 for ; Wed, 2 Mar 2011 05:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.588 X-Spam-Level: X-Spam-Status: No, score=-97.588 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, SARE_RECV_IP_222000=1.508, USER_IN_WHITELIST=-100] 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 LtTUraGY7Tfh for ; Wed, 2 Mar 2011 05:37:16 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 1D0213A67D8 for ; Wed, 2 Mar 2011 05:37:16 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0BF222780AC; Wed, 2 Mar 2011 22:38:18 +0900 (JST) Date: Wed, 02 Mar 2011 22:38:18 +0900 (JST) Message-Id: <20110302.223818.02880386.asaeda@sfc.wide.ad.jp> To: Dirk.von-Hugo@telekom.de From: Hitoshi Asaeda In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de> References: <643B0A1D1A13AB498304E0BBC8027848030A34AF@S4DE8PSAAQC.mitte.t-com.de> <176899.13118.qm@web111411.mail.gq1.yahoo.com> <643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de> X-Mailer: Mew version 6.2.51 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] OFFLIST: Charter and draft submission deadlines 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, 02 Mar 2011 13:37:16 -0000 Hi Dirk, > Hopefully I understand the AMT draft well enough - currently I think > that an enhancement of PMIP entities with AMT functionality would > allow for similar optimizations as proposed: > > Each MAG with multicast subscribing MNs attached behaves as an AMT > Gateway which has already established via a three way handshake a > tunnel to AMT Relay or does so on subcription of a MN - similar to an > M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extension]. Well, AMT establishes a bi-directional tunnel between AMT gateway and relay. This concept is similar to a bi-directional tunnel establishment between LMA and MAG. Therefore one may think all proposals using bi-directional tunnel look similar to the AMT at this point. However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT does not solve the fundamental problems, such as seamless handover and local routing. Also, an AMT gateway should have the IGMP/MLD proxy functionality. This means, if MAG acts as an MLD proxy having a bi-directional tunnel as proposed in the base solution, AMT is not necessary. AMT is a protocol that simply establishes a bi-directional tunnel bridging non-native multicast networks without explicit tunnel setup. Regards, -- Hitoshi Asaeda From Dirk.von-Hugo@telekom.de Wed Mar 2 06:54:53 2011 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 923D83A6835 for ; Wed, 2 Mar 2011 06:54:53 -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 p4T+7+EaAoAJ for ; Wed, 2 Mar 2011 06:54:52 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 52E8F3A67A1 for ; Wed, 2 Mar 2011 06:54:51 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 02 Mar 2011 15:55:49 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 15:55:49 +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, 2 Mar 2011 15:55:50 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20110302.223818.02880386.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] OFFLIST: Charter and draft submission deadlines Thread-Index: AcvY3xxRidrclXorQneDCia7IxcUAwACRlDg References: <643B0A1D1A13AB498304E0BBC8027848030A34AF@S4DE8PSAAQC.mitte.t-com.de><176899.13118.qm@web111411.mail.gq1.yahoo.com><643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de> <20110302.223818.02880386.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 02 Mar 2011 14:55:49.0811 (UTC) FILETIME=[EB600830:01CBD8E9] Cc: multimob@ietf.org Subject: Re: [multimob] OFFLIST: Charter and draft submission deadlines 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, 02 Mar 2011 14:54:53 -0000 Dear Hitoshi, Thank you for the comments. AFAIU the AMT draft the usage of IGMP/MLD = messages for managing groups is already foreseen there. And the AMT = solution does also apply for mobility with change of AMT Gateway (like = MAG) since it considers the case where the gateway that initially sent = the AMT Request dynamically changes its IP address as does occur e.g. = due to a link change in wireless networks. Corresponding teardown = messages are defined which would support at least 'a kind of' = seamlessness. And it is already a WG document and could be regarded as 'existing = approach' ... Just to include it in the consideration (whether it is an = optimum solution has to be evaluated). And since any AMT relay (not only one at the LMA site) can be used it = would enable local routing, no? But how would you estimate the messaging effort - perhaps that would be = a show stopper? Thanks! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda Gesendet: Mittwoch, 2. M=E4rz 2011 14:38 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: [multimob] OFFLIST: Charter and draft submission deadlines Hi Dirk, > Hopefully I understand the AMT draft well enough - currently I think > that an enhancement of PMIP entities with AMT functionality would > allow for similar optimizations as proposed: >=20 > Each MAG with multicast subscribing MNs attached behaves as an AMT > Gateway which has already established via a three way handshake a > tunnel to AMT Relay or does so on subcription of a MN - similar to = an > M-Tunnel set-up as proposed in = [I-D.asaeda-multimob-pmip6-extension]. Well, AMT establishes a bi-directional tunnel between AMT gateway and relay. This concept is similar to a bi-directional tunnel establishment between LMA and MAG. Therefore one may think all proposals using bi-directional tunnel look similar to the AMT at this point. However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT does not solve the fundamental problems, such as seamless handover and local routing. Also, an AMT gateway should have the IGMP/MLD proxy functionality. This means, if MAG acts as an MLD proxy having a bi-directional tunnel as proposed in the base solution, AMT is not necessary. AMT is a protocol that simply establishes a bi-directional tunnel bridging non-native multicast networks without explicit tunnel setup. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Wed Mar 2 19:28:24 2011 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 8BCAE3A692B for ; Wed, 2 Mar 2011 19:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 yDrxRUGRkbhF for ; Wed, 2 Mar 2011 19:28:23 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 907933A6927 for ; Wed, 2 Mar 2011 19:28:23 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:225:ff:feee:626f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 57662278085; Thu, 3 Mar 2011 12:28:59 +0900 (JST) Date: Thu, 03 Mar 2011 12:28:58 +0900 (JST) Message-Id: <20110303.122858.159094410.asaeda@sfc.wide.ad.jp> To: Dirk.von-Hugo@telekom.de From: Hitoshi Asaeda In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de> References: <643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de> <20110302.223818.02880386.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] OFFLIST: Charter and draft submission deadlines 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, 03 Mar 2011 03:28:24 -0000 Hi Dirk, > Thank you for the comments. AFAIU the AMT draft the usage of > IGMP/MLD messages for managing groups is already foreseen > there. I cannot understand what you imply here, but I try to explain the following statements. > And the AMT solution does also apply for mobility with change > of AMT Gateway (like MAG) since it considers the case where the > gateway that initially sent the AMT Request dynamically changes its > IP address as does occur e.g. due to a link change in wireless > networks. Corresponding teardown messages are defined which would > support at least 'a kind of' seamlessness. I think you are talking about a failover mechanism of AMT gateway. If we assume MN acts as an AMT gateway, it'd be possible for the MN to spontaneously switch to a different AMT relay due to its link failure detection. But this is not our assumption; MNs should not be obliged to install some additional functions. Moreover, if all MNs themselves act as AMT gateways, they (all MNs) must *directly* establish their own bi-dir tunnels to LMA acting as an AMT relay. On the other hand, we may be able to consider the case that MAG acts as an AMT gateway, and this is the case I've explained. However, in this situation, the MAG acting as an AMT gateway does not support handover or context transfer for each downstream MN. = > And it is already a WG document and could be regarded as 'existing > approach' ... Just to include it in the consideration (whether it is > an optimum solution has to be evaluated). > = > And since any AMT relay (not only one at the LMA site) can be used > it would enable local routing, no? In my thought, this is not local routing, but "AMT relay selection by the anycast mechanism". There is no routing dependency here. Regards, -- Hitoshi Asaeda > But how would you estimate the messaging effort - perhaps that would > be a show stopper? > = > Thanks! > = > Best regards > Dirk > = > -----Urspr=FCngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda > Gesendet: Mittwoch, 2. M=E4rz 2011 14:38 > An: von Hugo, Dirk > Cc: multimob@ietf.org > Betreff: Re: [multimob] OFFLIST: Charter and draft submission deadlin= es > = > Hi Dirk, > = >> Hopefully I understand the AMT draft well enough - currently I think= >> that an enhancement of PMIP entities with AMT functionality would >> allow for similar optimizations as proposed: >> = >> Each MAG with multicast subscribing MNs attached behaves as an AM= T >> Gateway which has already established via a three way handshake a= >> tunnel to AMT Relay or does so on subcription of a MN - similar t= o an >> M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extensi= on]. > = > Well, AMT establishes a bi-directional tunnel between AMT gateway and= > relay. This concept is similar to a bi-directional tunnel > establishment between LMA and MAG. Therefore one may think all > proposals using bi-directional tunnel look similar to the AMT at this= > point. > However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT > does not solve the fundamental problems, such as seamless handover an= d > local routing. > Also, an AMT gateway should have the IGMP/MLD proxy functionality. > This means, if MAG acts as an MLD proxy having a bi-directional tunne= l > as proposed in the base solution, AMT is not necessary. > = > AMT is a protocol that simply establishes a bi-directional tunnel > bridging non-native multicast networks without explicit tunnel setup.= > = > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Thu Mar 3 01:33:26 2011 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 4FE313A6964 for ; Thu, 3 Mar 2011 01:33:26 -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 XofcfNc7FdkH for ; Thu, 3 Mar 2011 01:33:25 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 8A3FF3A68AF for ; Thu, 3 Mar 2011 01:33:23 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail51.telekom.de with ESMTP; 03 Mar 2011 10:34:22 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 10:34: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: Thu, 3 Mar 2011 10:34:21 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20110303.122858.159094410.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [multimob]: Charter and draft submission deadlines Thread-Index: AcvZUyZhj7XSo2uQQI6KCjp2Dfvz5wAL08xg References: <643B0A1D1A13AB498304E0BBC80278480310EFA1@S4DE8PSAAQC.mitte.t-com.de><20110302.223818.02880386.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de> <20110303.122858.159094410.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 03 Mar 2011 09:34:22.0696 (UTC) FILETIME=[2DC59680:01CBD986] Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Dirk.von-Hugo@telekom.de List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 09:33:26 -0000 Dear Hitoshi, Thanks for your answer - and sorry for additional questions, = unfortunately I am not the Multicast expert ;-( Please see my comments inline ...=20 Best regards Dirk Hi Dirk, > Thank you for the comments. AFAIU the AMT draft the usage of > IGMP/MLD messages for managing groups is already foreseen > there. I cannot understand what you imply here, but I try to explain the following statements. =3D> I just referred to the AMT draft saying =20 If the gateway is serving as a local router, it SHOULD also function as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD host-mode interface being the AMT pseudo-interface. =3D> So the AMT approach should be in line with our charter. =20 > And the AMT solution does also apply for mobility with change > of AMT Gateway (like MAG) since it considers the case where the > gateway that initially sent the AMT Request dynamically changes its > IP address as does occur e.g. due to a link change in wireless > networks. Corresponding teardown messages are defined which would > support at least 'a kind of' seamlessness. I think you are talking about a failover mechanism of AMT gateway. If we assume MN acts as an AMT gateway, it'd be possible for the MN to spontaneously switch to a different AMT relay due to its link failure detection. But this is not our assumption; MNs should not be obliged to install some additional functions. Moreover, if all MNs themselves act as AMT gateways, they (all MNs) must *directly* establish their own bi-dir tunnels to LMA acting as an AMT relay. =3D> I agree that we should not modify the MN for mobility support as we = focus on PMIP! On the other hand, we may be able to consider the case that MAG acts as an AMT gateway, and this is the case I've explained. However, in this situation, the MAG acting as an AMT gateway does not support handover or context transfer for each downstream MN.=20 =3D> Right, the pure AMT gateway does not, but can't we assume a = combined MAG & AMT Gateway which can manage both - provide handover and = mobility towards the MNs and control a separate Multicast tunnel towards = the AMT relay for minimizing multiple packets downstream from the LMAs? > And it is already a WG document and could be regarded as 'existing > approach' ... Just to include it in the consideration (whether it is > an optimum solution has to be evaluated). >=20 > And since any AMT relay (not only one at the LMA site) can be used > it would enable local routing, no? In my thought, this is not local routing, but "AMT relay selection by the anycast mechanism". There is no routing dependency here. =3D> From formal wording you may be right - but isn't the effect a = similar one, when the AMT Gateway discovers the 'optimum relay' ... Or = does the anycast mechanism exclude the detection of a best suited local = MR? Or even require extension of the Relay Discovery message - then of = course the advantage of an 'existing approach' is no longer valid! =3D> Thanks for your patience in advance ;-) Regards, -- Hitoshi Asaeda > But how would you estimate the messaging effort - perhaps that would > be a show stopper? >=20 > Thanks! >=20 > Best regards > Dirk >=20 > -----Urspr=FCngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda > Gesendet: Mittwoch, 2. M=E4rz 2011 14:38 > An: von Hugo, Dirk > Cc: multimob@ietf.org > Betreff: Re: [multimob] OFFLIST: Charter and draft submission = deadlines >=20 > Hi Dirk, >=20 >> Hopefully I understand the AMT draft well enough - currently I think >> that an enhancement of PMIP entities with AMT functionality would >> allow for similar optimizations as proposed: >>=20 >> Each MAG with multicast subscribing MNs attached behaves as an AMT >> Gateway which has already established via a three way handshake a >> tunnel to AMT Relay or does so on subcription of a MN - similar to = an >> M-Tunnel set-up as proposed in = [I-D.asaeda-multimob-pmip6-extension]. >=20 > Well, AMT establishes a bi-directional tunnel between AMT gateway and > relay. This concept is similar to a bi-directional tunnel > establishment between LMA and MAG. Therefore one may think all > proposals using bi-directional tunnel look similar to the AMT at this > point. > However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT > does not solve the fundamental problems, such as seamless handover and > local routing. > Also, an AMT gateway should have the IGMP/MLD proxy functionality. > This means, if MAG acts as an MLD proxy having a bi-directional tunnel > as proposed in the base solution, AMT is not necessary. >=20 > AMT is a protocol that simply establishes a bi-directional tunnel > bridging non-native multicast networks without explicit tunnel setup. >=20 > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Thu Mar 3 02:22:47 2011 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 B2F643A69A2 for ; Thu, 3 Mar 2011 02:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] 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 Clmtwf-MIu+1 for ; Thu, 3 Mar 2011 02:22:46 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 4DEF43A68E3 for ; Thu, 3 Mar 2011 02:22:46 -0800 (PST) Received: from localhost (hapro.sfc.wide.ad.jp [203.178.143.166]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 61F0A278076; Thu, 3 Mar 2011 19:23:48 +0900 (JST) Date: Thu, 03 Mar 2011 19:23:48 +0900 (JST) Message-Id: <20110303.192348.127777724.asaeda@sfc.wide.ad.jp> To: Dirk.von-Hugo@telekom.de From: Hitoshi Asaeda In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> References: <643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de> <20110303.122858.159094410.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 03 Mar 2011 10:22:47 -0000 >> Thank you for the comments. AFAIU the AMT draft the usage of >> IGMP/MLD messages for managing groups is already foreseen >> there. > = > I cannot understand what you imply here, but I try to explain the > following statements. > = > =3D> I just referred to the AMT draft saying > = > If the gateway is serving as a local router, it SHOULD also functio= n > as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD= > host-mode interface being the AMT pseudo-interface. Ok, then as I previously said; > Also, an AMT gateway should have the IGMP/MLD proxy functionality. It means, if I simplify the spec, AMT gateway provides a tunneling protocol *having* the IGMP/MLD proxy function. If MAG already sets up a tunnel between LMA, then MAG only needs the IGMP/MLD function (i.e. no tunneling protocol required). > =3D> So the AMT approach should be in line with our charter. In my mind, the basic IGMP/MLD proxy solution suffices your demand at the same level. >> And the AMT solution does also apply for mobility with change >> of AMT Gateway (like MAG) since it considers the case where the >> gateway that initially sent the AMT Request dynamically changes its >> IP address as does occur e.g. due to a link change in wireless >> networks. Corresponding teardown messages are defined which would >> support at least 'a kind of' seamlessness. > = > I think you are talking about a failover mechanism of AMT gateway. > If we assume MN acts as an AMT gateway, it'd be possible for the MN t= o > spontaneously switch to a different AMT relay due to its link failure= > detection. But this is not our assumption; MNs should not be obliged > to install some additional functions. Moreover, if all MNs themselves= > act as AMT gateways, they (all MNs) must *directly* establish their > own bi-dir tunnels to LMA acting as an AMT relay. > = > =3D> I agree that we should not modify the MN for mobility support as= > we focus on PMIP! Right. > On the other hand, we may be able to consider the case that MAG acts > as an AMT gateway, and this is the case I've explained. However, in > this situation, the MAG acting as an AMT gateway does not support > handover or context transfer for each downstream MN. = > = > =3D> Right, the pure AMT gateway does not, but can't we assume a > combined MAG & AMT Gateway which can manage both - provide > handover and mobility towards the MNs and control a separate > Multicast tunnel towards the AMT relay for minimizing multiple > packets downstream from the LMAs? = In your scenario, MAG (acting an AMT gateway) is the tunnel end-point, and what is another tunnel end point (acting an AMT relay)? It must be always LMA, right? Then again, if we already set up MAG-LMA tunnel by the basic solution or PMIP extension or whatever, why we need AMT? >> And it is already a WG document and could be regarded as 'existing >> approach' ... Just to include it in the consideration (whether it is= >> an optimum solution has to be evaluated). >> = >> And since any AMT relay (not only one at the LMA site) can be used >> it would enable local routing, no? > = > In my thought, this is not local routing, but "AMT relay selection > by the anycast mechanism". There is no routing dependency here. > = > =3D> From formal wording you may be right - but isn't the effect a > similar one, when the AMT Gateway discovers the 'optimum relay' > ... Or does the anycast mechanism exclude the detection of a best > suited local MR? Or even require extension of the Relay Discovery > message - then of course the advantage of an 'existing approach' i= s > no longer valid! = AMT gateway discovers the optimam relay? "The optimam relay" and "best suited local MR" you are saying seems not LMA. This breaks the current LMA-MAG consolidation, no? It is beyond the scope, I bet. > =3D> Thanks for your patience in advance ;-) No problem.;) Regards, -- Hitoshi Asaeda = = >> But how would you estimate the messaging effort - perhaps that would= >> be a show stopper? >> = >> Thanks! >> = >> Best regards >> Dirk >> = >> -----Urspr=FCngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im= Auftrag von Hitoshi Asaeda >> Gesendet: Mittwoch, 2. M=E4rz 2011 14:38 >> An: von Hugo, Dirk >> Cc: multimob@ietf.org >> Betreff: Re: [multimob] OFFLIST: Charter and draft submission deadli= nes >> = >> Hi Dirk, >> = >>> Hopefully I understand the AMT draft well enough - currently I thin= k >>> that an enhancement of PMIP entities with AMT functionality would >>> allow for similar optimizations as proposed: >>> = >>> Each MAG with multicast subscribing MNs attached behaves as an A= MT >>> Gateway which has already established via a three way handshake = a >>> tunnel to AMT Relay or does so on subcription of a MN - similar = to an >>> M-Tunnel set-up as proposed in [I-D.asaeda-multimob-pmip6-extens= ion]. >> = >> Well, AMT establishes a bi-directional tunnel between AMT gateway an= d >> relay. This concept is similar to a bi-directional tunnel >> establishment between LMA and MAG. Therefore one may think all >> proposals using bi-directional tunnel look similar to the AMT at thi= s >> point. >> However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT >> does not solve the fundamental problems, such as seamless handover a= nd >> local routing. >> Also, an AMT gateway should have the IGMP/MLD proxy functionality. >> This means, if MAG acts as an MLD proxy having a bi-directional tunn= el >> as proposed in the base solution, AMT is not necessary. >> = >> AMT is a protocol that simply establishes a bi-directional tunnel >> bridging non-native multicast networks without explicit tunnel setup= .= >> = >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Thu Mar 3 04:23:29 2011 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 D7C563A677E for ; Thu, 3 Mar 2011 04:23:29 -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 GIIptQXjeyG7 for ; Thu, 3 Mar 2011 04:23:28 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 9C4FD3A6947 for ; Thu, 3 Mar 2011 04:23:22 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail81.telekom.de with ESMTP; 03 Mar 2011 13:24: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.4675); Thu, 3 Mar 2011 13:24: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: Thu, 3 Mar 2011 13:24:03 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20110303.192348.127777724.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [multimob]: Charter and draft submission deadlines Thread-Index: AcvZjaoKixMR2QMcRwOt2Uy/PPLvZwADd3mA References: <643B0A1D1A13AB498304E0BBC80278480310F03C@S4DE8PSAAQC.mitte.t-com.de><20110303.122858.159094410.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> <20110303.192348.127777724.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 03 Mar 2011 12:24:04.0279 (UTC) FILETIME=[E277DC70:01CBD99D] Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 03 Mar 2011 12:23:30 -0000 Dear Hitoshi, So if I understand you correctly you are saying that=20 - AMT approach via tunneling and MLD proxy adds no new advantage to PMIP = tunnel and moreover doesn't save effort =20 - in case of AMT relay is no LMA (as for local or direct routing) this = is again more complex than just adding MR capability to MAG - because = local routing only applies when the multicast source is within the PMIP = domain. For any content outside PMIP domain the M-LMA is the better = (i.e. more optimum and PMIP consistent) choice. That would rule out AMT approach for Route Optimization in case of = PMIP-Multimob ... Just being curious: May the AMT approach be a way to extend Multimob to = non-PMIP?? Since we have in the charter also =20 It is possible but not required that the solutions are applicable = also for Mobile IPv6 (MIPv6) based networks. Thanks again and Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp]=20 Gesendet: Donnerstag, 3. M=E4rz 2011 11:24 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: AW: AW: [multimob]: Charter and draft submission deadlines >> Thank you for the comments. AFAIU the AMT draft the usage of >> IGMP/MLD messages for managing groups is already foreseen >> there. >=20 > I cannot understand what you imply here, but I try to explain the > following statements. >=20 > =3D> I just referred to the AMT draft saying > =20 > If the gateway is serving as a local router, it SHOULD also function > as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD > host-mode interface being the AMT pseudo-interface. Ok, then as I previously said; > Also, an AMT gateway should have the IGMP/MLD proxy functionality. It means, if I simplify the spec, AMT gateway provides a tunneling protocol *having* the IGMP/MLD proxy function. If MAG already sets up a tunnel between LMA, then MAG only needs the IGMP/MLD function (i.e. no tunneling protocol required). > =3D> So the AMT approach should be in line with our charter. In my mind, the basic IGMP/MLD proxy solution suffices your demand at the same level. >> And the AMT solution does also apply for mobility with change >> of AMT Gateway (like MAG) since it considers the case where the >> gateway that initially sent the AMT Request dynamically changes its >> IP address as does occur e.g. due to a link change in wireless >> networks. Corresponding teardown messages are defined which would >> support at least 'a kind of' seamlessness. >=20 > I think you are talking about a failover mechanism of AMT gateway. > If we assume MN acts as an AMT gateway, it'd be possible for the MN to > spontaneously switch to a different AMT relay due to its link failure > detection. But this is not our assumption; MNs should not be obliged > to install some additional functions. Moreover, if all MNs themselves > act as AMT gateways, they (all MNs) must *directly* establish their > own bi-dir tunnels to LMA acting as an AMT relay. >=20 > =3D> I agree that we should not modify the MN for mobility support as > we focus on PMIP! Right. > On the other hand, we may be able to consider the case that MAG acts > as an AMT gateway, and this is the case I've explained. However, in > this situation, the MAG acting as an AMT gateway does not support > handover or context transfer for each downstream MN.=20 >=20 > =3D> Right, the pure AMT gateway does not, but can't we assume a > combined MAG & AMT Gateway which can manage both - provide > handover and mobility towards the MNs and control a separate > Multicast tunnel towards the AMT relay for minimizing multiple > packets downstream from the LMAs?=20 In your scenario, MAG (acting an AMT gateway) is the tunnel end-point, and what is another tunnel end point (acting an AMT relay)? It must be always LMA, right? Then again, if we already set up MAG-LMA tunnel by the basic solution or PMIP extension or whatever, why we need AMT? >> And it is already a WG document and could be regarded as 'existing >> approach' ... Just to include it in the consideration (whether it is >> an optimum solution has to be evaluated). >>=20 >> And since any AMT relay (not only one at the LMA site) can be used >> it would enable local routing, no? >=20 > In my thought, this is not local routing, but "AMT relay selection > by the anycast mechanism". There is no routing dependency here. >=20 > =3D> From formal wording you may be right - but isn't the effect a > similar one, when the AMT Gateway discovers the 'optimum relay' > ... Or does the anycast mechanism exclude the detection of a best > suited local MR? Or even require extension of the Relay Discovery > message - then of course the advantage of an 'existing approach' is > no longer valid!=20 AMT gateway discovers the optimam relay? "The optimam relay" and "best suited local MR" you are saying seems not LMA. This breaks the current LMA-MAG consolidation, no? It is beyond the scope, I bet. > =3D> Thanks for your patience in advance ;-) No problem.;) Regards, -- Hitoshi Asaeda =20 =20 >> But how would you estimate the messaging effort - perhaps that would >> be a show stopper? >>=20 >> Thanks! >>=20 >> Best regards >> Dirk >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda >> Gesendet: Mittwoch, 2. M=E4rz 2011 14:38 >> An: von Hugo, Dirk >> Cc: multimob@ietf.org >> Betreff: Re: [multimob] OFFLIST: Charter and draft submission = deadlines >>=20 >> Hi Dirk, >>=20 >>> Hopefully I understand the AMT draft well enough - currently I think >>> that an enhancement of PMIP entities with AMT functionality would >>> allow for similar optimizations as proposed: >>>=20 >>> Each MAG with multicast subscribing MNs attached behaves as an = AMT >>> Gateway which has already established via a three way handshake a >>> tunnel to AMT Relay or does so on subcription of a MN - similar = to an >>> M-Tunnel set-up as proposed in = [I-D.asaeda-multimob-pmip6-extension]. >>=20 >> Well, AMT establishes a bi-directional tunnel between AMT gateway and >> relay. This concept is similar to a bi-directional tunnel >> establishment between LMA and MAG. Therefore one may think all >> proposals using bi-directional tunnel look similar to the AMT at this >> point. >> However, as described in [I-D.asaeda-multimob-pmip6-extension], AMT >> does not solve the fundamental problems, such as seamless handover = and >> local routing. >> Also, an AMT gateway should have the IGMP/MLD proxy functionality. >> This means, if MAG acts as an MLD proxy having a bi-directional = tunnel >> as proposed in the base solution, AMT is not necessary. >>=20 >> AMT is a protocol that simply establishes a bi-directional tunnel >> bridging non-native multicast networks without explicit tunnel setup. >>=20 >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Thu Mar 3 06:24:34 2011 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 D18883A67F9 for ; Thu, 3 Mar 2011 06:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.588 X-Spam-Level: X-Spam-Status: No, score=-97.588 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, SARE_RECV_IP_222000=1.508, USER_IN_WHITELIST=-100] 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 cFgN4YpwatVa for ; Thu, 3 Mar 2011 06:24:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CB9F73A68AD for ; Thu, 3 Mar 2011 06:24:33 -0800 (PST) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 49A4127809F; Thu, 3 Mar 2011 23:25:38 +0900 (JST) Date: Thu, 03 Mar 2011 23:25:34 +0900 (JST) Message-Id: <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> To: Dirk.von-Hugo@telekom.de From: Hitoshi Asaeda In-Reply-To: <643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> <20110303.192348.127777724.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> X-Mailer: Mew version 6.2.51 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] : Charter and draft submission deadlines 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, 03 Mar 2011 14:24:35 -0000 > So if I understand you correctly you are saying that > - AMT approach via tunneling and MLD proxy adds no new advantage to > PMIP tunnel and moreover doesn't save effort Yes. > - in case of AMT relay is no LMA (as for local or direct routing) > this is again more complex than just adding MR capability to MAG - > because local routing only applies when the multicast source is > within the PMIP domain. For any content outside PMIP domain the > M-LMA is the better (i.e. more optimum and PMIP consistent) choice. M-LMA means multicast enabled LMA? If so, yes. > That would rule out AMT approach for Route Optimization in case of > PMIP-Multimob ... > > Just being curious: May the AMT approach be a way to extend Multimob > to non-PMIP?? Since we have in the charter also > > It is possible but not required that the solutions are applicable > also for Mobile IPv6 > (MIPv6) based networks. I think it is possible to use AMT in MIPv6. But in this case, I don't think any AMT or MIPv6 protocol modification is necessary. (This means, AMT can just cooperate with MIPv6 without any extension because MN having the AMT gateway function would simply discover an appropriate AMT relay and attach to it.) Regards, -- Hitoshi Asaeda > Thanks again and > > Best regards > Dirk From behcetsarikaya@yahoo.com Thu Mar 3 15:56:41 2011 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 F2E4E3A6823 for ; Thu, 3 Mar 2011 15:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74] 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 Q6vx7Kpw0hFe for ; Thu, 3 Mar 2011 15:56:40 -0800 (PST) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by core3.amsl.com (Postfix) with SMTP id 5B91E3A6816 for ; Thu, 3 Mar 2011 15:56:40 -0800 (PST) Received: from [98.139.91.67] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 23:57:46 -0000 Received: from [98.139.91.27] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 23:57:46 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 03 Mar 2011 23:57:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 25203.35271.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 17062 invoked by uid 60001); 3 Mar 2011 23:57:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299196665; bh=/Q5UWRHtsnZFr7Cyw3YY6WLBsOTU7GLcmaKUZXNNDZ4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=U/DMxssmOVa5SBVvjOlb48MFfxETV6SmWxKblrSS8lGIYyFeVSDD1J170hNS9IL2BwttpZo90gZJe0kaGuXiLRx+yxyQ8QAxHaOj2vcTqhuw3D8gQ0AxlUsUGRabDaOIVjASBxykhtLY+qWZwiZBVZyeTWAZhD5h/uto+/s2h4s= 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=xghtBdxm54O5Z5//F2WgBayC49+Zic1BD0OzsThkFq5Ii8Lsy8XXaWiLRod+nfgZvug+wFqgOMgFt8BVmBo9EcJJNRqnDRHArkUWpY4/2EJdhx8ZLSZesNHMbecYuLOq3+YeH8KCXrz6/FrEqmlwI352sVmg7fPbfEuh435na7c=; Message-ID: <519499.17047.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: MeUsXYMVM1nh_LkKLjERfLMXOPNl3UXS_TgJqtboNszhIWp MNi14JLlfEsYFYC_exP_WV_Qvr0cH8kbQ565myJC9sKOVsT33Z28zQ.Zr9oq 2hCe.1ZvgSbYt0720nntCZPZfhgNW9zRty9AD_9RPGMuiZJHHJsHwskzzeAd T3A_GiM0k5RXOvl3zWIcbHTeYSI8aNwsl8tnPyCZaN5sXFHDUYrrxWcTK3Wf vJMMnA0fLhVB07OkyBrjwCEnY58sHY4Jv.l5F2yyeTUyGyj3tr98gC_onm05 y9tzK5xn1IQTB_nX5sGj9RrElSGwYo7EU.zAt_rmGAA6jZepWCkAuJBzoyfm EMxOpNIupWAqeOK174HFX3JgQ8i5VVmv0QvtuxQB83D2yZKqTf8acJDms6Yg ZyzCxM2VZWd8- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 03 Mar 2011 15:57:45 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 Date: Thu, 3 Mar 2011 15:57:45 -0800 (PST) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Agenda 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: Thu, 03 Mar 2011 23:56:41 -0000 Folks, A very early version of Multimob agenda is now online: http://www.ietf.org/proceedings/80/agenda/multimob.html Regards, Chairs From Dirk.von-Hugo@telekom.de Fri Mar 4 04:04:31 2011 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 A45D53A6994 for ; Fri, 4 Mar 2011 04:04:31 -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 XSe5uAtzw5Fg for ; Fri, 4 Mar 2011 04:04:30 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8388E3A68A2 for ; Fri, 4 Mar 2011 04:04:30 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 04 Mar 2011 13:05:34 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 13:05:34 +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, 4 Mar 2011 13:05:33 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC8027848031741C0@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: AW: [multimob]: Charter and draft submission deadlines Thread-Index: AcvZruOjejXtpBmLTI6xwzGs+qTfLwAtDh8w References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de><20110303.192348.127777724.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 04 Mar 2011 12:05:34.0240 (UTC) FILETIME=[773F1A00:01CBDA64] Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 04 Mar 2011 12:04:31 -0000 Thanks, Hitoshi, So I think I will prepare a corresponding draft for the agenda item as = suggested by Behcet, and include you as co-author, if you don't bother? Concerning the mentioned 'MN having the AMT gateway function' that might = result in a big functionality set on a usually small, power- and size = limited MN ... For a NEMO router this is surely appropriate, but for a = pure single-customer operated MN perhaps a reduced lite-AMT version = would be a better approach, what do you think? Thanks and best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp]=20 Gesendet: Donnerstag, 3. M=E4rz 2011 15:26 An: von Hugo, Dirk Cc: multimob@ietf.org Betreff: Re: AW: AW: AW: [multimob]: Charter and draft submission = deadlines > So if I understand you correctly you are saying that=20 > - AMT approach via tunneling and MLD proxy adds no new advantage to > PMIP tunnel and moreover doesn't save effort =20 Yes. > - in case of AMT relay is no LMA (as for local or direct routing) > this is again more complex than just adding MR capability to MAG - > because local routing only applies when the multicast source is > within the PMIP domain. For any content outside PMIP domain the > M-LMA is the better (i.e. more optimum and PMIP consistent) choice. M-LMA means multicast enabled LMA? If so, yes. > That would rule out AMT approach for Route Optimization in case of > PMIP-Multimob ... >=20 > Just being curious: May the AMT approach be a way to extend Multimob > to non-PMIP?? Since we have in the charter also > =20 > It is possible but not required that the solutions are applicable > also for Mobile IPv6 > (MIPv6) based networks. I think it is possible to use AMT in MIPv6. But in this case, I don't think any AMT or MIPv6 protocol modification is necessary. (This means, AMT can just cooperate with MIPv6 without any extension because MN having the AMT gateway function would simply discover an appropriate AMT relay and attach to it.) Regards, -- Hitoshi Asaeda > Thanks again and >=20 > Best regards > Dirk=20 From sijeon79@gmail.com Mon Mar 7 03:29:40 2011 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 17F5A3A6944 for ; Mon, 7 Mar 2011 03:29:40 -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 SyUdpDKQGI+j for ; Mon, 7 Mar 2011 03:29:39 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 34E893A635F for ; Mon, 7 Mar 2011 03:29:39 -0800 (PST) Received: by pwi5 with SMTP id 5so1162459pwi.31 for ; Mon, 07 Mar 2011 03:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole; bh=0DaRb9lRNbc/iz7L1kZOGh2cya6rY1ziU/wYuYw4ru4=; b=gwsEtvAidVDzwUDj43NgUPOUFfmzwjfmDwtCyzrxSrw4NTCsZCI1kW7XusS52TtrhP wvzzcOS8sSp48iEYHQej7jSQyg1+5toxkica2Nkqm4lO7EErt1dBSw3p0JzWhsq4UDOZ wVQuM232O02dgoVppoI/6WOtcQjDseJAe7M5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=nRtKIv3ezBen2X2v/R45QrWr5jr1nk7VtZLtIiSxWliu44nDiZqDgzMjEAxRZjWk44 TJMdH5u/FxajQ+MfaGEltg2bLTR1BCv51yba88nsUxoJsNEklyi6xN2wGy7PtC0bRADn w8B2ArEF+XD4HQhISPftwLZZDEzpWChYkKzQU= Received: by 10.142.195.3 with SMTP id s3mr3282728wff.39.1299497451388; Mon, 07 Mar 2011 03:30:51 -0800 (PST) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id w32sm4300501wfh.19.2011.03.07.03.30.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 03:30:50 -0800 (PST) From: "Seil Jeon" To: Date: Mon, 7 Mar 2011 20:30:44 +0900 Message-ID: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvcsifJG+bFoXV5QoyGKUgUY20UXAACOA7g X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Subject: [multimob] FW: New Version Notification for draft-sijeon-multimob-direct-routing-pmip6-00 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, 07 Mar 2011 11:29:40 -0000 Hello, multimob folks, We submitted revised draft for direct routing architecture.This draft is derived and revised from [I-D.sijeon-multimob-mms-pmip6] as re-chartered MULTIMOB WG description. We gave a simple comparison with base solution and dedicated LMA approach. http://datatracker.ietf.org/doc/draft-sijeon-multimob-direct-routing- pmip6/?include_text=1 Best Regards, Seil Jeon -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, March 07, 2011 7:25 PM To: sijeon@dcn.ssu.ac.kr Cc: yhkim@dcn.ssu.ac.kr Subject: New Version Notification for draft-sijeon-multimob-direct-routing- pmip6-00 A new version of I-D, draft-sijeon-multimob-direct-routing-pmip6-00.txt has been successfully submitted by Seil Jeon and posted to the IETF repository. Filename: draft-sijeon-multimob-direct-routing-pmip6 Revision: 00 Title: PMIPv6 Multicasting Support using Native Infrastructure Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 12 Abstract: To support IP multicasting in PMIPv6 domain, [I-D.ietf-multimob- pmipv6- base-solution] has been determined as a base solution. This solution requires all the LMA to forward multicast packets to MAG via PMIPv6 tunnel. This approach creates a tunnel convergence problem. To resolve the issue, the current MULTIMOB WG charter is trying to draw a solution about how to separate multicasting routing from a mobility anchor. As an effective solution, we propose the direct routing approach that makes the direct connection between MAG and multicast router. The advantages of the proposed direct routing solution are compared with the base solution and dedicated LMA approach. This draft is derived and revised from [I- D.sijeon-multimob-mms-pmip6] as re-chartered MULTIMOB WG description. The IETF Secretariat. From hurryon@gmail.com Mon Mar 7 07:40:25 2011 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 568B63A67EE for ; Mon, 7 Mar 2011 07:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 TgpLDAzymJcV for ; Mon, 7 Mar 2011 07:40:24 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 66A2A3A67E2 for ; Mon, 7 Mar 2011 07:40:24 -0800 (PST) Received: by vxg33 with SMTP id 33so4490286vxg.31 for ; Mon, 07 Mar 2011 07:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ccjzTlP4OFCLqqke1ovSaWNCjppWjspxF/ei5aul76U=; b=unx5h0MDTbYvKFYThawX3zpXqWM1fp/iTy9VU5Q7xl7uHJZr91W/oyDvcZXQ7sG0E9 TsZS36VWzTYTuvHEKxPY9wdp5sfNpTxYCs97IYvTSVsCwQVRn92s7vx4nT5Nnfw1BJF3 obNdJZzqwPsjWqEpE3k03F0nSyHedlvxJ5ow8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; b=iqn6i2J0qBcDgBJrvZ7UEnHU2KPRvcyRcRQHZwXvwwb2KXFKneuDrpZb8BotuDS/vp aJXoD1NrRbq/pO9DQwHBTQBNiW3x9rV+p8qaIA+y0VWFw3n0jMgsx92M2YQLXMVw/k3m LQBVUMOD3cBOHxhTUK9CXzDeSHiJq/AMs9uuY= Received: by 10.52.100.65 with SMTP id ew1mr2151380vdb.183.1299512497643; Mon, 07 Mar 2011 07:41:37 -0800 (PST) MIME-Version: 1.0 Sender: hurryon@gmail.com Received: by 10.52.169.39 with HTTP; Mon, 7 Mar 2011 07:41:14 -0800 (PST) From: Jong-Hyouk Lee Date: Mon, 7 Mar 2011 16:41:14 +0100 X-Google-Sender-Auth: 7GvAeIC1nVXsCb5pdTd4O9Y_pw4 Message-ID: To: multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf3071ce9ecd9fca049de6545c Cc: Thierry Ernst Subject: [multimob] NEMO related text in draft-von-hugo-multimob-ro-compa-00. 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, 07 Mar 2011 15:40:25 -0000 --20cf3071ce9ecd9fca049de6545c Content-Type: text/plain; charset=UTF-8 Hello, Dirk. Could you explicitly why the AMT approach may be appropriate for NEMO multicast support? "However, a generally more complex NEMO [RFC3963] Mobile Router should have the capability to host also the AMT Gateway functionality and serve a set of nodes (LFN, MNN,...) with multicast traffic so that the AMT approach [I-D.ietf-mboned-auto-multicast] may be appropriate for such NEMO MultiMob support." In addition, what does "NEMO MultiMob support" mean? Are you referring any mechanism that supports NEMO (network mobility) based on PMIPv6 entities? According to the description of MultiMob WG, it is also weird to me. "The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener mobility. The group will work on extensions of Proxy Mobile IPv6 to improve its capability to handle multicast efficiently." Cheers. -- IMARA Team, INRIA, France. Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random. #email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr #webpage: https://sites.google.com/site/hurryon/ --20cf3071ce9ecd9fca049de6545c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Dirk.

Could you explicitly why the AMT approach may be approp= riate for NEMO multicast support?

"However, a generally more co= mplex NEMO [RFC3963] Mobile Router should have the capability to host also = the AMT Gateway functionality and serve a set of nodes (LFN, MNN,...) with = multicast traffic so that the AMT approach [I-D.ietf-mboned-auto-multicast]= may be appropriate for such NEMO MultiMob support."

In addition, what does "NEMO MultiMob support" mean? Are you = referring any mechanism that supports NEMO (network mobility) based on PMIP= v6 entities?

According to the description of MultiMob WG, it is also= weird to me.

"The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/ML= Dv2 protocols and listener mobility. The group will work on extensions of P= roxy Mobile IPv6 to improve its capability to handle multicast efficiently.= "

Cheers.

--
IMARA Team, INRIA, France.
Jon= g-Hyouk Lee, living somewhere between /dev/null and /dev/random.

#em= ail: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/
--20cf3071ce9ecd9fca049de6545c-- From stig@venaas.com Mon Mar 7 11:17:58 2011 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 189A73A67F4 for ; Mon, 7 Mar 2011 11:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 FR1yCuNwe8fi for ; Mon, 7 Mar 2011 11:17:57 -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 EE0963A67E2 for ; Mon, 7 Mar 2011 11:17:56 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4] (unknown [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4]) by ufisa.uninett.no (Postfix) with ESMTPSA id 44FAC8026; Mon, 7 Mar 2011 20:19:09 +0100 (CET) Message-ID: <4D752FA6.6020307@venaas.com> Date: Mon, 07 Mar 2011 11:19:02 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hitoshi Asaeda References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de> <20110303.192348.127777724.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [multimob] : Charter and draft submission deadlines 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, 07 Mar 2011 19:17:58 -0000 On 3/3/2011 6:25 AM, Hitoshi Asaeda wrote: >> So if I understand you correctly you are saying that >> - AMT approach via tunneling and MLD proxy adds no new advantage to >> PMIP tunnel and moreover doesn't save effort > > Yes. I'm not sure how useful AMT is to us either. If we just use AMT as it is, then I'm inclined to think of it as local multicast support. Multicast is somehow provided separate from the PMIP infrastructure. That is, does it make much difference to us from a protocol point of view whether MAG receives multicast natively from local routers or whether it is tunneled with the help of AMT or some other mechanism from a router somewhere that supports multicast? How exactly the multicast is received doesn't matter much to us unless it somehow relates to PMIP and/or mobility. The provider deploying PMIP and multicast can pretty much choose this independently and make different choices. I'm interested in hearing though if there are particular benefits with AMT, or ways it can fit with e.g. PMIP. But at least so far, I'm not so sure. I think AMT is pretty cool and has its use, just not sure how it applies to us. It may also be a concern that there are very few implementations and little deployment so far. I'm hoping that may change. Stig >> - in case of AMT relay is no LMA (as for local or direct routing) >> this is again more complex than just adding MR capability to MAG - >> because local routing only applies when the multicast source is >> within the PMIP domain. For any content outside PMIP domain the >> M-LMA is the better (i.e. more optimum and PMIP consistent) choice. > > M-LMA means multicast enabled LMA? If so, yes. > >> That would rule out AMT approach for Route Optimization in case of >> PMIP-Multimob ... >> >> Just being curious: May the AMT approach be a way to extend Multimob >> to non-PMIP?? Since we have in the charter also >> >> It is possible but not required that the solutions are applicable >> also for Mobile IPv6 >> (MIPv6) based networks. > > I think it is possible to use AMT in MIPv6. But in this case, I don't > think any AMT or MIPv6 protocol modification is necessary. (This > means, AMT can just cooperate with MIPv6 without any extension because > MN having the AMT gateway function would simply discover an > appropriate AMT relay and attach to it.) > > Regards, > -- > Hitoshi Asaeda > >> Thanks again and >> >> Best regards >> Dirk > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Mon Mar 7 11:26:04 2011 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 9BA723A67F4 for ; Mon, 7 Mar 2011 11:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 7pc9ZsZ2cGkd for ; Mon, 7 Mar 2011 11:26:03 -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 6E5773A67E2 for ; Mon, 7 Mar 2011 11:26:03 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4] (unknown [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4]) by ufisa.uninett.no (Postfix) with ESMTPSA id EE4FF8026; Mon, 7 Mar 2011 20:27:12 +0100 (CET) Message-ID: <4D75318F.7000009@venaas.com> Date: Mon, 07 Mar 2011 11:27:11 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de><20110303.192348.127777724.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848031741C0@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848031741C0@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 07 Mar 2011 19:26:04 -0000 On 3/4/2011 4:05 AM, Dirk.von-Hugo@telekom.de wrote: > Thanks, Hitoshi, > So I think I will prepare a corresponding draft for the agenda item as suggested by Behcet, and include you as co-author, if you don't bother? > > Concerning the mentioned 'MN having the AMT gateway function' that might result in a big functionality set on a usually small, power- and size limited MN ... For a NEMO router this is surely appropriate, but for a pure single-customer operated MN perhaps a reduced lite-AMT version would be a better approach, what do you think? I was assuming the MAG was the gateway. AMT can certainly be implemented in hosts, and could be in a MN. In that case, what can we do? In the access network and wrt PMIP, wouldn't we only see unicast traffic? It would be a reasonable solution if there was no multicast support in the network (locally nor PMIP), but we are trying to do something better. It would also result in waste of bandwidth, losing the benefit of multicast. Stig > Thanks and best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > Gesendet: Donnerstag, 3. März 2011 15:26 > An: von Hugo, Dirk > Cc: multimob@ietf.org > Betreff: Re: AW: AW: AW: [multimob]: Charter and draft submission deadlines > >> So if I understand you correctly you are saying that >> - AMT approach via tunneling and MLD proxy adds no new advantage to >> PMIP tunnel and moreover doesn't save effort > > Yes. > >> - in case of AMT relay is no LMA (as for local or direct routing) >> this is again more complex than just adding MR capability to MAG - >> because local routing only applies when the multicast source is >> within the PMIP domain. For any content outside PMIP domain the >> M-LMA is the better (i.e. more optimum and PMIP consistent) choice. > > M-LMA means multicast enabled LMA? If so, yes. > >> That would rule out AMT approach for Route Optimization in case of >> PMIP-Multimob ... >> >> Just being curious: May the AMT approach be a way to extend Multimob >> to non-PMIP?? Since we have in the charter also >> >> It is possible but not required that the solutions are applicable >> also for Mobile IPv6 >> (MIPv6) based networks. > > I think it is possible to use AMT in MIPv6. But in this case, I don't > think any AMT or MIPv6 protocol modification is necessary. (This > means, AMT can just cooperate with MIPv6 without any extension because > MN having the AMT gateway function would simply discover an > appropriate AMT relay and attach to it.) > > Regards, > -- > Hitoshi Asaeda > >> Thanks again and >> >> Best regards >> Dirk > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Mon Mar 7 14:52:05 2011 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 71DB03A6407 for ; Mon, 7 Mar 2011 14:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 WC4MsvMjv1Tv for ; Mon, 7 Mar 2011 14:52:04 -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 BF6BB3A6955 for ; Mon, 7 Mar 2011 14:52:03 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4] (unknown [IPv6:2001:420:4:ea0c:d8aa:670d:3d52:a9b4]) by ufisa.uninett.no (Postfix) with ESMTPSA id ED56A802E; Mon, 7 Mar 2011 23:53:15 +0100 (CET) Message-ID: <4D7561D9.4080803@venaas.com> Date: Mon, 07 Mar 2011 14:53:13 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110223.111952.31587963.asaeda@sfc.wide.ad.jp> <20110223.112945.92529548.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110223.112945.92529548.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] revision of igmp/mld optimization draft 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, 07 Mar 2011 22:52:05 -0000 Hi I like the latest revision. I have some thoughts on unicast queries. As is discussed in appendix A you can send IP unicast queries. Another approach which I think would be OK, is for say 802.11 to send IP multicast queries to host's unicast L2 addresses, see RFC 6085. One concern with 802.11 is that there are no re-transmissions of lost multicast packets, but there are for unicast. This means that multicast packets are more likely to get lost than unicast. When using unicast for the general queries (at layer 2, not necessarily IP unicast), you can then maybe lower the robustness variable. Stig From Dirk.von-Hugo@telekom.de Tue Mar 8 00:42:03 2011 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 195553A684A for ; Tue, 8 Mar 2011 00:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 igcE-auQ5ncW for ; Tue, 8 Mar 2011 00:42:02 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 464BF3A67F5 for ; Tue, 8 Mar 2011 00:42:01 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 08 Mar 2011 09:43:13 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 09:43:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDD6C.DCCD759D" Date: Tue, 8 Mar 2011 09:43:13 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784803174542@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] NEMO related text in draft-von-hugo-multimob-ro-compa-00. Thread-Index: Acvc3i37j+AObFKaT6qfis95rI76TgAjWd5Q References: From: To: , X-OriginalArrivalTime: 08 Mar 2011 08:43:14.0411 (UTC) FILETIME=[DCFF33B0:01CBDD6C] Cc: thierry.ernst@inria.fr Subject: Re: [multimob] NEMO related text in draft-von-hugo-multimob-ro-compa-00. 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, 08 Mar 2011 08:42:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDD6C.DCCD759D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Jong-Hyouk, thanks for the comment and reaction to our new draft = http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-ro-compa-00.t= xt=20 The text is perhaps not clear enough - instead of AMT proposing for = PMIP-based Multicast it should indicate that AMT approach might work = better (i.e. more efficient) for client MIP approach in setting up a = dedicated multicast tunnel. And while a MIP6 terminal might be not = capable of the additional functionalities a NEMO router serving a subnet = of subscribers might benefit from AMT.=20 And since the charter also says=20 It is possible but not required that the solutions are applicable also for Mobile IPv6 (MIPv6) based networks. we looked at NEMO which _might_ be seen as extension of MIPv6 ;-) Therefore the connection - and no, we don't request PMIP for NEMO. Thanks and best regards Dirk=20 =20 ________________________________ Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Jong-Hyouk Lee Gesendet: Montag, 7. M=E4rz 2011 16:41 An: multimob@ietf.org Cc: Thierry Ernst Betreff: [multimob] NEMO related text in = draft-von-hugo-multimob-ro-compa-00. Hello, Dirk. Could you explicitly why the AMT approach may be appropriate for NEMO = multicast support? "However, a generally more complex NEMO [RFC3963] Mobile Router should = have the capability to host also the AMT Gateway functionality and serve = a set of nodes (LFN, MNN,...) with multicast traffic so that the AMT = approach [I-D.ietf-mboned-auto-multicast] may be appropriate for such = NEMO MultiMob support." In addition, what does "NEMO MultiMob support" mean? Are you referring = any mechanism that supports NEMO (network mobility) based on PMIPv6 = entities? According to the description of MultiMob WG, it is also weird to me. "The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 = protocols and listener mobility. The group will work on extensions of = Proxy Mobile IPv6 to improve its capability to handle multicast = efficiently." Cheers.=20 --=20 IMARA Team, INRIA, France.=20 Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random. #email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) = fr #webpage: https://sites.google.com/site/hurryon/ ------_=_NextPart_001_01CBDD6C.DCCD759D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Jong-Hyouk,
thanks for the comment and reaction to our new = draft http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-r= o-compa-00.txt 
The text is perhaps not clear enough - instead = of AMT=20 proposing for PMIP-based Multicast it should indicate that AMT approach = might=20 work better (i.e. more efficient) for client MIP approach in setting up = a=20 dedicated multicast tunnel. And while a MIP6 terminal might be not = capable of=20 the additional functionalities a NEMO router serving a subnet of = subscribers=20 might benefit from AMT.
And since the charter also says =
It is = possible=20 but
   not required that the solutions are applicable also = for=20 Mobile IPv6
   (MIPv6) based networks.
we looked at NEMO which _might_ be seen as = extension of=20 MIPv6 ;-)

Therefore=20 the connection  - and no, we don't request PMIP for=20 NEMO.
Thanks=20 and best regards

Dirk

 

Von: multimob-bounces@ietf.org=20 [mailto:multimob-bounces@ietf.org] Im Auftrag von Jong-Hyouk=20 Lee
Gesendet: Montag, 7. M=E4rz 2011 16:41
An:=20 multimob@ietf.org
Cc: Thierry Ernst
Betreff: = [multimob] NEMO=20 related text in = draft-von-hugo-multimob-ro-compa-00.

Hello, Dirk.

Could you explicitly why the AMT approach = may be=20 appropriate for NEMO multicast support?

"However, a generally = more=20 complex NEMO [RFC3963] Mobile Router should have the capability to host = also the=20 AMT Gateway functionality and serve a set of nodes (LFN, MNN,...) with = multicast=20 traffic so that the AMT approach [I-D.ietf-mboned-auto-multicast] may be = appropriate for such NEMO MultiMob support."

In addition, what = does "NEMO=20 MultiMob support" mean? Are you referring any mechanism that supports = NEMO=20 (network mobility) based on PMIPv6 entities?

According to the = description=20 of MultiMob WG, it is also weird to me.

"The scope of work will = be=20 limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener = mobility. The=20 group will work on extensions of Proxy Mobile IPv6 to improve its = capability to=20 handle multicast efficiently."

Cheers.

-- =
IMARA=20 Team, INRIA, France.
Jong-Hyouk Lee, living somewhere between = /dev/null and=20 /dev/random.

#email: hurryon (at) gmail (dot) com || = jong-hyouk.lee (at)=20 inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/
------_=_NextPart_001_01CBDD6C.DCCD759D-- From Dirk.von-Hugo@telekom.de Tue Mar 8 01:37:39 2011 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 637B63A67D7 for ; Tue, 8 Mar 2011 01:37:39 -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 jNwP7eQMItTa for ; Tue, 8 Mar 2011 01:37:38 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id C11333A67AC for ; Tue, 8 Mar 2011 01:37:36 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Mar 2011 10:38:47 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 10:38:46 +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, 8 Mar 2011 10:38:46 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784803174599@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4D75318F.7000009@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] : Charter and draft submission deadlines Thread-Index: Acvc/anzb2rFNDS/SLGGfZjb6ySgnAAdaT2Q References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de><20110303.192348.127777724.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848031741C0@S4DE8PSAAQC.mitte.t-com.de> <4D75318F.7000009@venaas.com> From: To: X-OriginalArrivalTime: 08 Mar 2011 09:38:46.0999 (UTC) FILETIME=[9F5FC670:01CBDD74] Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 08 Mar 2011 09:37:39 -0000 Dear Stig, As you may have detected we meanwhile have submitted a draft at = http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-ro-compa-00.t= xt in which we also resume that AMT for PMIP would not make too much = sense (neither MN nor MAG), but that 'Client-MIP6' hosts or (mobile) = routers might be a possible use case for AMT deployment ... If one = understands the charter in the sense that the non-PMIP application is = foreseen only as add-on to a PMIP case, then this may not be in the = focus of our WG now ;-( Is that a unanimous understanding? Thanks and best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: Stig Venaas [mailto:stig@venaas.com]=20 Gesendet: Montag, 7. M=E4rz 2011 20:27 An: von Hugo, Dirk Cc: asaeda@sfc.wide.ad.jp; multimob@ietf.org Betreff: Re: [multimob] : Charter and draft submission deadlines On 3/4/2011 4:05 AM, Dirk.von-Hugo@telekom.de wrote: > Thanks, Hitoshi, > So I think I will prepare a corresponding draft for the agenda item as = suggested by Behcet, and include you as co-author, if you don't bother? > > Concerning the mentioned 'MN having the AMT gateway function' that = might result in a big functionality set on a usually small, power- and = size limited MN ... For a NEMO router this is surely appropriate, but = for a pure single-customer operated MN perhaps a reduced lite-AMT = version would be a better approach, what do you think? I was assuming the MAG was the gateway. AMT can certainly be implemented in hosts, and could be in a MN. In that case, what can we do? In the access network and wrt PMIP, wouldn't we only see unicast traffic? It would be a reasonable solution if there was no multicast support in the network (locally nor PMIP), but we are trying to do something better. It would also result in waste of bandwidth, losing the benefit of multicast. Stig > Thanks and best regards > Dirk > > -----Urspr=FCngliche Nachricht----- > Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > Gesendet: Donnerstag, 3. M=E4rz 2011 15:26 > An: von Hugo, Dirk > Cc: multimob@ietf.org > Betreff: Re: AW: AW: AW: [multimob]: Charter and draft submission = deadlines > >> So if I understand you correctly you are saying that >> - AMT approach via tunneling and MLD proxy adds no new advantage to >> PMIP tunnel and moreover doesn't save effort > > Yes. > >> - in case of AMT relay is no LMA (as for local or direct routing) >> this is again more complex than just adding MR capability to MAG - >> because local routing only applies when the multicast source is >> within the PMIP domain. For any content outside PMIP domain the >> M-LMA is the better (i.e. more optimum and PMIP consistent) choice. > > M-LMA means multicast enabled LMA? If so, yes. > >> That would rule out AMT approach for Route Optimization in case of >> PMIP-Multimob ... >> >> Just being curious: May the AMT approach be a way to extend Multimob >> to non-PMIP?? Since we have in the charter also >> >> It is possible but not required that the solutions are applicable >> also for Mobile IPv6 >> (MIPv6) based networks. > > I think it is possible to use AMT in MIPv6. But in this case, I don't > think any AMT or MIPv6 protocol modification is necessary. (This > means, AMT can just cooperate with MIPv6 without any extension because > MN having the AMT gateway function would simply discover an > appropriate AMT relay and attach to it.) > > Regards, > -- > Hitoshi Asaeda > >> Thanks again and >> >> Best regards >> Dirk > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Wed Mar 9 14:47:02 2011 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 8F9833A6AF6 for ; Wed, 9 Mar 2011 14:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 K1lt4P7LLGfa for ; Wed, 9 Mar 2011 14:47:01 -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 BE4C63A6768 for ; Wed, 9 Mar 2011 14:47:00 -0800 (PST) Received: from [10.33.12.92] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9D6517FFB; Wed, 9 Mar 2011 23:48:15 +0100 (CET) Message-ID: <4D7803AC.6050608@venaas.com> Date: Wed, 09 Mar 2011 14:48:12 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <643B0A1D1A13AB498304E0BBC80278480310F150@S4DE8PSAAQC.mitte.t-com.de><20110303.192348.127777724.asaeda@sfc.wide.ad.jp><643B0A1D1A13AB498304E0BBC802784803173FD6@S4DE8PSAAQC.mitte.t-com.de> <20110303.232534.205325634.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848031741C0@S4DE8PSAAQC.mitte.t-com.de> <4D75318F.7000009@venaas.com> <643B0A1D1A13AB498304E0BBC802784803174599@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784803174599@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] : Charter and draft submission deadlines 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, 09 Mar 2011 22:47:02 -0000 On 3/8/2011 1:38 AM, Dirk.von-Hugo@telekom.de wrote: > Dear Stig, > As you may have detected we meanwhile have submitted a draft at http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-ro-compa-00.txt in which we also resume that AMT for PMIP would not make too much sense (neither MN nor MAG), but that 'Client-MIP6' hosts or (mobile) routers might be a possible use case for AMT deployment ... If one understands the charter in the sense that the non-PMIP application is foreseen only as add-on to a PMIP case, then this may not be in the focus of our WG now ;-( Without saying anything conclusive now, I think at least our focus is on PMIP for most of our work. It's great if we come up with things that have a greater applicability though. Also, what work items we may have are a bit restrictive, but as long as it doesn't distract us from working on those, I like us to discuss other related topics. I read the draft maybe a bit too quickly now, but everything there looks quite reasonable, unless I missed something... Stig > Is that a unanimous understanding? > > Thanks and best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: Stig Venaas [mailto:stig@venaas.com] > Gesendet: Montag, 7. März 2011 20:27 > An: von Hugo, Dirk > Cc: asaeda@sfc.wide.ad.jp; multimob@ietf.org > Betreff: Re: [multimob] : Charter and draft submission deadlines > > On 3/4/2011 4:05 AM, Dirk.von-Hugo@telekom.de wrote: >> Thanks, Hitoshi, >> So I think I will prepare a corresponding draft for the agenda item as suggested by Behcet, and include you as co-author, if you don't bother? >> >> Concerning the mentioned 'MN having the AMT gateway function' that might result in a big functionality set on a usually small, power- and size limited MN ... For a NEMO router this is surely appropriate, but for a pure single-customer operated MN perhaps a reduced lite-AMT version would be a better approach, what do you think? > > I was assuming the MAG was the gateway. > > AMT can certainly be implemented in hosts, and could be in a MN. In that > case, what can we do? In the access network and wrt PMIP, wouldn't we > only see unicast traffic? It would be a reasonable solution if there was > no multicast support in the network (locally nor PMIP), but we are > trying to do something better. It would also result in waste of > bandwidth, losing the benefit of multicast. > > Stig > >> Thanks and best regards >> Dirk >> >> -----Ursprüngliche Nachricht----- >> Von: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] >> Gesendet: Donnerstag, 3. März 2011 15:26 >> An: von Hugo, Dirk >> Cc: multimob@ietf.org >> Betreff: Re: AW: AW: AW: [multimob]: Charter and draft submission deadlines >> >>> So if I understand you correctly you are saying that >>> - AMT approach via tunneling and MLD proxy adds no new advantage to >>> PMIP tunnel and moreover doesn't save effort >> >> Yes. >> >>> - in case of AMT relay is no LMA (as for local or direct routing) >>> this is again more complex than just adding MR capability to MAG - >>> because local routing only applies when the multicast source is >>> within the PMIP domain. For any content outside PMIP domain the >>> M-LMA is the better (i.e. more optimum and PMIP consistent) choice. >> >> M-LMA means multicast enabled LMA? If so, yes. >> >>> That would rule out AMT approach for Route Optimization in case of >>> PMIP-Multimob ... >>> >>> Just being curious: May the AMT approach be a way to extend Multimob >>> to non-PMIP?? Since we have in the charter also >>> >>> It is possible but not required that the solutions are applicable >>> also for Mobile IPv6 >>> (MIPv6) based networks. >> >> I think it is possible to use AMT in MIPv6. But in this case, I don't >> think any AMT or MIPv6 protocol modification is necessary. (This >> means, AMT can just cooperate with MIPv6 without any extension because >> MN having the AMT gateway function would simply discover an >> appropriate AMT relay and attach to it.) >> >> Regards, >> -- >> Hitoshi Asaeda >> >>> Thanks again and >>> >>> Best regards >>> Dirk >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob From contreras.uc3m@gmail.com Mon Mar 14 14:44:23 2011 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 2DC273A6BCA for ; Mon, 14 Mar 2011 14:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 j87T0VZJKQAu for ; Mon, 14 Mar 2011 14:44:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A3E843A6A4B for ; Mon, 14 Mar 2011 14:44:21 -0700 (PDT) Received: by eye13 with SMTP id 13so2120291eye.31 for ; Mon, 14 Mar 2011 14:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gjyTxtBYjGb2v/8bRHhbzJJvju+In1l4RfLMCyApcmg=; b=m6wskrj2aMLeGw7LzoOTl3p2G0VUIyCcs1Jnij9qiZTfc8tQU20fDfwqpUFkZjgc3T XKcL2vX/zNNACmYsKTvx7Z0+VSg2pgBQgvp7bplAkpWAqTbzDkLvVY7YvC1PUmg5p00P qA228COtYRwnctgvhtbyX+IzWreHwVlAgss0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f1ZZ5ka2U0emd8BGmMlHFxzbxs5ZcB5moerwzBL4g4aZ079mEdl2+QLKUujR+u/bA/ e/Fm0yxabomcWYj0NeOz9XB8SVTUeBt9KqAVbhiJDZjwI2hTSuqErsSfEi2yUvcn2uA/ Ss+tLmkXOcnR6L1cBss1b3Sa+6hJ92uuG1hyI= MIME-Version: 1.0 Received: by 10.213.17.1 with SMTP id q1mr3349500eba.8.1300139143798; Mon, 14 Mar 2011 14:45:43 -0700 (PDT) Received: by 10.213.4.195 with HTTP; Mon, 14 Mar 2011 14:45:43 -0700 (PDT) In-Reply-To: <20110314213635.A1F173A6BC2@core3.amsl.com> References: <20110314213635.A1F173A6BC2@core3.amsl.com> Date: Mon, 14 Mar 2011 22:45:43 +0100 Message-ID: From: "Luis M. Contreras" To: multimob@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1e164d31f67049e783bca Cc: "Rahman, Akbar" , Ignacio Soto , "Zuniga, Juan Carlos" Subject: [multimob] Fwd: New Version Notification for draft-zuniga-multimob-smspmip-05 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, 14 Mar 2011 21:44:23 -0000 --000e0cd1e164d31f67049e783bca Content-Type: text/plain; charset=ISO-8859-1 Hi all, we have just posted an updated version of the draft proposal for a dedicated multicast LMA architecture. You can find the new draft at the following link: http://www.ietf.org/id/draft-zuniga-multimob-smspmip-05.txt best regards, Luis ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2011/3/14 Subject: New Version Notification for draft-zuniga-multimob-smspmip-05 To: contreras.uc3m@gmail.com Cc: JuanCarlos.Zuniga@interdigital.com, Akbar.Rahman@interdigital.com, cjbc@it.uc3m.es, isoto@dit.upm.es A new version of I-D, draft-zuniga-multimob-smspmip-05.txt has been successfully submitted by Luis M. Contreras and posted to the IETF repository. Filename: draft-zuniga-multimob-smspmip Revision: 05 Title: Support Multicast Services Using Proxy Mobile IPv6 Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 22 Abstract: The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base- solution]. In this document, an enhancement is proposed to the base solution to use a dedicated multicast LMA as the topological anchor point for multicast traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement provides benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployments scenarios. The IETF Secretariat. --000e0cd1e164d31f67049e783bca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
we have just posted an updated version of the draft proposal for a ded= icated multicast LMA architecture.
=A0
You can find the new draft at the following link:
=A0
best regards,
=A0
Luis

---------- Forwarded message ----------
From:= IETF I-D Submission Tool <idsubmission@ietf.org&g= t;
Date: 2011/3/14
Subject: New Version Notification for draft-zuniga-multi= mob-smspmip-05
To: contreras= .uc3m@gmail.com
Cc: JuanCarlos.Zuniga@interdigital.com, Akbar.Rahman@interdigital.com, cjbc@it.uc3m.es, iso= to@dit.upm.es



A new version of I-D, draft-zuniga-multimob-smspmip-05.txt has = been successfully submitted by Luis M. Contreras and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-zuniga-multimob-smspmip
R= evision: =A0 =A0 =A0 =A005
Title: =A0 =A0 =A0 =A0 =A0 Support Multicast Services Using Proxy Mobile IP= v6
Creation_date: =A0 2011-03-14
WG ID: =A0 =A0 =A0 =A0 =A0 Independe= nt Submission
Number_of_pages: 22

Abstract:
The MULTIMOB group= has specified a base solution to support IP
multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base-
so= lution]. In this document, an enhancement is proposed to the base
soluti= on to use a dedicated multicast LMA as the topological anchor
point for = multicast traffic, while the MAG remains as an IGMP/MLD
proxy. This enhancement provides benefits such as reducing multicast
tra= ffic replication and supporting different PMIPv6 deployments
scenarios.<= br>


The IETF Secretariat.



--000e0cd1e164d31f67049e783bca-- From behcetsarikaya@yahoo.com Mon Mar 14 15:37:38 2011 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 AD11D3A6F28 for ; Mon, 14 Mar 2011 15:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klFgs6r3AD3m for ; Mon, 14 Mar 2011 15:37:37 -0700 (PDT) Received: from nm5.bullet.mail.sp2.yahoo.com (nm5.bullet.mail.sp2.yahoo.com [98.139.91.75]) by core3.amsl.com (Postfix) with SMTP id 06C813A6F20 for ; Mon, 14 Mar 2011 15:37:26 -0700 (PDT) Received: from [98.139.91.64] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 14 Mar 2011 22:38:47 -0000 Received: from [98.139.91.21] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 14 Mar 2011 22:38:47 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 14 Mar 2011 22:38:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 519422.83783.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 61129 invoked by uid 60001); 14 Mar 2011 22:38:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300142326; bh=UQ7SkxLa2xXMbSM3bfbzLkyN+UPnv6f7ebikO6ND0/M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=VyeEVZibckv8T+uuYTakq2h8Z9XICZ5bHEgUV2rKgbZATbKZtZ4wFIaTqnf95H1hnvzEtR+K9HLyoKr+Z52ppAJupg3Fb1h/qBX+iA8lIurowIGhS0B9YtmfG8Jvm2mSdRV4QgimTP/VW6NgKwLkn8u+LI7qQ57ao4pM3kwXUUU= 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=tPDadIDeRRDxirkTrjxRlCaD0U0IVUntGb2h6BS5/LG2y7mzJOSWAg04+wMSNap/tKxSIHSmZOjrPzyFUgiYJvsrySo4X6bR5yU//tg6+zZkS4+TepdKWl2rOFSQUcrszpxAHqdoDNt02uBNhZVd5gwSHUv6DRnaRAnfX2XKUtg=; Message-ID: <891866.57450.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: QnaiXakVM1km1Y8ey.FGKDm1Ij2jLUN5Lui.kiG9K9yFi7_ pZT5BvAVfpKRASM3kdNqx.GBdP1S30AnNkklq.6NEXfuZA9peKM194712msF WaiNkQxarBRGSDeAhGTZratwWaWTheEO5EtpyOMfQSBQYMWgrvqDyjrMSuvg _om07R9fk_fFRJGOWpUK9Hybe1ZP_Efdu80oQPQrh31uxZn_yKMtYXYRjrYy Gw42If3RH12drRSWHRlNToFZO4LZBA4xuq1ipdgBdJcgpIGUe8f05Rbo.Goi r9CWVFzCXe1XtWBqdHGXOrHH3OfpGpOGawJwbQpxKGMXpPd8jvIEaTiPeAB2 8AiZaCQaJthmj8oJrp68ekjSy3T.30ARX3VdaLWEtfGnzoYRndFHb.zbZzQQ PmwDar8NblcbP Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Mon, 14 Mar 2011 15:38:46 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Mon, 14 Mar 2011 15:38:46 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Presentations 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, 14 Mar 2011 22:37:38 -0000 Hi all, It seems like the agenda is now finalized. The next step is to post the presentations. Presenters: please submit your presentations to the chairs. Thanks, Chairs From JuanCarlos.Zuniga@InterDigital.com Mon Mar 14 19:27:21 2011 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 097C83A6973 for ; Mon, 14 Mar 2011 19:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HTML_MESSAGE=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 FM3ryeCHikfG for ; Mon, 14 Mar 2011 19:27:16 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id BD96B3A69AA for ; Mon, 14 Mar 2011 19:27:15 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 22:28:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE2B8.B1C094A2" Date: Mon, 14 Mar 2011 22:28:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-zuniga-multimob-smspmip-05 Thread-Index: AcvikS446asY7Te+Q4SF9xAammGjGAAJw4sw References: <20110314213635.A1F173A6BC2@core3.amsl.com> From: "Zuniga, Juan Carlos" To: "Luis M. Contreras" , X-OriginalArrivalTime: 15 Mar 2011 02:28:39.0401 (UTC) FILETIME=[B1BD1590:01CBE2B8] Cc: "Rahman, Akbar" , Ignacio Soto Subject: Re: [multimob] New Version Notification for draft-zuniga-multimob-smspmip-05 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, 15 Mar 2011 02:27:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE2B8.B1C094A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luis, =20 Thanks a lot for taking care of this! =20 Regarding the presentation, Behcet may ask for some slides soon. We should probably make a draft version to highlight the benefits (again) and the latest changes. Regarding the comparison, let's first take a look at the other drafts to evaluate the landscape of the meeting and then let's discuss how we want to proceed. =20 Regards, =20 Juan Carlos =20 From: Luis M. Contreras [mailto:contreras.uc3m@gmail.com]=20 Sent: March 15, 2011 5:46 AM To: multimob@ietf.org Cc: cjbc@it.uc3m.es; Ignacio Soto; Rahman, Akbar; Zuniga, Juan Carlos Subject: Fwd: New Version Notification for draft-zuniga-multimob-smspmip-05 =20 Hi all, =20 we have just posted an updated version of the draft proposal for a dedicated multicast LMA architecture. =20 You can find the new draft at the following link: http://www.ietf.org/id/draft-zuniga-multimob-smspmip-05.txt =20 best regards, =20 Luis ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2011/3/14 Subject: New Version Notification for draft-zuniga-multimob-smspmip-05 To: contreras.uc3m@gmail.com Cc: JuanCarlos.Zuniga@interdigital.com, Akbar.Rahman@interdigital.com, cjbc@it.uc3m.es, isoto@dit.upm.es A new version of I-D, draft-zuniga-multimob-smspmip-05.txt has been successfully submitted by Luis M. Contreras and posted to the IETF repository. Filename: draft-zuniga-multimob-smspmip Revision: 05 Title: Support Multicast Services Using Proxy Mobile IPv6 Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 22 Abstract: The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [I-D.draft-ietf-multimob-pmipv6-base- solution]. In this document, an enhancement is proposed to the base solution to use a dedicated multicast LMA as the topological anchor point for multicast traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement provides benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployments scenarios. The IETF Secretariat. =20 ------_=_NextPart_001_01CBE2B8.B1C094A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Luis,

 

Thanks a lot for taking care  of = this!

 

Regarding the presentation, Behcet may ask for some = slides soon. We should probably make a draft version to highlight the benefits = (again) and the latest changes. Regarding the comparison, let’s first take a = look at the other drafts to evaluate the landscape of the meeting and then = let’s discuss how we want to proceed.

 

Regards,

 

Juan Carlos

 

From:= Luis M. = Contreras [mailto:contreras.uc3m@gmail.com]
Sent: March 15, 2011 5:46 AM
To: multimob@ietf.org
Cc: cjbc@it.uc3m.es; Ignacio Soto; Rahman, Akbar; Zuniga, Juan = Carlos
Subject: Fwd: New Version Notification for draft-zuniga-multimob-smspmip-05

 

Hi all,

 

we have just posted an updated version of the draft = proposal for a dedicated multicast LMA architecture.

 

You can find the new draft at the following = link:

 

best regards,

 

Luis

---------- Forwarded = message ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: 2011/3/14
Subject: New Version Notification for = draft-zuniga-multimob-smspmip-05
To: contreras.uc3m@gmail.com
= Cc: JuanCarlos.Zuniga@inte= rdigital.com, Akbar.Rahman@interdigital.c= om, cjbc@it.uc3m.es, isoto@dit.upm.es



A new version of I-D, draft-zuniga-multimob-smspmip-05.txt has been successfully submitted by Luis M. Contreras and posted to the IETF = repository.

Filename:        draft-zuniga-multimob-smspmip
Revision:        05
Title:           Support Multicast Services = Using Proxy Mobile IPv6
Creation_date:   2011-03-14
WG ID:           Independent Submission
Number_of_pages: 22

Abstract:
The MULTIMOB group has specified a base solution to support IP
multicasting in a PMIPv6 domain = [I-D.draft-ietf-multimob-pmipv6-base-
solution]. In this document, an enhancement is proposed to the base
solution to use a dedicated multicast LMA as the topological anchor
point for multicast traffic, while the MAG remains as an IGMP/MLD
proxy. This enhancement provides benefits such as reducing multicast
traffic replication and supporting different PMIPv6 deployments
scenarios.



The IETF Secretariat.

 

------_=_NextPart_001_01CBE2B8.B1C094A2-- From gaoxlh@gmail.com Tue Mar 15 17:17:33 2011 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 1292A3A6F0E for ; Tue, 15 Mar 2011 17:17:33 -0700 (PDT) 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 siHJQNqmM6Ou for ; Tue, 15 Mar 2011 17:17:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id F04BE3A6A55 for ; Tue, 15 Mar 2011 17:17:19 -0700 (PDT) Received: by vws12 with SMTP id 12so1337202vws.31 for ; Tue, 15 Mar 2011 17:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:x-mailer :mime-version:content-type:content-transfer-encoding; bh=X8Heue4r7u3sv/YGYQepkQbTYlD5phAEcuFS3CvZgOo=; b=Jf0y2cH+iKSJ9+bw1jnqTxGNQT3y54bje8oyrxqgWhqfz/HcflOVj5MYq/jclo3IMe zk6twAANN0ZZmsp6KngJKGIUJ3V39JbqLLzZP6zKHwlSh0Gd9agtikDgVrvyK2+X8iUx 8mhTgZGGoMkXK0kXVfyr6Xoj5Rm0N4BopG8UY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; b=bA8F//1rjmiketCrodEYLPfgkNC6cntTW13Fj5IjTitZIMw3NL32hK34owORoc5VIX ndGcwlFJWOwhABeMh1dpcqDsIK4ytlhOybq7kaaPwFcWMw4ShVN/4VTDqtPoKKJn+tqE 0H7D8Wj7w7xw4jKcL2jp7DU0WO2hp8ehL/OGs= Received: by 10.52.91.230 with SMTP id ch6mr121228vdb.140.1300234725399; Tue, 15 Mar 2011 17:18:45 -0700 (PDT) Received: from gao-PC ([211.71.74.133]) by mx.google.com with ESMTPS id e20sm243124vbz.8.2011.03.15.17.18.42 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 17:18:44 -0700 (PDT) Date: Wed, 16 Mar 2011 08:18:41 +0800 From: "Shuai Gao" To: "multimob" Message-ID: <201103160818390167670@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: shgao Subject: [multimob] New Version Notification for draft-zhang-multimob-msm-02 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, 16 Mar 2011 00:17:33 -0000 Hi all, We have just posted an updated version of the draft proposal for multicast source mobility. You can find the new draft at the following link: http://www.ietf.org/id/draft-zhang-multimob-msm-02.txt Best Regards, Shuai Gao National Engineering Lab for Next Generation Internet Interconnection Devices Beijing Jiaotong University Beijing, China, 100044 gaoxlh@gmail.com 2011-03-16 From behcetsarikaya@yahoo.com Fri Mar 18 15:33:28 2011 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 B0AD83A6A63 for ; Fri, 18 Mar 2011 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 AvaOHCcQ9H4p for ; Fri, 18 Mar 2011 15:33:24 -0700 (PDT) Received: from nm16-vm1.bullet.mail.sp2.yahoo.com (nm16-vm1.bullet.mail.sp2.yahoo.com [98.139.91.211]) by core3.amsl.com (Postfix) with SMTP id 4FA2E3A6A53 for ; Fri, 18 Mar 2011 15:33:24 -0700 (PDT) Received: from [98.139.91.63] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 18 Mar 2011 22:34:51 -0000 Received: from [98.139.91.6] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 18 Mar 2011 22:34:51 -0000 Received: from [127.0.0.1] by omp1006.mail.sp2.yahoo.com with NNFMP; 18 Mar 2011 22:34:51 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 607245.9211.bm@omp1006.mail.sp2.yahoo.com Received: (qmail 87419 invoked by uid 60001); 18 Mar 2011 22:34:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300487691; bh=9Z7vfRBZgWF5VkqGFBcZr2ZhHtnkJVjOd6zkfqIwMzw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=E8cwRsXJkzW2Qsfw1TIKOq1ORIoHSDHHg7Ex0eRJMpYhXtYrYuU+eTkFkkO2NRLOyO1i5VL8OMZ7OjnfrVWXqKPxHK0xpAjLnSrOzRI70PSlm+6r89JcYrWM48HzolcsQsKlBhpbdhkO1sSa2cznJynmyf8yeDIXtoW55kc8ThE= 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; b=pXNxQVkt553HpMdaRcHPj89FtG25JKFi31qAyZnbl7BRPlnv4N3VVXdRP4TcR3B6dA5V7cy/OHwGPllfherrOeFzAVPByrH/nlwhpKbCXe2fgbiV10ZnpKIpnSBIbCkStc2DI5n69Bpr3VgIfvrL13e7+8XsQUxfTeNkR9Z5foU=; Message-ID: <204218.72559.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: SspKLLgVM1l0FAM1mUhu.wg90.ICyeq92X31D6_VVJs5WOK n5859Z2M.GqZ.z8yj5XaMZWSUS4IjAfa5uMMdGfzWAuk6J3QuJHRVobVRGdu pJ4UNcfbitMV2X3IpKvuPKle4ikp8Uqbti4LCrdV9yo1.TBQCOyad6gQY0Tm vCq9Z8qoECyf5zxlVvXs2Ey3Lw.j5qNGZ0ZtaOwgHbwSZd.mECCZXbkLGaei bI75aO5rqZ8kaJMyFfD6SK9dvuOcyxITy64zRsrKXpv3DzV0rWabjVgfMOcX Cgz8UfVVWrjM_EMbKppJSpGfQVxcn.zaUZfDdC6NXsMegATHM3ssxPquBBnf h_185GuicssHXl7.s72WYWhbu0TFaMDmMqJ92H_lgLv9jvZRXcVwSWjLNeDc ACk8f2TWaVqbPnw-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Fri, 18 Mar 2011 15:34:51 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> Date: Fri, 18 Mar 2011 15:34:51 -0700 (PDT) From: Behcet Sarikaya To: Seil Jeon , multimob@ietf.org In-Reply-To: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] FW: New Version Notification for draft-sijeon-multimob-direct-routing-pmip6-00 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, 18 Mar 2011 22:33:28 -0000 Hi Seil, I read your draft. I am confused about Fig. 1. You have one LMA and one MR there. As you explained the tunnel convergence problem occurs due to multiple LMAs. Could there be multiple MRs? Why could MR be not collocated with LMA? How does a multicast data packet sent by MR go to MN? You mentioned native multicasting infrastructure as a requirement. Regards, Behcet > Hello, multimob folks, > > We submitted revised draft for direct routing architecture.This draft is > derived and revised from [I-D.sijeon-multimob-mms-pmip6] as re-chartered > MULTIMOB WG description. > > We gave a simple comparison with base solution and dedicated LMA approach. > > http://datatracker.ietf.org/doc/draft-sijeon-multimob-direct-routing- > pmip6/?include_text=1 > > > Best Regards, > > Seil Jeon > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 07, 2011 7:25 PM > To: sijeon@dcn.ssu.ac.kr > Cc: yhkim@dcn.ssu.ac.kr > Subject: New Version Notification for draft-sijeon-multimob-direct-routing- > pmip6-00 > > > A new version of I-D, draft-sijeon-multimob-direct-routing-pmip6-00.txt has > been successfully submitted by Seil Jeon and posted to the IETF repository. > > Filename: draft-sijeon-multimob-direct-routing-pmip6 > Revision: 00 > Title: PMIPv6 Multicasting Support using Native Infrastructure > Creation_date: 2011-03-07 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > To support IP multicasting in PMIPv6 domain, [I-D.ietf-multimob- pmipv6- > base-solution] has been determined as a base solution. This solution > requires all the LMA to forward multicast packets to MAG via > PMIPv6 tunnel. This approach creates a tunnel convergence problem. To > resolve the issue, the current MULTIMOB WG charter is trying to draw a > solution about how to separate multicasting routing from a mobility anchor. > As an effective solution, we propose the direct routing approach that makes > the direct connection between MAG and multicast router. The advantages of > the proposed direct routing solution are compared with the base solution > and dedicated LMA approach. This draft is derived and revised from [I- > D.sijeon-multimob-mms-pmip6] as re-chartered MULTIMOB WG description. > > > > > The IETF Secretariat. > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From sijeon79@gmail.com Sun Mar 20 21:47:29 2011 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 939293A67A4 for ; Sun, 20 Mar 2011 21:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 80MH5OEqXqEm for ; Sun, 20 Mar 2011 21:47:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4FC423A67A3 for ; Sun, 20 Mar 2011 21:47:28 -0700 (PDT) Received: by iwl42 with SMTP id 42so7108500iwl.31 for ; Sun, 20 Mar 2011 21:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:x-mimeole; bh=L5cASeJMeKQOdcZezEc8dITe4nqtKQ29zybwz452kBk=; b=a9RjdW1uSlFk5z4wymatuNfzQrgHBJkwfsGeF8NvxkAnlOkjNLprH+LYt/rZ9Jt+G/ 2SCwcFwMdD+1nAFQ+T3VhoDGW4d0j7aJBf1Ag9rcqAw/Z1mA6WmTxcrJIauzbjGOT/sD IIRHN0RX1R06EOOuA3Xoh87iu2/8sRSseWdMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:x-mimeole; b=n+EbySJ5m/louLa//Xe9L0/EMIrvDexC3cffFYQywVxplpyfYw7MeY6UGmrZ03ngmS EYSljSXRMT2z7MjgBBD7QVQwSfNq/BgsTGaE6Q5+mPQt11pLAAiOjIljDAHQBomXXDxM 8s/l0yE+Y2UfEZFVHz/H84PCgZ8i/K0eQGgww= Received: by 10.231.117.93 with SMTP id p29mr3744158ibq.126.1300682940257; Sun, 20 Mar 2011 21:49:00 -0700 (PDT) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id d10sm4154444ibb.0.2011.03.20.21.48.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2011 21:48:59 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> <204218.72559.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <204218.72559.qm@web111412.mail.gq1.yahoo.com> Date: Mon, 21 Mar 2011 13:48:42 +0900 Message-ID: <7E42E5F6476E49F3ABD5542AE31DF4AE@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvlvLVjvreCkpM5SpWJcnHdq0yC1ABs9gcw X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-sijeon-multimob-direct-routing-pmip6-00 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, 21 Mar 2011 04:47:29 -0000 Hi Behcet, Please see below. ---- Q. Could there be multiple MRs? A. As you know, the tunnel convergence problem occurs due to tunnel-based multicasting transmission delivered by multiple LMAs. In direct routing architecture, no tunnels are employed. And a MLD client (proxy also) is connected to one MR as you can simply imagine native multicasting architecture. ---- Q. Why could MR be not collocated with LMA? A. Actually, depending on operator's deployment, an MR may be collocated with LMA. The main concept of direct routing is to separate multicasting function on LMA and to reuse native multicasting infrastructure. By doing so, tunnel convergence issue is completely resolved and the burden due to multicasting operation can also be reduced. And as I said before, an MLD client in general is not connected with multiple MRs. The tunnel convergence issue handled in MULTIMOB results from special PMIPv6 architecture. ---- Q. How does a multicast data packet sent by MR go to MN? You mentioned native multicasting infrastructure as a requirement. A. A MAG (MLD proxy) joins to the MR, so the MR sends the multicast packet to the MAG. The MAG knows where to forward multicast packets from its downstream interface. So, the multicast packet is forwarded to MN with multicast address. ---- Best regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Saturday, March 19, 2011 7:35 AM To: Seil Jeon; multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-sijeon- multimob-direct-routing-pmip6-00 Hi Seil, I read your draft. I am confused about Fig. 1. You have one LMA and one MR there. As you explained the tunnel convergence problem occurs due to multiple LMAs. Could there be multiple MRs? Why could MR be not collocated with LMA? How does a multicast data packet sent by MR go to MN? You mentioned native multicasting infrastructure as a requirement. Regards, Behcet > Hello, multimob folks, > > We submitted revised draft for direct routing architecture.This draft > is derived and revised from [I-D.sijeon-multimob-mms-pmip6] as > re-chartered MULTIMOB WG description. > > We gave a simple comparison with base solution and dedicated LMA approach. > > http://datatracker.ietf.org/doc/draft-sijeon-multimob-direct-routing- > pmip6/?include_text=1 > > > Best Regards, > > Seil Jeon > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 07, 2011 7:25 PM > To: sijeon@dcn.ssu.ac.kr > Cc: yhkim@dcn.ssu.ac.kr > Subject: New Version Notification for > draft-sijeon-multimob-direct-routing- > pmip6-00 > > > A new version of I-D, > draft-sijeon-multimob-direct-routing-pmip6-00.txt has been successfully submitted by Seil Jeon and posted to the IETF repository. > > Filename: draft-sijeon-multimob-direct-routing-pmip6 > Revision: 00 > Title: PMIPv6 Multicasting Support using Native Infrastructure > Creation_date: 2011-03-07 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > To support IP multicasting in PMIPv6 domain, [I-D.ietf-multimob- > pmipv6- base-solution] has been determined as a base solution. This > solution requires all the LMA to forward multicast packets to MAG via > PMIPv6 tunnel. This approach creates a tunnel convergence problem. To > resolve the issue, the current MULTIMOB WG charter is trying to draw > a solution about how to separate multicasting routing from a mobility anchor. > As an effective solution, we propose the direct routing approach that > makes the direct connection between MAG and multicast router. The > advantages of the proposed direct routing solution are compared with > the base solution and dedicated LMA approach. This draft is derived > and revised from [I- D.sijeon-multimob-mms-pmip6] as re-chartered MULTIMOB WG description. > > > > > The IETF Secretariat. > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From behcetsarikaya@yahoo.com Mon Mar 21 08:44:45 2011 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 6C1EF28C0E6 for ; Mon, 21 Mar 2011 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 iyEMHJV33Mbd for ; Mon, 21 Mar 2011 08:44:44 -0700 (PDT) Received: from nm20-vm1.bullet.mail.sp2.yahoo.com (nm20-vm1.bullet.mail.sp2.yahoo.com [98.139.91.219]) by core3.amsl.com (Postfix) with SMTP id B452228C0E2 for ; Mon, 21 Mar 2011 08:44:44 -0700 (PDT) Received: from [98.139.91.64] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 15:46:17 -0000 Received: from [98.139.91.51] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 15:46:17 -0000 Received: from [127.0.0.1] by omp1051.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 15:46:17 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 539706.56410.bm@omp1051.mail.sp2.yahoo.com Received: (qmail 58583 invoked by uid 60001); 21 Mar 2011 15:46:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300722377; bh=uOZfLm3daMzrkLA2kUmdeub/wxTAOhioQF4Cp4L1Azo=; 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=zIRqy30mKKumW9lPbw7mQpz/46rfaXmtPEit27gDD7UYSaogTUHYHaX6rEYuKsAgoZxBX76gsTjwPebIkap2DUc8jOLkzPkpyLS0+BoChnsig/ZmmZtqgtcb+h1i+/dYK0HL//GQrwNppzSni81CjAQXbaIFgRArzFiZE1ncht8= 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=1sr//vNb7FymCX0OFGKk4V2vlRvTeD9m8nQ/Yse8zwNZM9/ztFZb+NlQB4DB3ScW096+j2ToRM+WfV6j6j5pD29mh0efJljIEWXmK2S6HKH2+axtSbE+KGD3L6WhBVy6t0iy6opu8DkOFBY2AWkLTuzOgEiHPsp3O7+UN2VxfJw=; Message-ID: <129578.37016.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: TvFhFa4VM1kZggKccj1TbJPXgEqkR_5Fa6A27ZCXzSUR4xB GUMdlEwqXlFh0qCGd9BKQ3UIPQZxRuVPgD.Bc5v71B8MZaO4F51mgWFu1HPZ cwmnXZEDKe9XqAtlgYkB39NzizmLbXxSt.6_alAgBIDcn6lq9meT8wyFtwcM DYnwXzpA18yg9lxtRiBeN9MD_IKCeJg2x16MlN6MrqabDH7IcauMNrVBoJ24 JDAkAOxZvddL59GLMKYEyv16mx9LuIZCqs8TeuqTs31FLX9iDu9p344CqSXj .c6Fdkrc48jdEiexTaAvWURb1ZQSH0YSTZeW2mKanfBwcucWbSFfWqRQvTgU gJAFh3R3tAUuIK0J23YFFwmGfMPmeiQzHbhhbvfc1ALk.l1joE9_iCdol7HP 6eMte8QQlTOm1LA-- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 21 Mar 2011 08:46:16 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> <204218.72559.qm@web111412.mail.gq1.yahoo.com> <7E42E5F6476E49F3ABD5542AE31DF4AE@sijeonPC> Date: Mon, 21 Mar 2011 08:46:16 -0700 (PDT) From: Behcet Sarikaya To: Seil Jeon In-Reply-To: <7E42E5F6476E49F3ABD5542AE31DF4AE@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-sijeon-multimob-direct-routing-pmip6-00 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, 21 Mar 2011 15:44:45 -0000 Hi Seil, > Q. How does a multicast data packet sent by MR go to MN? You mentioned > native multicasting infrastructure as a requirement. > > A. A MAG (MLD proxy) joins to the MR, so the MR sends the multicast packet > to the MAG. > > The MAG knows where to forward multicast packets from its downstream > interface. So, the multicast packet is forwarded to MN with multicast > address. > This is kind of confusing because MAG and LMA are not on the same link in general and your Fig. 1 shows MR at the same level as LMA. However, it seems that you require MR to be on the same link as MAG? Over all, I think that the direct routing corresponds to what is stated in Section 11.3.4 in Mobile IPv6 draft-ietf-mext-rfc3775bis-13.txt In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets. where MAG is the local multicast router and there is MR upstream. Regards, Behcet From behcetsarikaya@yahoo.com Mon Mar 21 14:50:54 2011 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 B786E3A68ED for ; Mon, 21 Mar 2011 14:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 il2WCqd0FSFi for ; Mon, 21 Mar 2011 14:50:53 -0700 (PDT) Received: from nm30-vm1.bullet.mail.sp2.yahoo.com (nm30-vm1.bullet.mail.sp2.yahoo.com [98.139.91.239]) by core3.amsl.com (Postfix) with SMTP id 170043A68EA for ; Mon, 21 Mar 2011 14:50:53 -0700 (PDT) Received: from [98.139.91.63] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 21:52:25 -0000 Received: from [98.139.91.24] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 21:52:25 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 21 Mar 2011 21:52:25 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 317228.23498.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 41815 invoked by uid 60001); 21 Mar 2011 21:52:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300744344; bh=2CkknHlBeisvqcimdE3RiG2MbE9hq0Ps+ln2SaFdxrI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=vkaU/6NrZKDaUnykRYKo2tFHgI+0Eq92wrvcCiu5wPkDD9lrmmF+8Ml9tUFdjr/7Ys1hU65vBg/uhJzoOGIOMPOfcHIiQYtyHTZMPLOVNkH12QZ/kRJUlMPAJPXwvN2L5ZMpX1BUoCF+uGe9N4savryqvMTD5fl4hvEViXWcNng= 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=F1bqrVVhtN/E8eUlSEmS/uUsE538ZGH5SmoK7Sh1hyeSmaqcUlUbso6QVAwrE139e2QclqaWikTQBE1ydwL2tFS4xvUWbXccNESvpJ56RNOSVy/cgXW/XQcEDrBmRCe6tzvd7XJ5nhdlV95WjcRUIucZz7F/YQyH8myRm8oSD8A=; Message-ID: <956246.22143.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: YP_MzrgVM1mGDORfpkvaRa9ruBEpW9UuBTc3mpeYmf4VDWi ZebBHIpSbsSfFGZuZ4Uj4GrYoVPX.IalMF1iXe4efdRyk.TbuiFP5hbtdOSy 1bVMTA7RZL2UIgaPygisXoXG.DXBeTtSrX7QpB5MUq8tI9.vFEbw0G1Cfapo u0o6b8gmkiD1l6oIkEcQLWoqhYm_GvMZyQhx66lj56fXC1J2ZSICkp98XZ_c 4x4tteaxWSiK_v_mN0ieULspZvkG6mP.BAo3X7bRWX8Ku0QeYylM0b6mGmBm he0hY.VEdzZHnKZb_rP6KaHHHrK.AzBdyNx9o6.O2xMyqUKFBdUiMH_VN3XB wXB1Gy_TBH_kq726pssk.zuUpGd2T5txPLRDH1jHaub5f8Sjgef5gnzndarv YYoZVV3Z1H5MWhw-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Mon, 21 Mar 2011 14:52:24 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Mon, 21 Mar 2011 14:52:24 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] draft-asaeda-multimob-pmip6-extension-05 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, 21 Mar 2011 21:50:54 -0000 Hi Hitoshi, I read your draft and have some comments. In section 3.3, you say MN sends MLD Report upon multicast data reception. Why? I think there is something wrong in that sentence. Your draft is long and detailed and on top of that it mentions [9] draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative reference. What I am more curious about is how your draft solves the tunnel convergence problem. I don't think it is the M-Tunnel because as you mentioned M-Tunnel is MAG-LMA tunnel as in [2], i.e. RFC 5213. I don't think it is MAG as PIM-SM router as you mention that operators would not like it. Sorry but I could not find a specific solution proposal in your draft. Maybe I missed something. How relevant your Section 7 is to the tunnel convergence solution? I have a feeling that it is more relevant for handover optimizations work item we have. Regards, Behcet From sijeon79@gmail.com Mon Mar 21 23:57:03 2011 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 6B7963A68EC for ; Mon, 21 Mar 2011 23:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 DDDHTz6lEUMC for ; Mon, 21 Mar 2011 23:57:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9B9173A68E0 for ; Mon, 21 Mar 2011 23:57:02 -0700 (PDT) Received: by pve39 with SMTP id 39so1238547pve.31 for ; Mon, 21 Mar 2011 23:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:x-mimeole:thread-index; bh=P6HGHZrmBKXBUAYnEqS0q6CBS5rMPBXAV1efRFobrYk=; b=dj9qTbbNgq3WGqxJaTUE4oCqBU0fCmR6icByjrcMiGERhBfTdw0rTHQt4HuJQOR6RS ZZ6ZjDDY0VpL4AoWOrTQwE4GPbuphlSSKxdfLlkb3wy8RVp1vNCZSPBuAvzSW9pDrJWs EuUUr4ynS2JiohR/8hUJcI71mpSMV4LRkfULk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :x-mimeole:thread-index; b=PYraUlhevjHeh2jEWvvCZr+3q/fCLdQatrzwHXb9ihdFn3+krJvLK/xUiCKFbx3xY5 BKOJcPzit4oGOdk0Xca4NhMbxN/FzpdB89buDsjcxpup6a/aNB++xCwCsUPXkQ7vJQyW NN1aEx4kvfgoQpgNdBQVlhDbuK0Xcgtl2L9os= Received: by 10.142.247.2 with SMTP id u2mr3621169wfh.107.1300777115743; Mon, 21 Mar 2011 23:58:35 -0700 (PDT) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id 25sm8285819wfb.10.2011.03.21.23.58.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2011 23:58:34 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <0E9EB1BFACE249D3910D0098CC29CCD2@sijeonPC> <204218.72559.qm@web111412.mail.gq1.yahoo.com> <7E42E5F6476E49F3ABD5542AE31DF4AE@sijeonPC> <129578.37016.qm@web111405.mail.gq1.yahoo.com> In-Reply-To: <129578.37016.qm@web111405.mail.gq1.yahoo.com> Date: Tue, 22 Mar 2011 15:58:35 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: Acvn3yCMm90eLX4qSvqb0cXRx1gGxgAVqPhg Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-sijeon-multimob-direct-routing-pmip6-00 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, 22 Mar 2011 06:57:03 -0000 Hi Behcet, Please see below [Seil] -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Tuesday, March 22, 2011 12:46 AM To: Seil Jeon Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification for draft-sijeon- multimob-direct-routing-pmip6-00 Hi Seil, > Q. How does a multicast data packet sent by MR go to MN? You > mentioned > native multicasting infrastructure as a requirement. > > A. A MAG (MLD proxy) joins to the MR, so the MR sends the multicast > packet to the MAG. > > The MAG knows where to forward multicast packets from its > downstream interface. So, the multicast packet is forwarded to MN > with multicast address. > This is kind of confusing because MAG and LMA are not on the same link in general and your Fig. 1 shows MR at the same level as LMA. However, it seems that you require MR to be on the same link as MAG? => [Seil]: This is a reference architecture to see association between entities. And, it does not mean MR is at the same level as LMA. Direct routing solution is based on flat architecture that is different from MAG-LMA of hierarchical association. Over all, I think that the direct routing corresponds to what is stated in Section 11.3.4 in Mobile IPv6 draft-ietf-mext-rfc3775bis-13.txt In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets. where MAG is the local multicast router and there is MR upstream. => [Seil]: In MIPv6, access router is assumed to be multicast router. However, in direct routing solution, a MAG is not multicast router. A MAG has mld proxy function to avoid complexity in MAG. Regards, Seil Jeon From sijeon79@gmail.com Tue Mar 22 01:14:38 2011 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 7050B3A67AA for ; Tue, 22 Mar 2011 01:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 lU7PtBIe5U6c for ; Tue, 22 Mar 2011 01:14:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 889163A67A8 for ; Tue, 22 Mar 2011 01:14:37 -0700 (PDT) Received: by pzk30 with SMTP id 30so1251052pzk.31 for ; Tue, 22 Mar 2011 01:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:x-mailer:x-mimeole:thread-index; bh=eDKgT3E7rYEbLCVk1V0s9Z/3shIK//hL9KhoJem9Cpc=; b=X/CdcYwZD3riTVv5t/X3vtMqgmG8Wf9+yHeld0DyleiI81jzQ9hyvE2d+hLl6PFjDc vVhFLE6z9IvcWku0ryCBLtytqeu1QIVh9k5ntfts0poIuTszFcSbLAIbLR0yreV33c7a n95jsw6Doxd2M7j7igwpqpyxTkD2vVHvU8Nuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :x-mimeole:thread-index; b=GBWOM60OEc0u1V6WteGtFR9RgbeWZRtZz4SWsaQAHUj9cdQQl8TYFL0JiavKRO2MVh msHdJWh7N4o6QWAeJkivLEVJNEt658HSZckzPhfNOdIVjzF/6+VnnIgDpJRGskbeUbwM V7TfoLfwfJvt5bt0HsaK/tVpFhUDegM/VK3v0= Received: by 10.142.250.15 with SMTP id x15mr3963728wfh.187.1300781770557; Tue, 22 Mar 2011 01:16:10 -0700 (PDT) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id d35sm8361033wfj.21.2011.03.22.01.16.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 01:16:09 -0700 (PDT) From: "Seil Jeon" To: Date: Tue, 22 Mar 2011 17:16:10 +0900 Message-ID: <2A4C3E852AC64658B2721708571B0D4E@sijeonPC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CBE8B4.D8D9A290" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcvoaWaj2HWUxo7HRiWJbSc73LEzmA== Subject: [multimob] Discussion on PMIPv6 multicast routing optimization 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, 22 Mar 2011 08:14:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01CBE8B4.D8D9A290 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, multimob all, There have been several drafts for PMIPv6 multicast routing optimization. I think we need more discussions and clear comparison between drafts. Overall, in my opinion, there are two kinds of approaches : dedicated LMA and direct (local) routing. Before the discussion which is good or not, actually I think that both cases are reasonable depending on deployment scenarios. If the contents are located at PMIP domain outside, dedicated LMA approach can be appropriate because PMIP basically uses LMA for traffic anchor point even though it brings about optimization issues (tunneling overhead, complexity on LMA) However, in the case that the contents and contents providers are connected with MAG (locally available case), local routing approach is more suitable solution. Direct (local) routing approach is simple and resolves performance-related issues using native multicasting infrastructure. Actually, in 3GPP SAE, locally content-deliverying without LMA (PDN-GW) is reflected in MBMS architecture of 3GPP SAE (TS 23.246). In operator's perspective, this local available approach can be quite useful regarding service deployment. Certainly, the above are some of my thoughts. If we can see what others think before the prague meeting, it would be great. Regards, Seil Jeon ------=_NextPart_000_001B_01CBE8B4.D8D9A290 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi,=20 multimob all,
 
 
There=20 have been several drafts for PMIPv6 multicast routing optimization. I = think we=20 need more discussions and clear comparison between = drafts.
Overall, in my opinion, there are two kinds = of=20 approaches : dedicated LMA and direct (local) = routing.
 
Before=20 the discussion which is good or not, actually I think that both=20 cases are reasonable depending on deployment=20 scenarios.
 
If the contents are located at PMIP domain = outside,=20 dedicated LMA approach can be appropriate because PMIP basically uses = LMA for=20 traffic anchor point
even though it brings about optimization = issues=20 (tunneling overhead, complexity on LMA)
 
However, in the case that the = contents and=20 contents providers are connected with MAG (locally available case), = local=20 routing approach is more suitable solution.
Direct (local) routing approach is simple and = resolves=20 performance-related issues using native multicasting infrastructure.=20 Actually, in 3GPP SAE, locally content-deliverying without LMA = (PDN-GW) is=20 reflected in MBMS architecture of 3GPP SAE (TS 23.246). In operator's=20 perspective, this local available approach can be quite useful regarding = service=20 deployment.
 
 
Certainly, the above are some of my thoughts. = If we can=20 see what others think before the prague meeting, it would be=20 great.
 
 
Regards,
 
Seil = Jeon
------=_NextPart_000_001B_01CBE8B4.D8D9A290-- From asaeda@sfc.wide.ad.jp Wed Mar 23 11:44:42 2011 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 BE8B23A68BC for ; Wed, 23 Mar 2011 11:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 hKRY53E87MRg for ; Wed, 23 Mar 2011 11:44:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by core3.amsl.com (Postfix) with ESMTP id CAC2F3A68B8 for ; Wed, 23 Mar 2011 11:44:41 -0700 (PDT) Received: from localhost (40.119.71-86.rev.gaoland.net [86.71.119.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6FCF6278165; Thu, 24 Mar 2011 03:46:10 +0900 (JST) Date: Wed, 23 Mar 2011 19:46:07 +0100 (CET) Message-Id: <20110323.194607.39863226.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <956246.22143.qm@web111408.mail.gq1.yahoo.com> References: <956246.22143.qm@web111408.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 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] draft-asaeda-multimob-pmip6-extension-05 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, 23 Mar 2011 18:44:42 -0000 Hi Behcet, > I read your draft and have some comments. > In section 3.3, you say MN sends MLD Report upon multicast data > reception. Why? > I think there is something wrong in that sentence. I cannot understand what's wrong here? > Your draft is long and detailed and on top of that it mentions [9] > draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative > reference. Right, that draft should be informative reference. I'll move it in the next revision. > What I am more curious about is how your draft solves the tunnel convergence > problem. I don't think it is the M-Tunnel because as you mentioned > M-Tunnel is MAG-LMA tunnel as in [2], i.e. RFC 5213. Single M-Tunnel is established between LMA-MAG and dedicated to MLD messages and multicast data transmission. It is shared by all MNs attached to a MAG. It's not established per MN, unlike rfc5213. > I don't think it is MAG as PIM-SM router as you mention that > operators would not > like it. Sorry but I could not find a specific solution proposal in > your draft. > Maybe I missed something. It is one of the possible ways for multicast services in PMIPv6 domain. I cannot find the reason to prohibit PIM-SM capable MAG. In fact, since an incoming interface can be set up by the PIM-SM capable MAG, it gives the chance of localized routing and source mobility without any protocol modification. Giving the possibility of a PIM-SM capable MAG would be rather positive in my feeling. > How relevant your Section 7 is to the tunnel convergence solution? I > have a feeling that it is more relevant for handover optimizations > work item we have. I think sharing single M-Tunnel by all MNs address the tunnel convergence problem. If you don't think so, could you tell me what the problem is? Regarding handover, I believe our proposed extension is not only simple and in line with the standard functions, but effectively provides seamless handover. I don't deny someone will propose other mechanisms or extensions with a different view for the optimization in the later phase, such as proactive handover. But their mechanisms might require more extension or additional functions to give more optimization. Our proposal could be defined as the base extension for them, I guess. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed Mar 23 12:29:40 2011 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 8A5223A68CE for ; Wed, 23 Mar 2011 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 cNPB2bnQSuZB for ; Wed, 23 Mar 2011 12:29:39 -0700 (PDT) Received: from nm13-vm1.bullet.mail.sp2.yahoo.com (nm13-vm1.bullet.mail.sp2.yahoo.com [98.139.91.245]) by core3.amsl.com (Postfix) with SMTP id 9AF123A68CC for ; Wed, 23 Mar 2011 12:29:39 -0700 (PDT) Received: from [98.139.91.62] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 23 Mar 2011 19:31:14 -0000 Received: from [98.139.91.14] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 23 Mar 2011 19:31:14 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 23 Mar 2011 19:31:14 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 21035.86459.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 2203 invoked by uid 60001); 23 Mar 2011 19:31:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300908673; bh=bjTF9v5SRd7N+bWZsO6qjb+EbvuP2E551NWX6GypmEU=; 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=evtcEzmnEauzMcyRznhCm8gP48ssunxHYk8Kynkw9BIqhvIFLEgaIzgWfEBdXw9rTz8eRi7nHjPggmfmJCjjg+/dpt2N0ib4u8Lbd3O3XZAFs0Fz3z9Avbk8J6FPZ8qBtJ8V0bvWA13DZQ0+kYz80KiI9J3N1W+twEEkri/dhO0= 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=liD2wj8xzzkrSnckmFy/rNi5dygh3VJ75QQlfdbR1e4+X6/HfJPFgPalB0G/IS2iWYKAU0kuUCte8B2GRb/ebD+Hq5IEdIn7wysdY1uUbou6EzVc7Bs5xP+8sc0TXunOfQol9plRKRQR4Jt4kiRusSB8stP5mUJR/Sk2eMBMEB8=; Message-ID: <491930.98674.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: rHL.DgEVM1mkHXMGIRvMprDt_0rD1ike4aAFmnklMSu9FvC dBCA- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 23 Mar 2011 12:31:12 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <956246.22143.qm@web111408.mail.gq1.yahoo.com> <20110323.194607.39863226.asaeda@sfc.wide.ad.jp> Date: Wed, 23 Mar 2011 12:31:12 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110323.194607.39863226.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] draft-asaeda-multimob-pmip6-extension-05 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, 23 Mar 2011 19:29:40 -0000 Hi Hitoshi, > Hi Behcet, > > > I read your draft and have some comments. > > In section 3.3, you say MN sends MLD Report upon multicast data > > reception. Why? > > I think there is something wrong in that sentence. > > I cannot understand what's wrong here? May be you meant in order to join a group? > > > Your draft is long and detailed and on top of that it mentions [9] > > draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt as normative > > reference. > > Right, that draft should be informative reference. I'll move it in the > next revision. > > > What I am more curious about is how your draft solves the tunnel convergence > > > problem. I don't think it is the M-Tunnel because as you mentioned > > M-Tunnel is MAG-LMA tunnel as in [2], i.e. RFC 5213. > > Single M-Tunnel is established between LMA-MAG and dedicated to > MLD messages and multicast data transmission. It is shared by all MNs > attached to a MAG. It's not established per MN, unlike rfc5213. see below. > > > I don't think it is MAG as PIM-SM router as you mention that > > operators would not > > like it. Sorry but I could not find a specific solution proposal in > > your draft. > > Maybe I missed something. > > It is one of the possible ways for multicast services in PMIPv6 > domain. I cannot find the reason to prohibit PIM-SM capable MAG. > In fact, since an incoming interface can be set up by the PIM-SM > capable MAG, it gives the chance of localized routing and source > mobility without any protocol modification. > Giving the possibility of a PIM-SM capable MAG would be rather > positive in my feeling. Yes, if PIM-SM can be deployed at all MAGs, tunnel convergence problem won't happen. This is kind of like local routing. > > > How relevant your Section 7 is to the tunnel convergence solution? I > > have a feeling that it is more relevant for handover optimizations > > work item we have. > > I think sharing single M-Tunnel by all MNs address the tunnel > convergence problem. If you don't think so, could you tell me what the > problem is? No because the tunnel convergence problem happens due to multiple LMAs and MNs connected to multiple LMAs joining the same group like G1. Then LMAs deliver multicast data from G1 to the MAG and MAG just replicates the data to each member MN. M-Tunnel does not address this problem. I hope this is clear. > Regarding handover, I believe our proposed extension is not only > simple and in line with the standard functions, but effectively > provides seamless handover. > I don't deny someone will propose other mechanisms or extensions with > a different view for the optimization in the later phase, such as > proactive handover. But their mechanisms might require more extension > or additional functions to give more optimization. Our proposal could > be defined as the base extension for them, I guess. You need to show how relevant it is to the tunnel convergence problem. Right now I cannot see it. Regards, Behcet From asaeda@sfc.wide.ad.jp Thu Mar 24 01:42:39 2011 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 775FB3A683B for ; Thu, 24 Mar 2011 01:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 08RX6rJEKQxC for ; Thu, 24 Mar 2011 01:42:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by core3.amsl.com (Postfix) with ESMTP id A65193A683A for ; Thu, 24 Mar 2011 01:42:38 -0700 (PDT) Received: from localhost (40.119.71-86.rev.gaoland.net [86.71.119.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A90682780B4; Thu, 24 Mar 2011 17:44:08 +0900 (JST) Date: Thu, 24 Mar 2011 09:44:06 +0100 (CET) Message-Id: <20110324.094406.10596817.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <491930.98674.qm@web111416.mail.gq1.yahoo.com> References: <956246.22143.qm@web111408.mail.gq1.yahoo.com> <20110323.194607.39863226.asaeda@sfc.wide.ad.jp> <491930.98674.qm@web111416.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 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] draft-asaeda-multimob-pmip6-extension-05 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, 24 Mar 2011 08:42:39 -0000 Hi Behcet, >> > In section 3.3, you say MN sends MLD Report upon multicast data >> > reception. Why? >> > I think there is something wrong in that sentence. >> >> I cannot understand what's wrong here? > > May be you meant in order to join a group? Ok, then I change it to "when it subscribes a multicast channel". >> > How relevant your Section 7 is to the tunnel convergence solution? I >> > have a feeling that it is more relevant for handover optimizations >> > work item we have. >> >> I think sharing single M-Tunnel by all MNs address the tunnel >> convergence problem. If you don't think so, could you tell me what the >> problem is? > > No because the tunnel convergence problem happens due to multiple > LMAs and MNs > connected to multiple LMAs joining the same group like G1. Then LMAs deliver > multicast data from G1 to the MAG and MAG just replicates the data to each > member MN. > M-Tunnel does not address this problem. Ok, I understand. This consideration may be addressed with various approaches. Our current proposal is in line with the concept of minimum protocol modification, hence I'd propose the following changes. There is a statement in section 5.1; An MLD proxy requires that the upstream and downstream interfaces MUST be statistically configured. As well, MAG MUST configure an upstream interface that is the interface MLD Report messages are sent to LMA and downstream interfaces that are the interfaces MLD Report messages are received from mobile nodes. This upstream interface is the M-Tunnel end-point at the MAG. and I'll append the following sentence; Whether MAG acting as an MLD proxy connects to a single or multiple LMAs, M-Tunnel for the MAG MUST be established with one LMA. Also, I'll change a paragraph in section 5.2 as follows; Because of its implementation or operational costs, operators may not want to support PIM-SM on MAG. However, an MLD proxy requires to statically configure its upstream interface, which is an M-Tunnel as specified in Section 5.1, to receive all multicast data. It also does not allow multiple incoming interfaces. Hence even if MAG acting as an MLD proxy connects to multiple LMAs, it cannot establish with multiple M-Tunnels for each LMA. Therefore, if operators decide to support the case that 1) an upstream interface for the optimized multicast path is NOT an M-Tunnel to LMA but other interface, and should be dynamically selected by MAG according to the optimized routing path, or 2) MAG should establish multiple M-Tunnels for different LMAs, and an incoming interface should be decided by the RPF check, then MAG MUST act as a PIM-SM router. There might be some discussions for this, but I think above sentences would become a reasonable start. I'd appreciate any input, especially from providers and operators. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Mar 24 08:18:07 2011 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 48BE028C120 for ; Thu, 24 Mar 2011 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 0+ptBYuhYFD8 for ; Thu, 24 Mar 2011 08:18:06 -0700 (PDT) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by core3.amsl.com (Postfix) with SMTP id 9445628C11E for ; Thu, 24 Mar 2011 08:18:06 -0700 (PDT) Received: from [98.139.91.69] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:19:41 -0000 Received: from [98.139.91.42] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:19:41 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:19:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 579964.88816.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 76194 invoked by uid 60001); 24 Mar 2011 15:19:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300979981; bh=Cr8Cggk/nOBn4MYOM/+5M9NC6dKjTqhzNjGmADaPiB0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=X01lPUe0xFnu25xVgAVR8uCZTcJPLIV+oC1UgAdmedsVvHc0Agt67Q249B0gYTnEL7RFdMZHBCtuAdJkWnJ82graPlfrFOF7B4xHD1gPO47feoiWmG6FxI+nrzzXJDHzCh6aqIgxnJXlkn/YKMlPbQBVGdf1NlIS/qA9x8h6ZBk= 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=vOEGvUlgEsuGb3GE/XCemV/fo+bX8kgTl1dBqHb3gDsU/Ht30Y9O1+BRoQ1hLmIUvOiEjl53oQiCA9Lclt4DkdZhmzxbID50jdSBnPbUEa3hbxhzMUpOZc9BZD2NE8wICjmrv1VCW2MIl9LQSikC0rlzAAClrs+sR/rsOAQwE20=; Message-ID: <166911.74880.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: Hz81Il4VM1lnRro6MHFl_Wx3LHvC3ARTIybbJfBhxp6oqtQ 5mQxsNwO8FuXrA_81mdj8kq2rh7eU2neO.7kq52Nx1NSkzHKgpkWcFZs5ZCK W0AjVssIe6FH1ue7ekZ2QNxNhlbDhNkKcZTaasTHrp9R4_n3ZvnoE41LtbGm lNVqlvd_JWPFqNLrRMrPgX9v72ppFjlfTCTGn3wesOWzP4aVMZDKbF_3j0WU kX3ZJgqlTi1HmOhG2JUwP7LPJn1xJ99gz_56JjpXRETEI0ve6Bn.729Ydn.h WYZFOkkk_T_8YprJBiIgEAse54OT3SrpgsiT26hcipZeKHbEHpfaZ_DuOGol uLDbDPIl7DMfA.OucKSFQueATYpBI_fOqPDs8kvICFql.iYZYEkEKfv3CHDW GpYNlvdgqRrisQA-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 24 Mar 2011 08:19:41 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Thu, 24 Mar 2011 08:19:41 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , Shuai Gao , multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] draft-asaeda-multimob-pmip6-extension-05 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: Thu, 24 Mar 2011 15:18:07 -0000 Hi Hitoshi, Shuai, Regarding source mobility, in draft-asaeda-multimob-pmip6-extension-05 in the introduction you say: The base solution described in [14] provides options for deploying multicast listener functions in PMIPv6-Domains without modifying mobility and multicast protocol standards. However, in this specification, MAG MUST act as an MLD proxy and hence MUST dedicate a tunnel link between LMA and MAG to an incoming interface for all multicast traffic. This limitation does not allow to use PIM-SM native routing on MAG, does not enable local routing, and does not support source mobility. I think you mean that no source mobility is specified (that's why now we have a work item on this). You do not mean that with MLD proxy in the MAG you can not enable source mobility. Can you please clarify this? Regards, Behcet From behcetsarikaya@yahoo.com Thu Mar 24 08:29:01 2011 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 DA32128C102 for ; Thu, 24 Mar 2011 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 gLYZqGIFF3Z0 for ; Thu, 24 Mar 2011 08:28:58 -0700 (PDT) Received: from nm8.bullet.mail.sp2.yahoo.com (nm8.bullet.mail.sp2.yahoo.com [98.139.91.78]) by core3.amsl.com (Postfix) with SMTP id 0935A28C0F5 for ; Thu, 24 Mar 2011 08:28:58 -0700 (PDT) Received: from [98.139.91.63] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:30:33 -0000 Received: from [98.139.91.12] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:30:33 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 15:30:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 27717.72643.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 31502 invoked by uid 60001); 24 Mar 2011 15:30:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300980632; bh=aWhd3jKBJxaO3lJJOWbJmOL6NVP/dmGe9KVopaGWB0c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ubhimBApkbdO6iYkyC/HlGVSCDX6WsLhdw+A8Q7JNefgZ+PzdUY3HP3CZBFGQgRncFq703oKeAFsGTbII7mc+O3NaShqgV77tJCenNqkLh6YWOS7XTGRW41NIuN+YxtqsY8PH9LiPoMuJvs4d/5iE4p1c2zQ1253JY9i8RXo1v0= 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; b=pSqzgYVw/nPOLopHRjR384IfHIQa0DvuQ/KO6X5F0JadHHAc66rGy6otn8lA0rRjDYRG1P6l3HbG2Zu4arZEALMvzGl94H0P7n/446wadUCM2+4+RDDDnUIAUuUq6/5l+HMcT+XRlvf77pULALKt2ShoXBT0tvKy2YnWsVgKOXc=; Message-ID: <226077.25725.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: SUf1mbcVM1mjXY3gFyZFvuQyOA5GCaHIkj8jOeOOEkyU7OG U4ez8vwfJtlTAE1Niu48sSAbufV_4VBwqMtZzT8n0.VKrKte0r073bPIt8yY 8U7q4qfI1B79L049ZvFZaV0eVPLpcAhnlYFmbo0_WfuBWHFLtXRBJ1bSCkwo 2cYlKAie1JwVtTtsuk4FPHZ_rH0uoC6FA2egRD9shk1Xb.encyXZtGhRB_lr ZZJ.Voz_EHlgeKnVe6ITxBnGL3V_XMXCP7mfAA8zzjGjGejhu1du4ELjYSae 2399b7JrJg8CKBznSp_EXQgLDmVGppsKiKyy82KRLX1mx.DyOBfEhQzrk8Pq eCe5CkpOcP3gTGvWHnZy8JSalksCCFfHJFD_96ycnmBBE73wp26LQNHQUoNA 9.wBbOW77X0VbEw-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 24 Mar 2011 08:30:32 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <891866.57450.qm@web111414.mail.gq1.yahoo.com> Date: Thu, 24 Mar 2011 08:30:32 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: <891866.57450.qm@web111414.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] Presentations 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: Thu, 24 Mar 2011 15:29:01 -0000 Only a few days left to our meeting in Prague. So far we received one presentation. > > Hi all, > It seems like the agenda is now finalized. > The next step is to post the presentations. > > Presenters: please submit your presentations to the chairs. > > Thanks, > > Chairs > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From behcetsarikaya@yahoo.com Thu Mar 24 09:10:51 2011 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 E2BC428C0F8 for ; Thu, 24 Mar 2011 09:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 6bGM9LjnNsyX for ; Thu, 24 Mar 2011 09:10:46 -0700 (PDT) Received: from nm25-vm1.bullet.mail.sp2.yahoo.com (nm25-vm1.bullet.mail.sp2.yahoo.com [98.139.91.229]) by core3.amsl.com (Postfix) with SMTP id 7FA1828C0CE for ; Thu, 24 Mar 2011 09:10:46 -0700 (PDT) Received: from [98.139.91.67] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 16:12:21 -0000 Received: from [98.139.91.40] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 16:12:21 -0000 Received: from [127.0.0.1] by omp1040.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 16:12:21 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 531513.10406.bm@omp1040.mail.sp2.yahoo.com Received: (qmail 540 invoked by uid 60001); 24 Mar 2011 16:12:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300983140; bh=iS+CJXt9kpw+K+M/vau0RVB9hlGmzEv9ITnXViHqOnM=; 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=f5/Mtg/GcfyQwQz7MkiwTJe5scrbNZ/ruAKCiAG4t8Te2p6zKsQnKa7HlXNmldfk1qiHB3ZPGDBPtL3MSouhThaSDj6mRA/G0uGgUI+SvkYAvr0etUVADxLmdAru08aXj7qI9SAG4zNubCwPP3DR5+HwUqD76R+DQe/0qmcqDEQ= 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=WDKzbhVd+np80Zi6Weth9FdjOz9U5I6Bm8anctkr9D2FtnM1kLhcj8cI7boeX9RhpfbqKGi6uArW34Bg25o3C0l7grtmxYC3klLm/DGkObifPcKhlI4abHKXkJFyvJsnXlXmgr12FRVr+h7HwTSfbDlAAuGtWGzg3aEGYXtn8gY=; Message-ID: <555485.90600.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: uddE2Q0VM1kDUjvO9PMs4X5St4MLYPlXyiKUMNj3Ba_paza OTCHzCO95.lTpPb8gCDFDPmL1cU6xZe4sWcJ3fcv9C7PJcVnQiA33k7qZD6W OJSEietM6Ap7BLKPN_9LIFxQhW7o_jqR6081Cz.b.CEITzrL3Th93_MGN6Yf Md10n6Ba0eb.QzgzaLXnGLzCAltPmL8rcyZS72ykZrIgTDg5kfVGZeFIMqVt FxUZ05oQZ1dlp0UQTuDMev6lxI8zTF12nHvNeu3cjJpdBfhkDHjeIO_WY2C8 frH2Pnz3cnAYztDt.sYdPaHJIc9kbxf6OF61cBkXmRNphPChTROO6KEUuOTa T1g6weH9OgAoz6kJMJc6wr3axk5V_R6f0faVH_0WSq6s1IISTXmzikW0NJeI 0F7jU1DAdrCBVLQ-- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Thu, 24 Mar 2011 09:12:20 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <956246.22143.qm@web111408.mail.gq1.yahoo.com> <20110323.194607.39863226.asaeda@sfc.wide.ad.jp> <491930.98674.qm@web111416.mail.gq1.yahoo.com> <20110324.094406.10596817.asaeda@sfc.wide.ad.jp> Date: Thu, 24 Mar 2011 09:12:20 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110324.094406.10596817.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] draft-asaeda-multimob-pmip6-extension-05 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: Thu, 24 Mar 2011 16:10:51 -0000 Hi Hitoshi, Looking at the draft name, i.e. it is about pmip6 extensions, it seems to have much larger scope. I suggest revising it to address only PMIPv6 routing optimizations to avoid tunnel convergence problem maybe you can have another draft to address handover optimizations. Regards, Behcet > Hi Behcet, > > >> > In section 3.3, you say MN sends MLD Report upon multicast data > >> > reception. Why? > >> > I think there is something wrong in that sentence. > >> > >> I cannot understand what's wrong here? > > > > May be you meant in order to join a group? > > Ok, then I change it to "when it subscribes a multicast channel". > > >> > How relevant your Section 7 is to the tunnel convergence solution? I > >> > have a feeling that it is more relevant for handover optimizations > >> > work item we have. > >> > >> I think sharing single M-Tunnel by all MNs address the tunnel > >> convergence problem. If you don't think so, could you tell me what the > >> problem is? > > > > No because the tunnel convergence problem happens due to multiple > > LMAs and MNs > > connected to multiple LMAs joining the same group like G1. Then LMAs deliver > > > multicast data from G1 to the MAG and MAG just replicates the data to each > > member MN. > > M-Tunnel does not address this problem. > > Ok, I understand. > This consideration may be addressed with various approaches. > Our current proposal is in line with the concept of minimum protocol > modification, hence I'd propose the following changes. > > There is a statement in section 5.1; > > An MLD proxy requires that the upstream and downstream interfaces > MUST be statistically configured. As well, MAG MUST configure an > upstream interface that is the interface MLD Report messages are sent > to LMA and downstream interfaces that are the interfaces MLD Report > messages are received from mobile nodes. This upstream interface is > the M-Tunnel end-point at the MAG. > > and I'll append the following sentence; > > Whether MAG acting as an MLD proxy connects to a single or multiple > LMAs, M-Tunnel for the MAG MUST be established with one LMA. > > Also, I'll change a paragraph in section 5.2 as follows; > > Because of its implementation or operational costs, operators may not > want to support PIM-SM on MAG. However, an MLD proxy requires to > statically configure its upstream interface, which is an M-Tunnel as > specified in Section 5.1, to receive all multicast data. It also does > not allow multiple incoming interfaces. Hence even if MAG acting as > an MLD proxy connects to multiple LMAs, it cannot establish with > multiple M-Tunnels for each LMA. Therefore, if operators decide to > support the case that 1) an upstream interface for the optimized > multicast path is NOT an M-Tunnel to LMA but other interface, and > should be dynamically selected by MAG according to the optimized > routing path, or 2) MAG should establish multiple M-Tunnels for > different LMAs, and an incoming interface should be decided by the > RPF check, then MAG MUST act as a PIM-SM router. > > There might be some discussions for this, but I think above sentences > would become a reasonable start. > I'd appreciate any input, especially from providers and operators. > > Regards, > -- > Hitoshi Asaeda > From asaeda@sfc.wide.ad.jp Thu Mar 24 13:16:17 2011 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 04A0D3A68FB for ; Thu, 24 Mar 2011 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 Zg162wnDiQ5s for ; Thu, 24 Mar 2011 13:16:16 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by core3.amsl.com (Postfix) with ESMTP id 430273A68D4 for ; Thu, 24 Mar 2011 13:16:16 -0700 (PDT) Received: from localhost (40.119.71-86.rev.gaoland.net [86.71.119.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A687F278150; Fri, 25 Mar 2011 05:17:45 +0900 (JST) Date: Thu, 24 Mar 2011 21:17:42 +0100 (CET) Message-Id: <20110324.211742.232350715.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <166911.74880.qm@web111404.mail.gq1.yahoo.com> References: <166911.74880.qm@web111404.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 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, gaoxlh@gmail.com Subject: Re: [multimob] draft-asaeda-multimob-pmip6-extension-05 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, 24 Mar 2011 20:16:17 -0000 Hi, > Regarding source mobility, in draft-asaeda-multimob-pmip6-extension-05 in the > introduction you say: > > The base solution described in [14] provides options for deploying > multicast listener functions in PMIPv6-Domains without modifying > mobility and multicast protocol standards. However, in this > specification, MAG MUST act as an MLD proxy and hence MUST dedicate a > tunnel link between LMA and MAG to an incoming interface for all > multicast traffic. This limitation does not allow to use PIM-SM > native routing on MAG, does not enable local routing, and does not > support source mobility. > > > I think you mean that no source mobility is specified (that's why > now we have a work item on this). Right. In my draft, source mobility is not discussed. > You do not mean that with MLD proxy in the MAG you can not enable source > mobility. > > Can you please clarify this? If MAG is acting as an MLD proxy (having no modification), source mobility is not supported, because the incoming interface for the MAG is set to its tunnel interface whose end-point is LMA. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Thu Mar 24 13:22:22 2011 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 7E26A3A6846 for ; Thu, 24 Mar 2011 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 Q7X0KhV5lu8i for ; Thu, 24 Mar 2011 13:22:21 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by core3.amsl.com (Postfix) with ESMTP id CB2443A67F1 for ; Thu, 24 Mar 2011 13:22:21 -0700 (PDT) Received: from localhost (40.119.71-86.rev.gaoland.net [86.71.119.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9DA692780E5; Fri, 25 Mar 2011 05:23:52 +0900 (JST) Date: Thu, 24 Mar 2011 21:23:51 +0100 (CET) Message-Id: <20110324.212351.02807382.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <555485.90600.qm@web111411.mail.gq1.yahoo.com> References: <491930.98674.qm@web111416.mail.gq1.yahoo.com> <20110324.094406.10596817.asaeda@sfc.wide.ad.jp> <555485.90600.qm@web111411.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 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] draft-asaeda-multimob-pmip6-extension-05 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, 24 Mar 2011 20:22:22 -0000 Hi Behcet, > Looking at the draft name, i.e. it is about pmip6 extensions, it > seems to have > much larger scope. > I suggest revising it to address only > PMIPv6 routing optimizations to avoid tunnel convergence problem > > maybe you can have another draft to address > handover optimizations. Our approach (extension) supports routing optimizations and seamless handover, but it is pretty simple. We propose to set up the bi-directional tunnel called M-Tunnel that is dedicated to multicast transmission. And the protocol extensions are only new PBU-M message for PMIPv6 and new M-CTD message for CXTP. There are no other extensions. If we have concensus, I would be able to split my current draft to two drafts. But IMO, it is reasonable to keep it as is. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Mar 24 14:09:11 2011 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 471F728C142 for ; Thu, 24 Mar 2011 14:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 5hCYamOcDJAA for ; Thu, 24 Mar 2011 14:09:10 -0700 (PDT) Received: from nm7-vm0.bullet.mail.sp2.yahoo.com (nm7-vm0.bullet.mail.sp2.yahoo.com [98.139.91.192]) by core3.amsl.com (Postfix) with SMTP id 0957A28C0ED for ; Thu, 24 Mar 2011 14:09:10 -0700 (PDT) Received: from [98.139.91.63] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 21:10:45 -0000 Received: from [98.139.91.52] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 21:10:45 -0000 Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 24 Mar 2011 21:10:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 178319.55765.bm@omp1052.mail.sp2.yahoo.com Received: (qmail 86647 invoked by uid 60001); 24 Mar 2011 21:10:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301001044; bh=zWb9VTbN6A+wMfNf0ciWMh657+nhZVSDTJKmgEPAvoI=; 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=2+afQn/fRhWbT1wRWwxy5sb9VsByhQ105kolRJE3CDiCaqcx3KLLOpIMSzmwF45GAYy+W73FxejSV4ucmh1T4mvbQLgsXcerLqR37HsZ2AP+vy1DDHKhjshBPa8FED6Wa7M0wcGt7NJcJh4IS69/CUfUnw/BsGF5RxxSvlbsmZM= 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=jKKTkq7iFFQhNU6IwHfeZ7Jmasd8bQKMdU/8NxYPkrwY1z1F6UlZulabUDL+eo5Tr2o5VMLUtbkCWbvaaziEzcgYnoCRuYAKliTCjCHM493tidJADxXBeuJinA6VDicKyYJJePUDKZc3r7N8Y1dVLYB0+7I1QqQp++055Ot6mwA=; Message-ID: <901516.56805.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: dO_wVu4VM1kUtoDkQGDhxlRqYZw9YDyi4obxJbpsn0yNams 7tn5KwusFxrwkVQ2PADYV4ThbICKz2p0RSvCD5L7Ecy_hO1ki9u3OgJvw.nF OKritojAAi9oJdSzH4NaidGOzT_YqRhf4RtfnqCzQPDRkYwl0.VWTfNeKtqy NNVyxnDEOiR2PnIv0G1s.MoC7VlSerwE_uSfEXCvOfJ_Oz.1Yn8YmTWsPFC_ QEttX7PNlvku0pK5hyDC8oXI3A0dOpv0v.eHqYwQRMqPtoHDv2EK45MwozHE _opAqTnnVmCO_v3gBm4qc5MIjvYNJGZUR3FjasktGv3hDoAj9mEsEwyr2efQ NyZ7MvvfYljZNBd6ykTWPnTUGOFkdHdqQja6HiHsDSUzXUs1cTgwzhQJPKbC W1zazXbFyjSpKaA-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 24 Mar 2011 14:10:44 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <491930.98674.qm@web111416.mail.gq1.yahoo.com> <20110324.094406.10596817.asaeda@sfc.wide.ad.jp> <555485.90600.qm@web111411.mail.gq1.yahoo.com> <20110324.212351.02807382.asaeda@sfc.wide.ad.jp> Date: Thu, 24 Mar 2011 14:10:44 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110324.212351.02807382.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] draft-asaeda-multimob-pmip6-extension-05 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: Thu, 24 Mar 2011 21:09:11 -0000 > > Hi Behcet, > > > Looking at the draft name, i.e. it is about pmip6 extensions, it > > seems to have > > much larger scope. > > I suggest revising it to address only > > PMIPv6 routing optimizations to avoid tunnel convergence problem > > > > maybe you can have another draft to address > > handover optimizations. > > Our approach (extension) supports routing optimizations and seamless > handover, but it is pretty simple. > > We propose to set up the bi-directional tunnel called M-Tunnel that is > dedicated to multicast transmission. > And the protocol extensions are only new PBU-M message for PMIPv6 and > new M-CTD message for CXTP. > There are no other extensions. > > If we have concensus, I would be able to split my current draft to two > drafts. But IMO, it is reasonable to keep it as is. Hitoshi, my comments were individual, all hats off. Regards, Behcet From schmidt@informatik.haw-hamburg.de Thu Mar 24 17:40:51 2011 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 069A428C134 for ; Thu, 24 Mar 2011 17:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.683 X-Spam-Level: X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 7+3zInu4RSdR for ; Thu, 24 Mar 2011 17:40:50 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id C381B28C113 for ; Thu, 24 Mar 2011 17:40:49 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231108225.adsl.alicedsl.de ([92.231.108.225] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q2v4q-000Nyl-25; Fri, 25 Mar 2011 01:40:32 +0100 Message-ID: <4D8BE4EA.9020506@informatik.haw-hamburg.de> Date: Fri, 25 Mar 2011 01:42:18 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: Muhammad Omer Farooq Subject: [multimob] New draft on source mobility in the base solution 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, 25 Mar 2011 00:40:51 -0000 Hi all, we've just set up a new draft explaining source mobility in the base solution: Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast Deployment draft-schmidt-multimob-pmipv6-base-source-00 Abstract Multicast communication can be enabled in Proxy Mobile IPv6 domains by deploying MLD Proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario. Mobile sources remain agnostic of multicast mobility operations. Due to cut-off, this document could not be submitted, but can be retrieved under http://inet.cpt.haw-hamburg.de/papers/draft-schmidt-multimob-pmipv6-base-source-00.txt Sorry for being late. This document will be presented next week in Prague, but may also resolve parts of the recent discussion on source mobility following Hitoshi's draft-asaeda-multimob-pmip6-extension. See you in Prague, 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 Mar 28 05:41:44 2011 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 085793A692E for ; Mon, 28 Mar 2011 05:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 8okkTFn2US-1 for ; Mon, 28 Mar 2011 05:41:43 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 338703A691C for ; Mon, 28 Mar 2011 05:41:43 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4BlA-000JhX-KR for multimob@ietf.org; Mon, 28 Mar 2011 14:41:28 +0200 Message-ID: <4D908265.1020602@informatik.haw-hamburg.de> Date: Mon, 28 Mar 2011 14:43:17 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: [multimob] Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-base-source-00 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, 28 Mar 2011 12:41:44 -0000 Hi all, the draft is now online in the ID-repository: http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-base-source-00 A new version of I-D, draft-schmidt-multimob-pmipv6-base-source-00.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-base-source Revision: 00 Title: Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast Deployment Creation_date: 2011-03-28 WG ID: Independent Submission Number_of_pages: 12 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains by deploying MLD Proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario. Mobile sources remain agnostic of multicast mobility operations. Looking forward to discussing tomorrow! Thomas From waehlisch@ieee.org Tue Mar 29 05:21:39 2011 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 731DD3A67B6 for ; Tue, 29 Mar 2011 05:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 m-smzhf-P--u for ; Tue, 29 Mar 2011 05:21:38 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 37E7C3A63CA for ; Tue, 29 Mar 2011 05:21:38 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.10.51] (helo=mw-PC.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4XvI-00035E-LQ for multimob@ietf.org; Tue, 29 Mar 2011 14:21:25 +0200 Date: Tue, 29 Mar 2011 14:22:48 +0200 From: Matthias Waehlisch To: multimob@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: [multimob] Dedicated multicast anchor & SSM source issue X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:21:39 -0000 Hi Juan et al., just a short observation: Any solution that deploys a dedicated multicast anchor (such as your M-LMA) suffers from the following problem: You cannot easily apply this approach to SSM source mobility. Right? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From behcetsarikaya@yahoo.com Tue Mar 29 07:02:50 2011 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 3381C3A6A33 for ; Tue, 29 Mar 2011 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 d0TMduPzVChJ for ; Tue, 29 Mar 2011 07:02:49 -0700 (PDT) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by core3.amsl.com (Postfix) with SMTP id 804FF3A6A32 for ; Tue, 29 Mar 2011 07:02:49 -0700 (PDT) Received: from [98.139.91.62] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 29 Mar 2011 14:04:28 -0000 Received: from [98.139.91.24] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 29 Mar 2011 14:04:28 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 29 Mar 2011 14:04:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 37581.17706.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 12623 invoked by uid 60001); 29 Mar 2011 14:04:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301407467; bh=Nrb7yy+l5KPu9g3hmOhETJMIvg1woeO+9bM3hGGJnsw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=cSUw0fO85WCRkBnIhByex1Iqb0JZ7z0foW6QxwYs4w6hCQiF2lucH0HkaqCfQk08ipXKXhUFiuG4UmG1YmebyzUDq0tPquvChTE7Ew8vIV/LHOJ+xWuCzvn1WIRKtHafjuHyLD8BZAaXMkRAg3R3ARoCcLci9UMIpUdmRTkGlAY= 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=1kOk+LflvMVLKBTyX//Tl0KmCrVj6pW5BMf643dIMtCNrk66q8woCcgJPYzZwn0Ew8usVf6BBXVRR1RL+5wiUf0JcC2z/7IE3NfEdzxr84KqpT7BX7NOWtFzTUTOyzchS/tMVDU5BlD6YmT/dQMIjm+FtBditnhA9o50dM9z+Us=; Message-ID: <281989.12615.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: TFPYIusVM1mq0yRMFnmx1gFYcZIueZfwWGA1io3mB5WK5Dv 1zIJUfBLEk1iQ.krXvoktzgtQfjQTnWzhrY4RJBHIER741QBXFUb_WFD4oW6 CFvcr5wweqJshJgqOWbdcsd7YvSfwVaT4u8mfXMItBN.G6V6UgxMPt4Cc.qY XTHAqhzT5rtHGnqevGd3OspCDhx5LMOv80Yh4Q0Tr4MxOH7D75X_GHZBTqpa J8WU.Sr1iKRMt2oIVqBCrpfMZTkuWPWiyXUIVs.ebpf.fEX8HWZodfcGF8Ci M6UVLSDrUl3c2T72FiV.vex1XIQPRTfCbU16edkMl1GMwJ5WkiGVCh.OPiLt J1RXL_99OsP6qtGxgGUYIyZdkbeKHa5oN2LdHa95i14nLGMKuN4QFGqzLVDy 54bejggupIHrDYg-- Received: from [130.129.87.243] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 29 Mar 2011 07:04:26 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Tue, 29 Mar 2011 07:04:26 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Minutes of IETF 80 Session 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, 29 Mar 2011 14:02:50 -0000 Hi all, The minutes are at: http://www.ietf.org/proceedings/80/minutes/multimob.txt These are the draft minutes. Please send your comments to the list. Seil, Hitoshi: please provide details on where marked with ? as Matthias had trouble hearing you. Many thanks to Matthias for taking the minutes and providing us so quickly. Regards, Behcet From schmidt@informatik.haw-hamburg.de Tue Mar 29 07:55:35 2011 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 477743A6932 for ; Tue, 29 Mar 2011 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 fB0C5JJGV-z6 for ; Tue, 29 Mar 2011 07:55:34 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 532B73A6927 for ; Tue, 29 Mar 2011 07:55:34 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.61] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4aKH-000Mkl-9w for multimob@ietf.org; Tue, 29 Mar 2011 16:55:21 +0200 Message-ID: <4D91F335.40709@informatik.haw-hamburg.de> Date: Tue, 29 Mar 2011 16:56:53 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 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) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: [multimob] Thoughts on PMIP Optimized Routing 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, 29 Mar 2011 14:55:35 -0000 Hi all, after the presentations and discussions today, the following thoughts came up. 1. Scenarios for tunnel convergence problem Tunnel convergence is an issue of heavily used multicast reception. This only occurs for major events (e.g., sports on IPTV), or in flashcrowds, both scenarios cannot be serviced today (by unicast). For such situations, it may be realistic to assume that operators (somehow) pull the particular content into their network and deploy local multicast routing for scalability reasons. This is actually the cheapest and easiest. (There may be "political" reasons to act differently, though.) It may also be that some local social community group service is established within operator domains (with MNs acting as sources and receivers). Assuming this scenario, we need to provide * Coexistence of home/remote content retrieval (e.g., by the base solution) and access from local multicast routing. Thus a MAG would need to distinguish (preconfigured) local group subscriptions from non-local content. * Account for the scenario of Sri that an MN may move between PMIP domains, but stay with its LMA. This means that content that has been locally accessible at the previous MAG can only be retrieved via home its remote LMA at the new MAG. 2. State of the current proposals from the perspective of the above scenarios (a) M-tunnels to (unassociated) LMAs (Hitoschi) - aside from the other issues discussed today, this approach does seam to just "distribute load" over different LMAs and tunnels without addressing the specific scenario. (b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos) - this approach has the inverse scaling problem (avalanche) in the major event setting, i.e., the "M-LMA" needs to replicate data streams to all MAGs. So it sort of threatens the devil by being the beelzebub. In addition, it introduces the unpleasant asymmetry in routing Matthias mentioned in a previous mail. (c) Local mcast routing (Seil) - this approach lacks incorporation of home/remote content, as well as Sri's scenario. As a conclusion, my impression is that we don't have a striking proposal on the table yet. We should concentrate more an the key scenarios in PMIP deployment (maybe Sri can help ?), and on characteristic use cases for real scaling problems. Cheers, 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 Tue Mar 29 11:27:33 2011 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 C51553A6A93 for ; Tue, 29 Mar 2011 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 znqLswYuAz2U for ; Tue, 29 Mar 2011 11:27:31 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id AF9693A6A82 for ; Tue, 29 Mar 2011 11:27:30 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.61] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4ddN-000A2e-KQ; Tue, 29 Mar 2011 20:27:17 +0200 Message-ID: <4D9224DC.3000503@informatik.haw-hamburg.de> Date: Tue, 29 Mar 2011 20:28:44 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: "Koodli, Rajeev" Subject: [multimob] Thoughts on Context Transfer 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, 29 Mar 2011 18:27:34 -0000 Hi all, during the presentation of draft http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast, the following fundamental question was raised (in hurry): Why don't we use a generic context transfer (by RFC 4067) for multicast states only, and leave unicast handover aside? This question implies two subsequent questions: 1. Is there any use case, in which an application-specific group membership (not all nodes group ...) should be transferred in a "fast-handover-type" context transfer, but unicast handover should not do the context transfer between ARs / MAGs? 2. In case FMIPv6 / PFMIPv6 is applied, is it advisable to transfer multicast context different from unicast context (e.g., by CXTP)? It would be good to get more elaborated opinions on the list than could be articulated in the short remaining time of the meeting ... Cheers, 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 asaeda@sfc.wide.ad.jp Tue Mar 29 12:19:22 2011 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 4918D3A6825 for ; Tue, 29 Mar 2011 12:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 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, USER_IN_WHITELIST=-100] 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 PO-zhk2iyZXF for ; Tue, 29 Mar 2011 12:19:21 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by core3.amsl.com (Postfix) with ESMTP id 8C4CB3A67ED for ; Tue, 29 Mar 2011 12:19:21 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:df8:0:16:226:8ff:feec:a255]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DFC202780A3; Wed, 30 Mar 2011 04:20:53 +0900 (JST) Date: Tue, 29 Mar 2011 21:20:51 +0200 (CEST) Message-Id: <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4D9224DC.3000503@informatik.haw-hamburg.de> References: <4D9224DC.3000503@informatik.haw-hamburg.de> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 29 Mar 2011 19:19:22 -0000 > Why don't we use a generic context transfer (by RFC 4067) for > multicast states only, and leave unicast handover aside? As I presented today, our draft uses CXTP (rfc4067). Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Tue Mar 29 15:23:22 2011 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 C5BD23A6935 for ; Tue, 29 Mar 2011 15:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 6tqreexXLUYn for ; Tue, 29 Mar 2011 15:23:20 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 012C83A68A9 for ; Tue, 29 Mar 2011 15:23:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from 8-0-80-78.tmcz.cz ([78.80.0.8] helo=[172.19.3.13]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4hJa-000MAW-8D; Wed, 30 Mar 2011 00:23:06 +0200 Message-ID: <4D925C3B.1040608@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 00:24:59 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hitoshi Asaeda References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> 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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 29 Mar 2011 22:23:22 -0000 Hi Hitoschi, that may be - the first draft to present a context transfer by CXTP independent of unicast handover was http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. The question was about the reasons and the sense behind it ... ... and my reason for asking is that I cannot think of good reasons to do a multicast transfer directly between ARs decoupled from unicast handover. Best regards, Thomas On 29.03.2011 21:20, Hitoshi Asaeda wrote: >> Why don't we use a generic context transfer (by RFC 4067) for >> multicast states only, and leave unicast handover aside? > > As I presented today, our draft uses CXTP (rfc4067). > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > 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 Marco.Liebsch@neclab.eu Tue Mar 29 15:37:32 2011 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 CFA103A6991 for ; Tue, 29 Mar 2011 15:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.110, 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 ZNcjg3ZvaHIu for ; Tue, 29 Mar 2011 15:37:31 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2C9223A695B for ; Tue, 29 Mar 2011 15:37:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EF5812C0002E7; Wed, 30 Mar 2011 00:41:48 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhiNaQIYWdUY; Wed, 30 Mar 2011 00:41:48 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id CB7E82C000202; Wed, 30 Mar 2011 00:41:28 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 30 Mar 2011 00:38:48 +0200 From: Marco Liebsch To: "Thomas C. Schmidt" , Hitoshi Asaeda Thread-Topic: [multimob] Thoughts on Context Transfer Thread-Index: AQHL7j88v7gpX7cSQUWYhK0JREoWb5REjs+AgAAzcoCAACKQRw== Date: Tue, 29 Mar 2011 22:38:47 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp>, <4D925C3B.1040608@informatik.haw-hamburg.de> In-Reply-To: <4D925C3B.1040608@informatik.haw-hamburg.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.23.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rkoodli@cisco.com" , "multimob@ietf.org" Subject: Re: [multimob] Thoughts on Context Transfer 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, 29 Mar 2011 22:37:33 -0000 Hi,=0A= there was a further option mentioned during the meeting, which is the=0A= transfer of MC context via the LMA. So, why not establishing the MC=0A= context at the nMAG by means of PBU/PBA?=0A= I just thought mandating a Fast Handover protocol to solve context transfer= =0A= may be a bit heavyweight. At leat it's a valid option to consider. Is there= any=0A= MC state on the pMAG which cannot be stored on the LMA? I think this=0A= would meet also the requirement to establish MC context together with unica= st=0A= handover.=0A= =0A= just some thoughts.=0A= marco=0A= =0A= =0A= ________________________________________=0A= Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftrag= von "Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de]=0A= Gesendet: Mittwoch, 30. M=E4rz 2011 00:24=0A= Bis: Hitoshi Asaeda=0A= Cc: rkoodli@cisco.com; multimob@ietf.org=0A= Betreff: Re: [multimob] Thoughts on Context Transfer=0A= =0A= Hi Hitoschi,=0A= =0A= that may be - the first draft to present a context transfer by CXTP=0A= independent of unicast handover was=0A= http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005.=0A= =0A= The question was about the reasons and the sense behind it ...=0A= ... and my reason for asking is that I cannot think of good reasons to=0A= do a multicast transfer directly between ARs decoupled from unicast=0A= handover.=0A= =0A= Best regards,=0A= =0A= Thomas=0A= =0A= On 29.03.2011 21:20, Hitoshi Asaeda wrote:=0A= >> Why don't we use a generic context transfer (by RFC 4067) for=0A= >> multicast states only, and leave unicast handover aside?=0A= >=0A= > As I presented today, our draft uses CXTP (rfc4067).=0A= > Regards,=0A= > --=0A= > Hitoshi Asaeda=0A= > _______________________________________________=0A= > multimob mailing list=0A= > multimob@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/multimob=0A= =0A= --=0A= =0A= Prof. Dr. Thomas C. Schmidt=0A= =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0=0A= =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany= =B0=0A= =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0=0A= =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0=0A= _______________________________________________=0A= multimob mailing list=0A= multimob@ietf.org=0A= https://www.ietf.org/mailman/listinfo/multimob=0A= From Dirk.von-Hugo@telekom.de Wed Mar 30 00:37:59 2011 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 8BCEB3A6B20 for ; Wed, 30 Mar 2011 00:37:59 -0700 (PDT) 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=[AWL=0.000, 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 Gpks5vwd+oy4 for ; Wed, 30 Mar 2011 00:37:58 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 0EF053A676A for ; Wed, 30 Mar 2011 00:37:57 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 30 Mar 2011 09:39:30 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 09:39:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 09:39:29 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC80278480328CE93@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4D925C3B.1040608@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Thoughts on Context Transfer Thread-Index: AcvuYCn6I9ez+mxDTF2X49aN0aksAAATEoBQ References: <4D9224DC.3000503@informatik.haw-hamburg.de><20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 30 Mar 2011 07:39:31.0278 (UTC) FILETIME=[9B51E6E0:01CBEEAD] Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 07:37:59 -0000 Hi Thomas, Hitoshi, Regarding potential use cases for separated HO for multicast traffic = (independent of concurrent unicast traffic to the MN) a reason might be = operator policy running heterogeneous networks in parallel and doing = (multicast) traffic off-load e.g. from cellular (with only few = subscribers to a content) to a broadcast medium (e.g. DVB) in case the = subscriber group reaches a certain size making it economic to switch the = distribution path ... AR's in this case may be radio towers ... Spannung a larger area than = WiFi and cellular but nevertheless being limited e.g. in case of highway = or train movement ... Would this make sense? Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Thomas C. Schmidt Gesendet: Mittwoch, 30. M=E4rz 2011 00:25 An: Hitoshi Asaeda Cc: rkoodli@cisco.com; multimob@ietf.org Betreff: Re: [multimob] Thoughts on Context Transfer Hi Hitoschi, that may be - the first draft to present a context transfer by CXTP=20 independent of unicast handover was=20 http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. The question was about the reasons and the sense behind it ... ... and my reason for asking is that I cannot think of good reasons to=20 do a multicast transfer directly between ARs decoupled from unicast=20 handover. Best regards, Thomas On 29.03.2011 21:20, Hitoshi Asaeda wrote: >> Why don't we use a generic context transfer (by RFC 4067) for >> multicast states only, and leave unicast handover aside? > > As I presented today, our draft uses CXTP (rfc4067). > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Wed Mar 30 01:01:35 2011 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 5D0DE3A6B30 for ; Wed, 30 Mar 2011 01:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 5wWV863xqzp1 for ; Wed, 30 Mar 2011 01:01:34 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id ED0EE3A6B31 for ; Wed, 30 Mar 2011 01:01:33 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4qLA-000LtM-LP; Wed, 30 Mar 2011 10:01:20 +0200 Message-ID: <4D92E3C2.5000702@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 10:03:14 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marco Liebsch References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp>, <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> 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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: "rkoodli@cisco.com" , "multimob@ietf.org" Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 08:01:35 -0000 Hi Marco, thanks for commenting: On 30.03.2011 00:38, Marco Liebsch wrote: > there was a further option mentioned during the meeting, which is the > transfer of MC context via the LMA. So, why not establishing the MC > context at the nMAG by means of PBU/PBA? This would be the option of a "slow" context transfer, meaning that context transfer is not used for acceleration purposes. This raises the question about the benefit: What is the advantage of a network-based context transfer, if not speed? One answer I can think of is not to rely on MLD signaling on the wireless link. This will reduce sources of errors (lost MLD messages) and save wireless bandwidth (some bits). Do you have additional arguments in mind? > I just thought mandating a Fast Handover protocol to solve context transfer > may be a bit heavyweight. At leat it's a valid option to consider. Sure, and my question is earnestly looking for arguments that I may have missed. On the other hand, Mipshop did design the fast handover protocols for rapid (unicast) context transfer of MNs - if we believe that multicast context transfer should follow unicast context transfer, then we probably have to stick to the *fmip protocols (at least we are not chartered to design new unicast handover protocols). > Is there any > MC state on the pMAG which cannot be stored on the LMA? Normally, MC states are per interface. MAGs have interfaces per MN, while LMAs have (tunnel) interfaces per MAG. Thus, LMAs only see aggregated MC states independent of individual MNs. In other words, if an MN handovers, an LMA (on its own) would not know which MC state to transfer/duplicate/terminate. This knowledge is only at the pMAG (and needs to go to the nMAG). Of course you could build something like a "backup database" at the LMA ... but this does not sound clever to me. >I think this > would meet also the requirement to establish MC context together with unicast > handover. > I guess we agree on this :-) Cheers, Thomas _____________________________________ > Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftrag von"Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] > Gesendet: Mittwoch, 30. März 2011 00:24 > Bis: Hitoshi Asaeda > Cc: rkoodli@cisco.com; multimob@ietf.org > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good reasons to > do a multicast transfer directly between ARs decoupled from unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: >>> Why don't we use a generic context transfer (by RFC 4067) for >>> multicast states only, and leave unicast handover aside? >> >> As I presented today, our draft uses CXTP (rfc4067). >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> 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 -- 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 Wed Mar 30 01:15:10 2011 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 C45D43A68BD for ; Wed, 30 Mar 2011 01:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 Mfo0byOwx1A5 for ; Wed, 30 Mar 2011 01:15:09 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 56BF728C114 for ; Wed, 30 Mar 2011 01:15:06 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4qYH-000ORL-Oj; Wed, 30 Mar 2011 10:14:53 +0200 Message-ID: <4D92E6EF.3070803@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 10:16:47 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4D9224DC.3000503@informatik.haw-hamburg.de><20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <643B0A1D1A13AB498304E0BBC80278480328CE93@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480328CE93@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 08:15:10 -0000 Hi Dirk, On 30.03.2011 09:39, Dirk.von-Hugo@telekom.de wrote: > Hi Thomas, Hitoshi, > Regarding potential use cases for separated HO for multicast traffic (independent of concurrent unicast traffic to the MN) a reason might be operator policy running heterogeneous networks in parallel and doing (multicast) traffic off-load e.g. from cellular (with only few subscribers to a content) to a broadcast medium (e.g. DVB) in case the subscriber group reaches a certain size making it economic to switch the distribution path ... O.K., I see. But still this is not exactly a PMIP-like scenario. In your case, MN would have to activate an additional radio interface (DVB or ??) to receive multicast from there. But this interface would first need to configure a unicast IP address before participating in the multicast communication. However, this unicast interface would be newly instantiated, thus experiences no context transfer, and also lives at a different media - so this may be rather a case for MIH?? > AR's in this case may be radio towers ... Spannung a larger area than WiFi and cellular but nevertheless being limited e.g. in case of highway or train movement ... I agree, this is an interesting scenario, provided operators do such things (or are interested in doing so ???). Still, the problem is a different one, in particular for the case of unidirectional downlinks such as DVB or satellites or ... Even though I would argue that this scenario is something different, it might be quite interesting for the group to learn about possible deployment options. Will you be able to gather knowledge on this area and share with the group? Thanks & best wishes Thomas > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Thomas C. Schmidt > Gesendet: Mittwoch, 30. März 2011 00:25 > An: Hitoshi Asaeda > Cc: rkoodli@cisco.com; multimob@ietf.org > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good reasons to > do a multicast transfer directly between ARs decoupled from unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: >>> Why don't we use a generic context transfer (by RFC 4067) for >>> multicast states only, and leave unicast handover aside? >> >> As I presented today, our draft uses CXTP (rfc4067). >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> 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 Wed Mar 30 02:45:38 2011 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 1DE973A6B3C for ; Wed, 30 Mar 2011 02:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 JlFEA-KmbklU for ; Wed, 30 Mar 2011 02:45:37 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id E726C3A6B38 for ; Wed, 30 Mar 2011 02:45:36 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 05:47:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 05:47:13 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Dedicated multicast anchor & SSM source issue Thread-Index: AcvuDBdFM7DfcsVaTZi0mhFz/3zcsAAs0mTA References: From: "Zuniga, Juan Carlos" To: "Matthias Waehlisch" , X-OriginalArrivalTime: 30 Mar 2011 09:47:14.0852 (UTC) FILETIME=[732A7E40:01CBEEBF] Subject: Re: [multimob] Dedicated multicast anchor & SSM source issue X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 09:45:38 -0000 Hi Matthias, As we have been mentioning in our presentations, our proposal concentrates on solving the PMIPv6 routing optimizations problem milestone of the charter.=20 During the discussions at the meeting it was clear too that it is also the only architecture that allows a Home Network Operator to control the content delivered to the user, when it is in a Visited Network. We consider source mobility a different problem, for which the charter has different milestones. I fail to see the use case for source mobility with a Home Network content delivery. Hence, I would not characterize it as a problem. We could study this in more detail, if required. Regards, Juan-Carlos > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Matthias Waehlisch > Sent: March 29, 2011 8:23 AM > To: multimob@ietf.org > Subject: [multimob] Dedicated multicast anchor & SSM source issue >=20 > Hi Juan et al., >=20 > just a short observation: Any solution that deploys a dedicated > multicast anchor (such as your M-LMA) suffers from the following > problem: You cannot easily apply this approach to SSM source mobility. > Right? >=20 >=20 > Thanks > matthias >=20 >=20 > -- > Matthias Waehlisch > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . Takustr. 9, D-14195 Berlin, Germany > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From contreras.uc3m@gmail.com Wed Mar 30 02:59:38 2011 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 2B3CC3A6B44 for ; Wed, 30 Mar 2011 02:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JKGSzMKShIjH for ; Wed, 30 Mar 2011 02:59:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 6D5E228C0D8 for ; Wed, 30 Mar 2011 02:59:36 -0700 (PDT) Received: by ewy19 with SMTP id 19so386719ewy.31 for ; Wed, 30 Mar 2011 03:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WcN80wn8cNzh3BlPg51RKy9lsw+DvK69QOMLbPBBqzk=; b=NOue/fNFtpMVbhHPvSFHqd0vsWdbt4CGgl4T0Os4qxCrqiCOGsarmm0Q4iYOzBevX7 apV/Jm12po0gcbjgzLbiRmwfRxZC0081CCQikB/1+3MRprCibF1JrGtWtPSjeQjf+aPj sM0fXkeJuoU6IL2uN0LltOxeve+OoB2d6c5Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bsib4JnozCSDBQd6eSz/Tvh72RDyMcGaKgH950oQE6A5KcYYuIM7YAKrPGA4T6EH8o Plza5hX3YT8Kzn4KotvGJ97Il/CPCsmKbFd90nUdwihJYPUWdU9h2Iolz5nk10qvSTfm fALTdafPmz6voZ+KdmsxO8G55vBJPnQEzK44I= MIME-Version: 1.0 Received: by 10.213.34.193 with SMTP id m1mr778806ebd.6.1301479274306; Wed, 30 Mar 2011 03:01:14 -0700 (PDT) Received: by 10.213.15.201 with HTTP; Wed, 30 Mar 2011 03:01:14 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> Date: Wed, 30 Mar 2011 12:01:14 +0200 Message-ID: From: "Luis M. Contreras" To: Marco Liebsch Content-Type: multipart/alternative; boundary=000e0cd5f302d3dfc6049fb04119 Cc: "multimob@ietf.org" , Ignacio Soto , "rkoodli@cisco.com" , "Thomas C. Schmidt" Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 09:59:38 -0000 --000e0cd5f302d3dfc6049fb04119 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, this way is something already explored in draft-contreras-multimob-rams-00, where the active multicast subscription is transferred from the pMAG to the nMAG through the LMA by means of PBU/PBA messages (plus some additional mechanisms to govern the process). Regards, Luis 2011/3/30 Marco Liebsch > Hi, > there was a further option mentioned during the meeting, which is the > transfer of MC context via the LMA. So, why not establishing the MC > context at the nMAG by means of PBU/PBA? > I just thought mandating a Fast Handover protocol to solve context transf= er > may be a bit heavyweight. At leat it's a valid option to consider. Is the= re > any > MC state on the pMAG which cannot be stored on the LMA? I think this > would meet also the requirement to establish MC context together with > unicast > handover. > > just some thoughts. > marco > > > ________________________________________ > Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im > Auftrag von "Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] > Gesendet: Mittwoch, 30. M=E4rz 2011 00:24 > Bis: Hitoshi Asaeda > Cc: rkoodli@cisco.com; multimob@ietf.org > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good reasons to > do a multicast transfer directly between ARs decoupled from unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: > >> Why don't we use a generic context transfer (by RFC 4067) for > >> multicast states only, and leave unicast handover aside? > > > > As I presented today, our draft uses CXTP (rfc4067). > > Regards, > > -- > > Hitoshi Asaeda > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 > =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 > --000e0cd5f302d3dfc6049fb04119 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
this way is something already explored in draft-contreras-multimob-ram= s-00, where the active multicast subscription is transferred from the pMAG = to the nMAG through the LMA by means of PBU/PBA messages (plus some additio= nal mechanisms to govern the process).
=A0
Regards,
=A0
Luis

2011/3/30 Marco Liebsch <Marco.Liebsch@neclab.eu>
Hi,
there was a further optio= n mentioned during the meeting, which is the
transfer of MC context via = the LMA. So, why not establishing the MC
context at the nMAG by means of PBU/PBA?
I just thought mandating a Fast= Handover protocol to solve context transfer
may be a bit heavyweight. A= t leat it's a valid option to consider. Is there any
MC state on the= pMAG which cannot be stored on the LMA? I think this
would meet also the requirement to establish MC context together with unica= st
handover.

just some thoughts.
marco


____________= ____________________________
Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]&quot; im Auftrag von &quot;T= homas C. Schmidt [schm= idt@informatik.haw-hamburg.de]
Gesendet: Mittwoch, 30. M=E4rz 2011 00:24
Bis: Hitoshi Asaeda
Cc: rkoodli@cisco.com; multimob@ietf.org
Betreff: Re: [multimob] Thought= s on Context Transfer

Hi Hitoschi,

that may be - the first draft to = present a context transfer by CXTP
independent of unicast handover washttp://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00<= /a> in 2005.

The question was about the reasons and the sense behind it ...
... a= nd my reason for asking is that I cannot think of good reasons to
do a m= ulticast transfer directly between ARs decoupled from unicast
handover.<= br>
Best regards,

Thomas

On 29.03.2011 21:20, Hitoshi Asaeda = wrote:
>> Why don't we use a generic context transfer (by RFC = 4067) for
>> multicast states only, and leave unicast handover asi= de?
>
> As I presented today, our draft uses CXTP (rfc4067).
> R= egards,
> --
> Hitoshi Asaeda
> _________________________= ______________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob

--

= 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 =A020099 Hamburg, Ger= many =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/~schm= idt =A0 =A0Fax: +49-40-42875-8409 =B0
_______________________________________________
multimob mailing listmultimob@ietf.org
https://ww= w.ietf.org/mailman/listinfo/multimob
_______________________________________________
multimob mailing listmultimob@ietf.org
https://ww= w.ietf.org/mailman/listinfo/multimob

--000e0cd5f302d3dfc6049fb04119-- From schmidt@informatik.haw-hamburg.de Wed Mar 30 05:15:34 2011 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 490FE3A67CC for ; Wed, 30 Mar 2011 05:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 34Kg40HSvM7c for ; Wed, 30 Mar 2011 05:15:33 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D929E3A6947 for ; Wed, 30 Mar 2011 05:15:32 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4uIy-000M2d-Fh for multimob@ietf.org; Wed, 30 Mar 2011 14:15:20 +0200 Message-ID: <4D931F4A.9070602@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 14:17:14 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: multimob@ietf.org References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> 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) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 12:15:34 -0000 Hi Luis, yes ... and we already had a longer discussion on the list about this: Your argument was "handover acceleration" and I tried to give you numbers that - in regular deployment cases where the LMA is not adjacent to the MAG - this does not accelerate. In other words: in the base scenario, unicast handover (RtrSol -> PBU -> PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of time, while MLD query/answer is commonly few ms. Best, Thomas On 30.03.2011 12:01, Luis M. Contreras wrote: > Hi all, > this way is something already explored in > draft-contreras-multimob-rams-00, where the active multicast > subscription is transferred from the pMAG to the nMAG through the LMA by > means of PBU/PBA messages (plus some additional mechanisms to govern the > process). > Regards, > Luis > > 2011/3/30 Marco Liebsch > > > Hi, > there was a further option mentioned during the meeting, which is the > transfer of MC context via the LMA. So, why not establishing the MC > context at the nMAG by means of PBU/PBA? > I just thought mandating a Fast Handover protocol to solve context > transfer > may be a bit heavyweight. At leat it's a valid option to consider. > Is there any > MC state on the pMAG which cannot be stored on the LMA? I think this > would meet also the requirement to establish MC context together > with unicast > handover. > > just some thoughts. > marco > > > ________________________________________ > Von: multimob-bounces@ietf.org > [multimob-bounces@ietf.org ]" > im Auftrag von "Thomas C. Schmidt > [schmidt@informatik.haw-hamburg.de > ] > Gesendet: Mittwoch, 30. März 2011 00:24 > Bis: Hitoshi Asaeda > Cc: rkoodli@cisco.com ; multimob@ietf.org > > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good reasons to > do a multicast transfer directly between ARs decoupled from unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: > > > Why don't we use a generic context transfer (by RFC 4067) for > > > multicast states only, and leave unicast handover aside? > > > > As I presented today, our draft uses CXTP (rfc4067). > > Regards, > > -- > > Hitoshi Asaeda > > _______________________________________________ > > 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 > > > > > _______________________________________________ > 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 contreras.uc3m@gmail.com Wed Mar 30 06:30:01 2011 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 B46E03A6B32 for ; Wed, 30 Mar 2011 06:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mS31dc5n3-3M for ; Wed, 30 Mar 2011 06:30:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 812E73A6B11 for ; Wed, 30 Mar 2011 06:29:59 -0700 (PDT) Received: by eye13 with SMTP id 13so445195eye.31 for ; Wed, 30 Mar 2011 06:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CgtMhyWtjPgTtuk+AT5IdQnLXDGKNCaXJYiKrpeE2IE=; b=uhptvvdtdSAbHofBuPHeb3kzbotHv9CfPyhCa1r3ExnH3EcH02vW8iN2LTTUK1lDkL UNIftCykKrJuJZuttN7CgCSUgkQVBcJGilHtlRf7BGPGL0nNjpZCLcILEWvIQ7d8Vico AHxYnl79XgmGoMftajUhxMUsCN7ZDYW7ri5kc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NSChGXUboHsuCqan5qe8uxTZNBgPkbqrEiIRF1fzXe4rqcEFa0lc9HVnsneN9Boz+k p3b0sXd/uhCJKSKBlV/HVwvfELMjeCF7mgHGtdT8L8Nr+JZuAg6Q7OnON1MkcnJi0Sw2 +BUBOGPKXED23uUWJs3cGQQYIg6k7LZursWv8= MIME-Version: 1.0 Received: by 10.213.20.213 with SMTP id g21mr289748ebb.44.1301491897370; Wed, 30 Mar 2011 06:31:37 -0700 (PDT) Received: by 10.213.15.201 with HTTP; Wed, 30 Mar 2011 06:31:37 -0700 (PDT) In-Reply-To: <4D931F4A.9070602@informatik.haw-hamburg.de> References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> <4D931F4A.9070602@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 15:31:37 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=0015174a0bf4388812049fb33284 Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 13:30:01 -0000 --0015174a0bf4388812049fb33284 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, note that the MLD query can not been sent before PBA is received by the new MAG, so the ms you mention are additional to the PBU/PBA timing (thus, leading to a worst situation) Regards, Luis 2011/3/30 Thomas C. Schmidt > Hi Luis, > > yes ... and we already had a longer discussion on the list about this: Yo= ur > argument was "handover acceleration" and I tried to give you numbers that= - > in regular deployment cases where the LMA is not adjacent to the MAG - th= is > does not accelerate. > > In other words: in the base scenario, unicast handover (RtrSol -> PBU -> > PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of time, while = MLD > query/answer is commonly few ms. > > Best, > > Thomas > > > On 30.03.2011 12:01, Luis M. Contreras wrote: > >> Hi all, >> this way is something already explored in >> draft-contreras-multimob-rams-00, where the active multicast >> subscription is transferred from the pMAG to the nMAG through the LMA by >> means of PBU/PBA messages (plus some additional mechanisms to govern the >> process). >> Regards, >> Luis >> >> 2011/3/30 Marco Liebsch > > >> >> Hi, >> there was a further option mentioned during the meeting, which is the >> transfer of MC context via the LMA. So, why not establishing the MC >> context at the nMAG by means of PBU/PBA? >> I just thought mandating a Fast Handover protocol to solve context >> transfer >> may be a bit heavyweight. At leat it's a valid option to consider. >> Is there any >> MC state on the pMAG which cannot be stored on the LMA? I think this >> would meet also the requirement to establish MC context together >> with unicast >> handover. >> >> just some thoughts. >> marco >> >> >> ________________________________________ >> Von: multimob-bounces@ietf.org >> [multimob-bounces@ietf.org ]" >> >> im Auftrag von "Thomas C. Schmidt >> [schmidt@informatik.haw-hamburg.de >> ] >> >> Gesendet: Mittwoch, 30. M=E4rz 2011 00:24 >> Bis: Hitoshi Asaeda >> Cc: rkoodli@cisco.com ; multimob@ietf.org >> >> >> Betreff: Re: [multimob] Thoughts on Context Transfer >> >> Hi Hitoschi, >> >> that may be - the first draft to present a context transfer by CXTP >> independent of unicast handover was >> http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. >> >> The question was about the reasons and the sense behind it ... >> ... and my reason for asking is that I cannot think of good reasons t= o >> do a multicast transfer directly between ARs decoupled from unicast >> handover. >> >> Best regards, >> >> Thomas >> >> On 29.03.2011 21:20, Hitoshi Asaeda wrote: >> > > Why don't we use a generic context transfer (by RFC 4067) for >> > > multicast states only, and leave unicast handover aside? >> > >> > As I presented today, our draft uses CXTP (rfc4067). >> > Regards, >> > -- >> > Hitoshi Asaeda >> > _______________________________________________ >> > multimob mailing list >> > multimob@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/multimob >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner >> Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >> +49-40-42875-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 >> >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 > =B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --0015174a0bf4388812049fb33284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
note that the MLD query can not been sent before PBA is received by th= e new MAG, so the ms you mention are additional to the PBU/PBA timing (thus= , leading to a worst situation)
=A0
Regards,
=A0
Luis

2011/3/30 Thomas C. Schmidt &l= t;schmidt@informatik.h= aw-hamburg.de>
Hi Luis,

yes ... and we a= lready had a longer discussion on the list about this: Your argument was &q= uot;handover acceleration" and I tried to give you numbers that - in r= egular deployment cases where the LMA is not adjacent to the MAG - this doe= s not accelerate.

In other words: in the base scenario, unicast handover (RtrSol -> PB= U -> PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of tim= e, while MLD query/answer is commonly few ms.

Best,

Thomas=20


On 30.03.2011 12:01, Luis M. Contreras wrote:
=
Hi all,
this way is something already explored in
d= raft-contreras-multimob-rams-00, where the active multicast
subscription= is transferred from the pMAG to the nMAG through the LMA by
means of PB= U/PBA messages (plus some additional mechanisms to govern the
process).
Regards,
Luis

2011/3/30 Marco Liebsch <Marco.Liebsch@neclab.eu<= /a>
<mailto:Marco.Liebsch@neclab.eu>>

=A0 =A0Hi,
=A0= =A0there was a further option mentioned during the meeting, which is the=A0 =A0transfer of MC context via the LMA. So, why not establishing the M= C
=A0 =A0context at the nMAG by means of PBU/PBA?
=A0 =A0I just thought ma= ndating a Fast Handover protocol to solve context
=A0 =A0transfer
=A0= =A0may be a bit heavyweight. At leat it's a valid option to consider.<= br>=A0 =A0Is there any
=A0 =A0MC state on the pMAG which cannot be stored on the LMA? I think this=
=A0 =A0would meet also the requirement to establish MC context together=
=A0 =A0with unicast
=A0 =A0handover.

=A0 =A0just some thought= s.
=A0 =A0marco


=A0 =A0________________________________________
=A0 =A0Von= : multimob-b= ounces@ietf.org <mailto:multimob-bounces@ietf.org>
=A0 =A0[mult= imob-bounces@ietf.org <mailto:multimob-bounces@ietf.org>]&quot;=20

=A0 =A0im Auftrag von &quot;Thomas C. Schmidt
= =A0 =A0[schmidt@informatik.haw-hamburg.de
=A0 =A0<mailto:schmidt@in= formatik.haw-hamburg.de>]=20

=A0 =A0Gesendet: Mittwoch, 30. M=E4rz 2011 00:24
= =A0 =A0Bis: Hitoshi Asaeda
=A0 =A0Cc: rkoodli@cisco.com <mailto:rkoodli@cisco.com>; multimob@ietf.org
=A0 =A0<mailto:mu= ltimob@ietf.org>=20

=A0 =A0Betreff: Re: [multimob] Thoughts on Context Tr= ansfer

=A0 =A0Hi Hitoschi,

=A0 =A0that may be - the first dra= ft to present a context transfer by CXTP
=A0 =A0independent of unicast h= andover was
=A0 =A0http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv= 6-00 in 2005.

=A0 =A0The question was about the reasons and the = sense behind it ...
=A0 =A0... and my reason for asking is that I cannot think of good reasons = to
=A0 =A0do a multicast transfer directly between ARs decoupled from un= icast
=A0 =A0handover.

=A0 =A0Best regards,

=A0 =A0Thomas<= br>
=A0 =A0On 29.03.2011 21:20, Hitoshi Asaeda wrote:
=A0 =A0> > Why don't we use a generic context transfer (by RFC 40= 67) for
=A0 =A0> > multicast states only, and leave unicast handov= er aside?
=A0 =A0>
=A0 =A0> =A0As I presented today, our draft = uses CXTP (rfc4067).
=A0 =A0> =A0Regards,
=A0 =A0> =A0--
=A0 =A0> =A0Hitoshi Asae= da
=A0 =A0> =A0_______________________________________________
=A0= =A0> =A0multimob mailing list
=A0 =A0> =A0multimob@ietf.org <mailto:multimob@ietf.org>= ;=20

=A0 =A0> =A0https://www.ietf.org/mailman/listinf= o/multimob

=A0 =A0--

=A0 =A0Prof. Dr. Thomas C. Schmidt=A0 =A0=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 Berliner
=A0 =A0Tor 7 =B0
=A0 =A0=B0 Dept. Informatik, Internet Technologies Grou= p =A0 =A020099 Hamburg,
=A0 =A0Germany =B0
=A0 =A0=B0 http://www.haw-hamburg.de/ine= t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon:
=A0 =A0+49-40-42875-8452 =B0
=A0 =A0=B0 http://www.informatik.haw-hambu= rg.de/~schmidt =A0 =A0Fax:
=A0 =A0+49-40-42875-8409 =B0
=A0 =A0__= _____________________________________________
=A0 =A0multimob mailing list
=A0 =A0multimob@ietf.org <mailto:multimob@ietf.org>=20

=A0 =A0https://www.ietf.org/mailman/listinfo/multim= ob
=A0 =A0_______________________________________________
=A0 =A0= multimob mailing list
=A0 =A0multimo= b@ietf.org <mailto:multimob@ietf.org>=20

=A0 =A0https://www.ietf.org/mailman/listinfo/multim= ob




_______________________________________________multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--

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 =A020099 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 =A0Fax: +49-40-4= 2875-8409 =B0
_______________________________________________
multimo= b mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--0015174a0bf4388812049fb33284-- From Marco.Liebsch@neclab.eu Wed Mar 30 07:51:59 2011 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 486053A6B5F for ; Wed, 30 Mar 2011 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 1iRDerfSJtPS for ; Wed, 30 Mar 2011 07:51:58 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id B3DB03A6983 for ; Wed, 30 Mar 2011 07:51:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 55D232800018A; Wed, 30 Mar 2011 16:54:53 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93X8sumCg-DH; Wed, 30 Mar 2011 16:54:53 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3717F2800017B; Wed, 30 Mar 2011 16:54:38 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 30 Mar 2011 16:53:20 +0200 From: Marco Liebsch To: "Thomas C. Schmidt" Thread-Topic: [multimob] Thoughts on Context Transfer Thread-Index: AQHL7j88v7gpX7cSQUWYhK0JREoWb5REjs+AgAAzcoCAACKQR4AAfwAAgACPgeI= Date: Wed, 30 Mar 2011 14:53:20 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D05C77F31@Polydeuces.office.hd> References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp>, <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd>, <4D92E3C2.5000702@informatik.haw-hamburg.de> In-Reply-To: <4D92E3C2.5000702@informatik.haw-hamburg.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.23.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rkoodli@cisco.com" , "multimob@ietf.org" Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 14:51:59 -0000 Thomas,=0A= please see inline for my reply. This time labelled with [marco].=0A= =0A= =0A= ________________________________________=0A= Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftrag= von "Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de]=0A= Gesendet: Mittwoch, 30. M=E4rz 2011 10:03=0A= Bis: Marco Liebsch=0A= Cc: rkoodli@cisco.com; multimob@ietf.org=0A= Betreff: Re: [multimob] Thoughts on Context Transfer=0A= =0A= Hi Marco,=0A= =0A= thanks for commenting:=0A= =0A= On 30.03.2011 00:38, Marco Liebsch wrote:=0A= =0A= > there was a further option mentioned during the meeting, which is the=0A= > transfer of MC context via the LMA. So, why not establishing the MC=0A= > context at the nMAG by means of PBU/PBA?=0A= =0A= This would be the option of a "slow" context transfer, meaning that=0A= context transfer is not used for acceleration purposes. This raises the=0A= question about the benefit: What is the advantage of a network-based=0A= context transfer, if not speed?=0A= =0A= One answer I can think of is not to rely on MLD signaling on the=0A= wireless link. This will reduce sources of errors (lost MLD messages)=0A= and save wireless bandwidth (some bits).=0A= =0A= Do you have additional arguments in mind?=0A= =0A= [marco] Why not speed? I heard about the requirement that the MC context sh= ould=0A= not be established before unicast context. So, isn't it the fastest approac= h to establish=0A= MC context together with unicast context? This is what the PBU/PBA can do. = This implies=0A= that we define a completed unicast state establishment as a completed PBU/P= BA handshake.=0A= If you consider a different definition, e.g. a completed forwarding state b= etween pMAG and=0A= nMAG as sufficient, this can be done. But then the solution is fast Handove= r specific.=0A= =0A= =0A= =0A= > I just thought mandating a Fast Handover protocol to solve context transf= er=0A= > may be a bit heavyweight. At leat it's a valid option to consider.=0A= =0A= Sure, and my question is earnestly looking for arguments that I may have=0A= missed.=0A= =0A= On the other hand, Mipshop did design the fast handover protocols for=0A= rapid (unicast) context transfer of MNs - if we believe that multicast=0A= context transfer should follow unicast context transfer, then we=0A= probably have to stick to the *fmip protocols (at least we are not=0A= chartered to design new unicast handover protocols).=0A= =0A= > Is there any=0A= > MC state on the pMAG which cannot be stored on the LMA?=0A= =0A= Normally, MC states are per interface. MAGs have interfaces per MN,=0A= while LMAs have (tunnel) interfaces per MAG. Thus, LMAs only see=0A= aggregated MC states independent of individual MNs. In other words, if=0A= an MN handovers, an LMA (on its own) would not know which MC state to=0A= transfer/duplicate/terminate. This knowledge is only at the pMAG (and=0A= needs to go to the nMAG).=0A= =0A= [marco] ok=0A= =0A= Of course you could build something like a "backup database" at the LMA=0A= ... but this does not sound clever to me.=0A= =0A= >I think this=0A= > would meet also the requirement to establish MC context together with uni= cast=0A= > handover.=0A= >=0A= =0A= I guess we agree on this :-)=0A= =0A= [marco] I did not follow the previous discussion on this, I just heard this= requirement during yesterday's meeting.=0A= My comments are just based on observations. As I told you, I have to dig a = bit more into the details=0A= of the discussion. So, just treat my comments as input to the scope of an a= nalysis of solution candidates. =0A= =0A= Thanks,=0A= marco=0A= =0A= =0A= Cheers,=0A= =0A= Thomas=0A= =0A= _____________________________________=0A= > Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftr= ag von"Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de]=0A= > Gesendet: Mittwoch, 30. M=E4rz 2011 00:24=0A= > Bis: Hitoshi Asaeda=0A= > Cc: rkoodli@cisco.com; multimob@ietf.org=0A= > Betreff: Re: [multimob] Thoughts on Context Transfer=0A= >=0A= > Hi Hitoschi,=0A= >=0A= > that may be - the first draft to present a context transfer by CXTP=0A= > independent of unicast handover was=0A= > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005.=0A= >=0A= > The question was about the reasons and the sense behind it ...=0A= > ... and my reason for asking is that I cannot think of good reasons to=0A= > do a multicast transfer directly between ARs decoupled from unicast=0A= > handover.=0A= >=0A= > Best regards,=0A= >=0A= > Thomas=0A= >=0A= > On 29.03.2011 21:20, Hitoshi Asaeda wrote:=0A= >>> Why don't we use a generic context transfer (by RFC 4067) for=0A= >>> multicast states only, and leave unicast handover aside?=0A= >>=0A= >> As I presented today, our draft uses CXTP (rfc4067).=0A= >> Regards,=0A= >> --=0A= >> Hitoshi Asaeda=0A= >> _______________________________________________=0A= >> multimob mailing list=0A= >> multimob@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/multimob=0A= >=0A= > --=0A= >=0A= > Prof. Dr. Thomas C. Schmidt=0A= > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0=0A= > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0=0A= > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 =B0=0A= > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 =B0=0A= > _______________________________________________=0A= > multimob mailing list=0A= > multimob@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/multimob=0A= =0A= --=0A= =0A= Prof. Dr. Thomas C. Schmidt=0A= =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0=0A= =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany= =B0=0A= =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0=0A= =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0=0A= _______________________________________________=0A= multimob mailing list=0A= multimob@ietf.org=0A= https://www.ietf.org/mailman/listinfo/multimob=0A= From schmidt@informatik.haw-hamburg.de Wed Mar 30 08:03:05 2011 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 00A6A3A6821 for ; Wed, 30 Mar 2011 08:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 dNAqIwGSV-v2 for ; Wed, 30 Mar 2011 08:03:03 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 7A9F63A6983 for ; Wed, 30 Mar 2011 08:03:03 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4wv4-0003hf-Q2; Wed, 30 Mar 2011 17:02:50 +0200 Message-ID: <4D934689.4050805@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 17:04:41 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Luis M. Contreras" References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> <4D931F4A.9070602@informatik.haw-hamburg.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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 15:03:05 -0000 Hi Luis, the query is typically sent when the link comes up, see http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-07#appendix-A, latest after the link-local address is configured. On a ptp-link, this costs virtually no time. The biggest issue in handover delay is DAD, otherwise PBU/PBA when the LMA is far remote. So in conclusion, multicast state acquisition after handover is not an issue of time - the delays arise from unicast handover and address configuration. That's why I question the value of an additional multicast context transfer independent of the unicast handover. Cheers, Thomas On 30.03.2011 15:31, Luis M. Contreras wrote: > Hi Thomas, > note that the MLD query can not been sent before PBA is received by the > new MAG, so the ms you mention are additional to the PBU/PBA timing > (thus, leading to a worst situation) > Regards, > Luis > > 2011/3/30 Thomas C. Schmidt > > > Hi Luis, > > yes ... and we already had a longer discussion on the list about > this: Your argument was "handover acceleration" and I tried to give > you numbers that - in regular deployment cases where the LMA is not > adjacent to the MAG - this does not accelerate. > > In other words: in the base scenario, unicast handover (RtrSol -> > PBU -> PBA -> RtrAdv + perhaps DAD) consumes the dominant amount of > time, while MLD query/answer is commonly few ms. > > Best, > > Thomas > > > On 30.03.2011 12:01, Luis M. Contreras wrote: > > Hi all, > this way is something already explored in > draft-contreras-multimob-rams-00, where the active multicast > subscription is transferred from the pMAG to the nMAG through > the LMA by > means of PBU/PBA messages (plus some additional mechanisms to > govern the > process). > Regards, > Luis > > 2011/3/30 Marco Liebsch > >> > > Hi, > there was a further option mentioned during the meeting, > which is the > transfer of MC context via the LMA. So, why not establishing > the MC > context at the nMAG by means of PBU/PBA? > I just thought mandating a Fast Handover protocol to solve > context > transfer > may be a bit heavyweight. At leat it's a valid option to > consider. > Is there any > MC state on the pMAG which cannot be stored on the LMA? I > think this > would meet also the requirement to establish MC context together > with unicast > handover. > > just some thoughts. > marco > > > ________________________________________ > Von: multimob-bounces@ietf.org > > > > [multimob-bounces@ietf.org > > >]" > > im Auftrag von "Thomas C. Schmidt > [schmidt@informatik.haw-hamburg.de > > >] > > Gesendet: Mittwoch, 30. März 2011 00:24 > Bis: Hitoshi Asaeda > Cc: rkoodli@cisco.com > >; > multimob@ietf.org > > > > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer > by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good > reasons to > do a multicast transfer directly between ARs decoupled from > unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: > > > Why don't we use a generic context transfer (by RFC 4067) for > > > multicast states only, and leave unicast handover aside? > > > > As I presented today, our draft uses CXTP (rfc4067). > > Regards, > > -- > > Hitoshi Asaeda > > _______________________________________________ > > 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 > > > > > _______________________________________________ > 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 > > -- 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 Wed Mar 30 08:12:28 2011 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 5281A3A6B6F for ; Wed, 30 Mar 2011 08:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 YUvEeswiZ6d4 for ; Wed, 30 Mar 2011 08:12:27 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id E470A3A6B6B for ; Wed, 30 Mar 2011 08:12:26 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q4x4A-0005OA-JY; Wed, 30 Mar 2011 17:12:14 +0200 Message-ID: <4D9348C0.3090508@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 17:14:08 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marco Liebsch References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp>, <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd>, <4D92E3C2.5000702@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77F31@Polydeuces.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D05C77F31@Polydeuces.office.hd> 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) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: "rkoodli@cisco.com" , "multimob@ietf.org" Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 15:12:28 -0000 Hi Marco, thanks, my comments are labelled with [thomas] On 30.03.2011 16:53, Marco Liebsch wrote: > Thomas, > please see inline for my reply. This time labelled with [marco]. > > > ________________________________________ > Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftrag von"Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] > Gesendet: Mittwoch, 30. März 2011 10:03 > Bis: Marco Liebsch > Cc: rkoodli@cisco.com; multimob@ietf.org > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Marco, > > thanks for commenting: > > On 30.03.2011 00:38, Marco Liebsch wrote: > >> there was a further option mentioned during the meeting, which is the >> transfer of MC context via the LMA. So, why not establishing the MC >> context at the nMAG by means of PBU/PBA? > > This would be the option of a "slow" context transfer, meaning that > context transfer is not used for acceleration purposes. This raises the > question about the benefit: What is the advantage of a network-based > context transfer, if not speed? > > One answer I can think of is not to rely on MLD signaling on the > wireless link. This will reduce sources of errors (lost MLD messages) > and save wireless bandwidth (some bits). > > Do you have additional arguments in mind? > > [marco] Why not speed? I heard about the requirement that the MC context should > not be established before unicast context. So, isn't it the fastest approach to establish > MC context together with unicast context? This is what the PBU/PBA can do. This implies > that we define a completed unicast state establishment as a completed PBU/PBA handshake. > If you consider a different definition, e.g. a completed forwarding state between pMAG and > nMAG as sufficient, this can be done. But then the solution is fast Handover specific. > [thomas] As I just answered to Luis, the MLD state acquisition is not costly and starts before the unicast context (addressing) is fully established. However, we do have a communication problem as long as MN has no link-local address. There is an additional aspect: PMIP with local non-flat routing may want to initiate predictive joins (here we need predictive handovers, which we get from PFMIP) ... and we're also looking on (F)MIP scenarios where an update delay problem with HA obviously exists ... > > >> I just thought mandating a Fast Handover protocol to solve context transfer >> may be a bit heavyweight. At leat it's a valid option to consider. > > Sure, and my question is earnestly looking for arguments that I may have > missed. > > On the other hand, Mipshop did design the fast handover protocols for > rapid (unicast) context transfer of MNs - if we believe that multicast > context transfer should follow unicast context transfer, then we > probably have to stick to the *fmip protocols (at least we are not > chartered to design new unicast handover protocols). > >> Is there any >> MC state on the pMAG which cannot be stored on the LMA? > > Normally, MC states are per interface. MAGs have interfaces per MN, > while LMAs have (tunnel) interfaces per MAG. Thus, LMAs only see > aggregated MC states independent of individual MNs. In other words, if > an MN handovers, an LMA (on its own) would not know which MC state to > transfer/duplicate/terminate. This knowledge is only at the pMAG (and > needs to go to the nMAG). > > [marco] ok > > Of course you could build something like a "backup database" at the LMA > ... but this does not sound clever to me. > >> I think this >> would meet also the requirement to establish MC context together with unicast >> handover. >> > > I guess we agree on this :-) > > [marco] I did not follow the previous discussion on this, I just heard this requirement during yesterday's meeting. > My comments are just based on observations. As I told you, I have to dig a bit more into the details > of the discussion. So, just treat my comments as input to the scope of an analysis of solution candidates. > [thomas] Yes, thanks! Thomas > > _____________________________________ >> Von: multimob-bounces@ietf.org [multimob-bounces@ietf.org]" im Auftrag von"Thomas C. Schmidt [schmidt@informatik.haw-hamburg.de] >> Gesendet: Mittwoch, 30. März 2011 00:24 >> Bis: Hitoshi Asaeda >> Cc: rkoodli@cisco.com; multimob@ietf.org >> Betreff: Re: [multimob] Thoughts on Context Transfer >> >> Hi Hitoschi, >> >> that may be - the first draft to present a context transfer by CXTP >> independent of unicast handover was >> http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. >> >> The question was about the reasons and the sense behind it ... >> ... and my reason for asking is that I cannot think of good reasons to >> do a multicast transfer directly between ARs decoupled from unicast >> handover. >> >> Best regards, >> >> Thomas >> >> On 29.03.2011 21:20, Hitoshi Asaeda wrote: >>>> Why don't we use a generic context transfer (by RFC 4067) for >>>> multicast states only, and leave unicast handover aside? >>> >>> As I presented today, our draft uses CXTP (rfc4067). >>> Regards, >>> -- >>> Hitoshi Asaeda >>> _______________________________________________ >>> 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 > > -- > > 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 contreras.uc3m@gmail.com Wed Mar 30 12:18:31 2011 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 2345228C195 for ; Wed, 30 Mar 2011 12:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ABCxh63BaI+F for ; Wed, 30 Mar 2011 12:18:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 6D6133A6BBC for ; Wed, 30 Mar 2011 12:18:28 -0700 (PDT) Received: by eye13 with SMTP id 13so577948eye.31 for ; Wed, 30 Mar 2011 12:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xj5wt+meZY5Wf3fQF4t1ldbS4ptb4UR1+4SspYOOAl4=; b=m1a9zhqR5SyGUF3yXe7dtwrs3D+isnpFJQvJIK7GyT/eAiMfWnH1YCJ6u0Q571TOkn C8KCkWTJiUDocssyEPncF/etwnsKsKbDgP7oDl+7LMSECMLX4BSDkkSiHU/NaykZ1b91 Dmead89XVPQb2Wu/rzTmBq2yYy/J/pI8M/mmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ifm0O4K5rKl4bsHLZUohEFt+8Lxv9BsYs933a1+X3YGKCTjusZScs5IrPZsCvW+AOu WZrgszsJqa9ivdFO3EkAAMubCwQLeKXi9qIQv2ALF0/Det8kdLmzme6ANMizxnYgYqkh lvQttIgKICBwuH2nsp+JOQJndHfc95ji4mows= MIME-Version: 1.0 Received: by 10.213.7.83 with SMTP id c19mr629898ebc.63.1301512806902; Wed, 30 Mar 2011 12:20:06 -0700 (PDT) Received: by 10.213.15.201 with HTTP; Wed, 30 Mar 2011 12:20:06 -0700 (PDT) In-Reply-To: <4D934689.4050805@informatik.haw-hamburg.de> References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> <4D931F4A.9070602@informatik.haw-hamburg.de> <4D934689.4050805@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 21:20:06 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=0015174bdee286aec4049fb8101a Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 30 Mar 2011 19:18:31 -0000 --0015174bdee286aec4049fb8101a Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, three additional comments, on your mail the query is typically sent when the link comes up, see > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-07#appendix-A, > latest after the link-local address is configured. On a ptp-link, this costs > virtually no time. > Luis>> That's true, but this always come after PBU/PBA completion (the PBA carries the local-link address of the MAG, needed to send the MLD Query to the MN) > > The biggest issue in handover delay is DAD, otherwise PBU/PBA when the LMA > is far remote. > > So in conclusion, multicast state acquisition after handover is not an > issue of time - the delays arise from unicast handover and address > configuration. > Luis>> So the lower limit in the delay for multicast context transfer is the unicast handover. The fastest solution is then the one that equals the unicast handover. > > That's why I question the value of an additional multicast context transfer > independent of the unicast handover. > Luis>> I think on two reasons: .- Multicast traffic typically serves real-time traffic, that is, a traffic more sensitive to delay .- The multicast state is kept at MAG level (the LMA doesn't know the specific subscriptions of the MN) . For efficient service continuity, it seems better to transfer the subscription information than to rebuild the subscription at the destination point. > > Cheers, > > Thomas > > > Best regards, Luis --0015174bdee286aec4049fb8101a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
three additional comments, on your mail

the query is typically sent when= the link comes up, see http://tools.i= etf.org/html/draft-ietf-multimob-pmipv6-base-solution-07#appendix-A, la= test after the link-local address is configured. On a ptp-link, this costs = virtually no time.
Luis>> That's true, but this always come after PBU/PBA compl= etion (the PBA carries the local-link address of the MAG, needed to send th= e MLD Query to the MN)

The biggest issue in handove= r delay is DAD, otherwise PBU/PBA when the LMA is far remote.

So in = conclusion, multicast state acquisition after handover is not an issue of t= ime - the delays arise from unicast handover and address configuration.
Luis>> So the lower limit in the delay for multicast context tra= nsfer is the unicast handover. The fastest solution is then the one that eq= uals the unicast handover.

That's why I question th= e value of an additional multicast context transfer independent of the unic= ast handover.
Luis>> I think on two reasons:
.- Multicast traffic typically serves real-time traffic, that is, a tr= affic more sensitive to delay
.- The multicast state is kept at MAG level (the LMA doesn't know= =A0the specific=A0subscriptions of=A0the MN)=A0. For efficient service cont= inuity, it seems better to transfer the subscription information than to re= build the subscription at the destination point.
=A0

Cheers,

Thomas=20

=A0
Best regards,
Luis
=A0
--0015174bdee286aec4049fb8101a-- From contreras.uc3m@gmail.com Wed Mar 30 12:39:30 2011 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 4923928C18A for ; Wed, 30 Mar 2011 12:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, 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 q8yI8lG1dpgE for ; Wed, 30 Mar 2011 12:39:28 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id DBAC228C0DE for ; Wed, 30 Mar 2011 12:39:27 -0700 (PDT) Received: by ewy19 with SMTP id 19so588200ewy.31 for ; Wed, 30 Mar 2011 12:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0C1FyBB1d/+/VniPUPitEyUILOHcpyNxsCZPYNZHamY=; b=jc0OUQHOXpeg8slHG0s2QQKYp6LopjZtG89mOE2xvFg+tQ5e9zeBB+bFGUOy3Rg96Q vTRPKZLQpBU0PI3izcP6M+4uKpwj2S5J4ppELUUz/y5Zpp7hrKLJAHkccPkXznvKlDUv R7fku++uPqAByO88TA0N/fu0MjCj+KvxBAcPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DcRd/TW7zlDuzHNUCQF8B/IfD/52DLXhX5jdrfLt/rLBtGuNqbY31WZ+dCdO61Sz3j uOaQq5mydcv6Q2B+rDhEPWqcZ+Weq/RE24l0T94ZZ7J3qgFLCmYEHOftHXsDU+mCyFUV A0IlITzxAJ1Qm5wFmyUH0W+/jcYymEIINAiPA= MIME-Version: 1.0 Received: by 10.213.27.14 with SMTP id g14mr1225464ebc.63.1301514066129; Wed, 30 Mar 2011 12:41:06 -0700 (PDT) Received: by 10.213.15.201 with HTTP; Wed, 30 Mar 2011 12:41:05 -0700 (PDT) In-Reply-To: <4D91F335.40709@informatik.haw-hamburg.de> References: <4D91F335.40709@informatik.haw-hamburg.de> Date: Wed, 30 Mar 2011 21:41:05 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=0015174c1bfa94f537049fb85b04 Cc: "multimob@ietf.org" Subject: Re: [multimob] Thoughts on PMIP Optimized Routing 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, 30 Mar 2011 19:39:30 -0000 --0015174c1bfa94f537049fb85b04 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, some comments below: 2011/3/29 Thomas C. Schmidt > Hi all, > > after the presentations and discussions today, the following thoughts came > up. > > 1. Scenarios for tunnel convergence problem > > Tunnel convergence is an issue of heavily used multicast reception. This > only occurs for major events (e.g., sports on IPTV), or in flashcrowds, both > scenarios cannot be serviced today (by unicast). For such situations, it may > be realistic to assume that operators (somehow) pull the particular content > into their network and deploy local multicast routing for scalability > reasons. This is actually the cheapest and easiest. (There may be > "political" reasons to act differently, though.) It may also be that some > local social community group service is established within operator domains > (with MNs acting as sources and receivers). Luis>> The traffic is commonly placed close to the user in streaming scenarios, based on unicast delivery. In this situation it makes sense to deploy content locally, because a lot of resources are saved along the network. However, we are talking here of multicast, where only one flow for a major event is sent from the Home Network to the LMA in the border of the Visited Network. There is no better scalability than this. Internally, in the Visited Network, both the LMA and the MR are connected to the same number of MAGs, so not very much scalability advantage can be foreseen for local routing (of course, it depends on the topology). Operationally, to pull local content for certain events does not seem an easy task. It forces the Home network operator firstly to determine what kind of events are worthy to be deployed on local routing fashion, and what other not; secondly, to place locally in multiple Visited network the content (maybe a different content per Visited network), maybe in some timeframes of the day (e.g. football match duration), etc, etc. Only to save one multicast flow per content. I really don't see the benefit. > > Assuming this scenario, we need to provide > > * Coexistence of home/remote content retrieval (e.g., by the base > solution) and access from local multicast routing. Thus a MAG would need to > distinguish (preconfigured) local group subscriptions from non-local > content. Luis>> This is not possible with current functionality on MAG as MLD proxy. It is only possible to define one upstream interface, so the operator would be forced to permanently choose between local or remote multicast for all kind of traffic. > > * Account for the scenario of Sri that an MN may move between PMIP > domains, but stay with its LMA. This means that content that has been > locally accessible at the previous MAG can only be retrieved via home its > remote LMA at the new MAG. Luis>> This seems to not be affordable with other solution distinct to the M-LMA approach. How is the multicast traffic delivered from pMAG to nMAG via the LMA? Is it sent on unicast flows, one per MN attached to nMAG? Is it sent tunneled from pMAG to LMA?. In that case, is it pMAG multicast router to accept subscriptions coming from LMA? Please, compare this with the starightforward delivery of the multicast content from a common M-LMA placed in the border of both PMIPv6 domains. No strange mechanisms are needed to maintain multicast service for the MN changing the PMIPv6 domain. > > 2. State of the current proposals from the perspective of the above > scenarios > > (a) M-tunnels to (unassociated) LMAs (Hitoschi) - aside from the other > issues discussed today, this approach does seam to just "distribute load" > over different LMAs and tunnels without addressing the specific scenario. > > (b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos) - this approach > has the inverse scaling problem (avalanche) in the major event setting, > i.e., the "M-LMA" needs to replicate data streams to all MAGs. So it sort of > threatens the devil by being the beelzebub. In addition, it introduces the > unpleasant asymmetry in routing Matthias mentioned in a previous mail. Luis>> The M-LMA only sends one copy per connected MAG. In the major event setting, with a lot of viewers subscribed to the same content, the M-LMA approach is more efficient than the base solution (as described in the comparison there included). Furthermore, the service is offered without complex interaction with the Visited network provider. > > (c) Local mcast routing (Seil) - this approach lacks incorporation of > home/remote content, as well as Sri's scenario. > > Best regards, Luis --0015174c1bfa94f537049fb85b04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, some comments below:

2011/3/29 Thomas C. Schmidt &l= t;schmidt@informatik.h= aw-hamburg.de>
Hi all,

after the present= ations and discussions today, the following thoughts came up.

=A01. = Scenarios for tunnel convergence problem

Tunnel convergence is an issue of heavily used multicast reception. Thi= s only occurs for major events (e.g., sports on IPTV), or in flashcrowds, b= oth scenarios cannot be serviced today (by unicast). For such situations, i= t may be realistic to assume that operators (somehow) pull the particular c= ontent into their network and deploy local multicast routing for scalabilit= y reasons. This is actually the cheapest and easiest. (There may be "p= olitical" reasons to act differently, though.) It may also be that som= e local social community group service is established within operator domai= ns (with MNs acting as sources and receivers).
=A0
Luis>> The traffic is commonly placed close to the user in strea= ming scenarios, based on unicast delivery. In this situation it makes sense= to deploy content locally, because a lot of resources are saved along the = network. However, we are talking here of multicast, where only one flow for= a major event is sent from the Home Network to the LMA in the border of th= e Visited Network. There is no better scalability than this. Internally, in= the Visited Network, both the LMA and the MR are connected to the same num= ber of MAGs, so not very much scalability advantage can be foreseen for loc= al routing (of course, it depends on the topology).
Operationally, to pull local content for certain events does not seem an ea= sy task. It forces the Home network operator firstly to determine what kind= of events are worthy to be deployed on local routing fashion, and what oth= er not;=A0secondly, to place locally=A0in multiple Visited network the cont= ent (maybe a different content per Visited network), maybe in some timefram= es of the day (e.g. football match duration), etc, etc. Only to save one mu= lticast flow per content. I really don't see the benefit.

Assuming this scenario, we n= eed to provide

=A0* Coexistence of home/remote content retrieval (e.= g., by the base solution) and access from local multicast routing. Thus a M= AG would need to distinguish (preconfigured) local group subscriptions from= non-local content.
=A0
Luis>> This is not possible with current functionality on MAG as= MLD proxy. It is only possible to define one upstream interface, so the op= erator would be forced to permanently choose between local or remote multic= ast for all kind of traffic.
=A0

=A0* Account for the scenari= o of Sri that an MN may move between PMIP domains, but stay with its LMA. T= his means that content that has been locally accessible at the previous MAG= can only be retrieved via home its remote LMA at the new MAG.
=A0
Luis>> This seems to not be affordable with other solution disti= nct to the M-LMA approach. How is the multicast traffic delivered from pMAG= to nMAG via the LMA? Is it sent on unicast flows, one per MN attached to n= MAG? Is it sent tunneled from pMAG to LMA?. In that case, is it pMAG multic= ast router to accept subscriptions coming from LMA? Please, compare this wi= th the starightforward delivery of the multicast content from a common M-LM= A placed in the border of both PMIPv6 domains. No strange mechanisms are ne= eded to maintain multicast service for the MN changing the PMIPv6 domain.
=A0

=A02. State of the current p= roposals from the perspective of the above scenarios

=A0(a) M-tunnel= s to (unassociated) LMAs (Hitoschi) - aside from the other issues discussed= today, this approach does seam to just "distribute load" over di= fferent LMAs and tunnels without addressing the specific scenario.

=A0(b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos)= - this approach has the inverse scaling problem (avalanche) in the major e= vent setting, i.e., the "M-LMA" needs to replicate data streams t= o all MAGs. So it sort of threatens the devil by being the beelzebub. In ad= dition, it introduces the unpleasant asymmetry in routing Matthias mentione= d in a previous mail.
=A0
Luis>> The M-LMA only sends one copy per connected MAG. In the m= ajor event setting, with a lot of viewers subscribed to the same content, t= he M-LMA approach is more efficient than the base solution (as described in= the comparison there included).=A0Furthermore, the service is offered with= out complex interaction with the Visited network provider.
=A0

=A0(c) Local mcast routing (= Seil) - this approach lacks incorporation of home/remote content, as well a= s Sri's scenario.

Best regards,
=A0
Luis
--0015174c1bfa94f537049fb85b04-- From seiljeon@gmail.com Wed Mar 30 18:36:09 2011 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 656793A6AEC for ; Wed, 30 Mar 2011 18:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, 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 BfnPDSmd-HTj for ; Wed, 30 Mar 2011 18:36:06 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id E704F3A6AEA for ; Wed, 30 Mar 2011 18:36:05 -0700 (PDT) Received: by qyk29 with SMTP id 29so3029673qyk.10 for ; Wed, 30 Mar 2011 18:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LL+NgC5lC0SF8y1reRSjRB+QzpFSJDplIzhIrME0pm0=; b=xnba3He5/pJbcBPEp1jdca8PRTd8N5yaLpFkoSsvRYheFfHx2zPJIhy4xc5S/IKWFm Re3tOysoSP8NJP9J8qQmdyNUABMQKNTi6F29gudQggT+pBre3xGj2bz3yXtnpvU+7yLJ 2ZmTtv5BwJA/9bGtYjrY7nMayw5jNmNJegEGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wkPX6BFVSbeA5lOB19Vcwn3WduN881j07cnuFSlW1Api+eq/7CTi7TWz3j3AE0ePkG cbMjO/LP1p1PWJVtBi84PTN3x6RZIVh65U6I5NlSqj751HfMPK9fgHbDhThHUz50I/H+ EQo/1mFP5nM/HXIZW1FfsORYQLzT+2O7WyRt0= MIME-Version: 1.0 Received: by 10.229.2.69 with SMTP id 5mr1578468qci.158.1301535464979; Wed, 30 Mar 2011 18:37:44 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.187.77 with HTTP; Wed, 30 Mar 2011 18:37:44 -0700 (PDT) In-Reply-To: References: <4D91F335.40709@informatik.haw-hamburg.de> Date: Thu, 31 Mar 2011 10:37:44 +0900 X-Google-Sender-Auth: kJyS9Ku7IV0OK3egxnfo9w5z4CE Message-ID: From: seil jeon To: "Luis M. Contreras" Content-Type: multipart/alternative; boundary=0016e64bd0740d7c0a049fbd570c Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on PMIP Optimized Routing 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, 31 Mar 2011 01:37:50 -0000 --0016e64bd0740d7c0a049fbd570c Content-Type: text/plain; charset=ISO-8859-1 Hi Luis, Please see below "Seil" 2011/3/31 Luis M. Contreras > Hi Thomas, some comments below: > > 2011/3/29 Thomas C. Schmidt > > Hi all, >> >> after the presentations and discussions today, the following thoughts came >> up. >> >> 1. Scenarios for tunnel convergence problem >> >> Tunnel convergence is an issue of heavily used multicast reception. This >> only occurs for major events (e.g., sports on IPTV), or in flashcrowds, both >> scenarios cannot be serviced today (by unicast). For such situations, it may >> be realistic to assume that operators (somehow) pull the particular content >> into their network and deploy local multicast routing for scalability >> reasons. This is actually the cheapest and easiest. (There may be >> "political" reasons to act differently, though.) It may also be that some >> local social community group service is established within operator domains >> (with MNs acting as sources and receivers). > > > Luis>> The traffic is commonly placed close to the user in streaming > scenarios, based on unicast delivery. In this situation it makes sense to > deploy content locally, because a lot of resources are saved along the > network. However, we are talking here of multicast, where only one flow for > a major event is sent from the Home Network to the LMA in the border of the > Visited Network. There is no better scalability than this. Internally, in > the Visited Network, both the LMA and the MR are connected to the same > number of MAGs, so not very much scalability advantage can be foreseen for > local routing (of course, it depends on the topology). > Operationally, to pull local content for certain events does not seem an > easy task. It forces the Home network operator firstly to determine what > kind of events are worthy to be deployed on local routing fashion, and what > other not; secondly, to place locally in multiple Visited network the > content (maybe a different content per Visited network), maybe in some > timeframes of the day (e.g. football match duration), etc, etc. Only to save > one multicast flow per content. I really don't see the benefit. > "Seil" => You don't see the benefit. why? ISPs are now making a pitch for building and getting their own contents from public broadcasters, cable broadcasters, ... so on. Obiviously, this is inevitable trend to achieve competiveness from other ISPs. That will be getting serious more than now. And as I presented in my slot, this concept is reflected at MBMS architecture of 3GPP SAE. Only appropriate manner needs to be handled between home and visited network. About that, the draft will be updated. In M-LMA, how about local contents? > Assuming this scenario, we need to provide >> >> * Coexistence of home/remote content retrieval (e.g., by the base >> solution) and access from local multicast routing. Thus a MAG would need to >> distinguish (preconfigured) local group subscriptions from non-local >> content. > > > Luis>> This is not possible with current functionality on MAG as MLD proxy. > It is only possible to define one upstream interface, so the operator would > be forced to permanently choose between local or remote multicast for all > kind of traffic. > "Seil" => Yes, it's possible. Only one upstream interface is available but "per single MLD proxy instance". So, the choice will not be forced to operators. > > >> * Account for the scenario of Sri that an MN may move between PMIP >> domains, but stay with its LMA. This means that content that has been >> locally accessible at the previous MAG can only be retrieved via home its >> remote LMA at the new MAG. > > > Luis>> This seems to not be affordable with other solution distinct to the > M-LMA approach. How is the multicast traffic delivered from pMAG to nMAG via > the LMA? Is it sent on unicast flows, one per MN attached to nMAG? Is it > sent tunneled from pMAG to LMA?. In that case, is it pMAG multicast router > to accept subscriptions coming from LMA? Please, compare this with the > starightforward delivery of the multicast content from a common M-LMA placed > in the border of both PMIPv6 domains. No strange mechanisms are needed to > maintain multicast service for the MN changing the PMIPv6 domain. > "Seil" => Actually, M-LMA should not be said "LMA" as pointed out in the meeting because there's no PMIP action with a MAG and no information related to MNs. And I wonder only one M-LMA is enough to connect with MAGs in visited domain because M-LMA must be managed by certain operator. > >> 2. State of the current proposals from the perspective of the above >> scenarios >> >> (a) M-tunnels to (unassociated) LMAs (Hitoschi) - aside from the other >> issues discussed today, this approach does seam to just "distribute load" >> over different LMAs and tunnels without addressing the specific scenario. >> >> (b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos) - this >> approach has the inverse scaling problem (avalanche) in the major event >> setting, i.e., the "M-LMA" needs to replicate data streams to all MAGs. So >> it sort of threatens the devil by being the beelzebub. In addition, it >> introduces the unpleasant asymmetry in routing Matthias mentioned in a >> previous mail. > > > Luis>> The M-LMA only sends one copy per connected MAG. In the major event > setting, with a lot of viewers subscribed to the same content, the M-LMA > approach is more efficient than the base solution (as described in the > comparison there included). Furthermore, the service is offered without > complex interaction with the Visited network provider. > > "Seil" => In terms of "traffic distribution", hitoshi's approach is better than M-LMA. And local routing is the best among them. > >> (c) Local mcast routing (Seil) - this approach lacks incorporation of >> home/remote content, as well as Sri's scenario. >> >> Best regards, > > Luis > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > Your regards, Seil Jeon --0016e64bd0740d7c0a049fbd570c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Luis,
=A0
Please see below "Seil"
=A0

=A0
2011/3/31 Luis M. Contreras &l= t;contreras.uc3m@gmail.com&= gt;
Hi Thomas, some comments below:<= br>
2011/3/29 Thomas C. Schmidt &l= t;sc= hmidt@informatik.haw-hamburg.de>=20

Hi all,

after the present= ations and discussions today, the following thoughts came up.

=A01. = Scenarios for tunnel convergence problem

Tunnel convergence is an issue of heavily used multicast reception. Thi= s only occurs for major events (e.g., sports on IPTV), or in flashcrowds, b= oth scenarios cannot be serviced today (by unicast). For such situations, i= t may be realistic to assume that operators (somehow) pull the particular c= ontent into their network and deploy local multicast routing for scalabilit= y reasons. This is actually the cheapest and easiest. (There may be "p= olitical" reasons to act differently, though.) It may also be that som= e local social community group service is established within operator domai= ns (with MNs acting as sources and receivers).
=A0
Luis>> The traffic is commonly placed close to the user in strea= ming scenarios, based on unicast delivery. In this situation it makes sense= to deploy content locally, because a lot of resources are saved along the = network. However, we are talking here of multicast, where only one flow for= a major event is sent from the Home Network to the LMA in the border of th= e Visited Network. There is no better scalability than this. Internally, in= the Visited Network, both the LMA and the MR are connected to the same num= ber of MAGs, so not very much scalability advantage can be foreseen for loc= al routing (of course, it depends on the topology).
Operationally, to pull local content for certain events does not seem an ea= sy task. It forces the Home network operator firstly to determine what kind= of events are worthy to be deployed on local routing fashion, and what oth= er not;=A0secondly, to place locally=A0in multiple Visited network the cont= ent (maybe a different content per Visited network), maybe in some timefram= es of the day (e.g. football match duration), etc, etc. Only to save one mu= lticast flow per content. I really don't see the benefit.
=A0
=A0
"Seil" =3D>=A0You don't see the benefit. why? ISPs ar= e now making a pitch for building and getting their own contents from publi= c broadcasters, cable broadcasters, ... so on. Obiviously, this is inevitab= le trend to achieve competiveness from other ISPs. That will be getting ser= ious more than now.=A0And as I presented in my slot,=A0this concept is refl= ected=A0at MBMS architecture of=A03GPP SAE. Only appropriate manner needs t= o be handled between home and visited network. About that, the draft will b= e updated.
=A0
=A0=A0In M-LMA,=A0how about local contents?
=A0
=A0
Assuming this scenario, we need = to provide

=A0* Coexistence of home/remote content retrieval (e.g., = by the base solution) and access from local multicast routing. Thus a MAG w= ould need to distinguish (preconfigured) local group subscriptions from non= -local content.
=A0
Luis>> This is not possible with current functionality on MAG as= MLD proxy. It is only possible to define one upstream interface, so the op= erator would be forced to permanently choose between local or remote multic= ast for all kind of traffic.
=A0
=A0"Seil" =3D> Yes, it's possible. Only one upstream = interface is available but "per single MLD proxy instance". So, t= he choice will not be forced to operators.
=A0
=A0
=A0* Account for the scenario of= Sri that an MN may move between PMIP domains, but stay with its LMA. This = means that content that has been locally accessible at the previous MAG can= only be retrieved via home its remote LMA at the new MAG.
=A0
Luis>> This seems to not be affordable with other solution disti= nct to the M-LMA approach. How is the multicast traffic delivered from pMAG= to nMAG via the LMA? Is it sent on unicast flows, one per MN attached to n= MAG? Is it sent tunneled from pMAG to LMA?. In that case, is it pMAG multic= ast router to accept subscriptions coming from LMA? Please, compare this wi= th the starightforward delivery of the multicast content from a common M-LM= A placed in the border of both PMIPv6 domains. No strange mechanisms are ne= eded to maintain multicast service for the MN changing the PMIPv6 domain.
=A0
=A0"Seil" =3D> Actually, M-LMA=A0should not be said=A0&qu= ot;LMA" as pointed out in the meeting because there's no PMIP acti= on with a MAG and no=A0information related to MNs. And=A0I wonder=A0only on= e M-LMA is enough to connect with MAGs in visited domain because M-LMA must= be managed by certain operator.
=A0

=A02. State of the current p= roposals from the perspective of the above scenarios

=A0(a) M-tunnel= s to (unassociated) LMAs (Hitoschi) - aside from the other issues discussed= today, this approach does seam to just "distribute load" over di= fferent LMAs and tunnels without addressing the specific scenario.

=A0(b) Dedicated Multicast Tunnelrouter/"M-LMA" (Juan-Carlos)= - this approach has the inverse scaling problem (avalanche) in the major e= vent setting, i.e., the "M-LMA" needs to replicate data streams t= o all MAGs. So it sort of threatens the devil by being the beelzebub. In ad= dition, it introduces the unpleasant asymmetry in routing Matthias mentione= d in a previous mail.
=A0
Luis>> The M-LMA only sends one copy per connected MAG. In the m= ajor event setting, with a lot of viewers subscribed to the same content, t= he M-LMA approach is more efficient than the base solution (as described in= the comparison there included).=A0Furthermore, the service is offered with= out complex interaction with the Visited network provider.
=A0
=A0
=A0"Seil" =3D> In terms of "traffic distribution&quo= t;, hitoshi's approach is better than M-LMA. And local routing is the b= est among them.
=A0

=A0(c) Local mcast routing (= Seil) - this approach lacks incorporation of home/remote content, as well a= s Sri's scenario.

Best regards,
=A0
Luis

___________________________________________= ____
multimob mailing list
multi= mob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

Your regards,
=A0
Seil Jeon
=A0
=A0
--0016e64bd0740d7c0a049fbd570c-- From schmidt@informatik.haw-hamburg.de Thu Mar 31 10:48:08 2011 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 ADC383A6B2C for ; Thu, 31 Mar 2011 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 6sPD+eq4AvJt for ; Thu, 31 Mar 2011 10:48:07 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id AFB833A6952 for ; Thu, 31 Mar 2011 10:48:07 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q5LyN-000NHI-O4 for multimob@ietf.org; Thu, 31 Mar 2011 19:47:55 +0200 Message-ID: <4D94BEBF.8040503@informatik.haw-hamburg.de> Date: Thu, 31 Mar 2011 19:49:51 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: multimob@ietf.org References: <4D9224DC.3000503@informatik.haw-hamburg.de> <20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <69756203DDDDE64E987BC4F70B71A26D05C77D0F@Polydeuces.office.hd> <4D931F4A.9070602@informatik.haw-hamburg.de> <4D934689.4050805@informatik.haw-hamburg.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) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer 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, 31 Mar 2011 17:48:08 -0000 Hi Luis et al, some answers marked by [Thomas] On 30.03.2011 21:20, Luis M. Contreras wrote: > Hi Thomas, > three additional comments, on your mail > > the query is typically sent when the link comes up, see > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-07#appendix-A, > latest after the link-local address is configured. On a ptp-link, > this costs virtually no time. > > Luis>> That's true, but this always come after PBU/PBA completion (the > PBA carries the local-link address of the MAG, needed to send the MLD > Query to the MN) [Thomas] Well, the initial query of the router is before, when link comes up ... but the report can only be sent after PBA, that's correct. > > > The biggest issue in handover delay is DAD, otherwise PBU/PBA when > the LMA is far remote. > > So in conclusion, multicast state acquisition after handover is not > an issue of time - the delays arise from unicast handover and > address configuration. > > Luis>> So the lower limit in the delay for multicast context transfer is > the unicast handover. The fastest solution is then the one that equals > the unicast handover. [Thomas] Yes, ideally multicast is enabled with (or right after) unicast handover ... > > > That's why I question the value of an additional multicast context > transfer independent of the unicast handover. > > Luis>> I think on two reasons: > .- Multicast traffic typically serves real-time traffic, that is, a > traffic more sensitive to delay > .- The multicast state is kept at MAG level (the LMA doesn't know the > specific subscriptions of the MN) . For efficient service continuity, it > seems better to transfer the subscription information than to rebuild > the subscription at the destination point. [Thomas] IMHO, there is not much room for multicast to be treated independent of unicast, as both contexts need to be aligned to the actual handover. If multicast context transfer is not synchronized with handover, multicast context may decouple from the MN, i.e., at some times multicast groups end up at a different MAG than the MN. ... and on the other hand: if you perform a fast context transfer for multicast, you can treat this in combination with unicast. You always do exchange context records, in a HI/HACK pair or in some other pair that does not simplify the solution. Cheers, 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 contreras.uc3m@gmail.com Thu Mar 31 14:01:23 2011 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 E443128C101 for ; Thu, 31 Mar 2011 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 c-oka7T2X67Z for ; Thu, 31 Mar 2011 14:01:22 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 5F50928C0DE for ; Thu, 31 Mar 2011 14:01:22 -0700 (PDT) Received: by eye13 with SMTP id 13so992447eye.31 for ; Thu, 31 Mar 2011 14:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=swtkRFMNyT6cJBkB3Tc0Fs5kbFA+yR0c5HL7jlSqFy4=; b=XAVFg2tsWXNgYhQRY5rYqFvq3oD9JQWOpJ2HqQlkDLkFFBEwDHYnn+2Dr/N1s/KKg/ BHbPqSWGw4rOwpFsWze+bt6pdJ4DzztZGUEIsO5OzYsC8WwaIwEXjOmrYV16Dr9+OpBv Z+jj57YFNxRt4bj5V/WaOqqneongbCYkEB8ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aD3KXtkTtH4rZLkOnW6aVzrtu0ThY+fhblQhcBpoWp9etLcjRxoDWQ8Py4z9jDcARf V0DCEli0l9MVN9mEd4R/Utyxe6NXTol+RnuHh8skePjIZUf02P/MQIbDpD1vNAF+8Cgn NnUs6OlzRX6U5kVBAAhtwITY3UK0K/X6X/2ag= MIME-Version: 1.0 Received: by 10.213.7.83 with SMTP id c19mr1420468ebc.63.1301605381436; Thu, 31 Mar 2011 14:03:01 -0700 (PDT) Received: by 10.213.15.201 with HTTP; Thu, 31 Mar 2011 14:03:01 -0700 (PDT) In-Reply-To: References: <4D91F335.40709@informatik.haw-hamburg.de> Date: Thu, 31 Mar 2011 23:03:01 +0200 Message-ID: From: "Luis M. Contreras" To: seil jeon Content-Type: multipart/alternative; boundary=0015174bdee265f6e2049fcd9ec3 Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on PMIP Optimized Routing 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, 31 Mar 2011 21:01:24 -0000 --0015174bdee265f6e2049fcd9ec3 Content-Type: text/plain; charset=ISO-8859-1 Hi Seil, more discussion below: > "Seil" => You don't see the benefit. why? ISPs are now making a pitch for > building and getting their own contents from public broadcasters, cable > broadcasters, ... so on. Obiviously, this is inevitable trend to achieve > competiveness from other ISPs. That will be getting serious more than > now. And as I presented in my slot, this concept is reflected at MBMS > architecture of 3GPP SAE. Only appropriate manner needs to be handled > between home and visited network. About that, the draft will be updated. > > In M-LMA, how about local contents? > > Luis>> It is just my personal view in this interesting and necessary debate opened byThomas. I would like to distinguish two concepts: remote content distributed locally, and local content distributed locally. In the first case, I don't see the benefit. I think that the simplest way to deliver the service is through M-LMA. In the second case, I agree that it seems more optimal to use direct routing. But, in my opinion, the direct routing can not be consider as the main solution, but an ocassional optimization scenario in case the content is local to the visited domain (probably the most common is that a MN usually will demand contents from its Home Network, because the user maintains a service contract its Home Operator). I think it is the same idea than in the unicast case regarding the routing optimization: it is an optimization case for a more general solution (which I believe it is the M-LMA approach). > * Coexistence of home/remote content retrieval (e.g., by the base > solution) and access from local multicast routing. Thus a MAG would need to > distinguish (preconfigured) local group subscriptions from non-local > content. > >> >> Luis>> This is not possible with current functionality on MAG as MLD >> proxy. It is only possible to define one upstream interface, so the operator >> would be forced to permanently choose between local or remote multicast for >> all kind of traffic. >> > > "Seil" => Yes, it's possible. Only one upstream interface is available but > "per single MLD proxy instance". So, the choice will not be forced to > operators. > Luis>> I don't think so. According to base solution, the MN is associated to an MLD proxy instance as a function of the LMA it is bound to. That is, the association to an MLD instance is previous to the MLD Report processing. So, the MAG doesn't know the required content (local or remote) before associating the MN to a proxy instance. As consequence, the operator is forced to choose between using an MLD proxy pointing to the M-LMA or another one pointing to local MR for all kind of traffic, and for all the MNs associated to the same LMA. > > "Seil" => Actually, M-LMA should not be said "LMA" as pointed out in the > meeting because there's no PMIP action with a MAG and no information related > to MNs. And I wonder only one M-LMA is enough to connect with MAGs in > visited domain because M-LMA must be managed by certain operator. > Luis>> I'm not totally agree with this (it is my personal opinion). I think that establishing a tunnel following PMIPv6 procedures can be considered a PMIP action. Furthermore, all other stuff related with security, authentication, heartbeat, load balancing, etc, etc, defined in PMIPv6 can be applicable in an straightforward manner. It is true that there is no information per MN, but the protocol procedures of PMIPv6 are wider than this. Regarding the number of M-LMAs per visited domain, I consider possible that different Home providers connect to a common Visited Network, each of them managing its own M-LMA, and sharing (or not) the MAGs placed in the Visited network. > > "Seil" => In terms of "traffic distribution", hitoshi's approach is better > than M-LMA. And local routing is the best among them. > Luis>> I need to study this to provide a comparison. Thanks all for this enriching discussion, best regards, Luis --0015174bdee265f6e2049fcd9ec3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Seil,
=A0
more discussion below:

=A0
"Seil" =3D>=A0You don't see the benefit. why? ISPs ar= e now making a pitch for building and getting their own contents from publi= c broadcasters, cable broadcasters, ... so on. Obiviously, this is inevitab= le trend to achieve competiveness from other ISPs. That will be getting ser= ious more than now.=A0And as I presented in my slot,=A0this concept is refl= ected=A0at MBMS architecture of=A03GPP SAE. Only appropriate manner needs t= o be handled between home and visited network. About that, the draft will b= e updated.
=A0
=A0=A0In M-LMA,=A0how about local contents?
=A0
=A0
Luis>> It is just my personal view in this interesting and neces= sary debate opened byThomas. I would like to distinguish two concepts: remo= te content distributed locally, and local content distributed locally. In t= he first case, I don't see the benefit. I think that the simplest way t= o deliver the service is through M-LMA. In the second case, I agree that it= seems more optimal to use direct routing. But, in my opinion, the direct r= outing can not be consider as the main solution, but an ocassional optimiza= tion scenario in case the content is local to the visited domain (probably = the most common is that a MN usually will demand contents from its Home Net= work, because the user maintains a service contract its Home Operator). I t= hink it is the same idea than in the unicast case regarding the routing opt= imization: it is an optimization case for a more general solution (which I = believe it is the M-LMA approach).
=A0
=A0
=A0* Coexistence of home/remote content retrieval (e.g., by the base s= olution) and access from local multicast routing. Thus a MAG would need to = distinguish (preconfigured) local group subscriptions from non-local conten= t.
=A0
Luis>> This is not possible with current functionality on MAG as= MLD proxy. It is only possible to define one upstream interface, so the op= erator would be forced to permanently choose between local or remote multic= ast for all kind of traffic.
=A0
=A0"Seil" =3D> Yes, it's possible. Only one upstream = interface is available but "per single MLD proxy instance". So, t= he choice will not be forced to operators.
=A0
Luis>> I don't think so. According to base solution, the MN = is associated to an MLD proxy instance as a function=A0of the LMA it is bou= nd to. That is, the association to an MLD instance is previous to the MLD R= eport processing. So, the MAG doesn't know the required content (local = or remote) before associating the MN to a proxy instance. As consequence, t= he operator is forced to choose between using an MLD proxy pointing to the = M-LMA or another one pointing to local MR for all kind of traffic, and for = all the MNs associated to the same LMA.
=A0
=A0
=A0"Seil" =3D> Actually, M-LMA=A0should not be said=A0&qu= ot;LMA" as pointed out in the meeting because there's no PMIP acti= on with a MAG and no=A0information related to MNs. And=A0I wonder=A0only on= e M-LMA is enough to connect with MAGs in visited domain because M-LMA must= be managed by certain operator.
=A0
Luis>> I'm not totally agree with this (it is my personal op= inion). I think that establishing a tunnel following PMIPv6 procedures can = be considered a PMIP action. Furthermore, all other stuff related with secu= rity, authentication, heartbeat, load balancing, etc, etc, defined in PMIPv= 6 can be applicable in an straightforward manner. It is true that there is = no information per MN, but the protocol procedures of PMIPv6 are wider than= this.
=A0
Regarding the number of M-LMAs per visited domain, I consider possible= that different Home providers connect to a common Visited Network, each of= them managing its own M-LMA, and sharing (or not) the MAGs placed in the V= isited network.
=A0
=A0
=A0"Seil" =3D> In terms of "traffic distribution&quo= t;, hitoshi's approach is better than M-LMA. And local routing is the b= est among them.
=A0
Luis>> I need to study this to provide a comparison.
=A0
Thanks all for this enriching discussion,
=A0
best regards,
=A0
Luis
--0015174bdee265f6e2049fcd9ec3--