[multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

"John.zhao" <john.zhao@huawei.com> Fri, 24 October 2008 03:31 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 917FB3A6816; Thu, 23 Oct 2008 20:31:59 -0700 (PDT)
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 CAA823A67A2 for <multimob@core3.amsl.com>; Thu, 23 Oct 2008 20:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.564
X-Spam-Level: *
X-Spam-Status: No, score=1.564 tagged_above=-999 required=5 tests=[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, 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 ZUPXJMQWgSAD for <multimob@core3.amsl.com>; Thu, 23 Oct 2008 20:31:56 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 947E53A6359 for <multimob@ietf.org>; Thu, 23 Oct 2008 20:31:56 -0700 (PDT)
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 <0K9800K1Q4J6F3@szxga01-in.huawei.com> for multimob@ietf.org; Fri, 24 Oct 2008 11:33:06 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K98002TV4J6JG@szxga01-in.huawei.com> for multimob@ietf.org; Fri, 24 Oct 2008 11:33:06 +0800 (CST)
Received: from z49950 ([10.121.148.133]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K98009GA4J2JI@szxml03-in.huawei.com> for multimob@ietf.org; Fri, 24 Oct 2008 11:33:06 +0800 (CST)
Date: Fri, 24 Oct 2008 11:33:02 +0800
From: "John.zhao" <john.zhao@huawei.com>
To: 'Hui Deng' <denghui02@gmail.com>
Message-id: <007701c93589$381d0f30$a864a8c0@china.huawei.com>
Organization: Huawei Technologies Co., LTD.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Thread-index: Ack1iTfXrEzc+TaPQdKWli2ICutBjQ==
Cc: multimob@ietf.org
Subject: [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="===============1211297280=="
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

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