Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt
"John.zhao" <john.zhao@huawei.com> Tue, 04 November 2008 06:25 UTC
Return-Path: <multimob-bounces@ietf.org>
X-Original-To: multimob-archive@optimus.ietf.org
Delivered-To: ietfarch-multimob-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953213A6892; Mon, 3 Nov 2008 22:25:25 -0800 (PST)
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 82DEC3A68A0 for <multimob@core3.amsl.com>; Mon, 3 Nov 2008 22:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.527
X-Spam-Level: *
X-Spam-Status: No, score=1.527 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AdFzrb7Cpu2 for <multimob@core3.amsl.com>; Mon, 3 Nov 2008 22:25:23 -0800 (PST)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 085D03A688E for <multimob@ietf.org>; Mon, 3 Nov 2008 22:25:22 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9S003F8PTW6X@szxga01-in.huawei.com> for multimob@ietf.org; Tue, 04 Nov 2008 14:25:09 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9S00D21PTW37@szxga01-in.huawei.com> for multimob@ietf.org; Tue, 04 Nov 2008 14:25:08 +0800 (CST)
Received: from z49950 ([10.121.148.133]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K9S00AYNPTRUJ@szxml04-in.huawei.com> for multimob@ietf.org; Tue, 04 Nov 2008 14:25:08 +0800 (CST)
Date: Tue, 04 Nov 2008 14:25:03 +0800
From: "John.zhao" <john.zhao@huawei.com>
In-reply-to: <1d38a3350810311849g5aafb87x727bc2a799a2a247@mail.gmail.com>
To: 'Hui Deng' <denghui02@gmail.com>
Message-id: <012101c93e46$129928f0$a864a8c0@china.huawei.com>
Organization: Huawei Technologies Co., LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Thread-index: Ack7xNYy/ZnlBZMDQwml8H81vi1WxgCgPMBA
Cc: multimob@ietf.org
Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: john.zhao@huawei.com
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0161531341=="
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org
Hi,hui Forget to post the reply in maillist. See following comments. You are right. They are all need MN to send the request to join to trigger the receive of multicast except the CMMB , I'm not sure. But it is because we didn't have other methods to be used before. Currently, some system just like IEEE802.16 is discussing about this kind of support via layer-2, once it is ready, then the joinging in layer-3 can be omitted. In another side, the DVB-H is another case, since it havn't the uplink , so even mobile node want to send the joining request, but the request can't be sent to network. It is a kind of "uni-direction link". I think it is useful for operator to push some feature service within its domian . How about it? Best Rgds, Thanks, john.zhao _____ Hi, John, Sorry for my late reply, here you are suggesting that we would better include network preconfigured multicast service which need infrastrucutre support. What I could remind is that normally such kind of service will be provided by MBMS, BCMCS, especially mobile TV service they also could be based on dedicated TV mechanism like CMMB. thanks for your discussion. -Hui 2008/10/24 John.zhao <john.zhao@huawei.com> Hello,Hui and all One comments on section 3.1 about "R2 - The mobile node is responsible for initially subscribing to the multicast group(s)." . To some network control multicast service, this subscribtion info can be got from policy store or pre-configuration on MAG. I don't object MN can't initiate the subscribtion,but the subscribtion is no need rely on the request come from MN only. With only MN initiated subscription of multicast group(s),the operator's network will: 1.1)No network originated service support. All of any kind of multicast service will be initiated from MN.But in fact, there are still some typical service should be managed from network side.From the point of view of the MN it is like a TV broadcast model. It is worth to handle this case too because it may corresponds to DVB-H mobile TV service use-case. 1.2)Cost additional wireless resource in wireless situation. Without it , we can save more resource not only during handover but also in network entry progress. Espically, it is useful to those static multicast tree scenario. From the architecture perspective, the support of network management is the base of MN management. Since other signal flow will be the same except MAG need have the ability to deal with additional MLD report sent from MN.So it is no more additional cost on current design but bring a better scability. In detail, the progress of the management of multicast service by network just like the following: When the MN just attachs to a MAG, the MAG will get the MN's profile and will know some pre-configured multicast services need to be established, then it will ask LMA to provide the respective service, in this case, the method used to communicate to LMA from MAG can be either PMIP signals or MLD report(join) messages etc. LMA will check about this request and do the decision based on it's acknowledges about it. During handover, it will be very like current design. The CXT is expect to provide necessary multicast infomation and if need, a 3-rd party policy store is required. On summary, considering and allowing network administrativly subscription didn't impact on anything current we have considered and in addition , it can bring a scalability to current requirement of proxy multicast mobility. Best Rgds, Thanks, john.zhao
_______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob
- [multimob] Comments on draft-deng-multimob-pmip6-… Behcet Sarikaya
- Re: [multimob] Comments on draft-deng-multimob-pm… Thomas C. Schmidt
- Re: [multimob] Comments on draft-deng-multimob-pm… Behcet Sarikaya
- Re: [multimob] Comments on draft-deng-multimob-pm… Thomas C. Schmidt
- Re: [multimob] Comments on draft-deng-multimob-pm… Behcet Sarikaya
- Re: [multimob] Comments on draft-deng-multimob-pm… Thomas C. Schmidt
- [multimob] Comments on draft-deng-multimob-pmip6-… John.zhao
- Re: [multimob] Comments on draft-deng-multimob-pm… Hui Deng
- Re: [multimob] Comments on draft-deng-multimob-pm… Hui Deng
- Re: [multimob] Comments on draft-deng-multimob-pm… Hitoshi Asaeda
- Re: [multimob] Comments on draft-deng-multimob-pm… Hitoshi Asaeda
- Re: [multimob] Comments on draft-deng-multimob-pm… Thomas C. Schmidt
- Re: [multimob] Comments on draft-deng-multimob-pm… John.zhao
- Re: [multimob] Comments on draft-deng-multimob-pm… Hui Deng
- Re: [multimob] Comments on draft-deng-multimob-pm… John.zhao
- Re: [multimob] Comments ondraft-deng-multimob-pmi… von Hugo, Dirk
- Re: [multimob] Comments ondraft-deng-multimob-pmi… John.zhao
- Re: [multimob] Comments ondraft-deng-multimob-pmi… von Hugo, Dirk
- Re: [multimob] Comments ondraft-deng-multimob-pmi… John.zhao
- Re: [multimob] Comments ondraft-deng-multimob-pmi… pierrick.seite
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Thomas C. Schmidt
- Re: [multimob] Comments ondraft-deng-multimob-pmi… von Hugo, Dirk
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Hitoshi Asaeda
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Hitoshi Asaeda
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Thomas C. Schmidt
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Hitoshi Asaeda
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Thomas C. Schmidt
- Re: [multimob] Comments ondraft-deng-multimob-pmi… John.zhao
- Re: [multimob] Comments on draft-deng-multimob-pm… Hui Deng
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Hui Deng
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Hui Deng
- Re: [multimob] Comments ondraft-deng-multimob-pmi… Thomas C. Schmidt
- [multimob] Comments on draft-deng-multimob-pmip6-… Behcet Sarikaya
- Re: [multimob] Comments ondraft-deng-multimob-pmi… von Hugo, Dirk
- Re: [multimob] Comments on draft-deng-multimob-pm… Suresh Krishnan
- Re: [multimob] Comments on draft-deng-multimob-pm… Niklas Neumann
- Re: [multimob] Comments on draft-deng-multimob-pm… Brian Haberman
- Re: [multimob] Commentson draft-deng-multimob-pmi… pierrick.seite
- Re: [multimob] Commentson draft-deng-multimob-pmi… Hui Deng