From schmidt@informatik.haw-hamburg.de Fri Apr 1 02:17:23 2011 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1163F3A67A8 for ; Fri, 1 Apr 2011 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCkuvR1RpF0o for ; Fri, 1 Apr 2011 02:17:21 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 945823A6774 for ; Fri, 1 Apr 2011 02:17:21 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-533d.meeting.ietf.org ([130.129.83.61]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q5aTe-0004l3-4e; Fri, 01 Apr 2011 11:17:10 +0200 Message-ID: <4D95988A.9060703@informatik.haw-hamburg.de> Date: Fri, 01 Apr 2011 11:19:06 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Luis M. Contreras" References: <4D91F335.40709@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:17:23 -0000 Hi Luis, Seil, some additional remarks marked by [thomas] On 31.03.2011 23:03, Luis M. Contreras wrote: > Hi Seil, > more discussion below: > > "Seil" => You don't see the benefit. why? ISPs are now making a > pitch for building and getting their own contents from public > broadcasters, cable broadcasters, ... so on. Obiviously, this is > inevitable trend to achieve competiveness from other ISPs. That will > be getting serious more than now. And as I presented in my > slot, this concept is reflected at MBMS architecture of 3GPP SAE. > Only appropriate manner needs to be handled between home and visited > network. About that, the draft will be updated. > In M-LMA, how about local contents? > > Luis>> It is just my personal view in this interesting and necessary > debate opened byThomas. I would like to distinguish two concepts: remote > content distributed locally, and local content distributed locally. In > the first case, I don't see the benefit. I think that the simplest way > to deliver the service is through M-LMA. In the second case, I agree > that it seems more optimal to use direct routing. But, in my opinion, > the direct routing can not be consider as the main solution, but an > ocassional optimization scenario in case the content is local to the > visited domain (probably the most common is that a MN usually will > demand contents from its Home Network, because the user maintains a > service contract its Home Operator). I think it is the same idea than in > the unicast case regarding the routing optimization: it is an > optimization case for a more general solution (which I believe it is the > M-LMA approach). > [thomas] The problem with direct routing as a "general solution" is that it is unrealistic to assume all multicast traffic, which is globally available, is routed directly into an access network of an operator. This will most likely only be the case for content streams the operator is willing to offer to its customers, e.g., selected IPTV channels ... So relying purely on the direct routing might end up with a poor choice of content services, in particular with changing offers between access network operators. However, the benefit of local routing in the "remote content distributed locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Stream ...) guides the content into its access network and then simply turns on multicast routing (this is what wired operators do today). This will result in full scaling, no tunnels or extra boxes involved and at least optimizes Capex, but typically Opex, as well (depending on Mcast route management brains). The M-LMA, as mentioned many times, is an extra box that needs to handle all streams simultaneously and redistribute them via tunnels. This leads to a scaling bottleneck, traffic multiplication in the access network (including waste of bandwidth) and efforts in semi-manual configurations ... > * Coexistence of home/remote content retrieval (e.g., by the base > solution) and access from local multicast routing. Thus a MAG would > need to distinguish (preconfigured) local group subscriptions from > non-local content. > > Luis>> This is not possible with current functionality on MAG as > MLD proxy. It is only possible to define one upstream interface, > so the operator would be forced to permanently choose between > local or remote multicast for all kind of traffic. > > "Seil" => Yes, it's possible. Only one upstream interface is > available but "per single MLD proxy instance". So, the choice will > not be forced to operators. > > Luis>> I don't think so. According to base solution, the MN is > associated to an MLD proxy instance as a function of the LMA it is bound > to. That is, the association to an MLD instance is previous to the MLD > Report processing. So, the MAG doesn't know the required content (local > or remote) before associating the MN to a proxy instance. As > consequence, the operator is forced to choose between using an MLD proxy > pointing to the M-LMA or another one pointing to local MR for all kind > of traffic, and for all the MNs associated to the same LMA. > [Thomas] In my understanding, Luis is correct here. Upstream interfaces of RFC4605 MLD proxies cannot distinguish between different groups. For one downstream interface you always need to have one single proxy instance and this instance only can have one upstream interface. As the downstream interface corresponds to a link with an MN, this MN can either receive local or remote content. This is not what we want: we want to distinguish traffic per group, not per host. So I guess, a solution for this scenario is not possible using a standard MLD proxy function. It is of course easy to achieve by making MAGs PIM (SM or BIDIR) routers and configuring RPs per group(-range). 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 seiljeon@gmail.com Mon Apr 4 20:50:24 2011 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180053A686A for ; Mon, 4 Apr 2011 20:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38I0jcuJKEKL for ; Mon, 4 Apr 2011 20:50:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 964453A6875 for ; Mon, 4 Apr 2011 20:50:21 -0700 (PDT) Received: by qyk7 with SMTP id 7so4030120qyk.10 for ; Mon, 04 Apr 2011 20:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tq46Fu88dHWTu69cK1OjWRjVCY/5chCjVwKDJm7BLj8=; b=rtezzDe2AYI7DSoGy8K7hl3Qkj87sR5euV+OhE1RPNOhxFSVJmYboGWw7+pUWRBwFE xFzT6TEkoZAS1qb+z4DoNR7p4mL0RThRDC+b75D0LmU6a7eNA61g6FAyvnD82wf7uODp 4ZmmrpL63Ao2EyEwbnAHW9UjL75qRQ3mmBiV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=gZvaIpEL/ALQYd6XtpBwQke0p5vl7c72/kF/D3Yc06kmm+zfgfyM63CK+GQ83zcKL2 v3PDiurSHFJHjbmSgFLA4CMlUwlPLQR2Ahf33E6ckBQG3QC8J+Ygo1WPm6mWr7ty3zFO cepEDJazpIEbZcMF/VcFTpBf2WwhaUQRAj34c= MIME-Version: 1.0 Received: by 10.229.2.69 with SMTP id 5mr5798485qci.158.1301975524265; Mon, 04 Apr 2011 20:52:04 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.187.77 with HTTP; Mon, 4 Apr 2011 20:52:04 -0700 (PDT) In-Reply-To: References: <4D91F335.40709@informatik.haw-hamburg.de> Date: Tue, 5 Apr 2011 12:52:04 +0900 X-Google-Sender-Auth: sbCNoK3_E-Z-Qxj-AElN6bro9ms Message-ID: From: seil jeon To: "Luis M. Contreras" Content-Type: multipart/alternative; boundary=0016e64bd074a14f9704a023cca3 Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 03:50:24 -0000 --0016e64bd074a14f9704a023cca3 Content-Type: text/plain; charset=ISO-8859-1 Hi Luis, Thanks for your comments. Now, this discussion is getting more interesting. Please see below "Seil" 2011/4/1 Luis M. Contreras > Hi Seil, > > more discussion below: > > >> "Seil" => You don't see the benefit. why? ISPs are now making a pitch for >> building and getting their own contents from public broadcasters, cable >> broadcasters, ... so on. Obiviously, this is inevitable trend to achieve >> competiveness from other ISPs. That will be getting serious more than >> now. And as I presented in my slot, this concept is reflected at MBMS >> architecture of 3GPP SAE. Only appropriate manner needs to be handled >> between home and visited network. About that, the draft will be updated. >> >> In M-LMA, how about local contents? >> >> > > Luis>> It is just my personal view in this interesting and necessary debate > opened byThomas. I would like to distinguish two concepts: remote content > distributed locally, and local content distributed locally. In the first > case, I don't see the benefit. I think that the simplest way to deliver the > service is through M-LMA. In the second case, I agree that it seems more > optimal to use direct routing. But, in my opinion, the direct routing can > not be consider as the main solution, but an ocassional optimization > scenario in case the content is local to the visited domain (probably the > most common is that a MN usually will demand contents from its Home Network, > because the user maintains a service contract its Home Operator). I think it > is the same idea than in the unicast case regarding the routing > optimization: it is an optimization case for a more general solution (which > I believe it is the M-LMA approach). > "Seil" => Thank you for your comment. Regarding on remote content retrieval from home network, that is needed to be clearly presented in our draft. But, it is one of the issues to be considered in routing optimization item. As you guess, there are several methods like multicasting gateway, P2P, and so on... to interconnect home/visited network. But regarding on the methods, as I said before, it is better to discuss it later in updated our draft. Merely, what I would like to say, the tunnel convergence problem handled in current multimob charter comes from "multicast traffic" storm for a thousands of channels and users. The truth of the matter is how to effectively reduce and distribute multicast traffic. From that point of view, local routing concept crucially matters. M-LMA is required to handle a lot of channels and replicate the packet. It leads to heavy load on M-LMA, and potentially it has single point of failure. This issue appears much serious than tunnel convergence. > > > >> * Coexistence of home/remote content retrieval (e.g., by the base >> solution) and access from local multicast routing. Thus a MAG would need to >> distinguish (preconfigured) local group subscriptions from non-local >> content. >> >>> >>> Luis>> This is not possible with current functionality on MAG as MLD >>> proxy. It is only possible to define one upstream interface, so the operator >>> would be forced to permanently choose between local or remote multicast for >>> all kind of traffic. >>> >> >> "Seil" => Yes, it's possible. Only one upstream interface is available >> but "per single MLD proxy instance". So, the choice will not be forced to >> operators. >> > > Luis>> I don't think so. According to base solution, the MN is associated > to an MLD proxy instance as a function of the LMA it is bound to. That is, > the association to an MLD instance is previous to the MLD Report processing. > So, the MAG doesn't know the required content (local or remote) before > associating the MN to a proxy instance. As consequence, the operator is > forced to choose between using an MLD proxy pointing to the M-LMA or another > one pointing to local MR for all kind of traffic, and for all the MNs > associated to the same LMA. > > "Seil" => It seems that my response was not enough. First, one upstream interface is possible per single MLD proxy instance on MN. But several MLD proxy instance could be operated on an MAG like base solution. It was my answer. Regarding coexistence of home/remote content retrieval, it seems to me that you probably pointed out local source directly connected to MAG as described in our presentation. But this means optional usage depending on operator's network. Basically, it is assumed that all the contents (remote/local) are retrieved from MR. > >> "Seil" => Actually, M-LMA should not be said "LMA" as pointed out in the >> meeting because there's no PMIP action with a MAG and no information related >> to MNs. And I wonder only one M-LMA is enough to connect with MAGs in >> visited domain because M-LMA must be managed by certain operator. >> > > Luis>> I'm not totally agree with this (it is my personal opinion). I think > that establishing a tunnel following PMIPv6 procedures can be considered a > PMIP action. Furthermore, all other stuff related with security, > authentication, heartbeat, load balancing, etc, etc, defined in PMIPv6 can > be applicable in an straightforward manner. It is true that there is no > information per MN, but the protocol procedures of PMIPv6 are wider than > this. > "Seil" => I don't think so. Main function of the LMA is to provide session anchoring to MNs. As you mentioned that there is no information and no managing per MN, in my opinion, there's no reason to be said "M-LMA". PBU signal is used for mobility binding or mobility session update for individual MN. Protocol procedure is a means to an end and it seemed to me end disappeared. It has the strong impression of "Multicast Traffic Distributor" rather than "M-LMA". So, this is no longer PMIPv6 tunnel, in my opinion, I thnink special bearer is correct for multicast traffic delivery. > > Regarding the number of M-LMAs per visited domain, I consider possible that > different Home providers connect to a common Visited Network, each of them > managing its own M-LMA, and sharing (or not) the MAGs placed in the Visited > network. > >> "Seil" => In terms of "traffic distribution", hitoshi's approach is >> better than M-LMA. And local routing is the best among them. >> > > Luis>> I need to study this to provide a comparison. > > Thanks all for this enriching discussion, > > best regards, > > Luis > Thanks and your regards, Seil Jeon --0016e64bd074a14f9704a023cca3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Luis,
=A0
Thanks for your comments.
=A0
Now, this discussion is getting more interesting.
=A0
Please see below "Seil"


=A0
2011/4/1 Luis M. Contreras <= ;contreras.uc3m@gmail.com&g= t;
Hi Seil,
=A0
more discussion below:

=A0
"Seil" =3D>=A0You don't see the benefit. why? ISPs ar= e now making a pitch for building and getting their own contents from publi= c broadcasters, cable broadcasters, ... so on. Obiviously, this is inevitab= le trend to achieve competiveness from other ISPs. That will be getting ser= ious more than now.=A0And as I presented in my slot,=A0this concept is refl= ected=A0at MBMS architecture of=A03GPP SAE. Only appropriate manner needs t= o be handled between home and visited network. About that, the draft will b= e updated.
=A0
=A0=A0In M-LMA,=A0how about local contents?
=A0
=A0
Luis>> It is just my personal view in this interesting and neces= sary debate opened byThomas. I would like to distinguish two concepts: remo= te content distributed locally, and local content distributed locally. In t= he first case, I don't see the benefit. I think that the simplest way t= o deliver the service is through M-LMA. In the second case, I agree that it= seems more optimal to use direct routing. But, in my opinion, the direct r= outing can not be consider as the main solution, but an ocassional optimiza= tion scenario in case the content is local to the visited domain (probably = the most common is that a MN usually will demand contents from its Home Net= work, because the user maintains a service contract its Home Operator). I t= hink it is the same idea than in the unicast case regarding the routing opt= imization: it is an optimization case for a more general solution (which I = believe it is the M-LMA approach).
=A0
"Seil" =3D> Thank you for your comment. Regarding on remo= te content retrieval from home network, that is needed to be clearly presen= ted in our draft. But, it is one of the issues to be considered in routing = optimization item. As you guess, there are several methods like multicastin= g gateway, P2P, and so on... to interconnect home/visited network. But rega= rding on the methods, as I said before, it is better to discuss it later in= updated our draft.
=A0
Merely, what I would like to say, the tunnel convergence problem handl= ed in current multimob charter comes from "multicast traffic" sto= rm for a thousands of channels and users. The truth of the matter is how to= effectively reduce and distribute multicast traffic. From that point of vi= ew, local routing concept crucially matters. M-LMA is required to handle a = lot of channels and replicate the packet. It leads to heavy load on M-LMA, = and potentially it has single point of failure. This issue appears much ser= ious than tunnel convergence.
=A0
=A0
=A0* Coexistence of home/remote content retrieval (e.g., by the base s= olution) and access from local multicast routing. Thus a MAG would need to = distinguish (preconfigured) local group subscriptions from non-local conten= t.
=A0
Luis>> This is not possible with current functionality on MAG as= MLD proxy. It is only possible to define one upstream interface, so the op= erator would be forced to permanently choose between local or remote multic= ast for all kind of traffic.
=A0
=A0"Seil" =3D> Yes, it's possible. Only one upstream = interface is available but "per single MLD proxy instance". So, t= he choice will not be forced to operators.
=A0
Luis>> I don't think so. According to base solution, the MN = is associated to an MLD proxy instance as a function=A0of the LMA it is bou= nd to. That is, the association to an MLD instance is previous to the MLD R= eport processing. So, the MAG doesn't know the required content (local = or remote) before associating the MN to a proxy instance. As consequence, t= he operator is forced to choose between using an MLD proxy pointing to the = M-LMA or another one pointing to local MR for all kind of traffic, and for = all the MNs associated to the same LMA.
=A0
=A0
"Seil" =3D> It seems that my response was not enough. Fir= st, one upstream interface is possible per single MLD proxy instance on MN.= But several MLD proxy instance could be operated on an MAG like base solut= ion. It was my answer.
=A0
Regarding coexistence of home/remote content retrieval, it seems to me= that you probably pointed out local source directly connected to MAG as de= scribed in our presentation. But this means optional usage depending on ope= rator's network. Basically, it is assumed that all the contents (remote= /local) are retrieved from MR.
=A0
=A0
=A0
=A0"Seil" =3D> Actually, M-LMA=A0should not be said=A0&qu= ot;LMA" as pointed out in the meeting because there's no PMIP acti= on with a MAG and no=A0information related to MNs. And=A0I wonder=A0only on= e M-LMA is enough to connect with MAGs in visited domain because M-LMA must= be managed by certain operator.
=A0
Luis>> I'm not totally agree with this (it is my personal op= inion). I think that establishing a tunnel following PMIPv6 procedures can = be considered a PMIP action. Furthermore, all other stuff related with secu= rity, authentication, heartbeat, load balancing, etc, etc, defined in PMIPv= 6 can be applicable in an straightforward manner. It is true that there is = no information per MN, but the protocol procedures of PMIPv6 are wider than= this.
=A0
"Seil" =3D> I don't think so. Main function of the LM= A is to provide session anchoring to MNs. As you mentioned that there is no= information and no managing per MN, in my opinion, there's no reason t= o be said "M-LMA". PBU signal is used for mobility binding or mob= ility session update for individual MN. Protocol procedure is a means to an= end and it seemed to me end disappeared. It has the strong impression of &= quot;Multicast Traffic Distributor" rather than "M-LMA". So,= this is no longer PMIPv6 tunnel, in my opinion, I thnink special bearer is= correct for multicast traffic delivery.
=A0
=A0
Regarding the number of M-LMAs per visited domain, I consider possible= that different Home providers connect to a common Visited Network, each of= them managing its own M-LMA, and sharing (or not) the MAGs placed in the V= isited network.
=A0
=A0"Seil" =3D> In terms of "traffic distribution&quo= t;, hitoshi's approach is better than M-LMA. And local routing is the b= est among them.
=A0
Luis>> I need to study this to provide a comparison.
=A0
Thanks all for this enriching discussion,
=A0
best regards,
=A0
Luis

Thanks and your regards,
=A0
Seil Jeon
--0016e64bd074a14f9704a023cca3-- From seiljeon@gmail.com Mon Apr 4 21:44:32 2011 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F743A6886 for ; Mon, 4 Apr 2011 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOxtUod5hjuL for ; Mon, 4 Apr 2011 21:44:30 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id AA4323A688B for ; Mon, 4 Apr 2011 21:44:29 -0700 (PDT) Received: by qwc23 with SMTP id 23so2536qwc.31 for ; Mon, 04 Apr 2011 21:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rKDq5/nuHnwI4HDuAQuo3xYBl4SD2S3QYeZC7GomohY=; b=w+0xUS4/VE8Y02trIWYkBtPS+61uCTNTq/FMfjAlwIznOzikIvJzAnRdVB1U1kGyHN BYt2Bm7KibEA/cd3tHX91ZZcxueJg+/udZfNnlbu9jh6xI/kqqmfdgHpvPjKC3uLLP0v XDf3NnCHLx7/mKfoH/oOblfrE5eBkCSurV3Ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=i8/Gm4Fc3Us+PtmcA2F9AGxwYXs+LgS8+tuXIaLpu3UdZcxggQN8TyR5ePt2aESlzn iLl0432sP4nTbkJn5o4hcciDBELuA8MtAHNi/N7TWGinjt2dgFGCCaHhzFJDiEcqsSA2 /y4spIPnbBTXMS820zcYMW5ZNFZtbvmgdQuWs= MIME-Version: 1.0 Received: by 10.229.2.69 with SMTP id 5mr5820439qci.158.1301978771592; Mon, 04 Apr 2011 21:46:11 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.187.77 with HTTP; Mon, 4 Apr 2011 21:46:11 -0700 (PDT) In-Reply-To: <4D95988A.9060703@informatik.haw-hamburg.de> References: <4D91F335.40709@informatik.haw-hamburg.de> <4D95988A.9060703@informatik.haw-hamburg.de> Date: Tue, 5 Apr 2011 13:46:11 +0900 X-Google-Sender-Auth: ae6Ck0PN4_WK0oePfbAd3T4n8zA Message-ID: From: seil jeon To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=0016e64bd0742f9b3504a0248e8e Cc: multimob@ietf.org Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:44:32 -0000 --0016e64bd0742f9b3504a0248e8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Thomas, Thanks for your useful comment. Please see below "Seil" 2011/4/1 Thomas C. Schmidt > Hi Luis, Seil, > > some additional remarks marked by [thomas] > > > On 31.03.2011 23:03, Luis M. Contreras wrote: > >> Hi Seil, >> more discussion below: >> >> "Seil" =3D> You don't see the benefit. why? ISPs are now making a >> pitch for building and getting their own contents from public >> broadcasters, cable broadcasters, ... so on. Obiviously, this is >> inevitable trend to achieve competiveness from other ISPs. That will >> be getting serious more than now. And as I presented in my >> slot, this concept is reflected at MBMS architecture of 3GPP SAE. >> Only appropriate manner needs to be handled between home and visited >> network. About that, the draft will be updated. >> In M-LMA, how about local contents? >> >> Luis>> It is just my personal view in this interesting and necessary >> debate opened byThomas. I would like to distinguish two concepts: remote >> content distributed locally, and local content distributed locally. In >> the first case, I don't see the benefit. I think that the simplest way >> to deliver the service is through M-LMA. In the second case, I agree >> that it seems more optimal to use direct routing. But, in my opinion, >> the direct routing can not be consider as the main solution, but an >> ocassional optimization scenario in case the content is local to the >> visited domain (probably the most common is that a MN usually will >> demand contents from its Home Network, because the user maintains a >> service contract its Home Operator). I think it is the same idea than in >> the unicast case regarding the routing optimization: it is an >> optimization case for a more general solution (which I believe it is the >> M-LMA approach). >> >> > [thomas] The problem with direct routing as a "general solution" is that = it > is unrealistic to assume all multicast traffic, which is globally availab= le, > is routed directly into an access network of an operator. This will most > likely only be the case for content streams the operator is willing to of= fer > to its customers, e.g., selected IPTV channels ... So relying purely on t= he > direct routing might end up with a poor choice of content services, in > particular with changing offers between access network operators. > > However, the benefit of local routing in the "remote content distributed > locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Str= eam > ...) guides the content into its access network and then simply turns on > multicast routing (this is what wired operators do today). This will resu= lt > in full scaling, no tunnels or extra boxes involved and at least optimize= s > Capex, but typically Opex, as well (depending on Mcast route management > brains). > > The M-LMA, as mentioned many times, is an extra box that needs to handle > all streams simultaneously and redistribute them via tunnels. This leads = to > a scaling bottleneck, traffic multiplication in the access network > (including waste of bandwidth) and efforts in semi-manual configurations > ... "Seil" =3D> I agree this comment as my response to Luis's comment in previo= us mail. As I mentioned in previous comment, this is serious issue. In my opinion, it might be an instance of the biter getting bitten. > * Coexistence of home/remote content retrieval (e.g., by the base >> solution) and access from local multicast routing. Thus a MAG would >> need to distinguish (preconfigured) local group subscriptions from >> non-local content. >> >> Luis>> This is not possible with current functionality on MAG as >> MLD proxy. It is only possible to define one upstream interface, >> so the operator would be forced to permanently choose between >> local or remote multicast for all kind of traffic. >> >> "Seil" =3D> Yes, it's possible. Only one upstream interface is >> available but "per single MLD proxy instance". So, the choice will >> not be forced to operators. >> >> Luis>> I don't think so. According to base solution, the MN is >> associated to an MLD proxy instance as a function of the LMA it is bound >> to. That is, the association to an MLD instance is previous to the MLD >> Report processing. So, the MAG doesn't know the required content (local >> or remote) before associating the MN to a proxy instance. As >> consequence, the operator is forced to choose between using an MLD proxy >> pointing to the M-LMA or another one pointing to local MR for all kind >> of traffic, and for all the MNs associated to the same LMA. >> >> > [Thomas] In my understanding, Luis is correct here. Upstream interfaces o= f > RFC4605 MLD proxies cannot distinguish between different groups. For one > downstream interface you always need to have one single proxy instance an= d > this instance only can have one upstream interface. As the downstream > interface corresponds to a link with an MN, this MN can either receive lo= cal > or remote content. > > This is not what we want: we want to distinguish traffic per group, not p= er > host. So I guess, a solution for this scenario is not possible using a > standard MLD proxy function. It is of course easy to achieve by making MA= Gs > PIM (SM or BIDIR) routers and configuring RPs per group(-range). > > "Seil" =3D> Considering the structure where several sources connect to an M= AG, it could be a good candidate. > Best wishes, > > > Thomas > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 > =B0 > Thanks for your useful comment again. It would encourage the progress of our discussion. Your regards, Seil Jeon --0016e64bd0742f9b3504a0248e8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Thomas,
=A0
Thanks for your useful comment.
=A0
Please see below "Seil"


=A0
2011/4/1 Thomas C. Schmidt <= ;schmidt@informatik.ha= w-hamburg.de>
Hi Luis, Seil,

some addit= ional remarks marked by [thomas]=20


On 31.03.2011 23:03, Luis M. Contreras wrote:
Hi Seil,
more discussion belo= w:

=A0 =A0"Seil" =3D> You don't see the benefit. wh= y? ISPs are now making a
=A0 =A0pitch for building and getting their own contents from public
=A0= =A0broadcasters, cable broadcasters, ... so on. Obiviously, this is
=A0= =A0inevitable trend to achieve competiveness from other ISPs. That will=A0 =A0be getting serious more than now. And as I presented in my
=A0 =A0slot, this concept is reflected at MBMS architecture of 3GPP SAE.=A0 =A0Only appropriate manner needs to be handled between home and visite= d
=A0 =A0network. About that, the draft will be updated.
=A0 =A0 =A0 = In M-LMA, how about local contents?

Luis>> It is just my personal view in this interesting and necess= ary
debate opened byThomas. I would like to distinguish two concepts: re= mote
content distributed locally, and local content distributed locally.= In
the first case, I don't see the benefit. I think that the simplest way<= br>to deliver the service is through M-LMA. In the second case, I agree
= that it seems more optimal to use direct routing. But, in my opinion,
the direct routing can not be consider as the main solution, but an
ocas= sional optimization scenario in case the content is local to the
visited= domain (probably the most common is that a MN usually will
demand conte= nts from its Home Network, because the user maintains a
service contract its Home Operator). I think it is the same idea than inthe unicast case regarding the routing optimization: it is an
optimizat= ion case for a more general solution (which I believe it is the
M-LMA ap= proach).


[thomas] The problem with direct routing a= s a "general solution" is that it is unrealistic to assume all mu= lticast traffic, which is globally available, is routed directly into an ac= cess network of an operator. This will most likely only be the case for con= tent streams the operator is willing to offer to its customers, e.g., selec= ted IPTV channels ... So relying purely on the direct routing might end up = with a poor choice of content services, in particular with changing offers = between access network operators.

However, the benefit of local routing in the "remote content distr= ibuted locally"-scenario seems obvious to me: The operator somehow (CD= N, PtP-Stream ...) guides the content into its access network and then simp= ly turns on multicast routing (this is what wired operators do today). This= will result in full scaling, no tunnels or extra boxes involved and at lea= st optimizes Capex, but typically Opex, as well (depending on Mcast route m= anagement brains).

The M-LMA, as mentioned many times, is an extra box that needs to handl= e all streams simultaneously and redistribute them via tunnels. This leads = to a scaling bottleneck, traffic multiplication in the access network (incl= uding waste of bandwidth) and efforts in semi-manual configurations ...=A0= =A0
=A0
"Seil" =3D> I agree this comment as my response to Luis&#= 39;s comment in previous mail. As I mentioned in previous comment, this is = serious issue. In my opinion, it might be an instance of the biter getting = bitten.
=A0
=A0
=A0 =A0 =A0* Coexistence of home= /remote content retrieval (e.g., by the base
=A0 =A0solution) and access= from local multicast routing. Thus a MAG would
=A0 =A0need to distinguish (preconfigured) local group subscriptions from=A0 =A0non-local content.

=A0 =A0 =A0 =A0Luis>> This is not = possible with current functionality on MAG as
=A0 =A0 =A0 =A0MLD proxy. = It is only possible to define one upstream interface,
=A0 =A0 =A0 =A0so the operator would be forced to permanently choose betwee= n
=A0 =A0 =A0 =A0local or remote multicast for all kind of traffic.
<= br>=A0 =A0"Seil" =3D> Yes, it's possible. Only one upstrea= m interface is
=A0 =A0available but "per single MLD proxy instance". So, the cho= ice will
=A0 =A0not be forced to operators.

Luis>> I don= 9;t think so. According to base solution, the MN is
associated to an MLD= proxy instance as a function of the LMA it is bound
to. That is, the association to an MLD instance is previous to the MLD
R= eport processing. So, the MAG doesn't know the required content (local<= br>or remote) before associating the MN to a proxy instance. As
conseque= nce, the operator is forced to choose between using an MLD proxy
pointing to the M-LMA or another one pointing to local MR for all kind
o= f traffic, and for all the MNs associated to the same LMA.


[Thomas] In my understanding, Luis is correct here. Upstream = interfaces of RFC4605 MLD proxies cannot distinguish between different grou= ps. For one downstream interface you always need to have one single proxy i= nstance and this instance only can have one upstream interface. As the down= stream interface corresponds to a link with an MN, this MN can either recei= ve local or remote content.

This is not what we want: we want to distinguish traffic per group, not= per host. So I guess, a solution for this scenario is not possible using a= standard MLD proxy function. It is of course easy to achieve by making MAG= s PIM (SM or BIDIR) routers and configuring RPs per group(-range).

=A0
"Seil" =3D> Considering the structure where several sourc= es connect to an MAG, it=A0could be a=A0good candidate.
=A0
=A0
=A0
Best wishes,=20


Thomas

--

Prof. Dr. Thomas C. Schm= idt
=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Berliner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologi= es Group =A0 =A020099 Hamburg, Germany =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42= 875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 = =A0Fax: +49-40-42875-8409 =B0

=A0
Thanks for your useful comment again.
=A0
It would encourage the progress of our discussion.
=A0
Your regards,
=A0
Seil Jeon
=A0
=A0
--0016e64bd0742f9b3504a0248e8e-- From wwwrun@rfc-editor.org Mon Apr 11 12:21:22 2011 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AB228C14C; Mon, 11 Apr 2011 12:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV3crc6xN2+d; Mon, 11 Apr 2011 12:21:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 93AFD28C14D; Mon, 11 Apr 2011 12:21:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D30AE0790; Mon, 11 Apr 2011 12:21:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110411192121.5D30AE0790@rfc-editor.org> Date: Mon, 11 Apr 2011 12:21:21 -0700 (PDT) Cc: multimob@ietf.org, rfc-editor@rfc-editor.org Subject: [multimob] RFC 6224 on Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains 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, 11 Apr 2011 19:21:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6224 Title: Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains Author: T. Schmidt, M. Waehlisch, S. Krishnan Status: Informational Stream: IETF Date: April 2011 Mailbox: schmidt@informatik.haw-hamburg.de, mw@link-lab.net, suresh.krishnan@ericsson.com Pages: 19 Characters: 46105 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-multimob-pmipv6-base-solution-07.txt URL: http://www.rfc-editor.org/rfc/rfc6224.txt This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multicast Mobility Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From behcetsarikaya@yahoo.com Tue Apr 19 11:45:48 2011 Return-Path: X-Original-To: multimob@ietfc.amsl.com Delivered-To: multimob@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 219CEE06F2 for ; Tue, 19 Apr 2011 11:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.686 X-Spam-Level: X-Spam-Status: No, score=0.686 tagged_above=-999 required=5 tests=[AWL=-1.348, BAYES_40=-0.185, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3noarJ5lfOgR for ; Tue, 19 Apr 2011 11:45:47 -0700 (PDT) Received: from nm13.bullet.mail.sp2.yahoo.com (nm13.bullet.mail.sp2.yahoo.com [98.139.91.83]) by ietfc.amsl.com (Postfix) with SMTP id 92EC8E06DE for ; Tue, 19 Apr 2011 11:45:47 -0700 (PDT) Received: from [98.139.91.62] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 19 Apr 2011 18:45:44 -0000 Received: from [98.139.91.46] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 19 Apr 2011 18:45:44 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 19 Apr 2011 18:45:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 157335.53596.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 16627 invoked by uid 60001); 19 Apr 2011 18:45:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303238743; bh=zsTclJag1ZBH2/sCtsbpe1LX0uI28sBw7coTx7/3S/I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=yotyR6MUF7BYTS6O0nIwAlfCBYvHVogqJ5D3C7eT5T5H/ylU4A8GhOOla+s8JW4AvFDzrw7/CONJlEiJwj3h3kBNjBskwOkXmIc+Z/z22UE18La3fdMzsei3/C8ubFOwNFjfZEJdJj4zJrzFeBTEMOj1ByqgvlBdvlG64D93FRU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Uavpux1B7rxOc3RHkqMV2dijlWgfKvdBRloZgLWb/2iy9/Vp2nb/AMLwzPaJjKr1U/M/eThm6z8ZwUOaq2UN3C7U6u9RCMR0ciAefTA9/zMwY4GPMY79wML1/r1DV6XWbgkMsQptZvIRymmxaWVR4wT6/geMoDY2K6PvsQ1Emq8=; Message-ID: <655706.12688.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: bv9HV_0VM1nGHc46WZ54enDNgpjDqjlkxgPcnUoY7QVO2HH u_hgk.Jb71BVP54u8ByfEvTNsV3v_mUHAXOsDWo7v1Td7nIZOwXtKMLWne7y 1mRUpWuuGdliV8Zlbe2aWDJYuBPIAcaUidpLwTKE2581deIcJlVfEGdLdyHy YS3wZZpKj_QYXmaHWtvzF1sH.4.IWAGvGp.jm1HGlcoboAx2t8XeBDc80FWT 8iVyoKLjOryOooqys.O6WM9Kw3wbkP8svmcHw9GK5.tt13Tj9CTRSIlSA_SM H5tjDaL556Vqkm3mwpMg02gZbOE0gOe1HeF5Vg5petQPeow7swtgonsS17nJ IwNhgJWZrNwklJ6AN4lODxW9_lIr6C0blVWYz1SI8.1bqwK9.QbKHiJ5jVaH FVAhZVvSrdw-- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Tue, 19 Apr 2011 11:45:43 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Tue, 19 Apr 2011 11:45:43 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Minutes finalized X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2011 18:45:48 -0000 http://www.ietf.org/proceedings/80/minutes/multimob.txt From Dirk.von-Hugo@telekom.de Wed Apr 20 07:43:54 2011 Return-Path: X-Original-To: multimob@ietfc.amsl.com Delivered-To: multimob@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A07BEE0681 for ; Wed, 20 Apr 2011 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29ZDW06s807D for ; Wed, 20 Apr 2011 07:43:53 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfc.amsl.com (Postfix) with ESMTP id C1AC0E0613 for ; Wed, 20 Apr 2011 07:43:48 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail51.telekom.de with ESMTP; 20 Apr 2011 16:35:21 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 16:35:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 16:35:20 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC80278480338872C@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4D92E6EF.3070803@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [multimob] Thoughts on Context Transfer Thread-Index: AcvustlG1G5KsJpRSmmjHdCiT3E/7wQro5kQ References: <4D9224DC.3000503@informatik.haw-hamburg.de><20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <643B0A1D1A13AB498304E0BBC80278480328CE93@S4DE8PSAAQC.mitte.t-com.de> <4D92E6EF.3070803@informatik.haw-hamburg.de> From: To: X-OriginalArrivalTime: 20 Apr 2011 14:35:21.0396 (UTC) FILETIME=[2D6C8740:01CBFF68] Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:43:54 -0000 Dear Thomas et al., Regarding your wish for potential deployment scenarios (of mobile = multicast flows handling separated from unicast sessions ... I presume) = as below ... >> Regarding potential use cases for separated HO for multicast traffic = (independent of concurrent unicast traffic to the MN) a reason might be = operator policy running heterogeneous networks in parallel and doing = (multicast) traffic off-load e.g. from cellular (with only few = subscribers to a content) to a broadcast medium (e.g. DVB) in case the = subscriber group reaches a certain size making it economic to switch the = distribution path ... >O.K., I see. But still this is not exactly a PMIP-like scenario. In = your=20 case, MN would have to activate an additional radio interface (DVB or=20 ??) to receive multicast from there. But this interface would first need = to configure a unicast IP address before participating in the multicast=20 communication. However, this unicast interface would be newly=20 instantiated, thus experiences no context transfer, and also lives at a=20 different media - so this may be rather a case for MIH?? >> AR's in this case may be radio towers ... Spannung a larger area than = WiFi and cellular but nevertheless being limited e.g. in case of highway = or train movement ... >I agree, this is an interesting scenario, provided operators do such=20 things (or are interested in doing so ???). Still, the problem is a=20 different one, in particular for the case of unidirectional downlinks=20 such as DVB or satellites or ... >Even though I would argue that this scenario is something different, it = might be quite interesting for the group to learn about possible=20 deployment options. Will you be able to gather knowledge on this area=20 and share with the group? >Thanks & best wishes >Thomas ... I have tried to finally come up with applications not requiring = multiple interfaces, since I agree that this would add too much = complexity to our current PMIP based approach. Nevertheless regarding increasing wireless data traffic forecasts (and = popular services with a one-to-many communication structure as in social = networks, e-learning, multi-player gaming and so on) operators may seek = to save radio resources by replacing several parallel unicast streams by = a single (or fewer) multicast streams. E.g. within an urban (WiFi or = cellular) network consisting of several access nodes (BS/NodeBs or APs = with overlapping coverage which are linked to different MAGs) one of = them is taking over the multicast traffic (or even is a 'multicast = dedicated' node) - and all MNs which have joined a multicast group are = moved to the single multicast stream emerging from that access node - = thus requiring decoupled handover for some (or even all) MNs. Similarily the new TV services allowing to switch between different = viewpoints (e.g. for sports event transmission) may require to transfer = more parallel streams than can be handled by a single access node such = that more than one Multicast dedicated access nodes exist. A user = switching between different channels may have to be handed over to the = 'right' node (and corresponding MAG). Also the differing QoS requirements of parallel unicast and multicast = sessions of a MN (related to different services, e.g. mIPTV or video = conferencing with low delay vs. file transfer with 0 error probability) = may request in case of deterioating link quality to handover only the = unicast data session. Accordingly in case of failure of intermediate = nodes between LMA and MAG a rerouting may result in unacceptable delay = for real-time multicast streaming so that this flow is handed over to a = MAG with shorter path delay to the MN (in the scenario with multiple = visible MAGs per MN). At least in current 3G deployment with hierarchical cell structure (HCS) = macro cells and overlay micro or pico cells are in operation serving the = same area - and thus allowing for the assumed decoupled handover on = radio link layer. At the moment no more different scenarios come to my mind ... And of = course these are ideas only and not yet plans of an operator ;-)=20 Best regards and happy holidays! Dirk > -----Urspr=FCngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Thomas C. Schmidt > Gesendet: Mittwoch, 30. M=E4rz 2011 00:25 > An: Hitoshi Asaeda > Cc: rkoodli@cisco.com; multimob@ietf.org > Betreff: Re: [multimob] Thoughts on Context Transfer > > Hi Hitoschi, > > that may be - the first draft to present a context transfer by CXTP > independent of unicast handover was > http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. > > The question was about the reasons and the sense behind it ... > ... and my reason for asking is that I cannot think of good reasons to > do a multicast transfer directly between ARs decoupled from unicast > handover. > > Best regards, > > Thomas > > On 29.03.2011 21:20, Hitoshi Asaeda wrote: >>> Why don't we use a generic context transfer (by RFC 4067) for >>> multicast states only, and leave unicast handover aside? >> >> As I presented today, our draft uses CXTP (rfc4067). >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > --=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 From schmidt@informatik.haw-hamburg.de Fri Apr 29 08:39:58 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80134E0663 for ; Fri, 29 Apr 2011 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRvoWxHylCLm for ; Fri, 29 Apr 2011 08:39:51 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id AF4F2E06A7 for ; Fri, 29 Apr 2011 08:39:50 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231225083.adsl.alicedsl.de ([92.231.225.83] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QFplX-0006MI-0H; Fri, 29 Apr 2011 17:37:59 +0200 Message-ID: <4DBADBB7.5000605@informatik.haw-hamburg.de> Date: Fri, 29 Apr 2011 17:39:35 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4D9224DC.3000503@informatik.haw-hamburg.de><20110329.212051.109694544.asaeda@sfc.wide.ad.jp> <4D925C3B.1040608@informatik.haw-hamburg.de> <643B0A1D1A13AB498304E0BBC80278480328CE93@S4DE8PSAAQC.mitte.t-com.de> <4D92E6EF.3070803@informatik.haw-hamburg.de> <643B0A1D1A13AB498304E0BBC80278480338872C@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC80278480338872C@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Thoughts on Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 15:39:58 -0000 Hi Dirk, thanks for your perspectives ... and sorry for the late reply. Please see below marked with "Thomas>": On 20.04.2011 16:35, Dirk.von-Hugo@telekom.de wrote: > Dear Thomas et al., > Regarding your wish for potential deployment scenarios (of mobile multicast flows handling separated from unicast sessions ... I presume) as below ... > >>> Regarding potential use cases for separated HO for multicast traffic (independent of concurrent unicast traffic to the MN) a reason might be operator policy running heterogeneous networks in parallel and doing (multicast) traffic off-load e.g. from cellular (with only few subscribers to a content) to a broadcast medium (e.g. DVB) in case the subscriber group reaches a certain size making it economic to switch the distribution path ... > >> O.K., I see. But still this is not exactly a PMIP-like scenario. In your > case, MN would have to activate an additional radio interface (DVB or > ??) to receive multicast from there. But this interface would first need > to configure a unicast IP address before participating in the multicast > communication. However, this unicast interface would be newly > instantiated, thus experiences no context transfer, and also lives at a > different media - so this may be rather a case for MIH?? > Thomas> Btw. I have discussed this use case with Gorry and he was positive about it. Even though this is not a PMIP-like scenario, Gorry pointed out that - in particular with DVB-type interfaces - there is quite interesting work to do (preparing reception by channel:address mapping etc.). Maybe this is something worth working on, as the support of cheap broadcast-type link layers may be of interest in future scenarios. >>> AR's in this case may be radio towers ... Spannung a larger area than WiFi and cellular but nevertheless being limited e.g. in case of highway or train movement ... > >> I agree, this is an interesting scenario, provided operators do such > things (or are interested in doing so ???). Still, the problem is a > different one, in particular for the case of unidirectional downlinks > such as DVB or satellites or ... > >> Even though I would argue that this scenario is something different, it > might be quite interesting for the group to learn about possible > deployment options. Will you be able to gather knowledge on this area > and share with the group? > >> Thanks& best wishes > >> Thomas > > ... I have tried to finally come up with applications not requiring multiple interfaces, since I agree that this would add too much complexity to our current PMIP based approach. > > Nevertheless regarding increasing wireless data traffic forecasts (and popular services with a one-to-many communication structure as in social networks, e-learning, multi-player gaming and so on) operators may seek to save radio resources by replacing several parallel unicast streams by a single (or fewer) multicast streams. E.g. within an urban (WiFi or cellular) network consisting of several access nodes (BS/NodeBs or APs with overlapping coverage which are linked to different MAGs) one of them is taking over the multicast traffic (or even is a 'multicast dedicated' node) - and all MNs which have joined a multicast group are moved to the single multicast stream emerging from that access node - thus requiring decoupled handover for some (or even all) MNs. Thomas> This scenario would require two independent radio links at the MN, one attachment for unicast and the other for multicast. I'm not an expert on the capabilities of 3/4GPP radio interfaces at mobiles, but is one NIC able to independently connect to two different cells and receive independent data in parallel? In any case, we would see two different IP-interfaces at the MN, as well ... and I still wonder how one of them should be a multicast-only interface: even if data streams are sorted by interface for load-balancing purposes, one would expect both interfaces to have a unicast address, I suppose? > > Similarily the new TV services allowing to switch between different viewpoints (e.g. for sports event transmission) may require to transfer more parallel streams than can be handled by a single access node such that more than one Multicast dedicated access nodes exist. A user switching between different channels may have to be handed over to the 'right' node (and corresponding MAG). Thomas> This sounds really complicated to me because a mapping of L2 properties to multicast groups is needed. Either the MN or the cell APs (in Network-operated handovers) would need to know which radio connect serves which group. However, it may be interesting to think of such "inverse" mappings (L2-ID -> mcast-group)? > > Also the differing QoS requirements of parallel unicast and multicast sessions of a MN (related to different services, e.g. mIPTV or video conferencing with low delay vs. file transfer with 0 error probability) may request in case of deterioating link quality to handover only the unicast data session. Accordingly in case of failure of intermediate nodes between LMA and MAG a rerouting may result in unacceptable delay for real-time multicast streaming so that this flow is handed over to a MAG with shorter path delay to the MN (in the scenario with multiple visible MAGs per MN). > > At least in current 3G deployment with hierarchical cell structure (HCS) macro cells and overlay micro or pico cells are in operation serving the same area - and thus allowing for the assumed decoupled handover on radio link layer. > > At the moment no more different scenarios come to my mind ... And of course these are ideas only and not yet plans of an operator ;-) > Thomas> O.K., to sum up my understanding: There may be scenarios for a MN to receive Mcast via a different interface than its default unicast connect, and this interface may have the same or a different link type. MN may be somehow pushed (via its default unicast interface) to activate this additional link and configure multicast reception states without transferring its unicast default route. Still I cannot see why this second interface should work without a unicast address ?? In the outcome, I see two interesting questions: 1. How to signal / manage the selection / activation of a new radio interface by multicast subscription triggers and how to stir a per group state transfer to it? (This is basically the DVB-related question.) 2. Once the additional interface for multicast reception is up and running (incl. a unicast IP address), is there any difference in handover operations from a normal "all purpose" default interface? (Or isn't it just a second interface that has been select for parts of the communication ?). The first question is outside the PMIP domain and not a "standard-type" handover scenario that clearly requires new work: this is not solved by simply de-synchronizing multicast from unicast ... Best wishes, Thomas >> -----Ursprüngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Thomas C. Schmidt >> Gesendet: Mittwoch, 30. März 2011 00:25 >> An: Hitoshi Asaeda >> Cc: rkoodli@cisco.com; multimob@ietf.org >> Betreff: Re: [multimob] Thoughts on Context Transfer >> >> Hi Hitoschi, >> >> that may be - the first draft to present a context transfer by CXTP >> independent of unicast handover was >> http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005. >> >> The question was about the reasons and the sense behind it ... >> ... and my reason for asking is that I cannot think of good reasons to >> do a multicast transfer directly between ARs decoupled from unicast >> handover. >> >> Best regards, >> >> Thomas >> >> On 29.03.2011 21:20, Hitoshi Asaeda wrote: >>>> Why don't we use a generic context transfer (by RFC 4067) for >>>> multicast states only, and leave unicast handover aside? >>> >>> As I presented today, our draft uses CXTP (rfc4067). >>> Regards, >>> -- >>> Hitoshi Asaeda >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >> > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °