From luisc@it.uc3m.es Mon Jan 4 15:48:40 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671923A69D0 for ; Mon, 4 Jan 2010 15:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov5judygpvIc for ; Mon, 4 Jan 2010 15:48:39 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EF0FB3A6801 for ; Mon, 4 Jan 2010 15:48:38 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 7BDCE7F6FE4; Tue, 5 Jan 2010 00:48:35 +0100 (CET) Received: from 44.pool85-49-217.dynamic.orange.es (44.pool85-49-217.dynamic.orange.es [85.49.217.44]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 05 Jan 2010 00:48:35 +0100 Message-ID: <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> Date: Tue, 05 Jan 2010 00:48:35 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> In-Reply-To: <4B291EF2.7070808@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17112.002 Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 04 Jan 2010 23:48:40 -0000 Happy 2010 to all members of the list. After reading the new version of the draft-schmidt-multimob-pmipv6-mcast-deployment, I have some comments, thoughts and doubts on it, listed below. 1/ on page 4, second paragraph: "... group membership management as signaled by the Multicast Listener Discovery protocol [RFC3810], [RFC2710] requires a dedicated treatment at the network side ..." Due to the fact that either MAG or LMA will be equipments of a core network, any modification or tuning of multicast-related protocol parameters will appply not only to mobile part, but also to potential fixed multicast users using multicast capabilities of both of them, if that equipment is shared between mobile and fixed parts of the network. That could be a deployment objective for a network operator, looking for network roll-out sinergies. For that reason, the tuning of such parameters could not be optimal for the mobile case, except if it is established that the multicast functionalities of such boxes are only focused on and applicable to mobile users. 2/ on page 6, second paragraph: "... the LMA will implement appropriate multicast forwarding states at its tunnel interface." It could be the case in the network that some MAGs do not have multicast capabilities. Without extending the PMIPv6 protocol, the LMA is not able to know this fact in advance. So, the LMA could configure multicast capabilities and waiting for multicast related messages on a tunnel where the other end, the MAG, is not able to send them because it does not have multicast capabilities. Could be this a security threat? 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 [RFC3376] signaling for multicast ..." What about IGMPv2? Is there any reason for not including it? 4/ on page 8, fourth paragraph: "It therefore needs to implement an instance of the MLD proxy function [RFC4605] for each upstream tunnel interface that has been established with an LMA." It could be the case that the tunnel between LMA and MAG is not shared among MNs, but dedicated per MN. In that case a new MLD proxy per upstream tunnel interface imply an MLD proxy instance per MN, as worst case. Even if the shared tunnel seems to be the most logical way of solution deployment, these scalability issues should be reflected in the draft, with a recommendation or an advise of using shared tunnels for this solution to avoid such scalability problems. 5/ on page 8, fifth paragraph: "On the reception of MLD reports from an MN, the MAG MUST identify the corresponding proxy instance from the incoming interface and perform regular MLD proxy operations..." Using the same arguments of a past discussion on the mailing list between Hitoshi, Thomas and me about what can be considered as a protocol extension, I think that some aspects of this solution could also fit on such categorization, because from my point of view some of the functions required for this solution can not be implemented based on existing RFCs. IMO, functions such as dynamic set up of an MLD proxy instance per tunnel, binding association between MLD proxy instance and a certain LMA, or MLD proxy instance identification for the General Query message delivery based on the LMA serving an MN during the handover process, are functions not yet documented on existing RFCs. So, this features could be seen also as protocol extension even if no new messages are introduced in this solution. 6/ on page 9, first paragraph: "To learn about multicast groups subscribed by a newly attaching MN, the MAG sends a General Query to the MN's link." The MNs could use different operating systems with distinc support of group membership protocols. In an IPv6-based MN, the operating system could use either MLDv1 or v2 for subscribing multicast contents. In a similar way, IPv4-based MN could use IGMPv2 or v3. When a MN attaches to a new MAG. this new MAG ignores the group membership protocol in use by the operating system of the MN. For instance, in the IPv6 case, an MLD General Query is sent by the MAG, but if MAG runs MLDv2 and MN runs MLDv1, the query will be ignored. This could drive to inefficiencies and delay on delivering the multicast content to the MN. So, two possible solutions could be envisioned: (1) send one query per group membership version; or (2) send just one query of the lower version of the group membership protocol, because backward compatibility is ensured from the higher to the lower version. 7/ on page 9, second paragraph: "To prevent erroneous query timeouts at the MAG, MLD parameters SHOULD be carefully adjusted to the mobility regime. In particular, MLD timers and the Robustness Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant with the time scale of handover operations in the PMIPv6 domain." Comment 1 applies also here. 8/ on page 10, first bullet: "The LMA thus terminates multicast forwarding." The LMA will terminate the multicast forwarding downstream, but should not terminate immediately the reception of the content (by means of an MLD Done message upstream, if LMA acts as MLD proxy, or PIM prune message signalling upstream, if it acts as mutlicast router) because the MN could attach to another MAG in a short time. This protocol timing needs also to be reviewed to fit the PMIPv6 scenarios. 9/ on page 11, last paragraph: "... no new threats arrive from procedures described in this document in excess to [RFC3810], [RFC4605] and [RFC5213] security concerns." Comment 2 applies also here. 10/ on page 15, setting 2 evaluation. I think that the value for the number of simultaneous streams at LMA in the case of dedicated multicast LMA is not correct. If I understand well, the topology under consideration is the following: MAG1 to MAG50 are connected to LMA1, LMA2, LMA3 and LMA4 for unicast traffic, using one tunnel from every MAG to every LMA, and also they are connected to LMA-multicast for multicast traffic. Due that the multicast traffic is provided by a single LMA-multicast, each MAGs needs a single MLD proxy instance to manage such multicast traffic, and so, just one tunnel is required between any MAG to the LMA multicast. In this situation, the number of simultaneous streams at LMA-multicast is 50, not 200 as reported in the draft (200 would be the number obtained if we consider 4 MLD proxy instances per MAG, as in the combined unicast/multicast case, but it has no sense when using a dedicated LMA-multicast box) [Maybe Guang or Juan Carlos could confirm this]. So, the numbers should be as follows: Setting 2: +===================+================+===================+ | PMIP multicast | # of redundant | # of sim. streams | | scheme | streams at MAG | at LMA / LMA-M | +===================+================+===================+ | Combined Unicast/ | 4 | 50 | | Multicast LMA | | | +-------------------+----------------+-------------------+ | Dedicated | 0 | 50 | | Multicast LMA | | | +-------------------+----------------+-------------------+ 11/ on Appendix B. As mentioned in Comment 4, the worst case for the combined unicast/multicast LMA solution proposed by your draft is the case in which a new tunnel is set up per MN, that is, the tunnels between MAG and LMA are not shared among MNs. IMO this would represent the extremal case for this solution. In that case, the numbers for setting two would be: Setting 2: +===================+================+===================+ | PMIP multicast | # of redundant | # of sim. streams | | scheme | streams at MAG | at LMA / LMA-M | +===================+================+===================+ | Combined Unicast/ | 20000 | 50 | | Multicast LMA | | | +-------------------+----------------+-------------------+ | Dedicated | 0 | 50 | | Multicast LMA | | | +-------------------+----------------+-------------------+ --- Regards, Luis From behcetsarikaya@yahoo.com Tue Jan 5 08:03:26 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C079B28C112 for ; Tue, 5 Jan 2010 08:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPeOJjDZ-0FC for ; Tue, 5 Jan 2010 08:03:25 -0800 (PST) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id 8177628C10A for ; Tue, 5 Jan 2010 08:03:25 -0800 (PST) Received: (qmail 92260 invoked by uid 60001); 5 Jan 2010 16:03:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262707404; bh=6S/lUpTOHfW5vBCUhi5b1nvte+BYP54UEuIoeqzfRto=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SsxIghTkuZrq92ZbBRorxknF0ESzXEvRn+XWaWlpKZxxvwEbT5Nr/cXDySa1TNUPx1dZLmEmpB35iqmt83owRXykiWvEgw8ep4qc/xaHKQDk+sRf9Ipb74KnpsJvl/SHtOSvm2CTI5J9snnfO8hNulfSOjZFYsgFZAq2g6IjFSA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DQ1k6yebdclA+WYM8iQhBBocgLdrUsZmpSittMYj6fbcgXb5HrQW5yX4YioboZFDSTsTMB+E2hJwOHk0Z99AmbUyT/yF5NixzyfnmqClr6vTTOE0EVAN5Po6kSkORo6UJ9ISE2NsiGBD5l7Nnx8niZPrqq5eTS2KIXrOITeP2/4=; Message-ID: <599336.90673.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: sFVmOXYVM1mkQa5jAH3Q.bVxHebpiwUxaGNREY6PE6pO1N1SSmxyzf6ZjZ29CQlA2hIUxud5f8OCRjVWKx3fCmDbcNrpnwPY3wmV9CBNef6G1f5P0qz2cui_R6nxIvxOxIUSLaMYgmnPA_OxV4X3geLmgKH6roXc2NzZ.qdCwVE8vLj68zvAba9_NeODKZmLNNEE2fQJj5tvwGSiPrecWZAnQV.iPU54cMuFhpwowWO3JY1v9VN27grp8izleBCIg_lZTybNXUnNqOeqDw5Fram_iFuW7AsOmAIdBth7LSk28piseOVI4yuCxyZutLoSPLVBEyUEwCC6gb__lL7WfuFhuFEj_2xW7ToMh8v4 Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Tue, 05 Jan 2010 08:03:24 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> Date: Tue, 5 Jan 2010 08:03:24 -0800 (PST) From: Behcet Sarikaya To: "Luis M. Contreras" In-Reply-To: <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 05 Jan 2010 16:03:26 -0000 Hi Luis,=0A=A0Happy New Year to all!=0A=0AOne point I would like to clarify= : the charter clearly states IGMPv3/MLDv2, so we are not chartered to deal = with intricacies of dealing with various versions of IGMP and MLD.=0A=0AReg= ards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Luis M. = Contreras =0A> To: Thomas C. Schmidt =0A> Cc: multimob@ietf.org=0A> Sent: Mon, January 4, 2010 5:= 48:35 PM=0A> Subject: Re: [multimob] [Fwd: New Version Notification for dra= ft-schmidt-multimob-pmipv6-mcast-deployment-03]=0A> =0A> Happy 2010 to all = members of the list.=0A> =0A> After reading the new version of the =0A> dra= ft-schmidt-multimob-pmipv6-mcast-deployment, I have some comments, thoughts= =0A> and doubts on it, listed below.=0A> =0A> 1/ on page 4, second paragra= ph: "... group membership management as signaled by =0A> the Multicast List= ener Discovery protocol [RFC3810], [RFC2710] requires a =0A> dedicated trea= tment at the network side ..."=0A> Due to the fact that either MAG or LMA w= ill be equipments of a core network, any =0A> modification or tuning of mul= ticast-related protocol parameters will appply not =0A> only to mobile part= , but also to potential fixed multicast users using multicast =0A> capabili= ties of both of them, if that equipment is shared between mobile and =0A> f= ixed parts of the network. That could be a deployment objective for a netwo= rk =0A> operator, looking for network roll-out sinergies. For that reason, = the tuning of =0A> such parameters could not be optimal for the mobile case= , except if it is =0A> established that the multicast functionalities of su= ch boxes are only focused on =0A> and applicable to mobile users.=0A> =0A> = 2/ on page 6, second paragraph: "... the LMA will implement appropriate =0A= > multicast forwarding states at its tunnel interface."=0A> It could be the= case in the network that some MAGs do not have multicast =0A> capabilities= . Without extending the PMIPv6 protocol, the LMA is not able to know =0A> t= his fact in advance. So, the LMA could configure multicast capabilities and= =0A> waiting for multicast related messages on a tunnel where the other en= d, the MAG, =0A> is not able to send them because it does not have multicas= t capabilities. Could =0A> be this a security threat?=0A> =0A> 3/ on page 7= , first paragraph: " Such mobile node will use IGMPv3 [RFC3376] =0A> signal= ing for multicast ..."=0A> What about IGMPv2? Is there any reason for not i= ncluding it?=0A> =0A> 4/ on page 8, fourth paragraph: "It therefore needs t= o implement an instance of =0A> the MLD proxy function [RFC4605] for each u= pstream tunnel interface that has =0A> been established with an LMA."=0A> I= t could be the case that the tunnel between LMA and MAG is not shared among= =0A> MNs, but dedicated per MN. In that case a new MLD proxy per upstream = tunnel =0A> interface=A0 imply an MLD proxy instance per MN, as worst case.= Even if the shared =0A> tunnel seems to be the most logical way of solutio= n deployment, these =0A> scalability issues should be reflected in the draf= t, with a recommendation or an =0A> advise of using shared tunnels for this= solution to avoid such scalability =0A> problems.=0A> =0A> 5/ on page 8, f= ifth paragraph: "On the reception of MLD reports from an MN, the =0A> MAG M= UST identify the corresponding proxy instance from the incoming interface = =0A> and perform regular MLD proxy operations..."=0A> Using the same argume= nts of a past discussion on the mailing list between =0A> Hitoshi, Thomas a= nd me about what can be considered as a protocol extension, I =0A> think th= at some aspects of this solution could also fit on such categorization, =0A= > because from my point of view some of the functions required for this sol= ution =0A> can not be implemented based on existing RFCs. IMO, functions su= ch as dynamic =0A> set up of an MLD proxy instance per tunnel, binding asso= ciation between MLD =0A> proxy instance and a certain LMA, or MLD proxy ins= tance identification for the =0A> General Query message delivery based on t= he LMA serving an MN during the =0A> handover process, are functions not ye= t documented on existing RFCs. So, this =0A> features could be seen also as= protocol extension even if no new messages are =0A> introduced in this sol= ution.=0A> =0A> 6/ on page 9, first paragraph: "To learn about multicast gr= oups subscribed by a =0A> newly attaching MN, the MAG sends a General Query= to the MN's link."=0A> The MNs could use different operating systems with = distinc support of group =0A> membership protocols. In an IPv6-based MN, th= e operating system could use either =0A> MLDv1 or v2 for subscribing multic= ast contents. In a similar way, IPv4-based MN =0A> could use IGMPv2 or v3. = When a MN attaches to a new MAG. this new MAG ignores =0A> the group member= ship protocol in use by the operating system of the MN. For =0A> instance, = in the IPv6 case, an MLD General Query is sent by the MAG, but if MAG =0A> = runs MLDv2 and MN runs MLDv1, the query will be ignored. This could drive t= o =0A> inefficiencies and delay on delivering the multicast content to the = MN.=0A> So, two possible solutions could be envisioned: (1) send one query = per group =0A> membership version; or (2) send just one query of the lower = version of the group =0A> membership protocol, because backward compatibili= ty is ensured from the higher =0A> to the lower version.=0A> =0A> 7/ on pag= e 9, second paragraph: "To prevent erroneous query timeouts at the MAG, =0A= > MLD parameters SHOULD be carefully adjusted to the mobility regime.=A0 In= =0A> particular, MLD timers and the Robustness Variable (see section 9 of = [RFC3810]) =0A> MUST be chosen to be compliant with the time scale of hando= ver operations in the =0A> PMIPv6 domain."=0A> Comment 1 applies also here.= =0A> =0A> 8/ on page 10, first bullet: "The LMA thus terminates multicast f= orwarding."=0A> The LMA will terminate the multicast forwarding downstream,= but should not =0A> terminate immediately the reception of the content (by= means of an MLD Done =0A> message upstream, if LMA acts as MLD proxy, or P= IM prune message signalling =0A> upstream, if it acts as mutlicast router) = because the MN could attach to another =0A> MAG in a short time. This proto= col timing needs also to be reviewed to fit the =0A> PMIPv6 scenarios.=0A> = =0A> 9/ on page 11, last paragraph: "... no new threats arrive from procedu= res =0A> described in this document in excess to [RFC3810], [RFC4605] and [= RFC5213] =0A> security concerns."=0A> Comment 2 applies also here.=0A> =0A>= 10/ on page 15, setting 2 evaluation.=0A> I think that the value for the n= umber of simultaneous streams at LMA in the case =0A> of dedicated multicas= t LMA is not correct. If I understand well, the topology =0A> under conside= ration is the following: MAG1 to MAG50 are connected to LMA1, LMA2, =0A> LM= A3 and LMA4 for unicast traffic, using one tunnel from every MAG to every L= MA, =0A> and also they are connected to LMA-multicast for multicast traffic= . Due that the =0A> multicast traffic is provided by a single LMA-multicast= , each MAGs needs a =0A> single MLD proxy instance to manage such multicast= traffic, and so, just one =0A> tunnel is required between any MAG to the L= MA multicast. In this situation, the =0A> number of simultaneous streams at= LMA-multicast is 50, not 200 as reported in =0A> the draft (200 would be t= he number obtained if we consider 4 MLD proxy instances =0A> per MAG, as in= the combined unicast/multicast case, but it has no sense when =0A> using a= dedicated LMA-multicast box) [Maybe Guang or Juan Carlos could confirm =0A= > this].=0A> So, the numbers should be as follows:=0A> Setting 2:=0A> +=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=0A> | PMIP multicast=A0 =A0 | # of redundant | # of sim. s= treams |=0A> | scheme=A0 =A0 =A0 =A0 =A0 =A0 | streams at MAG | at LMA / LM= A-M=A0 =A0 |=0A> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=0A> | Combined Unicast/ |=A0 =A0 =A0 =A0= =A0 4=A0 =A0 |=A0 =A0 =A0 =A0 =A0 50=A0 =A0 =A0 |=0A> | Multicast LMA=A0 = =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =0A> +-------------------+----------------+-------------------+=0A> | Dedic= ated=A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 0=A0 =A0 |=A0 =A0 =A0 =A0 =A0 50= =A0 =A0 =A0 |=0A> | Multicast LMA=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A> +-------------------+------------= ----+-------------------+=0A> =0A> 11/ on Appendix B.=0A> As mentioned in C= omment 4, the worst case for the combined unicast/multicast LMA =0A> soluti= on proposed by your draft is the case in which a new tunnel is set up per = =0A> MN, that is, the tunnels between MAG and LMA are not shared among MNs.= IMO this =0A> would represent the extremal case for this solution. In that= case, the numbers =0A> for setting two would be:=0A> Setting 2:=0A> +=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=0A> | PMIP multicast=A0 =A0 | # of redundant | # of sim. s= treams |=0A> | scheme=A0 =A0 =A0 =A0 =A0 =A0 | streams at MAG | at LMA / LM= A-M=A0 =A0 |=0A> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=0A> | Combined Unicast/ |=A0 =A0 =A0 200= 00=A0 =A0 |=A0 =A0 =A0 =A0 =A0 50=A0 =A0 =A0 |=0A> | Multicast LMA=A0 =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A> = +-------------------+----------------+-------------------+=0A> | Dedicated= =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 0=A0 =A0 |=A0 =A0 =A0 =A0 =A0 50=A0 = =A0 =A0 |=0A> | Multicast LMA=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=0A> +-------------------+----------------= +-------------------+=0A> =0A> ---=0A> =0A> Regards,=0A> =0A> Luis=0A> =0A>= =0A> =0A> =0A> =0A> =0A> _______________________________________________= =0A> multimob mailing list=0A> multimob@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/multimob=0A=0A=0A=0A From schmidt@informatik.haw-hamburg.de Tue Jan 5 12:19:00 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937263A68DA for ; Tue, 5 Jan 2010 12:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-0kFf2Z8SZY for ; Tue, 5 Jan 2010 12:18:59 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A9E803A684A for ; Tue, 5 Jan 2010 12:18:57 -0800 (PST) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NSFrj-0000bN-3j; Tue, 05 Jan 2010 21:18:55 +0100 Message-ID: <4B439EA3.4080705@informatik.haw-hamburg.de> Date: Tue, 05 Jan 2010 21:18:43 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> In-Reply-To: <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 05 Jan 2010 20:19:00 -0000 Hi Luis and all, happy & successful new year to all! and thanks for reviewing. Please see my comments inline. Luis M. Contreras wrote: > 1/ on page 4, second paragraph: "... group membership management as > signaled by the Multicast Listener Discovery protocol [RFC3810], > [RFC2710] requires a dedicated treatment at the network side ..." > Due to the fact that either MAG or LMA will be equipments of a core > network, any modification or tuning of multicast-related protocol > parameters will appply not only to mobile part, but also to potential > fixed multicast users using multicast capabilities of both of them, if > that equipment is shared between mobile and fixed parts of the network. > That could be a deployment objective for a network operator, looking for > network roll-out sinergies. For that reason, the tuning of such > parameters could not be optimal for the mobile case, except if it is > established that the multicast functionalities of such boxes are only > focused on and applicable to mobile users. > I don't think we can regard MAGs & LMAs equally as core routers. MAGs are access routers, thus at the edges, and both are mobility-related entities. Furthermore, at that part of the draft nothing is said about MLD tuning - just an explicit treatment is stressed, here. > 2/ on page 6, second paragraph: "... the LMA will implement appropriate > multicast forwarding states at its tunnel interface." > It could be the case in the network that some MAGs do not have multicast > capabilities. Without extending the PMIPv6 protocol, the LMA is not able > to know this fact in advance. So, the LMA could configure multicast > capabilities and waiting for multicast related messages on a tunnel > where the other end, the MAG, is not able to send them because it does > not have multicast capabilities. Could be this a security threat? > I don't think so: an LMA will only activate multicast forwarding (on a particular interface) after it has received MLD reports. If a MAG is not capable of multicast, in particular an MLD proxy function, it will not issue upstream MLD reports and thus no forwarding states will appear at the LMA. > 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 > [RFC3376] signaling for multicast ..." > What about IGMPv2? Is there any reason for not including it? > No, except for the charter. It could as well be MLDv1. > 4/ on page 8, fourth paragraph: "It therefore needs to implement an > instance of the MLD proxy function [RFC4605] for each upstream tunnel > interface that has been established with an LMA." > It could be the case that the tunnel between LMA and MAG is not shared > among MNs, but dedicated per MN. In that case a new MLD proxy per > upstream tunnel interface imply an MLD proxy instance per MN, as worst > case. Even if the shared tunnel seems to be the most logical way of > solution deployment, these scalability issues should be reflected in the > draft, with a recommendation or an advise of using shared tunnels for > this solution to avoid such scalability problems. > We can add such a remark, but the shared tunnel is the standard picture of RFC5213. If tunnels are not shared, the primary scaling issue arises from the number of (unicast) tunnels, I believe. > 5/ on page 8, fifth paragraph: "On the reception of MLD reports from an > MN, the MAG MUST identify the corresponding proxy instance from the > incoming interface and perform regular MLD proxy operations..." > Using the same arguments of a past discussion on the mailing list > between Hitoshi, Thomas and me about what can be considered as a > protocol extension, I think that some aspects of this solution could > also fit on such categorization, because from my point of view some of > the functions required for this solution can not be implemented based on > existing RFCs. IMO, functions such as dynamic set up of an MLD proxy > instance per tunnel, binding association between MLD proxy instance and > a certain LMA, or MLD proxy instance identification for the General > Query message delivery based on the LMA serving an MN during the > handover process, are functions not yet documented on existing RFCs. So, > this features could be seen also as protocol extension even if no new > messages are introduced in this solution. > This was discussed on the list in early December: Of course, RFC 4605 does not address dynamic instantiation on tunnel appearance. But this is just a time-dependent change of configuration which could be done by a script or so. We haven't tried it out in a practical set up yet, but this is not a change in protocol behavior as it only dynamically adapts system parameters. Since LMAs and MAGs are infrastructure entities (not dynamically changing), this could also be configured manually. > 6/ on page 9, first paragraph: "To learn about multicast groups > subscribed by a newly attaching MN, the MAG sends a General Query to the > MN's link." > The MNs could use different operating systems with distinc support of > group membership protocols. In an IPv6-based MN, the operating system > could use either MLDv1 or v2 for subscribing multicast contents. In a > similar way, IPv4-based MN could use IGMPv2 or v3. When a MN attaches to > a new MAG. this new MAG ignores the group membership protocol in use by > the operating system of the MN. For instance, in the IPv6 case, an MLD > General Query is sent by the MAG, but if MAG runs MLDv2 and MN runs > MLDv1, the query will be ignored. This could drive to inefficiencies and > delay on delivering the multicast content to the MN. > So, two possible solutions could be envisioned: (1) send one query per > group membership version; or (2) send just one query of the lower > version of the group membership protocol, because backward compatibility > is ensured from the higher to the lower version. > Interesting point, even though it is only loosely related to PMIP. We can add a remark on IGMP/MLD compatibility strategies. > 7/ on page 9, second paragraph: "To prevent erroneous query timeouts at > the MAG, MLD parameters SHOULD be carefully adjusted to the mobility > regime. In particular, MLD timers and the Robustness Variable (see > section 9 of [RFC3810]) MUST be chosen to be compliant with the time > scale of handover operations in the PMIPv6 domain." > Comment 1 applies also here. > ... as does the answer: Personally, I don't see a deployment where MAGs are re-used as (home-gate) access routers. But such tuning, i.e., increasing robustness and adjusting timers to characteristic wireless behavior, are not likely to harm wired networks. They might lead to an increased retransmission or so - but this should not harm the (more robust) wired links. Am I missing something relevant here? > 8/ on page 10, first bullet: "The LMA thus terminates multicast > forwarding." > The LMA will terminate the multicast forwarding downstream, but should > not terminate immediately the reception of the content (by means of an > MLD Done message upstream, if LMA acts as MLD proxy, or PIM prune > message signalling upstream, if it acts as mutlicast router) because the > MN could attach to another MAG in a short time. This protocol timing > needs also to be reviewed to fit the PMIPv6 scenarios. > Yes, but in general multicast tree management operations are not that fast. Pruning usually follows queries on the downlink. > 9/ on page 11, last paragraph: "... no new threats arrive from > procedures described in this document in excess to [RFC3810], [RFC4605] > and [RFC5213] security concerns." > Comment 2 applies also here. > ... and is answered there. > 10/ on page 15, setting 2 evaluation. > I think that the value for the number of simultaneous streams at LMA in > the case of dedicated multicast LMA is not correct. If I understand > well, the topology under consideration is the following: MAG1 to MAG50 > are connected to LMA1, LMA2, LMA3 and LMA4 for unicast traffic, using > one tunnel from every MAG to every LMA, and also they are connected to > LMA-multicast for multicast traffic. Due that the multicast traffic is > provided by a single LMA-multicast, each MAGs needs a single MLD proxy > instance to manage such multicast traffic, and so, just one tunnel is > required between any MAG to the LMA multicast. In this situation, the > number of simultaneous streams at LMA-multicast is 50, not 200 as > reported in the draft (200 would be the number obtained if we consider 4 > MLD proxy instances per MAG, as in the combined unicast/multicast case, > but it has no sense when using a dedicated LMA-multicast box) [Maybe > Guang or Juan Carlos could confirm this]. > So, the numbers should be as follows: > Setting 2: > +===================+================+===================+ > | PMIP multicast | # of redundant | # of sim. streams | > | scheme | streams at MAG | at LMA / LMA-M | > +===================+================+===================+ > | Combined Unicast/ | 4 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > | Dedicated | 0 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > This is not talking about Proxy instances, but about real physical boxes. 200 streams are needed at the dedicated LMA, because in this sample scenario we have 200 MAGs. And multicast data need to reach a MAG at least once. It's actually a simplified extreme. > 11/ on Appendix B. > As mentioned in Comment 4, the worst case for the combined > unicast/multicast LMA solution proposed by your draft is the case in > which a new tunnel is set up per MN, that is, the tunnels between MAG > and LMA are not shared among MNs. IMO this would represent the extremal > case for this solution. In that case, the numbers for setting two would be: > Setting 2: > +===================+================+===================+ > | PMIP multicast | # of redundant | # of sim. streams | > | scheme | streams at MAG | at LMA / LMA-M | > +===================+================+===================+ > | Combined Unicast/ | 20000 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > | Dedicated | 0 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > As said before: The standard picture for RFC 5213 is to share tunnels between MAGs and LMAs (otherwise you had these large numbers of tunnels already in the unicast case ...). If you consider a scenario, where individual tunnels of each MN reach the LMA, then there is actually no way to aggregate tunnel states or group data within the standard PMIP infrastructure. You either live with the scaling issues (both in unicast and multicast), or you build a separate multicast infrastructure, e.g., direct routing or dedicated multicast tunnels. Thanks, 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 Dirk.von-Hugo@telekom.de Wed Jan 6 01:11:34 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC24E3A6839 for ; Wed, 6 Jan 2010 01:11:33 -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 mrKkL6Z7QxD2 for ; Wed, 6 Jan 2010 01:11:30 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 48A563A6844 for ; Wed, 6 Jan 2010 01:11:27 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 06 Jan 2010 10:11:02 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 10:11:02 +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, 6 Jan 2010 10:10:59 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801B4024B@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4B439EA3.4080705@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] [Fwd: New VersionNotification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] Thread-Index: AcqORFZ/wmu723v3TvmO9aDG+9CbHwAZXt0Q References: <4B291EF2.7070808@informatik.haw-hamburg.de><20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 06 Jan 2010 09:11:02.0566 (UTC) FILETIME=[2B51F460:01CA8EB0] Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New VersionNotification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 06 Jan 2010 09:11:35 -0000 Dear Thomas, Luis, and all, Two comments from my side to discussed issues: =20 - to Luis' comment 1/7 on converged entities for mobile and fixed users: = >From an operator point of view it might be advantageous to serve both = classes of terminals concurrently (it seems also for me to be an = efficiency problem for fixed case only, doing no harm) - perhaps this = can be an issue for future work (e.g. to add a flag for mobile = subscriptions to select timers etc. based on degree of mobility - this = could even distinguish between slow and fast movement and HO frequency = to form corresponding tunnels) =20 - to comment 4/5 on MLD proxy per tunnel behaviour: from my = understanding also RFC4605 merges subscriptions of MNs to same multicast = group and treats them as one (converged) tunnel so I agree that it = should be a genereal PMIP unicast scalability issue and on the other = hand: the 4605 definition of membership database treatment and change = reporting to upstream allows for some dynamic behaviour which would = support MN mobility and MAG handover ...=20 And a general remark to the evaluation in the Annex (which is a good = idea I like a lot):=20 Couldn't such a rough comparison be extended also to include figures for = the other solution drafts and perhaps also estimations on created = signalling message traffic (and corrsponding time delay if applicable) = to have some metric or criteria for a decision on the future WG draft? Thanks Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Thomas C. Schmidt Gesendet: Dienstag, 5. Januar 2010 21:19 An: Luis M. Contreras Cc: multimob@ietf.org Betreff: Re: [multimob] [Fwd: New VersionNotification for = draft-schmidt-multimob-pmipv6-mcast-deployment-03] Hi Luis and all, happy & successful new year to all! and thanks for reviewing. Please see my comments inline. Luis M. Contreras wrote: > 1/ on page 4, second paragraph: "... group membership management as=20 > signaled by the Multicast Listener Discovery protocol [RFC3810],=20 > [RFC2710] requires a dedicated treatment at the network side ..." > Due to the fact that either MAG or LMA will be equipments of a core=20 > network, any modification or tuning of multicast-related protocol=20 > parameters will appply not only to mobile part, but also to potential=20 > fixed multicast users using multicast capabilities of both of them, if = > that equipment is shared between mobile and fixed parts of the = network.=20 > That could be a deployment objective for a network operator, looking = for=20 > network roll-out sinergies. For that reason, the tuning of such=20 > parameters could not be optimal for the mobile case, except if it is=20 > established that the multicast functionalities of such boxes are only=20 > focused on and applicable to mobile users. >=20 I don't think we can regard MAGs & LMAs equally as core routers. MAGs=20 are access routers, thus at the edges, and both are mobility-related=20 entities. Furthermore, at that part of the draft nothing is said about=20 MLD tuning - just an explicit treatment is stressed, here. > 2/ on page 6, second paragraph: "... the LMA will implement = appropriate=20 > multicast forwarding states at its tunnel interface." > It could be the case in the network that some MAGs do not have = multicast=20 > capabilities. Without extending the PMIPv6 protocol, the LMA is not = able=20 > to know this fact in advance. So, the LMA could configure multicast=20 > capabilities and waiting for multicast related messages on a tunnel=20 > where the other end, the MAG, is not able to send them because it does = > not have multicast capabilities. Could be this a security threat? >=20 I don't think so: an LMA will only activate multicast forwarding (on a=20 particular interface) after it has received MLD reports. If a MAG is not = capable of multicast, in particular an MLD proxy function, it will not=20 issue upstream MLD reports and thus no forwarding states will appear at=20 the LMA. > 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3=20 > [RFC3376] signaling for multicast ..." > What about IGMPv2? Is there any reason for not including it? >=20 No, except for the charter. It could as well be MLDv1. > 4/ on page 8, fourth paragraph: "It therefore needs to implement an=20 > instance of the MLD proxy function [RFC4605] for each upstream tunnel=20 > interface that has been established with an LMA." > It could be the case that the tunnel between LMA and MAG is not shared = > among MNs, but dedicated per MN. In that case a new MLD proxy per=20 > upstream tunnel interface imply an MLD proxy instance per MN, as = worst=20 > case. Even if the shared tunnel seems to be the most logical way of=20 > solution deployment, these scalability issues should be reflected in = the=20 > draft, with a recommendation or an advise of using shared tunnels for=20 > this solution to avoid such scalability problems. >=20 We can add such a remark, but the shared tunnel is the standard picture=20 of RFC5213. If tunnels are not shared, the primary scaling issue arises=20 from the number of (unicast) tunnels, I believe. > 5/ on page 8, fifth paragraph: "On the reception of MLD reports from = an=20 > MN, the MAG MUST identify the corresponding proxy instance from the=20 > incoming interface and perform regular MLD proxy operations..." > Using the same arguments of a past discussion on the mailing list=20 > between Hitoshi, Thomas and me about what can be considered as a=20 > protocol extension, I think that some aspects of this solution could=20 > also fit on such categorization, because from my point of view some of = > the functions required for this solution can not be implemented based = on=20 > existing RFCs. IMO, functions such as dynamic set up of an MLD proxy=20 > instance per tunnel, binding association between MLD proxy instance = and=20 > a certain LMA, or MLD proxy instance identification for the General=20 > Query message delivery based on the LMA serving an MN during the=20 > handover process, are functions not yet documented on existing RFCs. = So,=20 > this features could be seen also as protocol extension even if no new=20 > messages are introduced in this solution. >=20 This was discussed on the list in early December: Of course, RFC 4605 does not address dynamic instantiation on tunnel=20 appearance. But this is just a time-dependent change of configuration=20 which could be done by a script or so. We haven't tried it out in a=20 practical set up yet, but this is not a change in protocol behavior as=20 it only dynamically adapts system parameters. Since LMAs and MAGs are infrastructure entities (not dynamically=20 changing), this could also be configured manually. > 6/ on page 9, first paragraph: "To learn about multicast groups=20 > subscribed by a newly attaching MN, the MAG sends a General Query to = the=20 > MN's link." > The MNs could use different operating systems with distinc support of=20 > group membership protocols. In an IPv6-based MN, the operating system=20 > could use either MLDv1 or v2 for subscribing multicast contents. In a=20 > similar way, IPv4-based MN could use IGMPv2 or v3. When a MN attaches = to=20 > a new MAG. this new MAG ignores the group membership protocol in use = by=20 > the operating system of the MN. For instance, in the IPv6 case, an MLD = > General Query is sent by the MAG, but if MAG runs MLDv2 and MN runs=20 > MLDv1, the query will be ignored. This could drive to inefficiencies = and=20 > delay on delivering the multicast content to the MN. > So, two possible solutions could be envisioned: (1) send one query per = > group membership version; or (2) send just one query of the lower=20 > version of the group membership protocol, because backward = compatibility=20 > is ensured from the higher to the lower version. >=20 Interesting point, even though it is only loosely related to PMIP. We=20 can add a remark on IGMP/MLD compatibility strategies. > 7/ on page 9, second paragraph: "To prevent erroneous query timeouts = at=20 > the MAG, MLD parameters SHOULD be carefully adjusted to the mobility=20 > regime. In particular, MLD timers and the Robustness Variable (see=20 > section 9 of [RFC3810]) MUST be chosen to be compliant with the time=20 > scale of handover operations in the PMIPv6 domain." > Comment 1 applies also here. >=20 ... as does the answer: Personally, I don't see a deployment where MAGs=20 are re-used as (home-gate) access routers. But such tuning, i.e.,=20 increasing robustness and adjusting timers to characteristic wireless=20 behavior, are not likely to harm wired networks. They might lead to an=20 increased retransmission or so - but this should not harm the (more=20 robust) wired links. Am I missing something relevant here? > 8/ on page 10, first bullet: "The LMA thus terminates multicast=20 > forwarding." > The LMA will terminate the multicast forwarding downstream, but should = > not terminate immediately the reception of the content (by means of an = > MLD Done message upstream, if LMA acts as MLD proxy, or PIM prune=20 > message signalling upstream, if it acts as mutlicast router) because = the=20 > MN could attach to another MAG in a short time. This protocol timing=20 > needs also to be reviewed to fit the PMIPv6 scenarios. >=20 Yes, but in general multicast tree management operations are not that=20 fast. Pruning usually follows queries on the downlink. > 9/ on page 11, last paragraph: "... no new threats arrive from=20 > procedures described in this document in excess to [RFC3810], = [RFC4605]=20 > and [RFC5213] security concerns." > Comment 2 applies also here. >=20 ... and is answered there. > 10/ on page 15, setting 2 evaluation. > I think that the value for the number of simultaneous streams at LMA = in=20 > the case of dedicated multicast LMA is not correct. If I understand=20 > well, the topology under consideration is the following: MAG1 to MAG50 = > are connected to LMA1, LMA2, LMA3 and LMA4 for unicast traffic, using=20 > one tunnel from every MAG to every LMA, and also they are connected to = > LMA-multicast for multicast traffic. Due that the multicast traffic is = > provided by a single LMA-multicast, each MAGs needs a single MLD proxy = > instance to manage such multicast traffic, and so, just one tunnel is=20 > required between any MAG to the LMA multicast. In this situation, the=20 > number of simultaneous streams at LMA-multicast is 50, not 200 as=20 > reported in the draft (200 would be the number obtained if we consider = 4=20 > MLD proxy instances per MAG, as in the combined unicast/multicast = case,=20 > but it has no sense when using a dedicated LMA-multicast box) [Maybe=20 > Guang or Juan Carlos could confirm this]. > So, the numbers should be as follows: > Setting 2: > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > | PMIP multicast | # of redundant | # of sim. streams | > | scheme | streams at MAG | at LMA / LMA-M | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > | Combined Unicast/ | 4 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > | Dedicated | 0 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ >=20 This is not talking about Proxy instances, but about real physical=20 boxes. 200 streams are needed at the dedicated LMA, because in this=20 sample scenario we have 200 MAGs. And multicast data need to reach a MAG = at least once. It's actually a simplified extreme. > 11/ on Appendix B. > As mentioned in Comment 4, the worst case for the combined=20 > unicast/multicast LMA solution proposed by your draft is the case in=20 > which a new tunnel is set up per MN, that is, the tunnels between MAG=20 > and LMA are not shared among MNs. IMO this would represent the = extremal=20 > case for this solution. In that case, the numbers for setting two = would be: > Setting 2: > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > | PMIP multicast | # of redundant | # of sim. streams | > | scheme | streams at MAG | at LMA / LMA-M | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+ > | Combined Unicast/ | 20000 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ > | Dedicated | 0 | 50 | > | Multicast LMA | | | > +-------------------+----------------+-------------------+ >=20 As said before: The standard picture for RFC 5213 is to share tunnels=20 between MAGs and LMAs (otherwise you had these large numbers of tunnels=20 already in the unicast case ...). If you consider a scenario, where individual tunnels of each MN reach=20 the LMA, then there is actually no way to aggregate tunnel states or=20 group data within the standard PMIP infrastructure. You either live with = the scaling issues (both in unicast and multicast), or you build a=20 separate multicast infrastructure, e.g., direct routing or dedicated=20 multicast tunnels. Thanks, Thomas --=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 luisc@it.uc3m.es Thu Jan 7 09:31:20 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216573A67AC for ; Thu, 7 Jan 2010 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG3cKyBrwUPC for ; Thu, 7 Jan 2010 09:31:18 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 684673A67F8 for ; Thu, 7 Jan 2010 09:31:18 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 22A31BA7C41; Thu, 7 Jan 2010 18:31:15 +0100 (CET) Received: from 85.62.13.197.static.abi.uni2.es (85.62.13.197.static.abi.uni2.es [85.62.13.197]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Thu, 07 Jan 2010 18:31:12 +0100 Message-ID: <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> Date: Thu, 07 Jan 2010 18:31:12 +0100 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> In-Reply-To: <4B439EA3.4080705@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17116.006 Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 07 Jan 2010 17:31:20 -0000 Hi Thomas, Thanks for clarification. I continue the discussion in some of the points below. >> 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 >> [RFC3376] signaling for multicast ..." >> What about IGMPv2? Is there any reason for not including it? >> > No, except for the charter. It could as well be MLDv1. > Nevertheless, along the draft, there are reference to MLDv1 (RFC 2710). Maybe they could be removed to avoid confussion. >> 4/ on page 8, fourth paragraph: "It therefore needs to implement an >> instance of the MLD proxy function [RFC4605] for each upstream >> tunnel interface that has been established with an LMA." >> It could be the case that the tunnel between LMA and MAG is not >> shared among MNs, but dedicated per MN. In that case a new MLD proxy >> per upstream tunnel interface imply an MLD proxy instance per MN, >> as worst case. Even if the shared tunnel seems to be the most >> logical way of solution deployment, these scalability issues should >> be reflected in the draft, with a recommendation or an advise of >> using shared tunnels for this solution to avoid such scalability >> problems. >> > We can add such a remark, but the shared tunnel is the standard > picture of RFC5213. If tunnels are not shared, the primary scaling > issue arises from the number of (unicast) tunnels, I believe. > I was thinking in the number of simultaneous MLD instances as limiting factor, more than in the number of simultaneous tunnels. I guess the MLD instances (together with the tunnel, of course) would waste much more resources (in terms of CPU and memory) compared to the resources wasted by the unicast tunnel alone. In other words, the number of supported unicast MNs with their own tunnel would be much higher than the number of supported multicast MNs with their own tunnel. >> 5/ on page 8, fifth paragraph: "On the reception of MLD reports from >> an MN, the MAG MUST identify the corresponding proxy instance from >> the incoming interface and perform regular MLD proxy operations..." >> Using the same arguments of a past discussion on the mailing list >> between Hitoshi, Thomas and me about what can be considered as a >> protocol extension, I think that some aspects of this solution could >> also fit on such categorization, because from my point of view some >> of the functions required for this solution can not be implemented >> based on existing RFCs. IMO, functions such as dynamic set up of an >> MLD proxy instance per tunnel, binding association between MLD proxy >> instance and a certain LMA, or MLD proxy instance identification for >> the General Query message delivery based on the LMA serving an MN >> during the handover process, are functions not yet documented on >> existing RFCs. So, this features could be seen also as protocol >> extension even if no new messages are introduced in this solution. >> > > This was discussed on the list in early December: > Of course, RFC 4605 does not address dynamic instantiation on tunnel > appearance. But this is just a time-dependent change of configuration > which could be done by a script or so. We haven't tried it out in a > practical set up yet, but this is not a change in protocol behavior > as it only dynamically adapts system parameters. > > Since LMAs and MAGs are infrastructure entities (not dynamically > changing), this could also be configured manually. > I must admit that it is not easy for me to recognize the border between what is considered a protocol extension and what not. Let me insist with a more specific event detailed in your draft, that I think it could be a protocol extension according to the arguments of our early discussion. The situation is the following. When a new MN attaches to nMAG, one of the MLD instances of the nMAG will send an MLD General Query. In order to determine what of the MLD proxy instances has to send the Query, the nMAG must know the association (new MN attached <-> LMA serving that MN <-> MLD proxy active in that nMAG-LMA tunnel). Such kind of register, database or binding association is not supported by any RFC nowadays. I think this example fits on what was argued as a protocol extension then. > >> 7/ on page 9, second paragraph: "To prevent erroneous query timeouts >> at the MAG, MLD parameters SHOULD be carefully adjusted to the >> mobility regime. In particular, MLD timers and the Robustness >> Variable (see section 9 of [RFC3810]) MUST be chosen to be compliant >> with the time scale of handover operations in the PMIPv6 domain." >> Comment 1 applies also here. >> > > ... as does the answer: Personally, I don't see a deployment where > MAGs are re-used as (home-gate) access routers. But such tuning, > i.e., increasing robustness and adjusting timers to characteristic > wireless behavior, are not likely to harm wired networks. They might > lead to an increased retransmission or so - but this should not harm > the (more robust) wired links. Am I missing something relevant here? > As Dirk says in a later mail, I think it would be a good idea to separate in some way mobile and fixed parametrization. Of course, this is for further work. >> 8/ on page 10, first bullet: "The LMA thus terminates multicast forwarding." >> The LMA will terminate the multicast forwarding downstream, but >> should not terminate immediately the reception of the content (by >> means of an MLD Done message upstream, if LMA acts as MLD proxy, or >> PIM prune message signalling upstream, if it acts as mutlicast >> router) because the MN could attach to another MAG in a short time. >> This protocol timing needs also to be reviewed to fit the PMIPv6 >> scenarios. >> > > Yes, but in general multicast tree management operations are not that > fast. Pruning usually follows queries on the downlink. > Anyway, I think it should be carefully reviewed to ensure that the LMA does not leave the multicast tree if acts as multicast router, or the LMA does not send and MLD done message if acts as another MLD proxy, as a general comment to multicast in PMIP. >> 10/ on page 15, setting 2 evaluation. >> I think that the value for the number of simultaneous streams at LMA >> in the case of dedicated multicast LMA is not correct. If I >> understand well, the topology under consideration is the following: >> MAG1 to MAG50 are connected to LMA1, LMA2, LMA3 and LMA4 for unicast >> traffic, using one tunnel from every MAG to every LMA, and also they >> are connected to LMA-multicast for multicast traffic. Due that the >> multicast traffic is provided by a single LMA-multicast, each MAGs >> needs a single MLD proxy instance to manage such multicast traffic, >> and so, just one tunnel is required between any MAG to the LMA >> multicast. In this situation, the number of simultaneous streams at >> LMA-multicast is 50, not 200 as reported in the draft (200 would be >> the number obtained if we consider 4 MLD proxy instances per MAG, as >> in the combined unicast/multicast case, but it has no sense when >> using a dedicated LMA-multicast box) [Maybe Guang or Juan Carlos >> could confirm this]. >> So, the numbers should be as follows: >> Setting 2: >> +===================+================+===================+ >> | PMIP multicast | # of redundant | # of sim. streams | >> | scheme | streams at MAG | at LMA / LMA-M | >> +===================+================+===================+ >> | Combined Unicast/ | 4 | 50 | >> | Multicast LMA | | | >> +-------------------+----------------+-------------------+ >> | Dedicated | 0 | 50 | >> | Multicast LMA | | | >> +-------------------+----------------+-------------------+ >> > > This is not talking about Proxy instances, but about real physical > boxes. 200 streams are needed at the dedicated LMA, because in this > sample scenario we have 200 MAGs. And multicast data need to reach a > MAG at least once. > > It's actually a simplified extreme. > Sorry, I don't understand well the scenario. If we have 200 MAGs and 4 LMAs, with 50 MAGs per LMA, then I don't see why 4 redundant streams arrive to the MAG in setting 2 for the combined unicast/multicast LMA. It should be also 0. For instance, if MAG1 to MAG50 connects to LMA1, then LMA1 will send a unique copy of the content to every MAG, so there is no case for redundant streams. Maybe it would be usefull to add some picture showing the scenario you want to study. Thanks, Regards, Luis From schmidt@informatik.haw-hamburg.de Thu Jan 7 10:02:40 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B3B3A6856 for ; Thu, 7 Jan 2010 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 yP4dr0TNJy76 for ; Thu, 7 Jan 2010 10:02:39 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id CBC8A3A6903 for ; Thu, 7 Jan 2010 10:02:35 -0800 (PST) Envelope-to: multimob@ietf.org Received: from [141.22.26.203] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NSwgn-000DtL-Ra; Thu, 07 Jan 2010 19:02:29 +0100 Message-ID: <4B4621A8.80503@informatik.haw-hamburg.de> Date: Thu, 07 Jan 2010 19:02:16 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> In-Reply-To: <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 07 Jan 2010 18:02:40 -0000 Hi Luis, sorry to answer only in brief - please see inline: Luis M. Contreras wrote: >>> 3/ on page 7, first paragraph: " Such mobile node will use IGMPv3 >>> [RFC3376] signaling for multicast ..." >>> What about IGMPv2? Is there any reason for not including it? >>> >> No, except for the charter. It could as well be MLDv1. >> > Nevertheless, along the draft, there are reference to MLDv1 (RFC 2710). > Maybe they could be removed to avoid confussion. > Right, we will make the citings consistent ... >>> 4/ on page 8, fourth paragraph: "It therefore needs to implement an >>> instance of the MLD proxy function [RFC4605] for each upstream tunnel >>> interface that has been established with an LMA." >>> It could be the case that the tunnel between LMA and MAG is not >>> shared among MNs, but dedicated per MN. In that case a new MLD proxy >>> per upstream tunnel interface imply an MLD proxy instance per MN, as >>> worst case. Even if the shared tunnel seems to be the most logical >>> way of solution deployment, these scalability issues should be >>> reflected in the draft, with a recommendation or an advise of using >>> shared tunnels for this solution to avoid such scalability problems. >>> >> We can add such a remark, but the shared tunnel is the standard >> picture of RFC5213. If tunnels are not shared, the primary scaling >> issue arises from the number of (unicast) tunnels, I believe. >> > I was thinking in the number of simultaneous MLD instances as limiting > factor, more than in the number of simultaneous tunnels. I guess the MLD > instances (together with the tunnel, of course) would waste much more > resources (in terms of CPU and memory) compared to the resources wasted > by the unicast tunnel alone. In other words, the number of supported > unicast MNs with their own tunnel would be much higher than the number > of supported multicast MNs with their own tunnel. > The scaling issue comes IMHO with numbers: not every MN will receive multicast, but supposedly will use unicast communication. So the number of unicast-related tunnels will be much higher than MLD proxy instances. >>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports from >>> an MN, the MAG MUST identify the corresponding proxy instance from >>> the incoming interface and perform regular MLD proxy operations..." >>> Using the same arguments of a past discussion on the mailing list >>> between Hitoshi, Thomas and me about what can be considered as a >>> protocol extension, I think that some aspects of this solution could >>> also fit on such categorization, because from my point of view some >>> of the functions required for this solution can not be implemented >>> based on existing RFCs. IMO, functions such as dynamic set up of an >>> MLD proxy instance per tunnel, binding association between MLD proxy >>> instance and a certain LMA, or MLD proxy instance identification for >>> the General Query message delivery based on the LMA serving an MN >>> during the handover process, are functions not yet documented on >>> existing RFCs. So, this features could be seen also as protocol >>> extension even if no new messages are introduced in this solution. >>> >> >> This was discussed on the list in early December: >> Of course, RFC 4605 does not address dynamic instantiation on tunnel >> appearance. But this is just a time-dependent change of configuration >> which could be done by a script or so. We haven't tried it out in a >> practical set up yet, but this is not a change in protocol behavior as >> it only dynamically adapts system parameters. >> >> Since LMAs and MAGs are infrastructure entities (not dynamically >> changing), this could also be configured manually. >> > I must admit that it is not easy for me to recognize the border between > what is considered a protocol extension and what not. Let me insist with > a more specific event detailed in your draft, that I think it could be a > protocol extension according to the arguments of our early discussion. > The situation is the following. When a new MN attaches to nMAG, one of > the MLD instances of the nMAG will send an MLD General Query. In order > to determine what of the MLD proxy instances has to send the Query, the > nMAG must know the association (new MN attached <-> LMA serving that MN > <-> MLD proxy active in that nMAG-LMA tunnel). > Such kind of register, database or binding association is not supported > by any RFC nowadays. I think this example fits on what was argued as a > protocol extension then. > The issue in your argument is that the order of operation is inversed: You don't need an MLD proxy instance for the querying - if the MN arrives, the new link will be just MLD-enabled (this is what our test report was about btw.). Once you have the unicast binding (including possible set-up of the LMA-MAG tunnel) and an answered MLD query, you set up the proxy instance / add the down-link interface to a specific proxy instance. Those operations are simple configurations, you don't need to change software for that. > >>> 10/ on page 15, setting 2 evaluation. >>> I think that the value for the number of simultaneous streams at LMA >>> in the case of dedicated multicast LMA is not correct. If I >>> understand well, the topology under consideration is the following: >>> MAG1 to MAG50 are connected to LMA1, LMA2, LMA3 and LMA4 for unicast >>> traffic, using one tunnel from every MAG to every LMA, and also they >>> are connected to LMA-multicast for multicast traffic. Due that the >>> multicast traffic is provided by a single LMA-multicast, each MAGs >>> needs a single MLD proxy instance to manage such multicast traffic, >>> and so, just one tunnel is required between any MAG to the LMA >>> multicast. In this situation, the number of simultaneous streams at >>> LMA-multicast is 50, not 200 as reported in the draft (200 would be >>> the number obtained if we consider 4 MLD proxy instances per MAG, as >>> in the combined unicast/multicast case, but it has no sense when >>> using a dedicated LMA-multicast box) [Maybe Guang or Juan Carlos >>> could confirm this]. >>> So, the numbers should be as follows: >>> Setting 2: >>> +===================+================+===================+ >>> | PMIP multicast | # of redundant | # of sim. streams | >>> | scheme | streams at MAG | at LMA / LMA-M | >>> +===================+================+===================+ >>> | Combined Unicast/ | 4 | 50 | >>> | Multicast LMA | | | >>> +-------------------+----------------+-------------------+ >>> | Dedicated | 0 | 50 | >>> | Multicast LMA | | | >>> +-------------------+----------------+-------------------+ >>> >> >> This is not talking about Proxy instances, but about real physical >> boxes. 200 streams are needed at the dedicated LMA, because in this >> sample scenario we have 200 MAGs. And multicast data need to reach a >> MAG at least once. >> >> It's actually a simplified extreme. >> > Sorry, I don't understand well the scenario. If we have 200 MAGs and 4 > LMAs, with 50 MAGs per LMA, then I don't see why 4 redundant streams > arrive to the MAG in setting 2 for the combined unicast/multicast LMA. > It should be also 0. For instance, if MAG1 to MAG50 connects to LMA1, > then LMA1 will send a unique copy of the content to every MAG, so there > is no case for redundant streams. Maybe it would be usefull to add some > picture showing the scenario you want to study. > Setting 2 describes that all MNs are joined to the same multicast group. It is assumed that due to the MN <-> LMA association, each MAG has tunnels to all (4) LMAs. Then each MAG receives mcast data 4 times, one from each MAG. Of course, it could be less in some sample scenario, but this describes the worst case. Best wishes, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From JuanCarlos.Zuniga@InterDigital.com Thu Jan 14 16:00:32 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5B83A68AF for ; Thu, 14 Jan 2010 16:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwaBGRaSyxkV for ; Thu, 14 Jan 2010 16:00:32 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id CF0173A6878 for ; Thu, 14 Jan 2010 16:00:28 -0800 (PST) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 19:00:25 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 18:59:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jan 2010 18:59:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-zuniga-multimob-smspmip-01 Thread-Index: AcqVZuI8ECVF5pdFRu26SEwGIW6EAgADYGkg From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 14 Jan 2010 23:59:39.0629 (UTC) FILETIME=[A21221D0:01CA9575] Subject: [multimob] FW: New Version Notification for draft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:00:32 -0000 Dear all, We have just submitted a new version of draft-zuniga-multimob-smspmip including the feedback received from the group at the IETF76 Hiroshima meeting and the mailing list. http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt We look forward to receiving your comments. Best regards, Juan Carlos, Guang and Akbar -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, January 14, 2010 5:14 PM To: Rahman, Akbar Cc: Zuniga, Juan Carlos; Lu, Guang Subject: New Version Notification for draft-zuniga-multimob-smspmip-01=20 A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been successfuly submitted by Akbar Rahman and posted to the IETF repository. Filename: draft-zuniga-multimob-smspmip Revision: 01 Title: Support Multicast Services Using Proxy Mobile IPv6 Creation_date: 2010-01-14 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document describes how multicast mobility services can be supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener Discovery (MLD) [RFC3810], and Internet Group Management Protocol (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for multicast listener mobility. It proposes the use of a dedicated Local Mobility Anchor as the topological anchor point for multicast traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. There are no impacts to the Mobile Node to support multicast listener mobility. =20 The IETF Secretariat. From Dirk.von-Hugo@telekom.de Mon Jan 18 07:15:35 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B063A6837 for ; Mon, 18 Jan 2010 07:15:35 -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 7t-tRZorTTVQ for ; Mon, 18 Jan 2010 07:15:34 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 7D9FF3A67D7 for ; Mon, 18 Jan 2010 07:15:33 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 18 Jan 2010 16:15:24 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 16:15:23 +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: Mon, 18 Jan 2010 16:15:21 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 Thread-Index: AcqVZuI8ECVF5pdFRu26SEwGIW6EAgADYGkgALVrm4A= References: From: To: X-OriginalArrivalTime: 18 Jan 2010 15:15:23.0777 (UTC) FILETIME=[0E930710:01CA9851] Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 15:15:35 -0000 Dear Juan Carlos, Guang and Akbar, Thank you for submitting a revised concise version of your draft. By = using a similar reference scenario as Thomas the direct comparison = between different approaches is greatly simplified. I am not sure whether a single Multicast-LMA really simplifies the tree = structure so much for application of RFC4605 and MAG as MLD proxy (sect. = 3.4) because for each MN-LMA association (which remains fixed throughout = a connection if I remember correctly) there is therefore also only one = LMA for the actual MAG to choose. So for each MLD-proxy instance it = looks like a simple tree structure ... And for each MAG like several = trees But this relation is the reason for successful replication minimization = - if I apply your consideration of Fig. 4/5 to the scenario of Thomas' = evaluation (draft I-D.schmidt-multimob-pmipv6-mcast-deployment) with 1 = Mio MNs, 200 MAGs and 4 LMAs plus an additional Multicast-LMA then = setting 1 (1 Mio. distinct group subscriptions) results in same traffic = for both scenarios (4 Mio packets), but for setting 2 (all subscriptions = to same group) it adds up to 1000805 vs. 1000202 packets, in favour of = the dedicated Multicast-LMA. (I hope the calculation is correct and = obvious ;-)) =20 What remains still open for me is the issue of stream replication = leverage (for scalability reasons) which seems difficult to achieve for = the dedicated Multicast-LMA approach. Just my 2 c(omm)ents. Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Zuniga, Juan Carlos Gesendet: Freitag, 15. Januar 2010 01:00 An: multimob@ietf.org Betreff: [multimob] FW: New Version Notification = fordraft-zuniga-multimob-smspmip-01 Dear all, We have just submitted a new version of draft-zuniga-multimob-smspmip including the feedback received from the group at the IETF76 Hiroshima meeting and the mailing list. http://www.ietf.org/id/draft-zuniga-multimob-smspmip-01.txt We look forward to receiving your comments. Best regards, Juan Carlos, Guang and Akbar -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, January 14, 2010 5:14 PM To: Rahman, Akbar Cc: Zuniga, Juan Carlos; Lu, Guang Subject: New Version Notification for draft-zuniga-multimob-smspmip-01=20 A new version of I-D, draft-zuniga-multimob-smspmip-01.txt has been successfuly submitted by Akbar Rahman and posted to the IETF repository. Filename: draft-zuniga-multimob-smspmip Revision: 01 Title: Support Multicast Services Using Proxy Mobile IPv6 Creation_date: 2010-01-14 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document describes how multicast mobility services can be supported with Proxy Mobile IPv6 [RFC5213], Multicast Listener Discovery (MLD) [RFC3810], and Internet Group Management Protocol (IGMP) [RFC3376]. Specifically, this document analyzes scenarios for multicast listener mobility. It proposes the use of a dedicated Local Mobility Anchor as the topological anchor point for multicast traffic, while the Mobile Access Gateway serves as an IGMP/MLD proxy. There are no impacts to the Mobile Node to support multicast listener mobility. =20 The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Mon Jan 18 16:38:36 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35773A688D for ; Mon, 18 Jan 2010 16:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEls2tAFnT-H for ; Mon, 18 Jan 2010 16:38:36 -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 2A1603A67D1 for ; Mon, 18 Jan 2010 16:38:35 -0800 (PST) Received: from [10.21.73.247] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id DE45821C05; Tue, 19 Jan 2010 01:38:29 +0100 (CET) Message-ID: <4B54FEA7.2000404@venaas.com> Date: Mon, 18 Jan 2010 16:36:55 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> In-Reply-To: <4B4621A8.80503@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 00:38:36 -0000 Thomas C. Schmidt wrote: > Hi Luis, > > sorry to answer only in brief - please see inline: > > Luis M. Contreras wrote: [...] >>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports from >>>> an MN, the MAG MUST identify the corresponding proxy instance from >>>> the incoming interface and perform regular MLD proxy operations..." >>>> Using the same arguments of a past discussion on the mailing list >>>> between Hitoshi, Thomas and me about what can be considered as a >>>> protocol extension, I think that some aspects of this solution could >>>> also fit on such categorization, because from my point of view some >>>> of the functions required for this solution can not be implemented >>>> based on existing RFCs. IMO, functions such as dynamic set up of an >>>> MLD proxy instance per tunnel, binding association between MLD proxy >>>> instance and a certain LMA, or MLD proxy instance identification for >>>> the General Query message delivery based on the LMA serving an MN >>>> during the handover process, are functions not yet documented on >>>> existing RFCs. So, this features could be seen also as protocol >>>> extension even if no new messages are introduced in this solution. >>>> >>> >>> This was discussed on the list in early December: >>> Of course, RFC 4605 does not address dynamic instantiation on tunnel >>> appearance. But this is just a time-dependent change of configuration >>> which could be done by a script or so. We haven't tried it out in a >>> practical set up yet, but this is not a change in protocol behavior >>> as it only dynamically adapts system parameters. >>> >>> Since LMAs and MAGs are infrastructure entities (not dynamically >>> changing), this could also be configured manually. According to RFC 4605 it must be possible to configure the proxy with an upstream interface and a set of downstream interfaces. We want to change the set of downstream interfaces dynamically, some implementations support this. But there may be some that don't too. Aside from this, I believe we don't require any changes in a proxy implementation, just that you can run multiple proxy processes with different configuration. >> I must admit that it is not easy for me to recognize the border >> between what is considered a protocol extension and what not. Let me >> insist with a more specific event detailed in your draft, that I think >> it could be a protocol extension according to the arguments of our >> early discussion. >> The situation is the following. When a new MN attaches to nMAG, one of >> the MLD instances of the nMAG will send an MLD General Query. In order >> to determine what of the MLD proxy instances has to send the Query, >> the nMAG must know the association (new MN attached <-> LMA serving >> that MN <-> MLD proxy active in that nMAG-LMA tunnel). >> Such kind of register, database or binding association is not >> supported by any RFC nowadays. I think this example fits on what was >> argued as a protocol extension then. >> A MAG already keeps track of which MNs are using which LMA, right? So my thinking is that first you do what is done today to set up the MAG-MN link and register with the LMA. Once this process is done, we need some new code in a MAG that determines whether the MN should be provisioned with multicast, and in that case, find the proxy process that is used with that LMA and reconfigure it, adding a new downstream interface. I don't see this as a protocol change. Whatever we do, we need some additional functionality in MAG and/or LMA for multicast to be provided. > The issue in your argument is that the order of operation is inversed: > You don't need an MLD proxy instance for the querying - if the MN > arrives, the new link will be just MLD-enabled (this is what our test > report was about btw.). > > Once you have the unicast binding (including possible set-up of the > LMA-MAG tunnel) and an answered MLD query, you set up the proxy instance > / add the down-link interface to a specific proxy instance. Those > operations are simple configurations, you don't need to change software > for that. There is a problem here. You can in theory send an MLD query before the proxy instance is configured with a new downstream interface. However, you cannot handle the MLD report until the proxy is reconfigured. When the proxy gets a new downstream interface, it will have no state for that interface. Hopefully, the proxy will as soon as it gets a new interface, send an MLD general query to create the desired state. Stig From stig@venaas.com Mon Jan 18 17:30:46 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518EF3A67F8 for ; Mon, 18 Jan 2010 17:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY7jlZI-7xen for ; Mon, 18 Jan 2010 17:30:45 -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 64A2A3A67B3 for ; Mon, 18 Jan 2010 17:30:44 -0800 (PST) Received: from [10.21.73.247] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id EF8F533B6E for ; Tue, 19 Jan 2010 02:30:39 +0100 (CET) Message-ID: <4B550AE0.70205@venaas.com> Date: Mon, 18 Jan 2010 17:29:04 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] An open MLD proxy implementation 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, 19 Jan 2010 01:30:46 -0000 One open source MLD proxy implementation is ecmh, see http://sourceforge.net/news/?group_id=98613 This proxy is used to provide IPv6 multicast with some IPv6 tunnel brokers. In particular as tunnels go up and down, the proxy will add/remove the tunnel interfaces to/from its list of downstream interfaces. One thing worth looking into, is perhaps whether it immediately sends an MLD query on new downstream interfaces. I think it would be useful to collect a list of IGMP/MLD proxy implementations, in particular open source ones. We may then see how close they are to what we want. What I think we need in addition to what is specified in 4605, is as follows. Dynamic config changes: That we can add/remove downstream interfaces while a proxy is running (without losing any existing state, restarting the proxy to change config would not be so good). Multiple proxy instances: Can we have multiple instances/processes can be run simultaneously, each with a different upstream and a different set of downstreams? E.g. on a UNIX-like system, I think you should be able to have a single proxy binary that can be run multiple times to have multiple independent processes. And any configuration must be unique to each process. Sending general query when new downstream is added: I don't think this is mentioned in 4605, but it's pretty obvious that you don't want to wait for a global timer whenever an interface comes up (or is added). Stig From schmidt@informatik.haw-hamburg.de Tue Jan 19 09:26:41 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02373A687B for ; Tue, 19 Jan 2010 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2s7cIoPX8Zp for ; Tue, 19 Jan 2010 09:26:40 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id C89DB3A684D for ; Tue, 19 Jan 2010 09:26:39 -0800 (PST) Envelope-to: multimob@ietf.org Received: from f053078028.adsl.alicedsl.de ([78.53.78.28] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NXHqc-000C2t-D2; Tue, 19 Jan 2010 18:26:34 +0100 Message-ID: <4B55EB38.8040900@informatik.haw-hamburg.de> Date: Tue, 19 Jan 2010 18:26:16 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> In-Reply-To: <4B54FEA7.2000404@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 17:26:41 -0000 Hi Stig & Luis, please see inline: Stig Venaas wrote: > Thomas C. Schmidt wrote: >> Hi Luis, >> >> sorry to answer only in brief - please see inline: >> >> Luis M. Contreras wrote: > [...] >>>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports >>>>> from an MN, the MAG MUST identify the corresponding proxy instance >>>>> from the incoming interface and perform regular MLD proxy >>>>> operations..." >>>>> Using the same arguments of a past discussion on the mailing list >>>>> between Hitoshi, Thomas and me about what can be considered as a >>>>> protocol extension, I think that some aspects of this solution >>>>> could also fit on such categorization, because from my point of >>>>> view some of the functions required for this solution can not be >>>>> implemented based on existing RFCs. IMO, functions such as dynamic >>>>> set up of an MLD proxy instance per tunnel, binding association >>>>> between MLD proxy instance and a certain LMA, or MLD proxy instance >>>>> identification for the General Query message delivery based on the >>>>> LMA serving an MN during the handover process, are functions not >>>>> yet documented on existing RFCs. So, this features could be seen >>>>> also as protocol extension even if no new messages are introduced >>>>> in this solution. >>>>> >>>> >>>> This was discussed on the list in early December: >>>> Of course, RFC 4605 does not address dynamic instantiation on tunnel >>>> appearance. But this is just a time-dependent change of >>>> configuration which could be done by a script or so. We haven't >>>> tried it out in a practical set up yet, but this is not a change in >>>> protocol behavior as it only dynamically adapts system parameters. >>>> >>>> Since LMAs and MAGs are infrastructure entities (not dynamically >>>> changing), this could also be configured manually. > > According to RFC 4605 it must be possible to configure the proxy > with an upstream interface and a set of downstream interfaces. We > want to change the set of downstream interfaces dynamically, some > implementations support this. But there may be some that don't too. > > Aside from this, I believe we don't require any changes in a proxy > implementation, just that you can run multiple proxy processes with > different configuration. > >>> I must admit that it is not easy for me to recognize the border >>> between what is considered a protocol extension and what not. Let me >>> insist with a more specific event detailed in your draft, that I >>> think it could be a protocol extension according to the arguments of >>> our early discussion. >>> The situation is the following. When a new MN attaches to nMAG, one >>> of the MLD instances of the nMAG will send an MLD General Query. In >>> order to determine what of the MLD proxy instances has to send the >>> Query, the nMAG must know the association (new MN attached <-> LMA >>> serving that MN <-> MLD proxy active in that nMAG-LMA tunnel). >>> Such kind of register, database or binding association is not >>> supported by any RFC nowadays. I think this example fits on what was >>> argued as a protocol extension then. >>> > > A MAG already keeps track of which MNs are using which LMA, right? So > my thinking is that first you do what is done today to set up the MAG-MN > link and register with the LMA. Once this process is done, we need some > new code in a MAG that determines whether the MN should be provisioned > with multicast, and in that case, find the proxy process that is used > with that LMA and reconfigure it, adding a new downstream interface. > > I don't see this as a protocol change. Whatever we do, we need some > additional functionality in MAG and/or LMA for multicast to be provided. Yes, we need the dynamic interface assignment to proxy instances triggered by the pure presence of MLD report (this is independent of groups/sources, so no multicast semantic is required). As mentioned earlier, this is something like a little script: exterior configuration code, not changing PMIP/MAG or MLD proxy implementations itself. > >> The issue in your argument is that the order of operation is inversed: >> You don't need an MLD proxy instance for the querying - if the MN >> arrives, the new link will be just MLD-enabled (this is what our test >> report was about btw.). >> >> Once you have the unicast binding (including possible set-up of the >> LMA-MAG tunnel) and an answered MLD query, you set up the proxy >> instance / add the down-link interface to a specific proxy instance. >> Those operations are simple configurations, you don't need to change >> software for that. > > There is a problem here. You can in theory send an MLD query before the > proxy instance is configured with a new downstream interface. However, > you cannot handle the MLD report until the proxy is reconfigured. > > When the proxy gets a new downstream interface, it will have no state > for that interface. Hopefully, the proxy will as soon as it gets a new > interface, send an MLD general query to create the desired state. O.K. - right: so we have gained a fruitful insight of this discussion. What happens is: When the MAG-MN interface comes up, it must be preconfigured to be simply MLD-enabled. So it sends a General Query on start-up. When the MN sends its first report, the proxy correspondence is resolved and the interface is added to the correct proxy instance - without forwarding state. Then a second report is required to implement the state. This second report could follow an additional Query of the proxy, but could also be received as iterate. This might be another reason (aside from wireless link characteristics) to increase the Robustness Variable ... In any case, it is worth adding the pointer to the draft that dynamic interface configuration should stay within the time limit of MLD/IGMP retransmissions. Thanks for the good point! 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 behcetsarikaya@yahoo.com Tue Jan 19 11:15:01 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE5F3A6886 for ; Tue, 19 Jan 2010 11:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akKI9YLo-9AY for ; Tue, 19 Jan 2010 11:14:59 -0800 (PST) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 407FA28C0DD for ; Tue, 19 Jan 2010 11:14:49 -0800 (PST) Received: (qmail 49323 invoked by uid 60001); 19 Jan 2010 19:14:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263928485; bh=HzwojsxZRmGIeXdZwe950e1kuY2Mm4Cm+Kre/kdJd3s=; 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=N2ASYgzA+PynxXmuFLSqtu2TAAgNHZs2xU550hYV5qiNYbdTJHbpotwwjPjiA1jrVCjlVgxrj+H3kKQKQTYT/RCXCXtKDihZERpYWw7EHq925J9IG8qDURLsBaZHyeVcsSIFxZ//ytMO1NOfHHr2BCNP/ghk+lB3K4AP2oPmSNI= 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=TiLH1IVQY8j/tBh8uY4QFLPSWhhyLLNLt1xW2+pvD/yrTJv2AudOfiznFSopAHlbzJm7zrpOjNy6Oe6CItgVZZzfFH6WiFST/p8ZhEKtQ3n9HeahuracyoYhcSyX0St/vXGCeMsMJANs0CT9ClUwz8bekyYut/y4/IOCR/LHigo=; Message-ID: <38772.48229.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: psd4zXUVM1mhu_xOEe2qwP.ev_A805UGyECOr9dAVsu3.Yy_4cxoVIDS5NL0HMdu9NFkD5hmg6VPRQ7d4v8ZF3D72yRUXrywvQvTgwh2.zo2IGRF9FvuXgWgAUXqiSAkMKNeZzk99yGh.57spY9D.fyL7DxsYcbBFvxV9dvN.Md6J6jB3Y82QV3b7Qh7_FOxlkPuCqBGmSRCnDNj3hG9PqqvChhQJIH5H7Mzc2XYyl_0LlvNZ5P5kG64FmBLmQZFO8Kco2WivmgoXIAPJFWJt1YrbDZ48Uxu8ss1S4QyvgTmiNncALkFnbScHVkRXb6ZUTBUDH7B Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 11:14:44 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> Date: Tue, 19 Jan 2010 11:14:44 -0800 (PST) From: Behcet Sarikaya To: "Thomas C. Schmidt" , Stig Venaas In-Reply-To: <4B55EB38.8040900@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 19:15:01 -0000 Hi, > > There is a problem here. You can in theory send an MLD query before the > > proxy instance is configured with a new downstream interface. However, > > you cannot handle the MLD report until the proxy is reconfigured. > > > > When the proxy gets a new downstream interface, it will have no state > > for that interface. Hopefully, the proxy will as soon as it gets a new > > interface, send an MLD general query to create the desired state. > > O.K. - right: so we have gained a fruitful insight of this discussion. > > What happens is: When the MAG-MN interface comes up, it must be preconfigured to > be simply MLD-enabled. So it sends a General Query on start-up. When the MN > sends its first report, the proxy correspondence is resolved and the interface > is added to the correct proxy instance - without forwarding state. Then a second > report is required to implement the state. > > This second report could follow an additional Query of the proxy, but could also > be received as iterate. This might be another reason (aside from wireless link > characteristics) to increase the Robustness Variable ... For my IGMP/MLD education, what about proxy aggregating the downstream state in its upstream interactions? The above sounds like every MLD report generates a MLD general query. Regards, Behcet From stig@venaas.com Tue Jan 19 12:11:49 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157553A6928 for ; Tue, 19 Jan 2010 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkaWu7O0ATBi for ; Tue, 19 Jan 2010 12:11:46 -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 B5B643A6947 for ; Tue, 19 Jan 2010 12:11:45 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id DC8ED239C5; Tue, 19 Jan 2010 21:11:39 +0100 (CET) Message-ID: <4B5611F1.3010007@venaas.com> Date: Tue, 19 Jan 2010 12:11:29 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> In-Reply-To: <4B55EB38.8040900@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 20:11:50 -0000 Thomas C. Schmidt wrote: > Hi Stig & Luis, > > please see inline: > > Stig Venaas wrote: >> Thomas C. Schmidt wrote: >>> Hi Luis, >>> >>> sorry to answer only in brief - please see inline: >>> >>> Luis M. Contreras wrote: >> [...] >>>>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports >>>>>> from an MN, the MAG MUST identify the corresponding proxy instance >>>>>> from the incoming interface and perform regular MLD proxy >>>>>> operations..." >>>>>> Using the same arguments of a past discussion on the mailing list >>>>>> between Hitoshi, Thomas and me about what can be considered as a >>>>>> protocol extension, I think that some aspects of this solution >>>>>> could also fit on such categorization, because from my point of >>>>>> view some of the functions required for this solution can not be >>>>>> implemented based on existing RFCs. IMO, functions such as dynamic >>>>>> set up of an MLD proxy instance per tunnel, binding association >>>>>> between MLD proxy instance and a certain LMA, or MLD proxy >>>>>> instance identification for the General Query message delivery >>>>>> based on the LMA serving an MN during the handover process, are >>>>>> functions not yet documented on existing RFCs. So, this features >>>>>> could be seen also as protocol extension even if no new messages >>>>>> are introduced in this solution. >>>>>> >>>>> >>>>> This was discussed on the list in early December: >>>>> Of course, RFC 4605 does not address dynamic instantiation on >>>>> tunnel appearance. But this is just a time-dependent change of >>>>> configuration which could be done by a script or so. We haven't >>>>> tried it out in a practical set up yet, but this is not a change in >>>>> protocol behavior as it only dynamically adapts system parameters. >>>>> >>>>> Since LMAs and MAGs are infrastructure entities (not dynamically >>>>> changing), this could also be configured manually. >> >> According to RFC 4605 it must be possible to configure the proxy >> with an upstream interface and a set of downstream interfaces. We >> want to change the set of downstream interfaces dynamically, some >> implementations support this. But there may be some that don't too. >> >> Aside from this, I believe we don't require any changes in a proxy >> implementation, just that you can run multiple proxy processes with >> different configuration. >> >>>> I must admit that it is not easy for me to recognize the border >>>> between what is considered a protocol extension and what not. Let me >>>> insist with a more specific event detailed in your draft, that I >>>> think it could be a protocol extension according to the arguments of >>>> our early discussion. >>>> The situation is the following. When a new MN attaches to nMAG, one >>>> of the MLD instances of the nMAG will send an MLD General Query. In >>>> order to determine what of the MLD proxy instances has to send the >>>> Query, the nMAG must know the association (new MN attached <-> LMA >>>> serving that MN <-> MLD proxy active in that nMAG-LMA tunnel). >>>> Such kind of register, database or binding association is not >>>> supported by any RFC nowadays. I think this example fits on what was >>>> argued as a protocol extension then. >>>> >> >> A MAG already keeps track of which MNs are using which LMA, right? So >> my thinking is that first you do what is done today to set up the MAG-MN >> link and register with the LMA. Once this process is done, we need some >> new code in a MAG that determines whether the MN should be provisioned >> with multicast, and in that case, find the proxy process that is used >> with that LMA and reconfigure it, adding a new downstream interface. >> >> I don't see this as a protocol change. Whatever we do, we need some >> additional functionality in MAG and/or LMA for multicast to be provided. > > Yes, we need the dynamic interface assignment to proxy instances > triggered by the pure presence of MLD report (this is independent of > groups/sources, so no multicast semantic is required). I thought the interface assignment would be done when the MAG has determined with LMA the MN uses. > As mentioned earlier, this is something like a little script: exterior > configuration code, not changing PMIP/MAG or MLD proxy implementations > itself. I agree. >> >>> The issue in your argument is that the order of operation is >>> inversed: You don't need an MLD proxy instance for the querying - if >>> the MN arrives, the new link will be just MLD-enabled (this is what >>> our test report was about btw.). >>> >>> Once you have the unicast binding (including possible set-up of the >>> LMA-MAG tunnel) and an answered MLD query, you set up the proxy >>> instance / add the down-link interface to a specific proxy instance. >>> Those operations are simple configurations, you don't need to change >>> software for that. >> >> There is a problem here. You can in theory send an MLD query before the >> proxy instance is configured with a new downstream interface. However, >> you cannot handle the MLD report until the proxy is reconfigured. >> >> When the proxy gets a new downstream interface, it will have no state >> for that interface. Hopefully, the proxy will as soon as it gets a new >> interface, send an MLD general query to create the desired state. > > O.K. - right: so we have gained a fruitful insight of this discussion. > > What happens is: When the MAG-MN interface comes up, it must be > preconfigured to be simply MLD-enabled. So it sends a General Query on > start-up. When the MN sends its first report, the proxy correspondence > is resolved and the interface is added to the correct proxy instance - > without forwarding state. Then a second report is required to implement > the state. > > This second report could follow an additional Query of the proxy, but > could also be received as iterate. This might be another reason (aside > from wireless link characteristics) to increase the Robustness Variable ... I can see that. But at least your order is different from what I have been thinking. First of all though, I'm not sure at what point the MAG-MN link is up, is it there even before the MAG has determined which LMA to use? This is a basic question, I should maybe go back and try to figure that out. My thinking is that things happen in the following order: 1. MAG-MN link comes up (a new MN has arrived) (1.5 MLD query sent here?) 2. MAG determines LMA 3. MAG determines if MN should have multicast, if not stop here 4. MAG tells the MLD proxy for the LMA that it needs to add the MAG-MN link to its list of downstream interfaces 5. Proxy adds sends (or somehow triggers) an MLD general query 6. MN sends MLD report 7. Proxy process the MLD report, updates state etc... I think it may vary between implementations whether MLD queries are sent on an interface that is up but not associated with a proxy. Similar to how say some routers need PIM configured on an interface to act as a multicast router and send MLD queries. Although I think this is more true for IGMP than MLD, since MLD is supposed to be there even for IPv6 unicast. That is, I think typically point 1.5 above would happen for MLD, but there may be implementations that don't. For IGMP it is less likely to happen. It also depends who is responsible for sending the MLD queries. If you think of a UNIX platform, the question is whether it would be the kernel or the proxy process. In the former case you might have queries sent as soon as interface comes up. If it is the proxy, then you would obviously not send queries until the proxy is there. If it is the kernel, the question is whether queries are sent by default on all interfaces that are up, or if the proxy needs to enable it for its downstream interfaces. Note that in point 5, you may either have the proxy sending the MLD query, or it might use an API to tell the kernel to send an MLD report now (and probably restart timers). I don't think it matters that much whether 1.5 happens or not, as long as the proxy does point 5. Of course there may be implementations that don't do 5 either, but I really expect them to do it. Else the proxy will have to wait until the next periodic query to build its state. It's critical that the proxy builds its state ASAP. This is not specific to our scenario. E.g. when you have a switch with some interfaces that are up, but not configured for MLD snooping. When you configure MLD snooping on such an interface, the switch should receive reports immediately. You might also see RFC 4541, section 4, Q9. This is regarding new queries sent for topology changes. You are right that by tuning MLD, maybe we can make sure that reports to the query at point 1.5 arrive after 4 above (actually after the proxy is listening for reports). Are we able to say for sure how long this takes? I think it's a better solution that the proxy sends a new query. I think some of these choices can be left to implementations, but its good if we document these considerations, so that implementers are aware of them. Stig > In any case, it is worth adding the pointer to the draft that dynamic > interface configuration should stay within the time limit of MLD/IGMP > retransmissions. > > Thanks for the good point! > > Cheers, > > Thomas From stig@venaas.com Tue Jan 19 14:08:04 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146303A67E1 for ; Tue, 19 Jan 2010 14:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9rD2+rWK2iq for ; Tue, 19 Jan 2010 14:08: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 36A6B3A67AB for ; Tue, 19 Jan 2010 14:07:57 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 1C72833B66; Tue, 19 Jan 2010 23:07:51 +0100 (CET) Message-ID: <4B562D34.2030501@venaas.com> Date: Tue, 19 Jan 2010 14:07:48 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <38772.48229.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <38772.48229.qm@web111403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 22:08:04 -0000 Behcet Sarikaya wrote: > Hi, > > > >>> There is a problem here. You can in theory send an MLD query before the >>> proxy instance is configured with a new downstream interface. However, >>> you cannot handle the MLD report until the proxy is reconfigured. >>> >>> When the proxy gets a new downstream interface, it will have no state >>> for that interface. Hopefully, the proxy will as soon as it gets a new >>> interface, send an MLD general query to create the desired state. >> O.K. - right: so we have gained a fruitful insight of this discussion. >> >> What happens is: When the MAG-MN interface comes up, it must be preconfigured to >> be simply MLD-enabled. So it sends a General Query on start-up. When the MN >> sends its first report, the proxy correspondence is resolved and the interface >> is added to the correct proxy instance - without forwarding state. Then a second >> report is required to implement the state. >> >> This second report could follow an additional Query of the proxy, but could also >> be received as iterate. This might be another reason (aside from wireless link >> characteristics) to increase the Robustness Variable ... > > > For my IGMP/MLD education, what about proxy aggregating the downstream state in its upstream interactions? The above sounds like every MLD report generates a MLD general query. There is a difference between IGMP/MLD snooping and proxying. A proxy should do aggregation as you say. So when a new report comes from a MN (either one that just got associated with this MAG, or one that changes its memberships), the proxy should update its state. It should however not trigger an IGMP/MLD report upstream unless the aggregate state has changed. E.g. if another MN previously sent reports for the same group (or S,G), there is no reason in sending a new report upstream. Aggregation may not strictly be necessary, but I think we need it for things to scale with a large number of MNs. This aggregation is already specified in RFC 4605. Stig > Regards, > > Behcet > > > From JuanCarlos.Zuniga@InterDigital.com Tue Jan 19 14:21:54 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265D43A686A for ; Tue, 19 Jan 2010 14:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJfVW4M9PiOE for ; Tue, 19 Jan 2010 14:21:53 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id EDCB33A67BD for ; Tue, 19 Jan 2010 14:21:52 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 17:21:48 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 17:21:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jan 2010 17:23:01 -0500 Message-ID: In-Reply-To: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 Thread-Index: AcqVZuI8ECVF5pdFRu26SEwGIW6EAgADYGkgALVrm4AAQjNlwA== References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 19 Jan 2010 22:21:48.0913 (UTC) FILETIME=[CAEAB610:01CA9955] Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:21:54 -0000 Hi Dirk, Thank you for your valuable comments and questions. We have some answers below. > -----Original Message----- > From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] > Sent: Monday, 18 January, 2010 10:15 AM > To: Zuniga, Juan Carlos > Cc: multimob@ietf.org > Subject: AW: [multimob] FW: New Version Notification fordraft-zuniga- > multimob-smspmip-01 >=20 > Dear Juan Carlos, Guang and Akbar, >=20 > Thank you for submitting a revised concise version of your draft. By > using a similar reference scenario as Thomas the direct comparison > between different approaches is greatly simplified. >=20 > I am not sure whether a single Multicast-LMA really simplifies the tree > structure so much for application of RFC4605 and MAG as MLD proxy > (sect. 3.4) because for each MN-LMA association (which remains fixed > throughout a connection if I remember correctly) there is therefore > also only one LMA for the actual MAG to choose. So for each MLD-proxy > instance it looks like a simple tree structure ... And for each MAG > like several trees >=20 In our draft (sect 3.4) we stated that the single Multicast-LMA architecture "allows a PMIPv6 domain to closely follow a simple multicast tree topology for Proxy MLD forwarding (cf. sections 1.1 and 1.2 of [RFC4605]". To be more explicit, we meant to refer to, for example, the following from [RFC4605, section 1.2] - "There are no other multicast routers except the proxy devices within the tree, and the root of the tree is expected to be connected to a wider multicast infrastructure". So our view of the single Multicast-LMA architecture, is that it maps nicely to RFC4605, in that there is clearly only one root for the multicast tree per PMIPv6 domain (namely the single Multicast-LMA). And obviously each MAG will connect back only to this single root of the single Multicast-LMA. Finally, each of the MAG-to-(single Multicast LMA) tunnel interface defines an MLD proxy domain at the MAG, containing all downstream links to multicast MNs. Does this clarify your point about "And for each MAG like several trees"? > But this relation is the reason for successful replication minimization > - if I apply your consideration of Fig. 4/5 to the scenario of Thomas' > evaluation (draft I-D.schmidt-multimob-pmipv6-mcast-deployment) with 1 > Mio MNs, 200 MAGs and 4 LMAs plus an additional Multicast-LMA then > setting 1 (1 Mio. distinct group subscriptions) results in same traffic > for both scenarios (4 Mio packets), but for setting 2 (all > subscriptions to same group) it adds up to 1000805 vs. 1000202 packets, > in favour of the dedicated Multicast-LMA. (I hope the calculation is > correct and obvious ;-)) >=20 We agree with your calculation and we had the same conclusion.=20 =20 For setting "1. All MNs participate in distinct multicast groups", combined Unicast/Multicast LMA (draft-schmidt) and dedicated multicast LMA (draft-zuniga) have the same traffic.=20 For setting "2. All MNs join the same multicast group", dedicated multicast LMA is better since it reduces the number of replications.=20 Based on the above analysis, the tables in Appendix B of draft-schmidt could be extended to include the extra information as follows: Setting 1: The combined Unicast/Multicast LMA have 4 LMAs, each with 250,000 streams, so on the network side, it is the same as dedicated multicast LMA, which has 1,000,000 streams at the dedicated LMA. =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D | PMIP multicast | # of redundant | # of sim. streams |# of sim. Streams | | scheme | streams at MAG | at each LMA/LMA-M |in network for all LMAs| =20 =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D| | Combined Unicast/ | 0 | 250,000 | 1,000,000 | | Multicast LMA | | | | =20 +-------------------+----------------+-------------------+-------------- ---------+ | Dedicated | 0 | 1,000,000 | 1,000,000 | | Multicast LMA | | | | =20 +-------------------+----------------+-------------------+-------------- ---------+ Setting 2:=20 Due to the traffic replication at MAG, the combined unicast/multicast LMA produces a total of 800 streams between all LMAs and MAGs. The dedicated LMA configuration only requires 200.=20 =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D | PMIP multicast | # of redundant | # of sim. streams | # of sim. Streams | | scheme | streams at MAG | at each LMA/LMA-M |in network for all LMAs| =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D| | Combined Unicast/ | 4 | 50 | 800 | | Multicast LMA | | | | =20 +-------------------+----------------+-------------------+-------------- ---------| | Dedicated | 0 | 200 | 200 | | Multicast LMA | | | | =20 +-------------------+----------------+-------------------+-------------- ---------+ Best regards, Juan Carlos, Akbar and Guang From behcetsarikaya@yahoo.com Tue Jan 19 14:41:32 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234F03A67FB for ; Tue, 19 Jan 2010 14:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyZxG6uepPvK for ; Tue, 19 Jan 2010 14:41:31 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 62B623A67BD for ; Tue, 19 Jan 2010 14:41:31 -0800 (PST) Received: (qmail 73090 invoked by uid 60001); 19 Jan 2010 22:41:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263940887; bh=bktZUke1Ujq2+kV7NrPpCUcqUhmM9+yB7BiWRndRTYg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nGNuu1HawOCSrRZBaYaajTP0JzfV3Cv+w7s1e/+VP+lgCAgr29bfg/hXiR4caNuoq2X4dwprWPxW1TuvfrvV6bPyBXwMzBPnv3yFl9E8W6Mf5y6UDm0CLpO8Jm4dX99Oiw+eBC3kHeuudVQUtJRVAciYqDny522XB7RjfbaBb7s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D7U3xYya6yqQuC9m63dWvVVimc6leB6Wz7e3tmkEQc10o4gwcViXMoAVd01L1e2as1QdDYFlUI0iZod0InOilQgRlorZgnTV7XvADB9Kmwwwm1D80xS0Oo7Z7QdrNGbardyMqY37QDcn7ktMqeROokyvlK7Iz+HK4V1Wnv5MZhA=; Message-ID: <934195.72058.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: MPHmesQVM1kArkwJnaEb9mL0bb7I4X1Mvp1g9s.oZVe9iCB2j7OlMV3N.0qEMTtNbPan24rpJ5fpTTw1fEVx5TKf8Rd4l68IET1VvQ4klWQleo50QkDdOd5eQuy9YHK2qvYvtchvM6ABzziIE7homCLBpn9TLWfsBn9jDmKb2kl4iZjavT6OG.1kzAQye_6KWwfMhX1Mb0t4FRVQXcQ6PmyNFLpc6fUuPuu4L4Vktin7U1HUyDxbRteL2U4Loz8QoHklkUYX1GLyM8Ac88LTY3YVpg0fXq0RzZAIP_PmuarHEqJxEWRNl5SqMzjnhvlze820kwsk1V9hgEa77b1M3eCxyl1UzvGMKZSXs0uz Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Tue, 19 Jan 2010 14:41:27 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> Date: Tue, 19 Jan 2010 14:41:27 -0800 (PST) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:41:32 -0000 Hi Juan Carlos,=0A=0A=0A=0A----- Original Message ----=0A> From: "Zuniga, J= uan Carlos" =0A> To: Dirk.von-Hugo@tele= kom.de=0A> Cc: multimob@ietf.org=0A> Sent: Tue, January 19, 2010 4:23:01 PM= =0A> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-m= ultimob-smspmip-01=0A> =0A> Hi Dirk,=0A> =0A> Thank you for your valuable c= omments and questions.=0A> We have some answers below.=0A> =0A> > -----Orig= inal Message-----=0A> > From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hug= o@telekom.de]=0A> > Sent: Monday, 18 January, 2010 10:15 AM=0A> > To: Zunig= a, Juan Carlos=0A> > Cc: multimob@ietf.org=0A> > Subject: AW: [multimob] FW= : New Version Notification fordraft-zuniga-=0A> > multimob-smspmip-01=0A> >= =0A> > Dear Juan Carlos, Guang and Akbar,=0A> > =0A> > Thank you for submi= tting a revised concise version of your draft. By=0A> > using a similar ref= erence scenario as Thomas the direct comparison=0A> > between different app= roaches is greatly simplified.=0A> > =0A> > I am not sure whether a single = Multicast-LMA really simplifies the=0A> tree=0A> > structure so much for ap= plication of RFC4605 and MAG as MLD proxy=0A> > (sect. 3.4) because for eac= h MN-LMA association (which remains fixed=0A> > throughout a connection if = I remember correctly) there is therefore=0A> > also only one LMA for the ac= tual MAG to choose. So for each MLD-proxy=0A> > instance it looks like a si= mple tree structure ... And for each MAG=0A> > like several trees=0A> > =0A= > =0A> In our draft (sect 3.4) we stated that the single Multicast-LMA=0A> = architecture "allows a PMIPv6 domain to closely follow a simple=0A> multica= st tree topology for Proxy MLD forwarding (cf. sections 1.1 and=0A> 1.2 of = [RFC4605]".=A0 To be more explicit, we meant to refer to, for=0A> example, = the following from [RFC4605, section 1.2] - "There are no other=0A> multica= st routers except the proxy devices within the tree, and the root=0A> of th= e tree is expected to be connected to a wider multicast=0A> infrastructure"= .=0A> =0A> So our view of the single Multicast-LMA architecture, is that it= maps=0A> nicely to RFC4605, in that there is clearly only one root for the= =0A> multicast tree per PMIPv6 domain (namely the single Multicast-LMA).=A0= And=0A> obviously each MAG will connect back only to this single root of t= he=0A> single Multicast-LMA.=A0 Finally, each of the MAG-to-(single Multica= st=0A> LMA) tunnel interface defines an MLD proxy domain at the MAG, contai= ning=0A> all downstream links to multicast MNs.=0A=0AJust a reminder: Multi= cast-LMA separates MN from its LMA, so it is not remote subscription. As we= discussed in some earlier thread on the list, there are problems arising f= rom deviating from remote subscription. That's why the charter requires the= work to employ remote subscription.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A = From schmidt@informatik.haw-hamburg.de Tue Jan 19 15:52:15 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C473A67E1 for ; Tue, 19 Jan 2010 15:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 26IO+oFNYD7K for ; Tue, 19 Jan 2010 15:52:13 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 339453A67BD for ; Tue, 19 Jan 2010 15:52:12 -0800 (PST) Envelope-to: multimob@ietf.org Received: from f053078028.adsl.alicedsl.de ([78.53.78.28] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NXNrj-0004QQ-AJ; Wed, 20 Jan 2010 00:52:07 +0100 Message-ID: <4B564592.2000906@informatik.haw-hamburg.de> Date: Wed, 20 Jan 2010 00:51:46 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> In-Reply-To: <4B5611F1.3010007@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 19 Jan 2010 23:52:15 -0000 Hi Stig, Stig Venaas wrote: > Thomas C. Schmidt wrote: >> Hi Stig & Luis, >> >> please see inline: >> >> Stig Venaas wrote: >>> Thomas C. Schmidt wrote: >>>> Hi Luis, >>>> >>>> sorry to answer only in brief - please see inline: >>>> >>>> Luis M. Contreras wrote: >>> [...] >>>>>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports >>>>>>> from an MN, the MAG MUST identify the corresponding proxy >>>>>>> instance from the incoming interface and perform regular MLD >>>>>>> proxy operations..." >>>>>>> Using the same arguments of a past discussion on the mailing list >>>>>>> between Hitoshi, Thomas and me about what can be considered as a >>>>>>> protocol extension, I think that some aspects of this solution >>>>>>> could also fit on such categorization, because from my point of >>>>>>> view some of the functions required for this solution can not be >>>>>>> implemented based on existing RFCs. IMO, functions such as >>>>>>> dynamic set up of an MLD proxy instance per tunnel, binding >>>>>>> association between MLD proxy instance and a certain LMA, or MLD >>>>>>> proxy instance identification for the General Query message >>>>>>> delivery based on the LMA serving an MN during the handover >>>>>>> process, are functions not yet documented on existing RFCs. So, >>>>>>> this features could be seen also as protocol extension even if no >>>>>>> new messages are introduced in this solution. >>>>>>> >>>>>> >>>>>> This was discussed on the list in early December: >>>>>> Of course, RFC 4605 does not address dynamic instantiation on >>>>>> tunnel appearance. But this is just a time-dependent change of >>>>>> configuration which could be done by a script or so. We haven't >>>>>> tried it out in a practical set up yet, but this is not a change >>>>>> in protocol behavior as it only dynamically adapts system parameters. >>>>>> >>>>>> Since LMAs and MAGs are infrastructure entities (not dynamically >>>>>> changing), this could also be configured manually. >>> >>> According to RFC 4605 it must be possible to configure the proxy >>> with an upstream interface and a set of downstream interfaces. We >>> want to change the set of downstream interfaces dynamically, some >>> implementations support this. But there may be some that don't too. >>> >>> Aside from this, I believe we don't require any changes in a proxy >>> implementation, just that you can run multiple proxy processes with >>> different configuration. >>> >>>>> I must admit that it is not easy for me to recognize the border >>>>> between what is considered a protocol extension and what not. Let >>>>> me insist with a more specific event detailed in your draft, that I >>>>> think it could be a protocol extension according to the arguments >>>>> of our early discussion. >>>>> The situation is the following. When a new MN attaches to nMAG, one >>>>> of the MLD instances of the nMAG will send an MLD General Query. In >>>>> order to determine what of the MLD proxy instances has to send the >>>>> Query, the nMAG must know the association (new MN attached <-> LMA >>>>> serving that MN <-> MLD proxy active in that nMAG-LMA tunnel). >>>>> Such kind of register, database or binding association is not >>>>> supported by any RFC nowadays. I think this example fits on what >>>>> was argued as a protocol extension then. >>>>> >>> >>> A MAG already keeps track of which MNs are using which LMA, right? So >>> my thinking is that first you do what is done today to set up the MAG-MN >>> link and register with the LMA. Once this process is done, we need some >>> new code in a MAG that determines whether the MN should be provisioned >>> with multicast, and in that case, find the proxy process that is used >>> with that LMA and reconfigure it, adding a new downstream interface. >>> >>> I don't see this as a protocol change. Whatever we do, we need some >>> additional functionality in MAG and/or LMA for multicast to be provided. >> >> Yes, we need the dynamic interface assignment to proxy instances >> triggered by the pure presence of MLD report (this is independent of >> groups/sources, so no multicast semantic is required). > > I thought the interface assignment would be done when the MAG has > determined with LMA the MN uses. > Either way, I guess this is a matter of choice: When done immediately after unicast binding, multicast will be operationally prepared ASAP on the price of possible proxy instances that are never used. If done only after the first MLD Report is received, multicast initialization may be delayed for the first MN <-> MAG <-> LMA association, but pure unicast communication will never activate the proxy instances. So I wouldn't mind any way. >> As mentioned earlier, this is something like a little script: exterior >> configuration code, not changing PMIP/MAG or MLD proxy implementations >> itself. > > I agree. >>> >>>> The issue in your argument is that the order of operation is >>>> inversed: You don't need an MLD proxy instance for the querying - if >>>> the MN arrives, the new link will be just MLD-enabled (this is what >>>> our test report was about btw.). >>>> >>>> Once you have the unicast binding (including possible set-up of the >>>> LMA-MAG tunnel) and an answered MLD query, you set up the proxy >>>> instance / add the down-link interface to a specific proxy instance. >>>> Those operations are simple configurations, you don't need to change >>>> software for that. >>> >>> There is a problem here. You can in theory send an MLD query before the >>> proxy instance is configured with a new downstream interface. However, >>> you cannot handle the MLD report until the proxy is reconfigured. >>> >>> When the proxy gets a new downstream interface, it will have no state >>> for that interface. Hopefully, the proxy will as soon as it gets a new >>> interface, send an MLD general query to create the desired state. >> >> O.K. - right: so we have gained a fruitful insight of this discussion. >> >> What happens is: When the MAG-MN interface comes up, it must be >> preconfigured to be simply MLD-enabled. So it sends a General Query on >> start-up. When the MN sends its first report, the proxy correspondence >> is resolved and the interface is added to the correct proxy instance - >> without forwarding state. Then a second report is required to >> implement the state. >> >> This second report could follow an additional Query of the proxy, but >> could also be received as iterate. This might be another reason (aside >> from wireless link characteristics) to increase the Robustness >> Variable ... > > I can see that. But at least your order is different from what I have > been thinking. > > First of all though, I'm not sure at what point the MAG-MN link is up, > is it there even before the MAG has determined which LMA to use? This > is a basic question, I should maybe go back and try to figure that out. > Yes, it must be up prior to the binding, as normally there is an initial RouterSolicitation. The MAG needs to know which MN is behind that link, at least. > My thinking is that things happen in the following order: > > 1. MAG-MN link comes up (a new MN has arrived) > (1.5 MLD query sent here?) > 2. MAG determines LMA > 3. MAG determines if MN should have multicast, if not stop here > 4. MAG tells the MLD proxy for the LMA that it needs to add the > MAG-MN link to its list of downstream interfaces > 5. Proxy adds sends (or somehow triggers) an MLD general query > 6. MN sends MLD report > 7. Proxy process the MLD report, updates state etc... > This sounds good to me. It might depend on the configuration how quick the initial MLD Query/Report. We have seen the Query to wait for IPv6 address configuration. > I think it may vary between implementations whether MLD queries are > sent on an interface that is up but not associated with a proxy. > Similar to how say some routers need PIM configured on an interface > to act as a multicast router and send MLD queries. Although I think > this is more true for IGMP than MLD, since MLD is supposed to be > there even for IPv6 unicast. > Yes, but we have seen Queries with and without PIM on the devices under test. > That is, I think typically point 1.5 above would happen for MLD, but > there may be implementations that don't. For IGMP it is less likely > to happen. > We have seen IGMP correspondingly to MLD. IGMP is usually a bit faster as it does not care about unicast address configuration. > It also depends who is responsible for sending the MLD queries. If > you think of a UNIX platform, the question is whether it would be > the kernel or the proxy process. In the former case you might have > queries sent as soon as interface comes up. If it is the proxy, then > you would obviously not send queries until the proxy is there. > We have tested without a proxy instance running. I would guess that the MLD kernel functions already have sent Queries when the proxy comes up in normal implementations, i.e., starting the proxy will not interfere with the regular MLD until it is running. > If it is the kernel, the question is whether queries are sent by > default on all interfaces that are up, or if the proxy needs to > enable it for its downstream interfaces. > This is by default. We have discussed this before and tested. It is documented in Appendix A of the document. Tests have been performed for a Cisco and Linux - unfortunately, we don't have Avici routers in our lab ;) > Note that in point 5, you may either have the proxy sending the > MLD query, or it might use an API to tell the kernel to send an > MLD report now (and probably restart timers). > > I don't think it matters that much whether 1.5 happens or not, > as long as the proxy does point 5. > This should probably be tested as well. We'll have a look. > Of course there may be implementations that don't do 5 either, but > I really expect them to do it. Else the proxy will have to wait > until the next periodic query to build its state. It's critical > that the proxy builds its state ASAP. This is not specific to > our scenario. E.g. when you have a switch with some interfaces > that are up, but not configured for MLD snooping. When you > configure MLD snooping on such an interface, the switch should > receive reports immediately. You might also see RFC 4541, > section 4, Q9. This is regarding new queries sent for topology > changes. > I guess so. It seems, that implementations are aware of that. > You are right that by tuning MLD, maybe we can make sure that > reports to the query at point 1.5 arrive after 4 above (actually > after the proxy is listening for reports). Are we able to say > for sure how long this takes? I think it's a better solution > that the proxy sends a new query. > Yes, it will be definitely more reliable and a redundant Query will not kill the air interface. But it may be worth pointing at that multicast services will profit from a quick interface management, which most likely does not cause effort as the proxy is already up and running. > I think some of these choices can be left to implementations, but > its good if we document these considerations, so that implementers > are aware of them. > Sure, we'll do. 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 stig@venaas.com Tue Jan 19 16:15:42 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669523A67F2 for ; Tue, 19 Jan 2010 16:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbL67HBSNL34 for ; Tue, 19 Jan 2010 16:15:41 -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 2DE3F3A67EE for ; Tue, 19 Jan 2010 16:15:40 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 4BC0122CF5; Wed, 20 Jan 2010 01:15:32 +0100 (CET) Message-ID: <4B564B21.80509@venaas.com> Date: Tue, 19 Jan 2010 16:15:29 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> <4B564592.2000906@informatik.haw-hamburg.de> In-Reply-To: <4B564592.2000906@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 20 Jan 2010 00:15:42 -0000 Thomas C. Schmidt wrote: > Hi Stig, > > Stig Venaas wrote: >> Thomas C. Schmidt wrote: >>> Hi Stig & Luis, >>> >>> please see inline: >>> >>> Stig Venaas wrote: >>>> Thomas C. Schmidt wrote: >>>>> Hi Luis, >>>>> >>>>> sorry to answer only in brief - please see inline: >>>>> >>>>> Luis M. Contreras wrote: >>>> [...] >>>>>>>> 5/ on page 8, fifth paragraph: "On the reception of MLD reports >>>>>>>> from an MN, the MAG MUST identify the corresponding proxy >>>>>>>> instance from the incoming interface and perform regular MLD >>>>>>>> proxy operations..." >>>>>>>> Using the same arguments of a past discussion on the mailing >>>>>>>> list between Hitoshi, Thomas and me about what can be considered >>>>>>>> as a protocol extension, I think that some aspects of this >>>>>>>> solution could also fit on such categorization, because from my >>>>>>>> point of view some of the functions required for this solution >>>>>>>> can not be implemented based on existing RFCs. IMO, functions >>>>>>>> such as dynamic set up of an MLD proxy instance per tunnel, >>>>>>>> binding association between MLD proxy instance and a certain >>>>>>>> LMA, or MLD proxy instance identification for the General Query >>>>>>>> message delivery based on the LMA serving an MN during the >>>>>>>> handover process, are functions not yet documented on existing >>>>>>>> RFCs. So, this features could be seen also as protocol extension >>>>>>>> even if no new messages are introduced in this solution. >>>>>>>> >>>>>>> >>>>>>> This was discussed on the list in early December: >>>>>>> Of course, RFC 4605 does not address dynamic instantiation on >>>>>>> tunnel appearance. But this is just a time-dependent change of >>>>>>> configuration which could be done by a script or so. We haven't >>>>>>> tried it out in a practical set up yet, but this is not a change >>>>>>> in protocol behavior as it only dynamically adapts system >>>>>>> parameters. >>>>>>> >>>>>>> Since LMAs and MAGs are infrastructure entities (not dynamically >>>>>>> changing), this could also be configured manually. >>>> >>>> According to RFC 4605 it must be possible to configure the proxy >>>> with an upstream interface and a set of downstream interfaces. We >>>> want to change the set of downstream interfaces dynamically, some >>>> implementations support this. But there may be some that don't too. >>>> >>>> Aside from this, I believe we don't require any changes in a proxy >>>> implementation, just that you can run multiple proxy processes with >>>> different configuration. >>>> >>>>>> I must admit that it is not easy for me to recognize the border >>>>>> between what is considered a protocol extension and what not. Let >>>>>> me insist with a more specific event detailed in your draft, that >>>>>> I think it could be a protocol extension according to the >>>>>> arguments of our early discussion. >>>>>> The situation is the following. When a new MN attaches to nMAG, >>>>>> one of the MLD instances of the nMAG will send an MLD General >>>>>> Query. In order to determine what of the MLD proxy instances has >>>>>> to send the Query, the nMAG must know the association (new MN >>>>>> attached <-> LMA serving that MN <-> MLD proxy active in that >>>>>> nMAG-LMA tunnel). >>>>>> Such kind of register, database or binding association is not >>>>>> supported by any RFC nowadays. I think this example fits on what >>>>>> was argued as a protocol extension then. >>>>>> >>>> >>>> A MAG already keeps track of which MNs are using which LMA, right? So >>>> my thinking is that first you do what is done today to set up the >>>> MAG-MN >>>> link and register with the LMA. Once this process is done, we need some >>>> new code in a MAG that determines whether the MN should be provisioned >>>> with multicast, and in that case, find the proxy process that is used >>>> with that LMA and reconfigure it, adding a new downstream interface. >>>> >>>> I don't see this as a protocol change. Whatever we do, we need some >>>> additional functionality in MAG and/or LMA for multicast to be >>>> provided. >>> >>> Yes, we need the dynamic interface assignment to proxy instances >>> triggered by the pure presence of MLD report (this is independent of >>> groups/sources, so no multicast semantic is required). >> >> I thought the interface assignment would be done when the MAG has >> determined with LMA the MN uses. >> > > Either way, I guess this is a matter of choice: When done immediately > after unicast binding, multicast will be operationally prepared ASAP on > the price of possible proxy instances that are never used. If done only I don't understand what you mean here. Are you somehow talking about a proxy instance that is not associated with a specific LMA? I can think of some ways to get the state from the MN before you know the LMA, and then later provide that info to the correct proxy, but that would IMO require a larger change to the proxy code. > after the first MLD Report is received, multicast initialization may be > delayed for the first MN <-> MAG <-> LMA association, but pure unicast > communication will never activate the proxy instances. I believe it would result in a slightly longer delay (longer time before the MN receives its content), but it may not be significant. > So I wouldn't mind any way. > >>> As mentioned earlier, this is something like a little script: >>> exterior configuration code, not changing PMIP/MAG or MLD proxy >>> implementations itself. >> >> I agree. >>>> >>>>> The issue in your argument is that the order of operation is >>>>> inversed: You don't need an MLD proxy instance for the querying - >>>>> if the MN arrives, the new link will be just MLD-enabled (this is >>>>> what our test report was about btw.). >>>>> >>>>> Once you have the unicast binding (including possible set-up of the >>>>> LMA-MAG tunnel) and an answered MLD query, you set up the proxy >>>>> instance / add the down-link interface to a specific proxy >>>>> instance. Those operations are simple configurations, you don't >>>>> need to change software for that. >>>> >>>> There is a problem here. You can in theory send an MLD query before the >>>> proxy instance is configured with a new downstream interface. However, >>>> you cannot handle the MLD report until the proxy is reconfigured. >>>> >>>> When the proxy gets a new downstream interface, it will have no state >>>> for that interface. Hopefully, the proxy will as soon as it gets a new >>>> interface, send an MLD general query to create the desired state. >>> >>> O.K. - right: so we have gained a fruitful insight of this discussion. >>> >>> What happens is: When the MAG-MN interface comes up, it must be >>> preconfigured to be simply MLD-enabled. So it sends a General Query >>> on start-up. When the MN sends its first report, the proxy >>> correspondence is resolved and the interface is added to the correct >>> proxy instance - without forwarding state. Then a second report is >>> required to implement the state. >>> >>> This second report could follow an additional Query of the proxy, but >>> could also be received as iterate. This might be another reason >>> (aside from wireless link characteristics) to increase the Robustness >>> Variable ... >> >> I can see that. But at least your order is different from what I have >> been thinking. >> >> First of all though, I'm not sure at what point the MAG-MN link is up, >> is it there even before the MAG has determined which LMA to use? This >> is a basic question, I should maybe go back and try to figure that out. >> > Yes, it must be up prior to the binding, as normally there is an initial > RouterSolicitation. The MAG needs to know which MN is behind that link, > at least. > >> My thinking is that things happen in the following order: >> >> 1. MAG-MN link comes up (a new MN has arrived) >> (1.5 MLD query sent here?) >> 2. MAG determines LMA >> 3. MAG determines if MN should have multicast, if not stop here >> 4. MAG tells the MLD proxy for the LMA that it needs to add the >> MAG-MN link to its list of downstream interfaces >> 5. Proxy adds sends (or somehow triggers) an MLD general query >> 6. MN sends MLD report >> 7. Proxy process the MLD report, updates state etc... >> > > This sounds good to me. It might depend on the configuration how quick > the initial MLD Query/Report. We have seen the Query to wait for IPv6 > address configuration. > >> I think it may vary between implementations whether MLD queries are >> sent on an interface that is up but not associated with a proxy. >> Similar to how say some routers need PIM configured on an interface >> to act as a multicast router and send MLD queries. Although I think >> this is more true for IGMP than MLD, since MLD is supposed to be >> there even for IPv6 unicast. >> > > Yes, but we have seen Queries with and without PIM on the devices under > test. > >> That is, I think typically point 1.5 above would happen for MLD, but >> there may be implementations that don't. For IGMP it is less likely >> to happen. >> > > We have seen IGMP correspondingly to MLD. IGMP is usually a bit faster > as it does not care about unicast address configuration. > >> It also depends who is responsible for sending the MLD queries. If >> you think of a UNIX platform, the question is whether it would be >> the kernel or the proxy process. In the former case you might have >> queries sent as soon as interface comes up. If it is the proxy, then >> you would obviously not send queries until the proxy is there. >> > We have tested without a proxy instance running. I would guess that the > MLD kernel functions already have sent Queries when the proxy comes up > in normal implementations, i.e., starting the proxy will not interfere > with the regular MLD until it is running. > >> If it is the kernel, the question is whether queries are sent by >> default on all interfaces that are up, or if the proxy needs to >> enable it for its downstream interfaces. >> > This is by default. We have discussed this before and tested. It is > documented in Appendix A of the document. Tests have been performed for > a Cisco and Linux - unfortunately, we don't have Avici routers in our > lab ;) > >> Note that in point 5, you may either have the proxy sending the >> MLD query, or it might use an API to tell the kernel to send an >> MLD report now (and probably restart timers). >> >> I don't think it matters that much whether 1.5 happens or not, >> as long as the proxy does point 5. >> > > This should probably be tested as well. We'll have a look. > >> Of course there may be implementations that don't do 5 either, but >> I really expect them to do it. Else the proxy will have to wait >> until the next periodic query to build its state. It's critical >> that the proxy builds its state ASAP. This is not specific to >> our scenario. E.g. when you have a switch with some interfaces >> that are up, but not configured for MLD snooping. When you >> configure MLD snooping on such an interface, the switch should >> receive reports immediately. You might also see RFC 4541, >> section 4, Q9. This is regarding new queries sent for topology >> changes. >> > I guess so. It seems, that implementations are aware of that. > >> You are right that by tuning MLD, maybe we can make sure that >> reports to the query at point 1.5 arrive after 4 above (actually >> after the proxy is listening for reports). Are we able to say >> for sure how long this takes? I think it's a better solution >> that the proxy sends a new query. >> > Yes, it will be definitely more reliable and a redundant Query will not > kill the air interface. But it may be worth pointing at that multicast > services will profit from a quick interface management, which most > likely does not cause effort as the proxy is already up and running. > >> I think some of these choices can be left to implementations, but >> its good if we document these considerations, so that implementers >> are aware of them. >> > Sure, we'll do. > > Cheers, > > Thomas Stig From schmidt@informatik.haw-hamburg.de Wed Jan 20 01:06:08 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F1F3A67D9 for ; Wed, 20 Jan 2010 01:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 vh6szLPjGYek for ; Wed, 20 Jan 2010 01:06:07 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 06CC33A680C for ; Wed, 20 Jan 2010 01:05:55 -0800 (PST) Envelope-to: multimob@ietf.org Received: from f053078177.adsl.alicedsl.de ([78.53.78.177] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NXWVa-000NLN-6Y; Wed, 20 Jan 2010 10:05:50 +0100 Message-ID: <4B56C76A.6080804@informatik.haw-hamburg.de> Date: Wed, 20 Jan 2010 10:05:46 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> <4B564592.2000906@informatik.haw-hamburg.de> <4B564B21.80509@venaas.com> In-Reply-To: <4B564B21.80509@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 20 Jan 2010 09:06:08 -0000 Hi Stig, Stig Venaas wrote: >>> I thought the interface assignment would be done when the MAG has >>> determined with LMA the MN uses. >>> >> >> Either way, I guess this is a matter of choice: When done immediately >> after unicast binding, multicast will be operationally prepared ASAP >> on the price of possible proxy instances that are never used. If done >> only > > I don't understand what you mean here. Are you somehow talking about a > proxy instance that is not associated with a specific LMA? > No, and I just see that I was confused by a previous discussion. I guess you're just right: the interface assignment should be done when the MAG has resolved the binding of the new MN. > I can think of some ways to get the state from the MN before you know > the LMA, and then later provide that info to the correct proxy, but > that would IMO require a larger change to the proxy code. > Yes, but this is a different story. One might do it that way, when re-implementing MLD proxy - but it is not needed here. 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 JuanCarlos.Zuniga@InterDigital.com Wed Jan 20 12:46:22 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAD13A67A7 for ; Wed, 20 Jan 2010 12:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIfB9aZnZJwO for ; Wed, 20 Jan 2010 12:46:21 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 56A503A63EC for ; Wed, 20 Jan 2010 12:46:21 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 15:46:13 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 15:45:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 15:47:00 -0500 Message-ID: In-Reply-To: <934195.72058.qm@web111416.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 Thread-Index: AcqZWItLgmbcElnrQXugmOHYRfujdwAt8/rQ References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> From: "Zuniga, Juan Carlos" To: "Behcet Sarikaya" X-OriginalArrivalTime: 20 Jan 2010 20:45:48.0113 (UTC) FILETIME=[8BA02410:01CA9A11] Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 20:46:22 -0000 Hi Behcet, > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Tuesday, 19 January, 2010 5:41 PM > To: Zuniga, Juan Carlos > Cc: multimob@ietf.org > Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga- > multimob-smspmip-01 >=20 > Hi Juan Carlos, >=20 >=20 > Just a reminder: Multicast-LMA separates MN from its LMA, so it is not > remote subscription. As we discussed in some earlier thread on the > list, there are problems arising from deviating from remote > subscription. That's why the charter requires the work to employ remote > subscription. As previously discussed, the Multicast-LMA approach is actually following remote subscription: http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html=20 - the term "Remote Subscription" as defined in the literature (-> see problem statement) was coined as counterpart to "home subscription" (HA-Tunneling). All the approaches we have been discussing in Hiroshima are of type "remote subscription". Regards, Juan Carlos From behcetsarikaya@yahoo.com Wed Jan 20 13:20:15 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB3F28C105 for ; Wed, 20 Jan 2010 13:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+rt7kKFovNP for ; Wed, 20 Jan 2010 13:20:14 -0800 (PST) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id AF8BC28C0F7 for ; Wed, 20 Jan 2010 13:20:14 -0800 (PST) Received: (qmail 68249 invoked by uid 60001); 20 Jan 2010 21:20:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1264022408; bh=tnFBv5yu+ImQewRv8Z3GPX1En2e/Wc4yRs0E65cQJEI=; 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=WXOjftLWGdFgXFwIyrMh22SWjxmFTS/EnNDYYGVXO6NZDoUVgSajZudQ9xSqWH4O+TuKGpXoFc3ZTMEFMDFTpwKFjLsWLEqRQO7RbSvhTKoIRQ2iLCwmrkPY+IxqSauZKx4+A42lWSswHi+30Gjnk4WU8mYFLHw5CETGhQoVzKA= 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=aGEZbc0HiRruNOLSkNAoqTeIhFy49sL83ZD3eV2p4nFpM48ECWWN/z5AGa7LbnLgnUFi5spc6afKo7r6HM8IZIA8gE88JnFYEit5V6HK2gZL84bjRxotKc1ASokGEby/Tkob7ECj+WsBCjKI9ocU7T5Tla9JGlgAjfcrEMZrOK8=; Message-ID: <62552.66574.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: .U74vp8VM1kVDXOgBgXgwDftfoKmm8wAR9LEWkcxgbfySUol4u9zOpzHGQLkFeCLJfpjHxwzaBHOgLGmosiOErN89MVQf2JZOKr9TIpSenHhN8I7smm2s79jspbHzwcmtHkvSl.7EFwFclTVJZORd93tdAq7Ry7l5E3GOBps4pmjwfH3QNqWfuVV3VC_R3yhzNyM0Y.7URo2wcGU0eqLIbihNelW7UVVKNEGz7p4eRq6GGfRwC9jKXsLew077gEFpkOv6C06Aqjio0CJ2Sl72bsi05EzLlTKYZN17XMIe.NsWFMTPSIM72K40WbVom5sVo34vxFYUAka3vQgDi0uSWmxhZbOPOU8R3cHq_bH Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 20 Jan 2010 13:20:07 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> Date: Wed, 20 Jan 2010 13:20:07 -0800 (PST) From: Behcet Sarikaya To: "Zuniga, Juan Carlos" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 21:20:15 -0000 Hi Juan Carlos, ----- Original Message ---- > From: "Zuniga, Juan Carlos" > To: Behcet Sarikaya > Cc: multimob@ietf.org > Sent: Wed, January 20, 2010 2:47:00 PM > Subject: RE: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 > > Hi Behcet, > > > > -----Original Message----- > > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Sent: Tuesday, 19 January, 2010 5:41 PM > > To: Zuniga, Juan Carlos > > Cc: multimob@ietf.org > > Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga- > > multimob-smspmip-01 > > > > Hi Juan Carlos, > > > > > > Just a reminder: Multicast-LMA separates MN from its LMA, so it is not > > remote subscription. As we discussed in some earlier thread on the > > list, there are problems arising from deviating from remote > > subscription. That's why the charter requires the work to employ > remote > > subscription. > > As previously discussed, the Multicast-LMA approach is actually > following remote subscription: > > http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html > > - the term "Remote Subscription" as defined in the literature (-> see > problem statement) was coined as counterpart to "home subscription" > (HA-Tunneling). All the approaches we have been discussing in Hiroshima > are of type "remote subscription". You should see my reply to that message in which I added another qualification which was bi-directional tunneling. You are taking it out of context. The point is this: Multicast-LMA does not actually have to an LMA. It is in fact an upstream multicast router, so LMA is a misnomer for that entity. This means that mobility of MN is not handled by the entity, i.e. MN's LMA which is unicast LMA in your draft. The charter is very clear on this. IGMP/MLD Proxy is remote-subscription if the unicast and multicast traffic of MN are handled by the same LMA. You have to support many LMAs because MNs may have different LMAs, e.g. due to roaming. We discussed this in a later thread with Thomas already you can check the archive. Regards, Behcet From stig@venaas.com Wed Jan 20 13:31:36 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0785628C0FE for ; Wed, 20 Jan 2010 13:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGPGF1rfsT+N for ; Wed, 20 Jan 2010 13:31:35 -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 3FDCB28C103 for ; Wed, 20 Jan 2010 13:31:34 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 0E034239C5; Wed, 20 Jan 2010 22:31:27 +0100 (CET) Message-ID: <4B57762C.4020500@venaas.com> Date: Wed, 20 Jan 2010 13:31:24 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <62552.66574.qm@web111416.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 21:31:36 -0000 Behcet Sarikaya wrote: > Hi Juan Carlos, > > > > ----- Original Message ---- >> From: "Zuniga, Juan Carlos" >> To: Behcet Sarikaya >> Cc: multimob@ietf.org >> Sent: Wed, January 20, 2010 2:47:00 PM >> Subject: RE: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 >> >> Hi Behcet, >> >> >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>> Sent: Tuesday, 19 January, 2010 5:41 PM >>> To: Zuniga, Juan Carlos >>> Cc: multimob@ietf.org >>> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga- >>> multimob-smspmip-01 >>> >>> Hi Juan Carlos, >>> >>> >>> Just a reminder: Multicast-LMA separates MN from its LMA, so it is not >>> remote subscription. As we discussed in some earlier thread on the >>> list, there are problems arising from deviating from remote >>> subscription. That's why the charter requires the work to employ >> remote >>> subscription. >> As previously discussed, the Multicast-LMA approach is actually >> following remote subscription: >> >> http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html >> >> - the term "Remote Subscription" as defined in the literature (-> see >> problem statement) was coined as counterpart to "home subscription" >> (HA-Tunneling). All the approaches we have been discussing in Hiroshima >> are of type "remote subscription". There is some confusion regarding "remote subscription" as I see it. I believe it is generally used as a counterpart to "home subscription" as you say. My understanding is then that in PMIP, the (unicast) LMA can be thought of as the HA. If we then use the (unicast) LMA also for multicast, then that should probably be called "home subscription". While using some other infrastructure, e.g. the access network infrastructure (or say a tunnel to some other router than the (unicast) LMA), would then be "remote subscription". However, in the charter, it says: The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. I think "remote subscription" may not be correct here (at least with the definitions discussed above), but the second sentence is pretty clear. I think when "remote subscription" was used in the charter text, it might have been as a counter part to "local subscription". As in, not using the local infrastructure (e.g. the access network), but rather something remote. It would be a good idea if we all used the same terms. I think it is pretty clear what the intention of the charter text is though. Of course I was not involved in writing the charter texts, so I would be happy to be corrected if my understanding is wrong. Stig > You should see my reply to that message in which I added another qualification which was bi-directional tunneling. > > You are taking it out of context. > > The point is this: Multicast-LMA does not actually have to an LMA. It is in fact an upstream multicast router, so LMA is a misnomer for that entity. This means that mobility of MN is not handled by the entity, i.e. MN's LMA which is unicast LMA in your draft. The charter is very clear on this. > > IGMP/MLD Proxy is remote-subscription if the unicast and multicast traffic of MN are handled by the same LMA. You have to support many LMAs because MNs may have different LMAs, e.g. due to roaming. > > > We discussed this in a later thread with Thomas already you can check the archive. > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Wed Jan 20 14:12:32 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECEC3A67D8 for ; Wed, 20 Jan 2010 14:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 EtQO4AEJVNII for ; Wed, 20 Jan 2010 14:12:31 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4C1613A68F8 for ; Wed, 20 Jan 2010 14:12:30 -0800 (PST) Envelope-to: multimob@ietf.org Received: from f053078177.adsl.alicedsl.de ([78.53.78.177] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NXimn-000CRI-52; Wed, 20 Jan 2010 23:12:25 +0100 Message-ID: <4B577FC4.4090206@informatik.haw-hamburg.de> Date: Wed, 20 Jan 2010 23:12:20 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> In-Reply-To: <4B57762C.4020500@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 22:12:32 -0000 Hi Stig & Juan Carlos, Stig Venaas wrote: > Behcet Sarikaya wrote: >> Hi Juan Carlos, >> >> >> >> ----- Original Message ---- >>> From: "Zuniga, Juan Carlos" >>> To: Behcet Sarikaya >>> Cc: multimob@ietf.org >>> Sent: Wed, January 20, 2010 2:47:00 PM >>> Subject: RE: [multimob] FW: New Version Notification >>> fordraft-zuniga-multimob-smspmip-01 >>> >>> Hi Behcet, >>> >>> >>>> -----Original Message----- >>>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>>> Sent: Tuesday, 19 January, 2010 5:41 PM >>>> To: Zuniga, Juan Carlos >>>> Cc: multimob@ietf.org >>>> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga- >>>> multimob-smspmip-01 >>>> >>>> Hi Juan Carlos, >>>> >>>> >>>> Just a reminder: Multicast-LMA separates MN from its LMA, so it is not >>>> remote subscription. As we discussed in some earlier thread on the >>>> list, there are problems arising from deviating from remote >>>> subscription. That's why the charter requires the work to employ >>> remote >>>> subscription. >>> As previously discussed, the Multicast-LMA approach is actually >>> following remote subscription: >>> >>> http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html >>> - the term "Remote Subscription" as defined in the literature (-> see >>> problem statement) was coined as counterpart to "home subscription" >>> (HA-Tunneling). All the approaches we have been discussing in Hiroshima >>> are of type "remote subscription". > > There is some confusion regarding "remote subscription" as I see it. I > believe it is generally used as a counterpart to "home subscription" as > you say. > > My understanding is then that in PMIP, the (unicast) LMA can be thought > of as the HA. If we then use the (unicast) LMA also for multicast, then > that should probably be called "home subscription". > > While using some other infrastructure, e.g. the access network > infrastructure (or say a tunnel to some other router than the (unicast) > LMA), would then be "remote subscription". > > However, in the charter, it says: > > The work will employ the remote subscription model. This is a > mechanism by which a mobile node joins a multicast group and receives > multicast data forwarded via the local mobility anchor. > > I think "remote subscription" may not be correct here (at least with > the definitions discussed above), but the second sentence is pretty > clear. > > I think when "remote subscription" was used in the charter text, it > might have been as a counter part to "local subscription". As in, > not using the local infrastructure (e.g. the access network), but > rather something remote. > > It would be a good idea if we all used the same terms. I think it is > pretty clear what the intention of the charter text is though. > > Of course I was not involved in writing the charter texts, so I would > be happy to be corrected if my understanding is wrong. > From my understanding you are both perfectly right: the general term in the literature was somewhat abused in the charter text. However, this is not a real complication, since - as Stig pointed out - the dedication of the charter text is clear: it tried to avoid restriction to the trivial solution, where multicast routing is done in parallel to PMIP. From that perspective, I don't see a point for disagreement here. A "home subscription" or bi-directional tunneling between MN and LMA is infeasible, as the MN won't cooperate in tunneling. Pure local multicast routing (without assistance of MAGs) is infeasible, as well, since the MN won't actively renew subscriptions after handoff. Everything else that uses the PMIP infrastructure correctly is IMHO a "PMIP-compliant remote subscription". And within the charter text. Aside from this: competition is open on the best and most feasible solution, not on glorifying the wording of the charter ;) 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 stig@venaas.com Wed Jan 20 14:48:53 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968AA3A6AA5 for ; Wed, 20 Jan 2010 14:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnfOisUb0XLh for ; Wed, 20 Jan 2010 14:48:52 -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 8A4E63A6AA0 for ; Wed, 20 Jan 2010 14:48:52 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 4B3AD239A2; Wed, 20 Jan 2010 23:48:47 +0100 (CET) Message-ID: <4B57884C.3060304@venaas.com> Date: Wed, 20 Jan 2010 14:48:44 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Behcet Sarikaya References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> In-Reply-To: <62552.66574.qm@web111416.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 22:48:53 -0000 Behcet Sarikaya wrote: [...] > You should see my reply to that message in which I added another qualification which was bi-directional tunneling. > > You are taking it out of context. > > The point is this: Multicast-LMA does not actually have to an LMA. It is in fact an upstream multicast router, so LMA is a misnomer for that entity. This means that mobility of MN is not handled by the entity, i.e. MN's LMA which is unicast LMA in your draft. The charter is very clear on this. > > IGMP/MLD Proxy is remote-subscription if the unicast and multicast traffic of MN are handled by the same LMA. You have to support many LMAs because MNs may have different LMAs, e.g. due to roaming. I agree that the term LMA is not good, if all you are doing is receiving multicast via a tunnel from a remote router. With the term LMA I think of it in PMIP terms where I would expect the PMIP protocol to be used between the MAG and the LMA... If the MAG is using a multicast router for upstream connectivity, and it is not the (unicast) LMA, then it is using multicast connectivity outside of the PMIP infrastructure. Whether that is a local router physically connected to the MAG or a remote router connected via a tunnel, is not a significant difference I think. Stig > > We discussed this in a later thread with Thomas already you can check the archive. > > Regards, > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Wed Jan 20 15:13:58 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D024B3A6AA6 for ; Wed, 20 Jan 2010 15:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbmBufqZJAS5 for ; Wed, 20 Jan 2010 15:13:50 -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 823513A6AA7 for ; Wed, 20 Jan 2010 15:13:45 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 8B66C21C40; Thu, 21 Jan 2010 00:13:38 +0100 (CET) Message-ID: <4B578E1D.5060109@venaas.com> Date: Wed, 20 Jan 2010 15:13:33 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> In-Reply-To: <4B577FC4.4090206@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Zuniga, Juan Carlos" Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 23:13:59 -0000 Thomas C. Schmidt wrote: > Hi Stig & Juan Carlos, > > Stig Venaas wrote: >> Behcet Sarikaya wrote: >>> Hi Juan Carlos, >>> >>> >>> >>> ----- Original Message ---- >>>> From: "Zuniga, Juan Carlos" >>>> To: Behcet Sarikaya >>>> Cc: multimob@ietf.org >>>> Sent: Wed, January 20, 2010 2:47:00 PM >>>> Subject: RE: [multimob] FW: New Version Notification >>>> fordraft-zuniga-multimob-smspmip-01 >>>> >>>> Hi Behcet, >>>> >>>> >>>>> -----Original Message----- >>>>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>>>> Sent: Tuesday, 19 January, 2010 5:41 PM >>>>> To: Zuniga, Juan Carlos >>>>> Cc: multimob@ietf.org >>>>> Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga- >>>>> multimob-smspmip-01 >>>>> >>>>> Hi Juan Carlos, >>>>> >>>>> >>>>> Just a reminder: Multicast-LMA separates MN from its LMA, so it is not >>>>> remote subscription. As we discussed in some earlier thread on the >>>>> list, there are problems arising from deviating from remote >>>>> subscription. That's why the charter requires the work to employ >>>> remote >>>>> subscription. >>>> As previously discussed, the Multicast-LMA approach is actually >>>> following remote subscription: >>>> >>>> http://www.ietf.org/mail-archive/web/multimob/current/msg00638.html >>>> - the term "Remote Subscription" as defined in the literature (-> see >>>> problem statement) was coined as counterpart to "home subscription" >>>> (HA-Tunneling). All the approaches we have been discussing in Hiroshima >>>> are of type "remote subscription". >> >> There is some confusion regarding "remote subscription" as I see it. I >> believe it is generally used as a counterpart to "home subscription" as >> you say. >> >> My understanding is then that in PMIP, the (unicast) LMA can be thought >> of as the HA. If we then use the (unicast) LMA also for multicast, then >> that should probably be called "home subscription". >> >> While using some other infrastructure, e.g. the access network >> infrastructure (or say a tunnel to some other router than the (unicast) >> LMA), would then be "remote subscription". >> >> However, in the charter, it says: >> >> The work will employ the remote subscription model. This is a >> mechanism by which a mobile node joins a multicast group and receives >> multicast data forwarded via the local mobility anchor. >> >> I think "remote subscription" may not be correct here (at least with >> the definitions discussed above), but the second sentence is pretty >> clear. >> >> I think when "remote subscription" was used in the charter text, it >> might have been as a counter part to "local subscription". As in, >> not using the local infrastructure (e.g. the access network), but >> rather something remote. >> >> It would be a good idea if we all used the same terms. I think it is >> pretty clear what the intention of the charter text is though. >> >> Of course I was not involved in writing the charter texts, so I would >> be happy to be corrected if my understanding is wrong. >> > > From my understanding you are both perfectly right: the general term in > the literature was somewhat abused in the charter text. However, this is > not a real complication, since - as Stig pointed out - the dedication of > the charter text is clear: it tried to avoid restriction to the trivial > solution, where multicast routing is done in parallel to PMIP. > > From that perspective, I don't see a point for disagreement here. A > "home subscription" or bi-directional tunneling between MN and LMA is > infeasible, as the MN won't cooperate in tunneling. Pure local multicast > routing (without assistance of MAGs) is infeasible, as well, since the > MN won't actively renew subscriptions after handoff. > > Everything else that uses the PMIP infrastructure correctly is IMHO a > "PMIP-compliant remote subscription". And within the charter text. But if you are using the MAG, then the question is where the MAG gets multicast from. There are several options. But the charter is quite clear when it says: This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. And when it says "the local mobility anchor", it is clear to me that it is the LMA unicast is received from. There is (at least currently) nothing else called LMA in the PMIP architecture. Looking at other solutions is interesting, but it is outside the current charter. Hopefully it is something we can look at in the future. Stig > Aside from this: competition is open on the best and most feasible > solution, not on glorifying the wording of the charter ;) > > Cheers, > > Thomas > From luisc@it.uc3m.es Fri Jan 22 09:01:30 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E676B3A6A72 for ; Fri, 22 Jan 2010 09:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dMSNlTO9-Vu for ; Fri, 22 Jan 2010 09:01:29 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 47CCF28C0CF for ; Fri, 22 Jan 2010 09:01:25 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id C8068BA79FD; Fri, 22 Jan 2010 18:01:19 +0100 (CET) Received: from 85.62.13.196.static.abi.uni2.es (85.62.13.196.static.abi.uni2.es [85.62.13.196]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Fri, 22 Jan 2010 18:01:17 +0100 Message-ID: <20100122180117.j0tix59hk4488ogg@webcartero01.uc3m.es> Date: Fri, 22 Jan 2010 18:01:17 +0100 From: "Luis M. Contreras" To: Stig Venaas References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> In-Reply-To: <4B5611F1.3010007@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17148.000 Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 22 Jan 2010 17:01:31 -0000 Hi Stig, following your sequence description and a further comment: > > 1. MAG-MN link comes up (a new MN has arrived) > (1.5 MLD query sent here?) > 2. MAG determines LMA > 3. MAG determines if MN should have multicast, if not stop here > 4. MAG tells the MLD proxy for the LMA that it needs to add the > MAG-MN link to its list of downstream interfaces > 5. Proxy adds sends (or somehow triggers) an MLD general query > 6. MN sends MLD report > 7. Proxy process the MLD report, updates state etc... > [...] > > I don't think it matters that much whether 1.5 happens or not, > as long as the proxy does point 5. > if step 1.5 does not happen, then the MAG in step 3 can not determine that the MN requires multicast service, at least at this stage (no protocol extension), because there is no other way to know it. So, the Proxy instance should always send the MLD Query as stated on step 5, or wait for a periodic MLD status refresh. As a consequence, the MAG-MN link will be always added to the list of downstream interfaces (and it could be removed afterwards if MN has no active multicast service). Am I wrong? Thanks, regards, Luis From schmidt@informatik.haw-hamburg.de Fri Jan 22 14:03:51 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8233A684E for ; Fri, 22 Jan 2010 14:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 tMM+Z6VbCBTq for ; Fri, 22 Jan 2010 14:03:50 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 7163D3A677C for ; Fri, 22 Jan 2010 14:03:49 -0800 (PST) Envelope-to: multimob@ietf.org Received: from f053079116.adsl.alicedsl.de ([78.53.79.116] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NYRbT-000H0K-SM; Fri, 22 Jan 2010 23:03:44 +0100 Message-ID: <4B5A20B9.2070108@informatik.haw-hamburg.de> Date: Fri, 22 Jan 2010 23:03:37 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Luis M. Contreras" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> <20100122180117.j0tix59hk4488ogg@webcartero01.uc3m.es> In-Reply-To: <20100122180117.j0tix59hk4488ogg@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 22 Jan 2010 22:03:51 -0000 Hi Luis, Luis M. Contreras wrote: > Hi Stig, > > following your sequence description and a further comment: > >> >> 1. MAG-MN link comes up (a new MN has arrived) >> (1.5 MLD query sent here?) >> 2. MAG determines LMA >> 3. MAG determines if MN should have multicast, if not stop here >> 4. MAG tells the MLD proxy for the LMA that it needs to add the >> MAG-MN link to its list of downstream interfaces >> 5. Proxy adds sends (or somehow triggers) an MLD general query >> 6. MN sends MLD report >> 7. Proxy process the MLD report, updates state etc... >> > [...] >> >> I don't think it matters that much whether 1.5 happens or not, >> as long as the proxy does point 5. >> > > if step 1.5 does not happen, then the MAG in step 3 can not determine > that the MN requires multicast service, at least at this stage (no > protocol extension), because there is no other way to know it. So, the > Proxy instance should always send the MLD Query as stated on step 5, or > wait for a periodic MLD status refresh. > > As a consequence, the MAG-MN link will be always added to the list of > downstream interfaces (and it could be removed afterwards if MN has no > active multicast service). > > Am I wrong? Sounds about right to me. I know we had the discussion on resources consumed by proxies on the MAG, but I suppose (without knowing realistic numbers) a downstream interface controlled by a proxy does not make much difference when compared to a pure MLD-enabled one (MLD state tables need to be allocated either way). 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 stig@venaas.com Fri Jan 22 14:13:20 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF1B3A63EB for ; Fri, 22 Jan 2010 14:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGuCtICWg0FP for ; Fri, 22 Jan 2010 14:13:17 -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 C808B3A677C for ; Fri, 22 Jan 2010 14:13:16 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 3822333B81; Fri, 22 Jan 2010 23:13:08 +0100 (CET) Message-ID: <4B5A22EC.8090004@venaas.com> Date: Fri, 22 Jan 2010 14:13:00 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4B291EF2.7070808@informatik.haw-hamburg.de> <20100105004835.btz6lf37cwo48ogs@webcartero01.uc3m.es> <4B439EA3.4080705@informatik.haw-hamburg.de> <20100107183112.5p0khzkiio40ckcs@webcartero01.uc3m.es> <4B4621A8.80503@informatik.haw-hamburg.de> <4B54FEA7.2000404@venaas.com> <4B55EB38.8040900@informatik.haw-hamburg.de> <4B5611F1.3010007@venaas.com> <20100122180117.j0tix59hk4488ogg@webcartero01.uc3m.es> <4B5A20B9.2070108@informatik.haw-hamburg.de> In-Reply-To: <4B5A20B9.2070108@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] [Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-03] 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, 22 Jan 2010 22:13:20 -0000 Thomas C. Schmidt wrote: > Hi Luis, > > Luis M. Contreras wrote: >> Hi Stig, >> >> following your sequence description and a further comment: >> >>> >>> 1. MAG-MN link comes up (a new MN has arrived) >>> (1.5 MLD query sent here?) >>> 2. MAG determines LMA >>> 3. MAG determines if MN should have multicast, if not stop here >>> 4. MAG tells the MLD proxy for the LMA that it needs to add the >>> MAG-MN link to its list of downstream interfaces >>> 5. Proxy adds sends (or somehow triggers) an MLD general query >>> 6. MN sends MLD report >>> 7. Proxy process the MLD report, updates state etc... >>> >> [...] >>> >>> I don't think it matters that much whether 1.5 happens or not, >>> as long as the proxy does point 5. >>> >> >> if step 1.5 does not happen, then the MAG in step 3 can not determine >> that the MN requires multicast service, at least at this stage (no >> protocol extension), because there is no other way to know it. So, the >> Proxy instance should always send the MLD Query as stated on step 5, >> or wait for a periodic MLD status refresh. >> >> As a consequence, the MAG-MN link will be always added to the list of >> downstream interfaces (and it could be removed afterwards if MN has no >> active multicast service). >> >> Am I wrong? I think maybe it should always be added anyway (except if the MAG has some policy for which MNs should get multicast service, and knows it should not get it). The problem is that if you send MLD query to the MN, it will (is supposed to) always send a report back for some link-local addresses. This is just how IPv6 unicast should work where the host joins e.g. the solicited-node-multicast-address or whatever it's called. If you want to determine if it needs a multicast service, you would need to check if there are any non-link-local groups in the report, and only in that case add it to the list of downstream interfaces. But this is a bit tricky. Also, it might be that it's only later that the host joins some non-link-local groups. You would then have to keep monitoring MLD reports to find out when the interface should be added. It's much simpler to always add the interface, and have the proxy examine the MLD reports. Stig > Sounds about right to me. I know we had the discussion on resources > consumed by proxies on the MAG, but I suppose (without knowing realistic > numbers) a downstream interface controlled by a proxy does not make much > difference when compared to a pure MLD-enabled one (MLD state tables > need to be allocated either way). > > Cheers, > > Thomas From luisc@it.uc3m.es Wed Jan 27 13:53:09 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A160B3A68E6 for ; Wed, 27 Jan 2010 13:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaqyfL4dYjCe for ; Wed, 27 Jan 2010 13:53:08 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 7F24D3A6882 for ; Wed, 27 Jan 2010 13:53:07 -0800 (PST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 4D9017F7B05; Wed, 27 Jan 2010 22:53:21 +0100 (CET) Received: from 217.pool85-54-50.dynamic.orange.es (217.pool85-54-50.dynamic.orange.es [85.54.50.217]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 27 Jan 2010 22:53:18 +0100 Message-ID: <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> Date: Wed, 27 Jan 2010 22:53:18 +0100 From: "Luis M. Contreras" To: Stig Venaas References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> In-Reply-To: <4B578E1D.5060109@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17158.002 Cc: multimob@ietf.org Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:53:09 -0000 My thoughts on this: >> >> Everything else that uses the PMIP infrastructure correctly is IMHO >> a "PMIP-compliant remote subscription". And within the charter text. > > But if you are using the MAG, then the question is where the MAG gets > multicast from. There are several options. But the charter is quite > clear when it says: > > This is a mechanism by which a mobile node joins a multicast group and > receives multicast data forwarded via the local mobility anchor. > > And when it says "the local mobility anchor", it is clear to me that it > is the LMA unicast is received from. There is (at least currently) > nothing else called LMA in the PMIP architecture. > I think that the limitation on receiving the multicast traffic via the LMA is certainly artificial. What is the real benefit obtained with this limitation? I can understand the requirement of remote (or non-local) subscription of the multicast traffic as a way of isolating the local network from the traffic intrinsics of the home network. But this does not necessarily means that the multicast traffic must reach the MN through its serving LMA. We can confine the multicast traffic in the PMIPv6 domain infrastructure withoud being forced to deliver it through the MN's LMA. Let me ellaborate more on this. A certain MAG can be connected to several LMAs, namely LMA1, LMA2 and LMA3, for instance. We can consider three different MNs, MN1, MN2 and MN3 which are respectively bound to LMA1, LMA2 and LMA3 for the forwarding of their respective unicast traffic. But, additionally, we can consider that one of those three LMA, e.g. LMA2, is the box in charge of delivering multicast traffic for all of the considered MNs in the domain, resulting that the multicast traffic for MN1, MN2 and MN3 reaches the nodes via LMA2. The multicast traffic will be always under control of the same MAG serving MN1, 2 and 3. I think that this idea adheres the charter's spirit of constraining the multicast traffic within the PMIPv6 infrastructure entities, while opens the possibilities of getting a more optimal solution for multicast delivery in PMIPv6 domains. Regards, Luis From schmidt@informatik.haw-hamburg.de Sat Jan 30 14:29:45 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE133A67FC for ; Sat, 30 Jan 2010 14:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfVZaK+Tu2zZ for ; Sat, 30 Jan 2010 14:29:44 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A24E13A67B6 for ; Sat, 30 Jan 2010 14:29:42 -0800 (PST) Envelope-to: multimob@ietf.org Received: from e178137126.adsl.alicedsl.de ([85.178.137.126] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NbLpQ-0003Jm-Gk for multimob@ietf.org; Sat, 30 Jan 2010 23:30:08 +0100 Message-ID: <4B64B2E6.8040908@informatik.haw-hamburg.de> Date: Sat, 30 Jan 2010 23:29:58 +0100 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: multimob@ietf.org References: <643B0A1D1A13AB498304E0BBC802784801C2212D@S4DE8PSAAQC.mitte.t-com.de> <934195.72058.qm@web111416.mail.gq1.yahoo.com> <62552.66574.qm@web111416.mail.gq1.yahoo.com> <4B57762C.4020500@venaas.com> <4B577FC4.4090206@informatik.haw-hamburg.de> <4B578E1D.5060109@venaas.com> <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> In-Reply-To: <20100127225318.bf17rjkvhwcgc0s0@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] FW: New Version Notification fordraft-zuniga-multimob-smspmip-01 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 22:29:45 -0000 Dear Luis, Luis M. Contreras wrote: > My thoughts on this: > >>> >>> Everything else that uses the PMIP infrastructure correctly is IMHO a >>> "PMIP-compliant remote subscription". And within the charter text. >> >> But if you are using the MAG, then the question is where the MAG gets >> multicast from. There are several options. But the charter is quite >> clear when it says: >> >> This is a mechanism by which a mobile node joins a multicast group and >> receives multicast data forwarded via the local mobility anchor. >> >> And when it says "the local mobility anchor", it is clear to me that it >> is the LMA unicast is received from. There is (at least currently) >> nothing else called LMA in the PMIP architecture. >> > > I think that the limitation on receiving the multicast traffic via the > LMA is certainly artificial. What is the real benefit obtained with this > limitation? > My understanding of this objective and of the charter is that PMIPv6 infrastructure should be taken as granted, as the things that are deployed, and a multicast service should be enabled just on top of it. This makes sense from two perspectives: (i) At first, multicast will come at no additional infrastructure costs/efforts. (ii) second, every multicast operation will/must be integrated into PMIP mobility management; in particular, no additional handover operations should be required for multicast. > I can understand the requirement of remote (or non-local) subscription > of the multicast traffic as a way of isolating the local network from > the traffic intrinsics of the home network. But this does not > necessarily means that the multicast traffic must reach the MN through > its serving LMA. We can confine the multicast traffic in the PMIPv6 > domain infrastructure withoud being forced to deliver it through the > MN's LMA. Let me ellaborate more on this. > A problem you seem to struggle with arises from this confusion with the term "remote subscription". Being (somehow) remote is not equivalent to being integrated into the existing mobility management. > A certain MAG can be connected to several LMAs, namely LMA1, LMA2 and > LMA3, for instance. We can consider three different MNs, MN1, MN2 and > MN3 which are respectively bound to LMA1, LMA2 and LMA3 for the > forwarding of their respective unicast traffic. But, additionally, we > can consider that one of those three LMA, e.g. LMA2, is the box in > charge of delivering multicast traffic for all of the considered MNs in > the domain, resulting that the multicast traffic for MN1, MN2 and MN3 > reaches the nodes via LMA2. The multicast traffic will be always under > control of the same MAG serving MN1, 2 and 3. > Yes, but this requires a separate multicast mobility management. If MN1 is associated with LMA1 and receives multicast via LMA2, then its changing the association with the MAG does not lead to multicast traffic following the MN to the new MAG (see the problem statement http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-09). In fact for this example, as LMA2 may be serving several MNs (associated with different LMAs), its MCAST flows could not even be simply redirected. Instead, a new mobility-related signaling would be needed to initiate or terminate multicast data transmission from this LMA to all the MAGs. The idea of the current charter is to identify solutions without this need. In a sense this charter is quite clever, because the open option of freely introducing a new control plane would give rise to solutions that are much more efficient than your thoughts, but much less compatible with the PMIPv6 unicast routing. > I think that this idea adheres the charter's spirit of constraining the > multicast traffic within the PMIPv6 infrastructure entities, while opens > the possibilities of getting a more optimal solution for multicast > delivery in PMIPv6 domains. > Yes and no: as stated above, if we were free to define whatever signaling we wanted, we could design a good multicast layer that is fully independent of PMIP. However, the idea is to extract a minimal solution that allows PMIP operators to enable multicast without radical (but rather minimal) changes to whatever they have put in place. Could I explain the difference well enough? Thanks, 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 °