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

"Hui Deng" <denghui02@gmail.com> Sat, 01 November 2008 01:49 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 C33473A6B6E; Fri, 31 Oct 2008 18:49:13 -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 C23533A6A86 for <multimob@core3.amsl.com>; Fri, 31 Oct 2008 18:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_53=0.6]
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 rS4C0tdUkOsL for <multimob@core3.amsl.com>; Fri, 31 Oct 2008 18:49:11 -0700 (PDT)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 1B15B3A6B6E for <multimob@ietf.org>; Fri, 31 Oct 2008 18:49:10 -0700 (PDT)
Received: by nf-out-0910.google.com with SMTP id b11so728558nfh.39 for <multimob@ietf.org>; Fri, 31 Oct 2008 18:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=KPnlv9HwJr/29DyGT5fhu+zF+5xnCFcF579m+Tfh/ig=; b=BHnAaJ0mUGorgJqlD1d87Gc0l2R0paH3ADLrvICQEUXluzn8/tA12EjmE8+JXWeGjk G18MFYl7qVsgrUgZkXW6riIOr3gkv1o6k69XseeSh7LfbTApFt6EZ86BDnDSbvYYDaSt nd9tEsm28PUyeRlb1h8EVCpS47BbUMbUqXT/E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=H8hcnDoEbui7c5x271qZAipdZ13TIEAg5z8pMBnNVPyQebsKEsHYh2JD1EOT17z1Nl 7fpOXk3RurwKipahhUcisDfOe7rtWeJ8XQDFJU6JFVvdAAjpqBZbGUzTPXt54X2ycRBl 4tfw4MaL6fFZa2M6+uz2qAaEgUeDT/tiaYlLk=
Received: by 10.210.115.17 with SMTP id n17mr14264251ebc.160.1225504147621; Fri, 31 Oct 2008 18:49:07 -0700 (PDT)
Received: by 10.210.109.14 with HTTP; Fri, 31 Oct 2008 18:49:07 -0700 (PDT)
Message-ID: <1d38a3350810311849g5aafb87x727bc2a799a2a247@mail.gmail.com>
Date: Sat, 01 Nov 2008 09:49:07 +0800
From: Hui Deng <denghui02@gmail.com>
To: john.zhao@huawei.com
In-Reply-To: <007701c93589$381d0f30$a864a8c0@china.huawei.com>
MIME-Version: 1.0
References: <007701c93589$381d0f30$a864a8c0@china.huawei.com>
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
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="===============1475112873=="
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

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