From multimob-bounces@ietf.org Wed Oct 1 05:41:26 2008 Return-Path: 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 8AA3B3A6CAB; Wed, 1 Oct 2008 05:41:26 -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 1A6733A6C32 for ; Wed, 1 Oct 2008 05:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 HxomVwoHjo6z for ; Wed, 1 Oct 2008 05:41:23 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by core3.amsl.com (Postfix) with ESMTP id 3D8BA3A6C9E for ; Wed, 1 Oct 2008 05:39:40 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c30so332794ika.5 for ; Wed, 01 Oct 2008 05:39:27 -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=FTLRXqxhSa1zIhTXoDbheTPpRZoOY11lHrs7Dqwl8KE=; b=pG7rzyd6/d77Ux+XQwXqtqiqzUD8ZZ0fVAHJnpgpjPqL4IkBGzTOoXWhI9dZf28AGo g4RStkJYsLsifnDmKs0ffO+DK3+DMRl6imqRtwa/BC+jmDmGb1uIcfhKBW9MH6iEKk5z Qg1kNQ7NDjdBxOcVUmK/qPU8TEtcmctScZK88= 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=LURNPVlaDA1fDCEWjylPrjORdi7AAVQZWh9YJWnKZKq+5gs4ijKcoY0xz7cju7BKmG afmaex9upLDvL6JnS4Q5JjH261x+lKER6Cy8vaQrsaSZs9BZyEPhpq6rNpb9ou/Xkae8 MUrdgXaWJAIZx7oFYE5YgsMrL+lTEvjtAyYuI= Received: by 10.210.22.16 with SMTP id 16mr1701189ebv.14.1222864767645; Wed, 01 Oct 2008 05:39:27 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Wed, 1 Oct 2008 05:39:27 -0700 (PDT) Message-ID: <1d38a3350810010539o3c8638bjb6b051c6b7e5b098@mail.gmail.com> Date: Wed, 1 Oct 2008 20:39:27 +0800 From: "Hui Deng" To: pierrick.seite@orange-ftgroup.com In-Reply-To: MIME-Version: 1.0 References: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> <20080919.125902.250136943.asaeda@sfc.wide.ad.jp> Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated 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: , Content-Type: multipart/mixed; boundary="===============0703203248==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0703203248== Content-Type: multipart/alternative; boundary="----=_Part_11781_7050322.1222864767655" ------=_Part_11781_7050322.1222864767655 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, all For ASM/SSM, since there is no persistant argument here, I plan to keep SSM only, not mention ASM at the moment, see future other inputs. For multicast control function and multicast replication function, this is = a more IPTV related, doesn't clearly operate in our current scenario, I agree Pierrick's suggestion to group the two statements. Please Pierrick update the section 4. I will update and submit it after shortly, Many thanks for all your work. Best regards, -Hui 2008/9/29 > Hi Hitoshi, > > Thanks fo the comments and sorry for the late reply, please see inline fo= r > clarifications. > > Regards, > Pierrick > > > -----Message d'origine----- > > De : Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > > Envoy=E9 : vendredi 19 septembre 2008 05:59 > > =C0 : SEITE Pierrick RD-RESA-REN > > Cc : multimob@ietf.org > > Objet : Re: [multimob] PMIPv6 Requirements Draft Updated > > > > Hi Pierrick, > > > > Looks better now. Thanks. > > > > Several small comments below. > > > > > 4. Architecture requirements > > > > > > Deployment of mobile multicast services for listeners, > > > e.g. Mobile IPTV, may lead to operational requirements which MAY > > > impact PMIPv6 architectural entities. These potential features are > > > sketched in the following and may come in addition to protocol > > > requirements, as listed in the preceding section: > > > > > > - Multicast Bandwidth Control: the system should be able to > > > control the total bandwidth of a user port that can be used for > > > multicast service, > > > thereby monitoring the fraction of the total bandwidth consumed by > > > multicast. This requirement may lead for the LMA to support a > > > range of different service classes with various QoS requirements. > > > > > > - Multicast session control: AAA functions, which may reside at > > > the LMA, in particular admission control and accounting, SHOULD be > > > preserved and applicable under multicast services. > > > > This is not "multicast session control", which includes many general > > meanings. > > "AAA functions" is straightforward for your statement. > > I agree, we will fix that in next release. > > > > > > - Connection Admission Control (CAC): it is an operational > > > requirement that Connection Admission Control should be based on > > > available resources. This feature may be supported at the MAG. > > > > I don't recommend to use the word "CAC". As I said, it may not be > > a common term except with ATM, no? > > And the statement is a little ambiguous. What function do you require? > > > > > - Network Attachment Control: the attachment control should be > > > supported by a multicast control function and multicast replicatio= n > > > function. > > > > This is also a bit ambiguous. > > Multicast control means traffic control? Quality control? What > > information is needed for what? > > And what does multicast replication mean? > > > > To clarify, I would suggest to group the two above statements in a single > "access control" (or something like that) requirement. But it's typically= an > operational requirement, so, it would be valuable to hear Hui's opinion > before modifying. > > > > - Considering deployment, it is foreseeable that the MAG MAY act as > > > a multicast designated router. Hence support of MLDv2 [RFC3810] MAY > > > be required at the MAG. > > > > As I said, I perfer to also say "or LW-MLDv2" with MLDv2 here, but > > it's up to other members' opinions. > > > > I have no religion on that... > > > Thanks, > > -- > > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > ------=_Part_11781_7050322.1222864767655 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello, all
 
For ASM/SSM, since there is no persistant argument here, I plan to
keep SSM only, not mention ASM at the moment, see future other inputs.=
 
For multicast control function and multicast replication function, thi= s is a more
IPTV related, doesn't clearly operate in our current scenario, I a= gree Pierrick's
suggestion to group the two statements. Please Pierrick update the sec= tion 4.
 
I will update and submit it after shortly,
 
Many thanks for all your work.
Best regards,
 
-Hui

2008/9/29 <pierrick.seite@orange-ftgroup.com&= gt;
Hi Hitoshi,

Thanks fo the= comments and sorry for the late reply, please see inline for clarification= s.

Regards,
Pierrick

> -----Message d&#= 39;origine-----
> De : Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp]
> Envoy=E9&nb= sp;: vendredi 19 septembre 2008 05:59
> =C0 : SEITE Pierrick RD-RESA-REN
> Cc : m= ultimob@ietf.org
> Objet : Re: [multimob] PMIPv6 Requirement= s Draft Updated
>
> Hi Pierrick,
>
> Looks better now. T= hanks.
>
> Several small comments below.
>
> > 4= . Architecture requirements
> >
> >    Deployme= nt of mobile multicast services for listeners,
> > e.g. Mobile IPTV, may lead to operational requirements which MAY<= br>> > impact PMIPv6 architectural entities. These potential features= are
> > sketched in the following and may come in addition to pro= tocol
> > requirements, as listed in the preceding section:
> >> >    - Multicast Bandwidth Control: the system should be= able to
> > control the total bandwidth of a user port that can b= e used for
> > multicast service,
> >    thereby monitoring t= he fraction of the total bandwidth consumed by
> >    mu= lticast.  This requirement may lead for the LMA to support a
> &= gt; range of different service classes with various QoS requirements.
> >
> >    - Multicast session control: AAA functi= ons, which may reside at
> > the LMA, in particular admission cont= rol and accounting, SHOULD be
> > preserved and applicable under m= ulticast services.
>
> This is not "multicast session control", which inclu= des many general
> meanings.
> "AAA functions" is str= aightforward for your statement.

I agree, we will fix that in = next release.

>
> >    - Connection Admis= sion Control (CAC): it is an operational
> > requirement that Conn= ection Admission Control should be based on
> > available resource= s.  This feature may be supported at the MAG.
>
> I don't recommend to use the word "CAC". As I sa= id, it may not be
> a common term except with ATM, no?
> And th= e statement is a little ambiguous. What function do you require?
> > >    - Network Attachment Control: the attachment control= should be
> >    supported by a multicast control funct= ion and multicast replication
> >    function.
>> This is also a bit ambiguous.
> Multicast control means traffic control? Quality control? What
>= information is needed for what?
> And what does multicast replicatio= n mean?
>

To clarify, I would suggest to group the two a= bove statements in a single "access control" (or something like t= hat) requirement. But it's typically an operational requirement, so, it= would be valuable to hear Hui's opinion before modifying.

> > - Considering deployment, it is foresee= able that the MAG MAY act as
> > a multicast designated router. &n= bsp;Hence support of MLDv2 [RFC3810] MAY
> > be required at the MA= G.
>
> As I said, I perfer to also say "or LW-MLDv2" with M= LDv2 here, but
> it's up to other members' opinions.
><= br>
I have no religion on that...

> Thanks,
> --
> Hitoshi Asaeda_______________________________________________
multimob mailing listmultimob@ietf.org
https://w= ww.ietf.org/mailman/listinfo/multimob

------=_Part_11781_7050322.1222864767655-- --===============0703203248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0703203248==-- From multimob-bounces@ietf.org Sun Oct 5 23:39:48 2008 Return-Path: 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 BDF923A6A31; Sun, 5 Oct 2008 23:39:48 -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 C05C73A69BB for ; Sun, 5 Oct 2008 23:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 R5f8tGfGkm3Y for ; Sun, 5 Oct 2008 23:39:42 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5C2613A6A31 for ; Sun, 5 Oct 2008 23:39:42 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2D536198723; Mon, 6 Oct 2008 09:40:17 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id D0FD719870D; Mon, 6 Oct 2008 09:40:16 +0300 (EEST) Message-ID: <48E9B2DC.5080401@piuha.net> Date: Mon, 06 Oct 2008 09:40:28 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: multimob@ietf.org, Behcet Sarikaya , Brian Haberman X-Virus-Scanned: ClamAV using ClamSMTP Subject: [multimob] BOF 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Your BOF has been approved for Minneapolis. Please keep working further with requirements, solutions, preparation of the agenda, etc. Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Sun Oct 12 13:13:09 2008 Return-Path: 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 33ABB3A6932; Sun, 12 Oct 2008 13:13:09 -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 651DA3A6932 for ; Sun, 12 Oct 2008 13:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=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 hEtFreGUXM5e for ; Sun, 12 Oct 2008 13:13:06 -0700 (PDT) Received: from web38804.mail.mud.yahoo.com (web38804.mail.mud.yahoo.com [209.191.125.95]) by core3.amsl.com (Postfix) with SMTP id 931293A683D for ; Sun, 12 Oct 2008 13:13:06 -0700 (PDT) Received: (qmail 78845 invoked by uid 60001); 12 Oct 2008 20:12:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=Ws4tqDBXVPU3HsUzw2WEFQ7EunnHYdJJ9iC7nTh80IjIToiBnGdd+QKt9c3JPXHxkGwTrb2Ck+z8/BN9RIKqGUvRfDMS5N6/abmPSDa7Gj9GMwUotXynWJYguEQKenBeBGwGxBOYWS8iXDJ1R3c5Afy+Coo8LBWKj+9Pajodcps=; X-YMail-OSG: huUCfBUVM1lI6WCa86vvIaFymXQtPTeqt5HUdo8Pe.2FYbKnOXQJkpCbGgGEaqi1we9XU4lC_FnbTsMfUYaVqBcTpxhim_42Rqyl165EzQXuo55SrhpKA7z29OlZQrOU4C_N89UPPcRZiN9ay3H9SmNcoU0e55wPHZxvifkeyYrwfF9fAlYi82_CIU39 Received: from [88.244.223.250] by web38804.mail.mud.yahoo.com via HTTP; Sun, 12 Oct 2008 13:12:50 PDT X-Mailer: YahooMailRC/1096.40 YahooMailWebService/0.7.218.2 Date: Sun, 12 Oct 2008 13:12:50 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <215440.78091.qm@web38804.mail.mud.yahoo.com> Subject: [multimob] Fw: BOF 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: , Content-Type: multipart/mixed; boundary="===============0036223291==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0036223291== Content-Type: multipart/alternative; boundary="0-1254476128-1223842370=:78091" --0-1254476128-1223842370=:78091 Content-Type: text/plain; charset=us-ascii Folks, You have seen Jari's mail. We need to work hard and advance things in our proposed charter. I hope to see the new version of PMIP6 requirements draft and and early version of the solution draft this week. Regards, Behcet ----- Forwarded Message ---- From: Jari Arkko To: multimob@ietf.org; Behcet Sarikaya ; Brian Haberman Sent: Monday, October 6, 2008 1:40:28 AM Subject: [multimob] BOF Your BOF has been approved for Minneapolis. Please keep working further with requirements, solutions, preparation of the agenda, etc. Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --0-1254476128-1223842370=:78091 Content-Type: text/html; charset=us-ascii
Folks,
  You have seen Jari's mail. We need to work hard and advance things in our proposed charter.
  I hope to see the new version of PMIP6 requirements draft and and early version of the solution draft this week.

Regards,

Behcet

----- Forwarded Message ----
From: Jari Arkko <jari.arkko@piuha.net>
To: multimob@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Brian Haberman <brian@innovationslab.net>
Sent: Monday, October 6, 2008 1:40:28 AM
Subject: [multimob] BOF

Your BOF has been approved for Minneapolis. Please keep working further
with requirements, solutions, preparation of the agenda, etc.

Jari

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--0-1254476128-1223842370=:78091-- --===============0036223291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0036223291==-- From multimob-bounces@ietf.org Sun Oct 19 09:16:07 2008 Return-Path: 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 E38E63A6A71; Sun, 19 Oct 2008 09:16:07 -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 EAA7A3A6A09 for ; Sun, 19 Oct 2008 09:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 flVbVQw-nL-X for ; Sun, 19 Oct 2008 09:16:06 -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 C2EB03A6A07 for ; Sun, 19 Oct 2008 09:16:05 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so587816nfh.39 for ; Sun, 19 Oct 2008 09:17:14 -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:in-reply-to:mime-version:content-type:references; bh=Fht3um00xFwtmK6uOMF4nVoX63JRvFxQDlQHowGIRrg=; b=xJ3ZQMqvMSqQe2Nh7lQ6HCeML6E7utveW2XdV3ii7VlfBtbUWDwPmpI98ECHgnYS8B Hysvzy2FsV30DzyRS7EA3AYHb13LCAEop4iVrNCR1UQu2aNOGtS57RU8TDxB1flPMfu5 XC0seI40UZrg285LcfSMSVLkclqdeYlnvSDM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Iot/KAjIQbBU53YxSkFd/IbdnU0HYgqSwQKcGgkZG1VKWdmIR6TlwpzWU313/uWMp3 57xO1uXaK834J0IzCM/pnaA3iNOTby6WjMcermlePFm75GJMCV80I/7F0OJ957aIVLd9 STT/FDL7QjZQq66dD5xCiRnP9Ex3PVQnbR7eI= Received: by 10.210.111.4 with SMTP id j4mr7419477ebc.170.1224433033956; Sun, 19 Oct 2008 09:17:13 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Sun, 19 Oct 2008 09:17:13 -0700 (PDT) Message-ID: <1d38a3350810190917g5258eaacs7ba688f1f90623d3@mail.gmail.com> Date: Mon, 20 Oct 2008 00:17:13 +0800 From: "Hui Deng" To: multimob@ietf.org In-Reply-To: <20081019160002.1032E3A6998@core3.amsl.com> MIME-Version: 1.0 References: <20081019160002.1032E3A6998@core3.amsl.com> Subject: [multimob] Fwd: I-D Action:draft-deng-multimob-pmip6-requirement-01.txt 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: , Content-Type: multipart/mixed; boundary="===============0309479682==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0309479682== Content-Type: multipart/alternative; boundary="----=_Part_141849_27708277.1224433033943" ------=_Part_141849_27708277.1224433033943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all We have updated the draft based on the list discussion. Please help to review and comment. thanks -Hui A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Support Requirements for Proxy Mobile IPv6 Author(s) : H. Deng, et al. Filename : draft-deng-multimob-pmip6-requirement-01.txt Pages : 14 Date : 2008-10-19 This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-01.txt ------=_Part_141849_27708277.1224433033943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello, all
 
We have updated the draft based on the list discussion.
Please help to review and comment.
 
thanks
 
-Hui



A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Multicast Support Requirements for Proxy Mobile IPv6
       Author(s)       : H. Deng, et al.
       Filename        : draft-deng-multimob-pmip6-requirement-01.txt
       Pages           : 14
       Date            : 2008-10-19

This document summarizes requirements for multicast listener support
in Proxy Mobile IPv6 (PMIPv6) scenarios.  In correspondance to
PMIPv6, multicast mobility management requirements do not request any
active participation of the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-01.txt

------=_Part_141849_27708277.1224433033943-- --===============0309479682== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0309479682==-- From multimob-bounces@ietf.org Wed Oct 22 14:07:38 2008 Return-Path: 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 C8A1C3A6945; Wed, 22 Oct 2008 14:07:38 -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 E9C8A3A6945 for ; Wed, 22 Oct 2008 14:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=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 iMMWh6sOEsAf for ; Wed, 22 Oct 2008 14:07:36 -0700 (PDT) Received: from web38808.mail.mud.yahoo.com (web38808.mail.mud.yahoo.com [209.191.125.99]) by core3.amsl.com (Postfix) with SMTP id EEDFD3A67D4 for ; Wed, 22 Oct 2008 14:07:35 -0700 (PDT) Received: (qmail 29949 invoked by uid 60001); 22 Oct 2008 21:08:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=dkCkxVwPXLs9vYG4MeBWbdFPG3hdSKSj+l1trbG4mWUufwUCGIKhnH5FhLwdcdxx96StSBEvBTHV+gRrNCyAbGUExyN53yHdATCg09sLHJZI9I+bkMPLKC/Oqovb6I5ojIoYHfzBjYcfoGEx6X5Kf/BfXSPA5I9VvcZ9a8KwzuA=; X-YMail-OSG: ZPmPttoVM1ngoL949PW5lWkwDsekYBmVzyRr6hWUdDqoJ.jxQ1.eHE_1h3wRCveJxjq_8D499YdJ23E6h2_fwvjGSF5tDyDIcwfbwWGu9L67poJHX_iRVKgL85Dp5.31pIv95boCc0J73u4ZvzguC6mEYiAQxwlYie1wBtcSw3_k5ZE- Received: from [206.16.17.212] by web38808.mail.mud.yahoo.com via HTTP; Wed, 22 Oct 2008 14:08:52 PDT X-Mailer: YahooMailRC/1096.40 YahooMailWebService/0.7.247.3 Date: Wed, 22 Oct 2008 14:08:52 -0700 (PDT) From: Behcet Sarikaya To: Hui Deng , multimob@ietf.org MIME-Version: 1.0 Message-ID: <510352.29702.qm@web38808.mail.mud.yahoo.com> 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: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0507770415==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0507770415== Content-Type: multipart/alternative; boundary="0-1465425453-1224709732=:29702" --0-1465425453-1224709732=:29702 Content-Type: text/plain; charset=us-ascii Hello Hui, Thanks for your hard work in coming up with this revised version. I read it. My comment is regarding Section 2. Local routing in PMIP6 as described in Section 6.10.3 of RFC 5213 refers to the routing by the MAG locally without tunneling to the LMA. In draft-deng-multimob-pmip6-requirement-01 Figure 2 depicts local routing as something totally different. The text you have seems to be OK but the figure is certainly not correct. Regards, Behcet ----- Original Message ---- From: Hui Deng To: multimob@ietf.org Sent: Sunday, October 19, 2008 11:17:13 AM Subject: [multimob] Fwd: I-D Action:draft-deng-multimob-pmip6-requirement-01.txt Hello, all We have updated the draft based on the list discussion. Please help to review and comment. thanks -Hui A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Support Requirements for Proxy Mobile IPv6 Author(s) : H. Deng, et al. Filename : draft-deng-multimob-pmip6-requirement-01.txt Pages : 14 Date : 2008-10-19 This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-01.txt --0-1465425453-1224709732=:29702 Content-Type: text/html; charset=us-ascii
Hello Hui,
  Thanks for your hard work in coming up with this revised version. I read it.
  My comment is regarding Section 2. Local routing in PMIP6 as described in Section 6.10.3 of RFC 5213 refers to the routing by the MAG locally without tunneling to the LMA. In draft-deng-multimob-pmip6-requirement-01 Figure 2 depicts local routing as something totally different. The text you have seems to be OK but the figure is certainly not correct.

Regards,

Behcet

----- Original Message ----
From: Hui Deng <denghui02@gmail.com>
To: multimob@ietf.org
Sent: Sunday, October 19, 2008 11:17:13 AM
Subject: [multimob] Fwd: I-D Action:draft-deng-multimob-pmip6-requirement-01.txt

Hello, all
 
We have updated the draft based on the list discussion.
Please help to review and comment.
 
thanks
 
-Hui



A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Multicast Support Requirements for Proxy Mobile IPv6
       Author(s)       : H. Deng, et al.
       Filename        : draft-deng-multimob-pmip6-requirement-01.txt
       Pages           : 14
       Date            : 2008-10-19

This document summarizes requirements for multicast listener support
in Proxy Mobile IPv6 (PMIPv6) scenarios.  In correspondance to
PMIPv6, multicast mobility management requirements do not request any
active participation of the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-01.txt


--0-1465425453-1224709732=:29702-- --===============0507770415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0507770415==-- From multimob-bounces@ietf.org Wed Oct 22 14:34:23 2008 Return-Path: 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 BB2FA3A6A4B; Wed, 22 Oct 2008 14:34:23 -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 260C23A6A4B for ; Wed, 22 Oct 2008 14:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 QAU2Qii2NI2t for ; Wed, 22 Oct 2008 14:34:21 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 24F073A6861 for ; Wed, 22 Oct 2008 14:34:17 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178172212.adsl.alicedsl.de ([85.178.172.212] helo=[192.168.178.20]) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KslMb-0007vC-Ej; Wed, 22 Oct 2008 23:35:33 +0200 Message-ID: <48FF9CA5.8060408@informatik.haw-hamburg.de> Date: Wed, 22 Oct 2008 23:35:33 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behcet Sarikaya References: <510352.29702.qm@web38808.mail.mud.yahoo.com> In-Reply-To: <510352.29702.qm@web38808.mail.mud.yahoo.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Behcet, I'm in charge to defend Hui as the figure is from my side. It is not exactly clear why you state "Figure 2 depicts local routing as something totally different" ??? - what is expressed here: a content source local to the PMIP-domain - but = not local to a particular MAP. And in consequence a (multicast) routing = within the PMIP domain without LMA-MAG tunneling. That's what the text = says, as well. This has been discussed prior to version 00 on the mailing list ... and = seems a reasonable approach to me: what is "certainly not correct"? Regards, Thomas Behcet Sarikaya wrote: > Hello Hui, > Thanks for your hard work in coming up with this revised version. I = > read it. > My comment is regarding Section 2. Local routing in PMIP6 as described = > in Section 6.10.3 of RFC 5213 refers to the routing by the MAG locally = > without tunneling to the LMA. In = > draft-deng-multimob-pmip6-requirement-01 Figure 2 depicts local routing = > as something totally different. The text you have seems to be OK but the = > figure is certainly not correct. > = > Regards, > = > Behcet > = > ----- Original Message ---- > From: Hui Deng > To: multimob@ietf.org > Sent: Sunday, October 19, 2008 11:17:13 AM > Subject: [multimob] Fwd: I-D = > Action:draft-deng-multimob-pmip6-requirement-01.txt > = > Hello, all > = > We have updated the draft based on the list discussion. > Please help to review and comment. > = > thanks > = > -Hui > = > = > = > A New Internet-Draft is available from the on-line Internet-Drafts = > directories. > = > Title : Multicast Support Requirements for Proxy Mobile = > IPv6 > Author(s) : H. Deng, et al. > Filename : draft-deng-multimob-pmip6-requirement-01.txt > Pages : 14 > Date : 2008-10-19 > = > This document summarizes requirements for multicast listener support > in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to > PMIPv6, multicast mobility management requirements do not request any > active participation of the mobile node. > = > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement= -01.txt > = > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Oct 22 15:14:37 2008 Return-Path: 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 0142228C1C1; Wed, 22 Oct 2008 15:14:37 -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 0495928C1C1 for ; Wed, 22 Oct 2008 15:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HTML_MESSAGE=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 m5J5CMnuXBL0 for ; Wed, 22 Oct 2008 15:14:34 -0700 (PDT) Received: from web38802.mail.mud.yahoo.com (web38802.mail.mud.yahoo.com [209.191.125.93]) by core3.amsl.com (Postfix) with SMTP id AEE2528C1BC for ; Wed, 22 Oct 2008 15:14:34 -0700 (PDT) Received: (qmail 22504 invoked by uid 60001); 22 Oct 2008 22:15:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=4d8cCOWcvlshYQY4qyjNlbaTPUxGnu2z0HaHWK48I4bC/KehOzO75RIlpC3uJn06XxNfEhM5DCDd4DAwhoMaaIYBX4/RriMbLHPiMCWLYw0U/bKlX9FK/wZmOjY9WrkKmM3LwM2dwiWsDmojPK5/y35II0jWTaGDjI4CQg/w790=; X-YMail-OSG: WxpUGmAVM1mbEVi_MaZJVDXfoY9_q2JUjqrr2PnTSj1Dk3OI5ZLzW355.3B5kB6ErhEftIFkKuhpjJZilMnc_vDjTLRrHB5fGchpgk5TTPBe6.hP5iL2dU6hw9PEVgpYzijlK7c1i87yO_9ajAopz7WahxmNctAy_M2sZ4_UoG9FGlo- Received: from [206.16.17.212] by web38802.mail.mud.yahoo.com via HTTP; Wed, 22 Oct 2008 15:15:51 PDT X-Mailer: YahooMailRC/1096.40 YahooMailWebService/0.7.247.3 Date: Wed, 22 Oct 2008 15:15:51 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" MIME-Version: 1.0 Message-ID: <881583.21711.qm@web38802.mail.mud.yahoo.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 Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883127078==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1883127078== Content-Type: multipart/alternative; boundary="0-2103022091-1224713751=:21711" --0-2103022091-1224713751=:21711 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,=0A Please see inline.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----= - Original Message ----=0AFrom: Thomas C. Schmidt =0ATo: Behcet Sarikaya =0ACc: Hui Deng ; multimob@ietf.org=0ASent: Wednesday, October 22, 2008 4:35:= 33 PM=0ASubject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requi= rement-01.txt=0A=0AHi Behcet,=0A=0AI'm in charge to defend Hui as the figur= e is from my side.=0A=0AIt is not exactly clear why you state "Figure 2 dep= icts local routing=0Aas something totally different" ??? -=0Awhat is expres= sed here: a content source local to the PMIP-domain - but =0Anot local to a= particular MAP. =0A=0A[behcet] In PMIP6 there is no MAP. You mean MAG here= ?=0A=0AAnd in consequence a (multicast) routing =0A within the PMIP domain= without LMA-MAG tunneling. That's what the text =0Asays, as well.=0A=0A[be= hcet] In PMIP6, the nodes between MAG and LMA do not matter because all tra= ffic is tunneled. =0ALocal routing in Fig. 2 would refer to a packet sent f= rom MN1 to MN2 being routed by MAG1 locally without tunneling it to LMA1. = =0AIf the packet MN1 sends is a multicast packet, RFC 5213 does not describ= e how such a packet would be routed. Is this what you are trying to address= ?=0A=0AThis has been discussed prior to version 00 on the mailing list ... = and =0Aseems a reasonable approach to me: what is "certainly not correct"?= =0A=0ARegards,=0A=0AThomas=0A=0ABehcet Sarikaya wrote:=0A> Hello Hui,=0A> = Thanks for your hard work in coming up with this revised version. I =0A> r= ead it.=0A> My comment is regarding Section 2. Local routing in PMIP6 as = described =0A> in Section 6.10.3 of RFC 5213 refers to the routing by the M= AG locally =0A> without tunneling to the LMA. In =0A> draft-deng-multimob-p= mip6-requirement-01 Figure 2 depicts local routing =0A> as something totall= y different. The text you have seems to be OK but the =0A> figure is certai= nly not correct.=0A> =0A> Regards,=0A> =0A> Behcet=0A> =0A> ----- Original = Message ----=0A> From: Hui Deng =0A> To: multimob@ietf= .org=0A> Sent: Sunday, October 19, 2008 11:17:13 AM=0A> Subject: [multimob]= Fwd: I-D =0A> Action:draft-deng-multimob-pmip6-requirement-01.txt=0A> =0A>= Hello, all=0A> =0A> We have updated the draft based on the list discussio= n.=0A> Please help to review and comment.=0A> =0A> thanks=0A> =0A> -Hui= =0A> =0A> =0A> =0A> A New Internet-Draft is available from the on-line Inte= rnet-Drafts =0A> directories.=0A> =0A> Title : Multicast S= upport Requirements for Proxy Mobile =0A> IPv6=0A> Author(s) := H. Deng, et al.=0A> Filename : draft-deng-multimob-pmip6-req= uirement-01.txt=0A> Pages : 14=0A> Date = : 2008-10-19=0A> =0A> This document summarizes requirements for multicast l= istener support=0A> in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspond= ance to=0A> PMIPv6, multicast mobility management requirements do not reque= st any=0A> active participation of the mobile node.=0A> =0A> A URL for this= Internet-Draft is:=0A> http://www.ietf.org/internet-drafts/draft-deng-mult= imob-pmip6-requirement-01.txt=0A> =0A> =0A> =0A> --------------------------= ----------------------------------------------=0A> =0A> ___________________= ____________________________=0A> multimob mailing list=0A> multimob@ietf.or= g=0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A-- =0A=0A=B0 Prof= . Dr. Thomas C. Schmidt=0A=B0 HAW Hamburg, Dept. Informatik=0A=B0 Universit= y of Applied Sciences=0A=B0 Berliner Tor 7, D 20099 Hamburg, Germany=0A=B0 = Fon: +49-40-42875-8452, Fax: -8409=0A=B0 http://www.informatik.haw-hamburg.= de/~schmidt=0A=0A=0A=0A --0-2103022091-1224713751=:21711 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
  Please see inline.

Regards,
Behcet

----- Original Message ----
From: Thomas= C. Schmidt <schmidt@informatik.haw-hamburg.de>
To: Behcet Sarikay= a <sarikaya@ieee.org>
Cc: Hui Deng <denghui02@gmail.com>; mu= ltimob@ietf.org
Sent: Wednesday, October 22, 2008 4:35:33 PM
Subject:= Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt
=0AHi Behcet,

I'm in charge to defend Hui as the figure is from= my side.

It is not exactly clear why you state "Figure 2 depicts lo= cal routing
as something totally different" ??? -
what is expressed h= ere: a content source local to the PMIP-domain - but
not local to a par= ticular MAP.

[behcet] In PMIP6 there is no MAP. You mean MAG here?<= br>
And in consequence a (multicast) routing
  within the PMIP = domain without LMA-MAG tunneling. That's what the text
says, as well.
[behcet] In PMIP6, the nodes between MAG and LMA do not matter becaus= e all traffic is tunneled.
Local routing in Fig. 2 would refer to a pac= ket sent from MN1 to MN2 being routed by MAG1 locally without tunneling it = to LMA1.
If the packet MN1 sends is a multicast packet, RFC 5213 does n= ot describe how such a packet would be routed. Is this what you are trying = to address?

This has been discussed prior to version 00 on the mailing list ... and
seems a reasonable approach to me: what is "certa= inly not correct"?

Regards,

Thomas

Behcet Sarikaya wro= te:
> Hello Hui,
>  Thanks for your hard work in coming u= p with this revised version. I
> read it.
>  My comment = is regarding Section 2. Local routing in PMIP6 as described
> in Sec= tion 6.10.3 of RFC 5213 refers to the routing by the MAG locally
> w= ithout tunneling to the LMA. In
> draft-deng-multimob-pmip6-requirem= ent-01 Figure 2 depicts local routing
> as something totally differe= nt. The text you have seems to be OK but the
> figure is certainly n= ot correct.
>
> Regards,
>
> Behcet
>
&= gt; ----- Original Message ----
> From: Hui Deng <denghui02@gma= il.com>
> To: multimob@ietf.org
> Sent: Sund= ay, October 19, 2008 11:17:13 AM
> Subject: [multimob] Fwd: I-D
&= gt; Action:draft-deng-multimob-pmip6-requirement-01.txt
>
> He= llo, all
> 
> We have updated the draft based on the list= discussion.
> Please help to review and comment.
> 
&= gt; thanks
> 
> -Hui
>
>
>
> A= New Internet-Draft is available from the on-line Internet-Drafts
> = directories.
>
>        Title   =       : Multicast Support Requirements for Proxy Mobile > IPv6
>        Author(s)     = ; : H. Deng, et al.
>        Filename  &nbs= p;     : draft-deng-multimob-pmip6-requirement-01.txt
>&nbs= p;       Pages          : 14
>        Date        &nbs= p;   : 2008-10-19
>
> This document summarizes requiremen= ts for multicast listener support
> in Proxy Mobile IPv6 (PMIPv6) sce= narios.  In correspondance to
> PMIPv6, multicast mobility manag= ement requirements do not request any
> active participation of the m= obile node.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-d= eng-multimob-pmip6-requirement-01.txt
>
>
>
>= ; ------------------------------------------------------------------------<= br>>
> _______________________________________________
> mu= ltimob mailing list
> multimob@ietf.org
> = https://www.ietf.org/mailman/listinfo/multimob

--

=B0 Pr= of. Dr. Thomas C. Schmidt
=B0 HAW Hamburg, Dept. Informatik
=B0 Unive= rsity of Applied Sciences
=B0 Berliner Tor 7, D 20099 Hamburg, Germany=B0 Fon: +49-40-42875-8452, Fax: -8409
=B0 http://www.informatik.ha= w-hamburg.de/~schmidt

=0A=0A --0-2103022091-1224713751=:21711-- --===============1883127078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1883127078==-- From multimob-bounces@ietf.org Thu Oct 23 01:16:18 2008 Return-Path: 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 C19E83A6C25; Thu, 23 Oct 2008 01:16:18 -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 7EF133A6C21 for ; Thu, 23 Oct 2008 01:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 QGdpNBS9mFga for ; Thu, 23 Oct 2008 01:16:16 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D09603A6C26 for ; Thu, 23 Oct 2008 01:15:20 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178169063.adsl.alicedsl.de ([85.178.169.63] helo=[192.168.178.20]) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KsvMl-000LTj-5i; Thu, 23 Oct 2008 10:16:23 +0200 Message-ID: <490032CA.1040809@informatik.haw-hamburg.de> Date: Thu, 23 Oct 2008 10:16:10 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behcet Sarikaya References: <881583.21711.qm@web38802.mail.mud.yahoo.com> In-Reply-To: <881583.21711.qm@web38802.mail.mud.yahoo.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Behcet, Behcet Sarikaya wrote: > It is not exactly clear why you state "Figure 2 depicts local routing > as something totally different" ??? - > what is expressed here: a content source local to the PMIP-domain - but > not local to a particular MAP. > = > [behcet] In PMIP6 there is no MAP. You mean MAG here? [thomas] Yes, sorry for the misprint. > = > And in consequence a (multicast) routing > within the PMIP domain without LMA-MAG tunneling. That's what the text > says, as well. > = > [behcet] In PMIP6, the nodes between MAG and LMA do not matter because = > all traffic is tunneled. [thomas] except for the local routing option as described in section = 6.10.3 of RFC 5213. Here a local routing is foreseen between two unicast = nodes on the same access link. > Local routing in Fig. 2 would refer to a packet sent from MN1 to MN2 = > being routed by MAG1 locally without tunneling it to LMA1. > If the packet MN1 sends is a multicast packet, RFC 5213 does not = > describe how such a packet would be routed. Is this what you are trying = > to address? > = [thomas] RFC5213 does not address multicast routing (that's why we are = discussing it). The scenario described in fig 2 is *not* addressing = mobile multicast senders, but a typical content distribution setting as = for instance used in a provider-centric IPTV service. This means, a = provider issues multicast streams from within his network domain, aiming = at an efficient way to preserve (his own) network resources. From the minimal perspective of RFC5213 (unicast routing) there is no = efficient way to do this. That's why we are trying to identify protocol = extensions that smoothly cooperate with RFC 5213. Best regards, Thomas -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 23 13:35:09 2008 Return-Path: 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 C8EC13A6BA0; Thu, 23 Oct 2008 13:35:09 -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 C25153A6AD1 for ; Thu, 23 Oct 2008 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=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 1l+-LkL6eJwE for ; Thu, 23 Oct 2008 13:35:07 -0700 (PDT) Received: from web38808.mail.mud.yahoo.com (web38808.mail.mud.yahoo.com [209.191.125.99]) by core3.amsl.com (Postfix) with SMTP id 71F573A68F7 for ; Thu, 23 Oct 2008 13:35:07 -0700 (PDT) Received: (qmail 68152 invoked by uid 60001); 23 Oct 2008 20:36:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=aJUfmzeCrWq/mLKyOXiCRfR1h1UvAbz31/LPffrTv9T3Vu1bsRpLAH2/89fSUKh6zacSoM9QryuEs+QHTvpYHOhC/yndiov2AV0A26jpSim+lfGaJdaKoa19NNLTIUEDjgwkSOnNQ2GkmsRyPzJiFvWUAAh7X7vb23aN7sI/9Uo=; X-YMail-OSG: Xuu6NPwVM1lUB5LYw4BS.Hea6QeLxFL5wSR63jzqemUFjdIVCfm9NxLIQiUN8K879MPQHrdM7x_w4wuCbaDUVqJZaB.ZyFk2PEXnHKw3kYcB5hq2QKOcfOplJiVPW3.SXq91sY.33vHPYWibgbYBxbApg4x4LzMcXwEfmfN14DfpPQU- Received: from [206.16.17.212] by web38808.mail.mud.yahoo.com via HTTP; Thu, 23 Oct 2008 13:36:27 PDT X-Mailer: YahooMailRC/1096.40 YahooMailWebService/0.7.247.3 Date: Thu, 23 Oct 2008 13:36:27 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" MIME-Version: 1.0 Message-ID: <352065.68132.qm@web38808.mail.mud.yahoo.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 Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195359208==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0195359208== Content-Type: multipart/alternative; boundary="0-321120331-1224794187=:68132" --0-321120331-1224794187=:68132 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,=0A=0A=0A=0A----- Original Message ----=0AFrom: Thomas C. Schmidt= =0ATo: Behcet Sarikaya =0ACc: Hui Deng ; multimob@ietf.org=0ASent: Thursda= y, October 23, 2008 3:16:10 AM=0ASubject: Re: [multimob] Comments on draft-= deng-multimob-pmip6-requirement-01.txt=0A=0AHi Behcet,=0A=0ABehcet Sarikaya= wrote:=0A=0A> It is not exactly clear why you state "Figure 2 depicts loca= l routing=0A> as something totally different" ??? -=0A> what is expressed h= ere: a content source local to the PMIP-domain - but=0A> not local to a par= ticular MAP.=0A> =0A> [behcet] In PMIP6 there is no MAP. You mean MAG here?= =0A=0A[thomas] Yes, sorry for the misprint.=0A> =0A> And in consequence a (= multicast) routing=0A> within the PMIP domain without LMA-MAG tunneling. = That's what the text=0A> says, as well.=0A> =0A> [behcet] In PMIP6, the nod= es between MAG and LMA do not matter because =0A> all traffic is tunneled.= =0A=0A[thomas] except for the local routing option as described in section = =0A6.10.3 of RFC 5213. Here a local routing is foreseen between two unicast= =0Anodes on the same access link.=0A=0A> Local routing in Fig. 2 would ref= er to a packet sent from MN1 to MN2 =0A> being routed by MAG1 locally witho= ut tunneling it to LMA1.=0A> If the packet MN1 sends is a multicast packet,= RFC 5213 does not =0A> describe how such a packet would be routed. Is this= what you are trying =0A> to address?=0A> =0A[thomas] RFC5213 does not addr= ess multicast routing (that's why we are =0Adiscussing it). The scenario de= scribed in fig 2 is *not* addressing =0Amobile multicast senders, =0A=0A[be= hcet] Then I think the text and figure on the local routing is not needed b= ecause local routing in PMIPv6 refers to the routing of packets coming from= the uplink and as you said this would be multicast sender situation which = you left out in the requirements draft.=0A=0Abut a typical content distribu= tion setting as =0Afor instance used in a provider-centric IPTV service. Th= is means, a =0Aprovider issues multicast streams from within his network do= main, aiming =0Aat an efficient way to preserve (his own) network resources= .=0A=0AFrom the minimal perspective of RFC5213 (unicast routing) there is n= o =0Aefficient way to do this. That's why we are trying to identify protoco= l =0Aextensions that smoothly cooperate with RFC 5213.=0A=0A[behcet] The si= tuation you are talking about could become valid if route optimization is u= sed with PMIPv6. In that case the content server in between MAG and LMA wou= ld send directly to MAG. If route optimization is not used then all traffic= goes through LMA-MAG tunnel. Route optimization for PMIPv6 is some future = work, there are drafts but we don't know if the standardization will go ahe= ad.=0ARoute optimization with multicasting is even more complicated problem= . If you wish to state some requirements for this very complicated case ple= ase go ahead.=0ABest regards,=0A=0ABehcet=0A=0ABest regards,=0A=0AThomas=0A= =0A=0A-- =0A=0A=B0 Prof. Dr. Thomas C. Schmidt=0A=B0 HAW Hamburg, Dept. Inf= ormatik=0A=B0 University of Applied Sciences=0A=B0 Berliner Tor 7, D 20099 = Hamburg, Germany=0A=B0 Fon: +49-40-42875-8452, Fax: -8409=0A=B0 http://www.= informatik.haw-hamburg.de/~schmidt=0A=0A=0A=0A --0-321120331-1224794187=:68132 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

----- Original Message ----=
From: Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>
To= : Behcet Sarikaya <sarikaya@ieee.org>
Cc: Hui Deng <denghui02@g= mail.com>; multimob@ietf.org
Sent: Thursday, October 23, 2008 3:16:10= AM
Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requir= ement-01.txt

=0AHi Behcet,

Behcet Sarikaya wrote:

>= It is not exactly clear why you state "Figure 2 depicts local routing
&= gt; as something totally different" ??? -
> what is expressed here: a= content source local to the PMIP-domain - but
> not local to a parti= cular MAP.
>
> [behcet] In PMIP6 there is no MAP. You mean MAG= here?

[thomas] Yes, sorry for the misprint.
>
> And in= consequence a (multicast) routing
>  within the PMIP domain wi= thout LMA-MAG tunneling. That's what the text
> says, as well.
>= ;
> [behcet] In PMIP6, the nodes between MAG and LMA do not matter b= ecause
> all traffic is tunneled.

[thomas] except for the loc= al routing option as described in section
6.10.3 of RFC 5213. Here a lo= cal routing is foreseen between two unicast
nodes on the same access li= nk.

> Local routing in Fig. 2 would refer to a packet sent from M= N1 to MN2
> being routed by MAG1 locally without tunneling it to LMA1.
>= ; If the packet MN1 sends is a multicast packet, RFC 5213 does not
>= describe how such a packet would be routed. Is this what you are trying > to address?
>
[thomas] RFC5213 does not address multicast = routing (that's why we are
discussing it). The scenario described in fi= g 2 is *not* addressing
mobile multicast senders,

[behcet] Then I think the text and figure on t= he local routing is not needed because local routing in PMIPv6 refers to th= e routing of packets coming from the uplink and as you said this would be m= ulticast sender situation which you left out in the requirements draft.

but a typical content distribution setting as
for instance u= sed in a provider-centric IPTV service. This means, a
provider issues m= ulticast streams from within his network domain, aiming
at an efficient way to preserve (his own) network resources.

From the mi= nimal perspective of RFC5213 (unicast routing) there is no
efficient wa= y to do this. That's why we are trying to identify protocol
extensions = that smoothly cooperate with RFC 5213.

[behcet] The situation you are talking about could become valid = if route optimization is used with PMIPv6. In that case the content server = in between MAG and LMA would send directly to MAG. If route optimization is= not used then all traffic goes through LMA-MAG tunnel. Route optimization = for PMIPv6 is some future work, there are drafts but we don't know if the s= tandardization will go ahead.
<= span style=3D"color: rgb(0, 96, 191);">Route optimization with multicasting= is even more complicated problem. If you wish to state some requirements f= or this very complicated case please go ahead.
Best regards,

Behcet

Best regards,

Thomas


--
=B0 Prof. Dr. Thomas C. Schmidt
=B0 HAW Hamburg, Dept. Informatik
= =B0 University of Applied Sciences
=B0 Berliner Tor 7, D 20099 Hamburg, = Germany
=B0 Fon: +49-40-42875-8452, Fax: -8409
=B0 http://www.info= rmatik.haw-hamburg.de/~schmidt

=0A=0A --0-321120331-1224794187=:68132-- --===============0195359208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0195359208==-- From multimob-bounces@ietf.org Thu Oct 23 13:57:59 2008 Return-Path: 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 EAE153A6A11; Thu, 23 Oct 2008 13:57: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 148B03A6955 for ; Thu, 23 Oct 2008 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.133, 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 EHnYJuSnCRCo for ; Thu, 23 Oct 2008 13:57:58 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 1E0873A676A for ; Thu, 23 Oct 2008 13:57:58 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178173070.adsl.alicedsl.de ([85.178.173.70] helo=[192.168.178.20]) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Kt7H3-000EZl-2O; Thu, 23 Oct 2008 22:59:17 +0200 Message-ID: <4900E5A0.9050306@informatik.haw-hamburg.de> Date: Thu, 23 Oct 2008 22:59:12 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Behcet Sarikaya References: <352065.68132.qm@web38808.mail.mud.yahoo.com> In-Reply-To: <352065.68132.qm@web38808.mail.mud.yahoo.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Behcet, Behcet Sarikaya wrote: > [thomas] RFC5213 does not address multicast routing (that's why we are > discussing it). The scenario described in fig 2 is *not* addressing > mobile multicast senders, > = > [behcet] Then I think the text and figure on the local routing is not = > needed because local routing in PMIPv6 refers to the routing of packets = > coming from the uplink and as you said this would be multicast sender = > situation which you left out in the requirements draft. > [thomas] This is a misunderstanding: Fig 2 does *not* refer to sender = mobility. > but a typical content distribution setting as > for instance used in a provider-centric IPTV service. This means, a > provider issues multicast streams from within his network domain, aiming > at an efficient way to preserve (his own) network resources. > = > From the minimal perspective of RFC5213 (unicast routing) there is no > efficient way to do this. That's why we are trying to identify protocol > extensions that smoothly cooperate with RFC 5213. > = > [behcet] The situation you are talking about could become valid if route = > optimization is used with PMIPv6. In that case the content server in = > between MAG and LMA would send directly to MAG. If route optimization is = > not used then all traffic goes through LMA-MAG tunnel. Route = > optimization for PMIPv6 is some future work, there are drafts but we = > don't know if the standardization will go ahead. > Route optimization with multicasting is even more complicated problem. = > If you wish to state some requirements for this very complicated case = > please go ahead. [thomas] Hmm, I'm not trying to add complicated requirements. This is = the overview about possible scenarios. We're all just trying to think of a reasonable scope to address and = solve the problem (so does the recent pmip6-extension-draft ... see also = the last mail from Hitoshi). If multicast on PMIPv6 is supposed to serve as a solution for = large-scale content distribution (like in IPTV applications), then we = should not just propose to tunnel all traffic from one LMA to the MAGs. = That's a bitter pill for those who have to pay for the infrastructure. Best regards, Thomas -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Oct 23 20:31:59 2008 Return-Path: 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 ; 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 ; 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 ; 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" To: 'Hui Deng' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1211297280==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1211297280== Content-type: multipart/alternative; boundary="Boundary_(ID_21b1nhFXAs/hNzgrEi99ZQ)" This is a multi-part message in MIME format. --Boundary_(ID_21b1nhFXAs/hNzgrEi99ZQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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 --Boundary_(ID_21b1nhFXAs/hNzgrEi99ZQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
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
 
--Boundary_(ID_21b1nhFXAs/hNzgrEi99ZQ)-- --===============1211297280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1211297280==-- From multimob-bounces@ietf.org Tue Oct 28 07:49:45 2008 Return-Path: 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 D5B013A6C49; Tue, 28 Oct 2008 07:49:45 -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 257763A6C4C for ; Tue, 28 Oct 2008 07:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 W+84OOShvx70 for ; Tue, 28 Oct 2008 07:49:44 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with SMTP id 0F60D3A6C42 for ; Tue, 28 Oct 2008 07:49:43 -0700 (PDT) Received: from ([128.244.206.121]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.122575044; Tue, 28 Oct 2008 10:43:31 -0400 Message-ID: <49072513.3090508@innovationslab.net> Date: Tue, 28 Oct 2008 10:43:31 -0400 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: multimob@ietf.org Subject: [multimob] [Fwd: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt] 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org -------- Original Message -------- Subject: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt Date: Mon, 27 Oct 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PMIPv6 Extensions for Multicast Author(s) : H. Asaeda, et al. Filename : draft-asaeda-multimob-pmip6-extension-00.txt Pages : 32 Date : 2008-10-27 This document describes Proxy Mobile IPv6 (PMIPv6) extensions and solutions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and establish a bi-directional tunnel to manage mobility for mobile nodes within the Proxy Mobile IPv6 domain. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-asaeda-multimob-pmip6-extension-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Oct 28 07:54:29 2008 Return-Path: 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 4101D3A6C09; Tue, 28 Oct 2008 07:54:29 -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 4575F3A69E9 for ; Tue, 28 Oct 2008 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 6EyIvm5vwhtA for ; Tue, 28 Oct 2008 07:54:24 -0700 (PDT) Received: from web38804.mail.mud.yahoo.com (web38804.mail.mud.yahoo.com [209.191.125.95]) by core3.amsl.com (Postfix) with SMTP id 36EA93A688F for ; Tue, 28 Oct 2008 07:54:24 -0700 (PDT) Received: (qmail 45724 invoked by uid 60001); 28 Oct 2008 14:54:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=4O3U2oHjoAjp7zq34X8XeHo+97KbwhBkRS0+S5Q4qfAHXP+uxnI6OgipErH1Z9oSQef0wheCQApchW4w9n8H60y/QIHKI7dtVK9Oj8tqU8ma+DPOsuv7keIih8qAHL4xrVZ4+6zyFTWOaR/6jBh0F4U+1mOaEcf3gWHN1YHKcng=; X-YMail-OSG: 4thaJmMVM1niX9Ci51UPrFDr2Ie2cVVcXkLpdXnL9MMDSp7Bsb8DQUpjp37NW7AYuoZiSsgC8enOB14zs00EZYqxozTLgdEXxvYsFrMZDXcPw1suZEU5wGr4t8YjVp6YCHtFJGKl144LvE3z7Fk_2i7qzKrd_GAxA.3o1xkwuaCo1XhI6JjJFxF60ZFn Received: from [71.252.158.246] by web38804.mail.mud.yahoo.com via HTTP; Tue, 28 Oct 2008 07:54:23 PDT X-Mailer: YahooMailRC/1155.11 YahooMailWebService/0.7.247.3 Date: Tue, 28 Oct 2008 07:54:23 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <548036.45239.qm@web38804.mail.mud.yahoo.com> Subject: Re: [multimob] [Fwd: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt] 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: , Content-Type: multipart/mixed; boundary="===============0925404938==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0925404938== Content-Type: multipart/alternative; boundary="0-241586629-1225205663=:45239" --0-241586629-1225205663=:45239 Content-Type: text/plain; charset=us-ascii Hello all, This draft has been discussed by several people before submission.Now that it has been submitted, please post your comments on the list. Regards, Behcet ________________________________ From: Brian Haberman To: multimob@ietf.org Sent: Tuesday, October 28, 2008 9:43:31 AM Subject: [multimob] [Fwd: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt] -------- Original Message -------- Subject: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt Date: Mon, 27 Oct 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PMIPv6 Extensions for Multicast Author(s) : H. Asaeda, et al. Filename : draft-asaeda-multimob-pmip6-extension-00.txt Pages : 32 Date : 2008-10-27 This document describes Proxy Mobile IPv6 (PMIPv6) extensions and solutions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and establish a bi-directional tunnel to manage mobility for mobile nodes within the Proxy Mobile IPv6 domain. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-asaeda-multimob-pmip6-extension-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --0-241586629-1225205663=:45239 Content-Type: text/html; charset=us-ascii
Hello all,
  This draft has been discussed by several people before submission.Now that it has been submitted, please post your comments on the list.

Regards,

Behcet

From: Brian Haberman <brian@innovationslab.net>
To: multimob@ietf.org
Sent: Tuesday, October 28, 2008 9:43:31 AM
Subject: [multimob] [Fwd: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt]



-------- Original Message --------
Subject: I-D Action:draft-asaeda-multimob-pmip6-extension-00.txt
Date: Mon, 27 Oct 2008 10:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title          : PMIPv6 Extensions for Multicast
    Author(s)      : H. Asaeda, et al.
    Filename        : draft-asaeda-multimob-pmip6-extension-00.txt
    Pages          : 32
    Date            : 2008-10-27

This document describes Proxy Mobile IPv6 (PMIPv6) extensions and
solutions to support IP multicast.  The Mobile Access Gateway (MAG)
and the Local Mobility Anchor (LMA) are the mobility entities defined
in the PMIPv6 protocol and establish a bi-directional tunnel to
manage mobility for mobile nodes within the Proxy Mobile IPv6 domain.
This document defines the roles of LMA and MAG to support IP
multicast for the mobile nodes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-asaeda-multimob-pmip6-extension-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--0-241586629-1225205663=:45239-- --===============0925404938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0925404938==-- From multimob-bounces@ietf.org Tue Oct 28 08:47:25 2008 Return-Path: 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 52C303A695A; Tue, 28 Oct 2008 08:47:25 -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 85EE93A695A for ; Tue, 28 Oct 2008 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] 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 Wj0xu0Tsvtj4 for ; Tue, 28 Oct 2008 08:47:22 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id A46243A6914 for ; Tue, 28 Oct 2008 08:47:22 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id E39BF13D03D6 for ; Wed, 29 Oct 2008 00:24:44 +0900 (JST) Date: Wed, 29 Oct 2008 00:46:48 +0900 (JST) Message-Id: <20081029.004648.109891455.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Subject: [multimob] IGMP/MLD requirement draft revised 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hello group, The IGMP/MLD requirement draft was revised. http://www.ietf.org/internet-drafts/draft-liu-multimob-igmp-mld-mobility-req-01.txt Comments are very welcome. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Oct 28 13:22:28 2008 Return-Path: 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 CAFE228C1F6; Tue, 28 Oct 2008 13:22:28 -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 92C4F28C1F6 for ; Tue, 28 Oct 2008 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 vrbAzgL+ULad for ; Tue, 28 Oct 2008 13:22:26 -0700 (PDT) Received: from web38804.mail.mud.yahoo.com (web38804.mail.mud.yahoo.com [209.191.125.95]) by core3.amsl.com (Postfix) with SMTP id CEBB128C12C for ; Tue, 28 Oct 2008 13:22:26 -0700 (PDT) Received: (qmail 21706 invoked by uid 60001); 28 Oct 2008 20:22:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=sSJPOA1GwexKL3c1+SS0if9iZq14cAiRNrh0l3T/NztlLJnZVHbzPgoUWmtsb85KASfWl4RmkI9LAQWvLINa2PVZqDWLoitInv5vMKubRY0OaAra0xUXRaYS2CmxzZR8hya62ljwColsx+eeRirQg4uuhTigXHn2Z6HwJNIwkqQ=; X-YMail-OSG: KKZJQKAVM1n9OLzeWqu4UJGCf_VylnkKIfOi6jJ7ZLwm09wfx3Uff0Yk98bV52PFQw-- Received: from [206.16.17.212] by web38804.mail.mud.yahoo.com via HTTP; Tue, 28 Oct 2008 13:22:24 PDT X-Mailer: YahooMailRC/1155.11 YahooMailWebService/0.7.247.3 Date: Tue, 28 Oct 2008 13:22:24 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1304958314-1225225344=:21566" Message-ID: <603300.21566.qm@web38804.mail.mud.yahoo.com> Subject: [multimob] Draft BoF Agenda 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: , Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --0-1304958314-1225225344=:21566 Content-Type: multipart/alternative; boundary="0-2064961843-1225225344=:21566" --0-2064961843-1225225344=:21566 Content-Type: text/plain; charset=us-ascii Hello Folks, Please find attached draft agenda for the upcoming Multimob BoF meeting in IETF-73. Please send any requests for a slot to me and Brian. We will finalize the agenda and then post it online at IETF page. Regards, Brian & Behcet --0-2064961843-1225225344=:21566 Content-Type: text/html; charset=us-ascii
Hello Folks,
  Please find attached draft agenda for the upcoming Multimob BoF meeting in IETF-73.
  Please send any requests for a slot to me and Brian.
We will finalize the agenda and then post it online at IETF page.

Regards,

Brian & Behcet

--0-2064961843-1225225344=:21566-- --0-1304958314-1225225344=:21566 Content-Type: text/plain; name="ietf73multimobbofagenda.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ietf73multimobbofagenda.txt" TXVsdGljYXN0IE1vYmlsaXR5IEJPRiAoTXVsdGltb2IpDQoNCg0KV2VlayBk YXksIERhdGUgYW5kIFRpbWUNCj09PT09PT09PT09PT09PT09PT09PT09PQ0K DQpDSEFJUlM6IEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xh Yi5uZXQ+IA0KICAgICAgICBCZWhjZXQgIFNhcmlrYXlhIDxzYXJpa2F5YUBp ZWVlLm9yZz4NCiAgICAgICAgDQpBR0VOREE6DQoNCjEuIEFkbWluaXN0cmF0 aXZpYSAoQ2hhaXJzLCA1IG1pbikgDQogIC0gTm90ZSB0YWtlcnMsIEphYmJl ciBzY3JpYmVzDQogIC0gQWdlbmRhIGJhc2hpbmcNCiAgDQoyLiBTY29wZSBv ZiB0aGUgQm9GIChDaGFpcnMvQURzLCAxNSBtaW4pIA0KICAtIE1vdGl2YXRp b24gYW5kIHByb2JsZW0gc3RhdGVtZW50DQogIA0KMy4gTXVsdGltb2IgUmVx dWlyZW1lbnRzIChIaXRvc2hpLCBIdWkgJiBDaGFpcnMsIDMwIG1pbikgDQog IC0gZHJhZnQtbGl1LW11bHRpbW9iLWlnbXAtbWxkLW1vYmlsaXR5LXJlcS0w MiAoSGl0b3NoaSkgMTUNCiAgLSBkcmFmdC1kZW5nLW11bHRpbW9iLXBtaXA2 LXJlcXVpcmVtZW50LTAxICAgIChIdWkpICAgICAxNQ0KICANCjQuIFByb3Rv Y29scyAoSGl0b3NoaSwgTmlrbGFzICYgQ2hhaXJzLCAzMCBtaW4pIA0KICAt IGRyYWZ0LWFzYWVkYS1tdWx0aW1vYi1pZ21wLW1sZC1tb2JpbGl0eS1leHRl bnNpb25zLTAxIDE1DQogIC0gZHJhZnQtbmV1bWFubi1tdWx0aW1vYi1wbWlw Ni1zb2x1dGlvbiAgICAgICAgICAgICAgICAgMTUNCiAgLSBQTUlQNiBJUHY0 IHN1cHBvcnQgc29sdXRpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAx NQ0KICANCjUuIENvbnNlbnN1cyBhbmQgQ2hhcnRlciBEaXNjdXNzaW9uIChB bGwsIDE1IG1pbikgDQoNCjYuIENvbmNsdXNpb25zIGFuZCBOZXh0IFN0ZXBz IChDaGFpcnMvQURzLCAxMCBtaW4pICANCiAgDQoNCg== --0-1304958314-1225225344=:21566 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --0-1304958314-1225225344=:21566-- From multimob-bounces@ietf.org Tue Oct 28 13:25:40 2008 Return-Path: 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 3D9293A6CAA; Tue, 28 Oct 2008 13:25:40 -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 C41B43A68DF for ; Tue, 28 Oct 2008 13:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 L5v8uvrFWbJg for ; Tue, 28 Oct 2008 13:25:37 -0700 (PDT) Received: from web38806.mail.mud.yahoo.com (web38806.mail.mud.yahoo.com [209.191.125.97]) by core3.amsl.com (Postfix) with SMTP id C227F3A6968 for ; Tue, 28 Oct 2008 13:25:37 -0700 (PDT) Received: (qmail 89114 invoked by uid 60001); 28 Oct 2008 20:25:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=DtUgxiQS80xeox2bfsoe6jkCGzIwxuZpAlb+R7cEl+H/8TkrGF6tEoXr0kvLc4TafgkgvXoMAHJlbQWIw1mcJtseh2/40krt202n1oCiw1EVcEPSszvWTxgN0LKTGH4S7Utke06cu7Vmmc5Z/STc29vv+jtS/JEIOypZrCz3XBo=; X-YMail-OSG: KA3C_OcVM1nknV1n29fB.dXPy3zZV.cifH.5cMFwYo6vYv4ql7kegiuSnADtgeBv5xRVm90Oibpv.z_dH30Tb1gG6D9mVnCftWlq0X8StlwloCluwV7WgA_uUWl2xrvUwHE9FUUXBtshUCxa9UVqKRDqS.p5XlgCCk541bcrM8eVXYYZ6KQ91NdejieS Received: from [206.16.17.212] by web38806.mail.mud.yahoo.com via HTTP; Tue, 28 Oct 2008 13:25:36 PDT X-Mailer: YahooMailRC/1155.11 YahooMailWebService/0.7.247.3 Date: Tue, 28 Oct 2008 13:25:36 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-880890035-1225225536=:88971" Message-ID: <54397.88971.qm@web38806.mail.mud.yahoo.com> Subject: [multimob] Draft Charter 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: , Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --0-880890035-1225225536=:88971 Content-Type: multipart/alternative; boundary="0-152573204-1225225536=:88971" --0-152573204-1225225536=:88971 Content-Type: text/plain; charset=us-ascii Dear all, Please find attached the draft charter for Multimob BoF meeting coming up at IETF-73. Please post your comments on the list. We will finalize the charter and then post it on IETF page. Kind regards, Brian & Behcet --0-152573204-1225225536=:88971 Content-Type: text/html; charset=us-ascii
Dear all,
  Please find attached the draft charter for Multimob BoF meeting coming up at IETF-73.
  Please post your comments on the list. We will finalize the charter and then post it on IETF page.

Kind regards,

Brian & Behcet

--0-152573204-1225225536=:88971-- --0-880890035-1225225536=:88971 Content-Type: text/plain; name="multimob_charter_v8.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="multimob_charter_v8.txt" TXVsdGljYXN0IE1vYmlsaXR5IChtdWx0aW1vYikNCg0KQ2hhaXJzOg0KQnJp YW4gSGFiZXJtYW4gPDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ+DQpCZWhj ZXQgIFNhcmlrYXlhIDxzYXJpa2F5YUBpZWVlLm9yZz4NCg0KSW50ZXJuZXQg QXJlYSAoaW50KSBEaXJlY3RvcnM6DQpKYXJpIEFya2tvIDxqYXJpLmFya2tv QHBpdWhhLm5ldD4NCk1hcmsgVG93bnNsZXkgPHRvd25zbGV5QGNpc2NvLmNv bT4gDQoNClNlY3VyaXR5IEFyZWEgQWR2aXNvcjoNCk1hcnNoYWxsIEV1YmFu a3MgPHRtZUBhbWVyaWNhZnJlZS50dj4uDQoNCk1haWxpbmcgTGlzdHM6DQpH ZW5lcmFsIERpc2N1c3Npb246IG11bHRpbW9iQGlldGYub3JnDQpTdWJzY3Jp YmUgb25saW5lIGF0OiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tdWx0aW1vYg0KDQpEZXNjcmlwdGlvbiBvZiBXb3JraW5nIEdy b3VwDQoNCklQIG11bHRpY2FzdGluZyB0ZWNobm9sb2d5IGhhcyBub3cgc3Rh cnRlZCB0byBiZSB1c2VkIGluIG1vYmlsZSBuZXR3b3JrcyBhbmQgdGhpcyB0 cmVuZCBpcyBleHBlY3RlZCB0bw0KY29udGludWUuIE11bHRpY2FzdCBtb2Jp bGl0eSAobXVsdGltb2IpIHByb3Bvc2VzIHRvIGRlYWwgd2l0aCB0aGUgcHJv YmxlbXMgYW5kIGluZWZmaWNpZW5jaWVzIA0KdGhhdCBhcmlzZSBmcm9tIHVz aW5nIElQIG11bHRpY2FzdGluZyBpbiBtb2JpbGUgZW52aXJvbm1lbnRzLiBU aGUgc2NvcGUgd2lsbCBiZSBsaW1pdGVkIHRvDQp0aGUgIGdyb3VwIG1hbmFn ZW1lbnQgYW5kIHByb3h5IG1vYmlsZSBJUCBwcm90b2NvbHMuIEJvdGggc291 cmNlIHNwZWNpZmljIG11bHRpY2FzdCAoU1NNKSANCmFuZCBhbnkgc291cmNl IG11bHRpY2FzdGluZyB3aWxsIGJlIGNvbnNpZGVyZWQuIFdvcmsgcmVsYXRl ZCB0byBhbmQgcmVxdWlyaW5nIG1vZGlmaWNhdGlvbnMgb2YgDQptdWx0aWNh c3Qgcm91dGluZyBwcm90b2NvbHMgKFBJTS1TTSwgUElNLURNLCBldGMuKSBp cyBvdXQgb2Ygc2NvcGUuIEJvdGggSVB2NCBhbmQgSVB2NiB2ZXJzaW9ucw0K b2YgdGhlIHNvbHV0aW9ucyB3aWxsIGJlIGRldmVsb3BlZCBpbiB0aGUgc2Ft ZSBvciBzZXBhcmF0ZSBkb2N1bWVudHMuIA0KDQpJR01QdjMvTUxEdjIgaXMg b3JpZ2luYWxseSBkZWZpbmVkIGZvciB3aXJlZCBuZXR3b3JrcyB3aXRoIHNo YXJlZCBsaW5rcy4gQWxzbyBtb2JpbGUgbm9kZXMgaGF2ZSB0byANCnNhdmUg YmF0dGVyeSBieSBlbnRlcmluZyBpbnRvIHRoZSBkb3JtYW50IG1vZGUuIFRo ZXJlZm9yZSBkb3JtYW50IG1vZGUgb3BlcmF0aW9uIG5lZWRzIHRvIGJlIHN1 cHBvcnRlZCANCmJ5IElHTVB2My9NTER2Mi4gVGhlcmUgYXJlIGFsc28gY29u Y2VybnMgcmVsYXRlZCB0byB0aGUgbGF0ZW5jeSBvZiBqb2lucyBhbmQgbGVh dmVzIHRoYXQgSUdNUHYzL01MRHYyIHByb3ZpZGVzLiANClRoZSBsYXRlbmN5 IG5lZWRzIHRvIGJlIG1pbmltaXplZC4gVGhlcmUgYXJlIGN1cnJlbnRseSBk ZXBsb3llZCBleHRlbnNpb25zIHRvIHJlZHVjZSB0aGUgam9pbiBhbmQgbGVh dmUgDQpsYXRlbmNpZXMuICBJbiBNdWx0aW1vYiB0aGVzZSBpc3N1ZXMgd2ls bCBiZSBhZGRyZXNzZWQgYW5kIElHTVB2My9NTER2MiBmb3IgbW9iaWxlIGVu dmlyb25tZW50cyANCndpbGwgYmUgc3RhbmRhcmRpemVkLiBEaWZmZXJlbnQg c3RyYXRlZ2llcyBmb3Igc29sdmluZyB0aGVzZSBpc3N1ZXMgd2lsbCBiZSBw dXJzdWVkLiANClRoZSBzaW1wbGVzdCBzdHJhdGVneSB3b3VsZCBiZSBkb2N1 bWVudGluZyBhbHJlYWR5IGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBmYXN0 IGpvaW4vZmFzdCBsZWF2ZSBleHRlbnNpb25zLiANClRoZSBXRyBuZWVkcyB0 byBhc2NlcnRhaW4gd2hldGhlciB0aGUgZXhpc3Rpbmcgc29sdXRpb25zIGFy ZSBzdWZmaWNpZW50IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSwgYW5kIGlmIG5v dCwgDQpjb21lIHVwIHdpdGggYmV0dGVyIHNvbHV0aW9ucy4gRm9yIHN1cHBv cnRpbmcgZG9ybWFudCBtb2RlLCB0aGUgV0cgbmVlZHMgdG8gZGVmaW5lIHBy b3RvY29sIGNoYW5nZXMgDQp0aGF0IG1heSBzaW1wbHkgbW9kaWZ5IHRoZSB0 aW1lcnMgaW4gdGhlIHByb3RvY29scyBvciBzdXBwb3J0IGFkZGl0aW9uYWwg bWVzc2FnZSB0eXBlcy4gDQoNClRoZSB1bmljYXN0IG1vYmlsaXR5IHByb3Rv Y29sIFByb3h5IE1vYmlsZSBJUHY2IChQTUlQdjYpIGRvZXMgbm90IGN1cnJl bnRseSBzdXBwb3J0IG11bHRpY2FzdGluZy4gDQpQTUlQdjYgd2lsbCBiZSBl eHRlbmRlZCB0byBzdXBwb3J0IG11bHRpY2FzdGluZy4gQWxzbyBQTUlQdjYg SVB2NCBzdXBwb3J0IHByb3RvY29sIHdpbGwgYmUgZXh0ZW5kZWQNCnRvIHN1 cHBvcnQgbXVsdGljYXN0aW5nIHdpdGggSVB2NC4NCg0KSXQgaXMgYSBnb2Fs IG9mIHRoZSBuZXcgd29ya2luZyBncm91cCB0byBlbmhhbmNlIFBNSVB2NiB0 byByZW5kZXIgdGhlIHByb3RvY29sIG1vcmUgZGVwbG95YWJsZSBpbiBuZXcg DQphbmQgdXBjb21pbmcgTW9iaWxlIElQVFYgbmV0d29ya3MuIA0KDQpJR01Q djMvTUxEdjIgd2lsbCBiZSBleHRlbmRlZCB0byBzdXBwb3J0IGhvc3QgbW9i aWxpdHkuIE1vYmlsZSBJR01QdjMvTUxEdjIgZmVhdHVyaW5nIHJlZHVjZWQg am9pbiBhbmQgIA0KbGVhdmUgbGF0ZW5jaWVzLCBkb3JtYW50IG1vZGUgYW5k IHBvaW50LXRvLXBvaW50IGxpbmsgc3VwcG9ydCB3aWxsIGJlIHN0YW5kYXJk aXplZC4NCg0KSW4gZG9pbmcgaXRzIHdvcmssIHRoZSBNdWx0aW1vYiB3b3Jr aW5nIGdyb3VwIHdpbGwgd29yayBjbG9zZWx5IHdpdGggTkVUTE1NDQp3b3Jr aW5nIGdyb3VwIGFuZCB3aWxsIGNvb3JkaW5hdGUgSUdNUC9NTEQgZXh0ZW5z aW9ucyB3b3JrIHdpdGggTUFHTUEgYW5kIE1CT05FRCB3b3JraW5nIGdyb3Vw cy4NCg0KR09BTFMgQU5EIE1JTEVTVE9ORVMNCg0KDQoNCkFwcmlsIDIwMDkg UmVxdWlyZW1lbnRzIGZvciBJR01QdjMvTUxEdjIgRXh0ZW5zaW9ucyBkb2N1 bWVudCBhcyBpbmZvcm1hdGlvbmFsIHN0YW5kYXJkIHRvIElFU0cNCg0KTWF5 IDIwMDkgTXVsdGljYXN0IFN1cHBvcnQgUmVxdWlyZW1lbnRzIGZvciBQTUlQ djYgZG9jdW1lbnQgYXMgaW5mb3JtYXRpb25hbCBzdGFuZGFyZCB0byBJRVNH DQoNClNlcHRlbWJlciAyMDA5IElHTVB2My9NTER2MiBFeHRlbnNpb25zIGRv Y3VtZW50IGFzIHByb3Bvc2VkIHN0YW5kYXJkIHRvIElFU0cNCg0KRGVjZW1i ZXIgMjAwOSBQTUlQdjYgTXVsdGljYXN0IFN1cHBvcnQgUHJvdG9jb2wgZG9j dW1lbnQgYXMgcHJvcG9zZWQgc3RhbmRhcmQgdG8gSUVTRw0KDQpGZWJydWFy eSAyMDEwIE11bHRpY2FzdCBTdXBwb3J0IFByb3RvY29sIGZvciBQTUlQdjYg SVB2NCBFeHRlbnNpb25zIGRvY3VtZW50IGFzIHByb3Bvc2VkIHN0YW5kYXJk IHRvIElFU0cNCg0KUmVjaGFydGVyIG9yIGNsb3NlIHdvcmtpbmcgZ3JvdXA= --0-880890035-1225225536=:88971 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --0-880890035-1225225536=:88971-- From multimob-bounces@ietf.org Thu Oct 30 08:02:44 2008 Return-Path: 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 CD1063A6A6A; Thu, 30 Oct 2008 08:02:44 -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 66AF93A6A3F for ; Thu, 30 Oct 2008 08:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, HTML_MESSAGE=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 hMzmHFr7qnNJ for ; Thu, 30 Oct 2008 08:02:42 -0700 (PDT) Received: from web38802.mail.mud.yahoo.com (web38802.mail.mud.yahoo.com [209.191.125.93]) by core3.amsl.com (Postfix) with SMTP id 347F33A699D for ; Thu, 30 Oct 2008 08:02:27 -0700 (PDT) Received: (qmail 60196 invoked by uid 60001); 30 Oct 2008 15:02:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=3Xi/U4kMm+/91J/HddHovD1V76jzEiDsM9nXEITR50G4aF97Lsu9yFXiOXVyo5kwmOlfIQpOLQ4rQ3m6rGlJRv7+GhVzWn6gh+HTSPMBNcDfbxxo9b2zORt9jv8IV3vKnek5FREXzoO0RKDt2lIH6Vq8uN6UWy5QXz1uzun8Ki8=; X-YMail-OSG: xbkTnCkVM1ma98whE.s.M8wUIpZmMUWk_zsI_251uroEKf1PIAhTDkf_Q5RSPhoEAA-- Received: from [206.16.17.212] by web38802.mail.mud.yahoo.com via HTTP; Thu, 30 Oct 2008 08:02:26 PDT X-Mailer: YahooMailRC/1155.11 YahooMailWebService/0.7.247.3 Date: Thu, 30 Oct 2008 08:02:26 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <103417.58006.qm@web38802.mail.mud.yahoo.com> Subject: [multimob] Presentations at the BoF 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: , Content-Type: multipart/mixed; boundary="===============1758075884==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1758075884== Content-Type: multipart/alternative; boundary="0-146221368-1225378946=:58006" --0-146221368-1225378946=:58006 Content-Type: text/plain; charset=us-ascii Dear all, Datatracker system is allowing us to post presentations as well. If you plan on requesting a slot or if you already have a slot reserved please make sure to send Brian and I your presentation. The presentations can be in txt, pdf, doc, or ppt format. Regards, Behcet --0-146221368-1225378946=:58006 Content-Type: text/html; charset=us-ascii
Dear all,
  Datatracker system is allowing us to post presentations as well. If you plan on requesting a slot or if you already have a slot reserved please make sure to send Brian and I your presentation.
  The presentations can be in txt, pdf, doc, or ppt format.

Regards,

Behcet

--0-146221368-1225378946=:58006-- --===============1758075884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1758075884==-- From multimob-bounces@ietf.org Fri Oct 31 05:51:24 2008 Return-Path: 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 C9BB33A6BDF; Fri, 31 Oct 2008 05:51:24 -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 A4A653A6BEA for ; Fri, 31 Oct 2008 05:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=2.325, 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 7662a04VVhxZ for ; Fri, 31 Oct 2008 05:51:23 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C8C703A6BDF for ; Fri, 31 Oct 2008 05:51:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9L000CBT1JYW@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 31 Oct 2008 20:51:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9L0015MT1J8I@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 31 Oct 2008 20:51:19 +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 <0K9L006LST1GT3@szxml03-in.huawei.com> for multimob@ietf.org; Fri, 31 Oct 2008 20:51:19 +0800 (CST) Date: Fri, 31 Oct 2008 20:51:16 +0800 From: "John.zhao" To: multimob@ietf.org Message-id: <016b01c93b57$5ced7830$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: Ack7VwF+XN3CDlTGTrii8XJvLVZ2lwAABJaw Subject: [multimob] FW: I-D Submitter Authentication for draft-zhao-multimob-pmip6-solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: john.zhao@huawei.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi,all Following is the draft for pmipv6-based mobility multicast, welcome comments or correct if something is not right. Best Rgds, Thanks, john.zhao > draft-zhao-multimob-pmip6-solution > > Please follow the link below to complete your I-D submission. > > https://datatracker.ietf.org/idst/auto_post.cgi?auth_key=ikQAu > RlrfmZTNLMnFcGGQZBP7JsyCYMZ&submission_id=10344 > > Please note that if you do not follow the link above by > 2008-11-03, then this submission will be canceled and your > Internet-Draft will be permanently removed from the staging area. > > The IETF Secretariat. > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 31 18:49:14 2008 Return-Path: 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 ; 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 ; 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 ; Fri, 31 Oct 2008 18:49:10 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so728558nfh.39 for ; 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, 1 Nov 2008 09:49:07 +0800 From: "Hui Deng" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1475112873==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1475112873== Content-Type: multipart/alternative; boundary="----=_Part_49580_227199.1225504147590" ------=_Part_49580_227199.1225504147590 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > 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 > > ------=_Part_49580_227199.1225504147590 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgSm9obiw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5Tb3JyeSBmb3IgbXkg bGF0ZSByZXBseSwgaGVyZSB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCB3ZSB3b3VsZCBiZXR0ZXIg aW5jbHVkZSBuZXR3b3JrIHByZWNvbmZpZ3VyZWQgbXVsdGljYXN0IHNlcnZpY2Ugd2hpY2ggbmVl ZCBpbmZyYXN0cnVjdXRyZSBzdXBwb3J0Ljxicj48L2Rpdj4KPGRpdj5XaGF0IEkgY291bGQgcmVt aW5kIGlzIHRoYXQgbm9ybWFsbHkgc3VjaCBraW5kIG9mIHNlcnZpY2Ugd2lsbCBiZSBwcm92aWRl ZCBieSZuYnNwO01CTVMsJm5ic3A7QkNNQ1MsIGVzcGVjaWFsbHkgbW9iaWxlIFRWIHNlcnZpY2Ug dGhleSBhbHNvIGNvdWxkIGJlIGJhc2VkIG9uIGRlZGljYXRlZCBUViBtZWNoYW5pc20gbGlrZSBD TU1CLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PnRoYW5rcyBmb3IgeW91ciBkaXNjdXNz aW9uLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pi1IdWk8YnI+PC9kaXY+CjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4yMDA4LzEwLzI0IEpvaG4uemhhbyA8c3BhbiBkaXI9Imx0ciI+Jmx0 OzxhIGhyZWY9Im1haWx0bzpqb2huLnpoYW9AaHVhd2VpLmNvbSI+am9obi56aGFvQGh1YXdlaS5j b208L2E+Jmd0Ozwvc3Bhbj48YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVIt TEVGVDogI2NjYyAxcHggc29saWQiPgo8ZGl2Pgo8ZGl2PjxzcGFuPjxmb250IHNpemU9IjIiPkhl bGxvLEh1aSBhbmQgYWxsPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBzaXpl PSIyIj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuPiZuYnNwOyZuYnNwOyZu YnNwOyA8Zm9udCBzaXplPSIyIj5PbmUgY29tbWVudHMgb24gc2VjdGlvbiAzLjEgYWJvdXQgJnF1 b3Q7UjIgLSBUaGUgbW9iaWxlIG5vZGUgaXMgcmVzcG9uc2libGUgZm9yIGluaXRpYWxseSBzdWJz Y3JpYmluZyB0byB0aGUgbXVsdGljYXN0IGdyb3VwKHMpLiZxdW90OyAuJm5ic3A7VG8gc29tZSBu ZXR3b3JrIGNvbnRyb2wgbXVsdGljYXN0IHNlcnZpY2UsIHRoaXMgc3Vic2NyaWJ0aW9uIGluZm8g Y2FuIGJlIGdvdCBmcm9tIHBvbGljeSBzdG9yZSBvciBwcmUtY29uZmlndXJhdGlvbiBvbiBNQUcu IEkgZG9uJiMzOTt0IG9iamVjdCBNTiBjYW4mIzM5O3QgaW5pdGlhdGUgdGhlIHN1YnNjcmlidGlv bixidXQgdGhlIHN1YnNjcmlidGlvbiBpcyBubyBuZWVkIHJlbHkgb24gdGhlIHJlcXVlc3QgY29t ZSBmcm9tIE1OIG9ubHkuJm5ic3A7V2l0aCBvbmx5IE1OIGluaXRpYXRlZCZuYnNwO3N1YnNjcmlw dGlvbiBvZiBtdWx0aWNhc3QgZ3JvdXAocyksdGhlIG9wZXJhdG9yJiMzOTtzIG5ldHdvcmsgd2ls bDo8L2ZvbnQ+PC9zcGFuPjwvZGl2PgoKPGRpdj48c3Bhbj48L3NwYW4+PHNwYW4+PGZvbnQgc2l6 ZT0iMiI+Jm5ic3A7MS4xKU5vIG5ldHdvcmsgb3JpZ2luYXRlZCBzZXJ2aWNlIHN1cHBvcnQuIEFs bCBvZiBhbnkga2luZCBvZiBtdWx0aWNhc3Qgc2VydmljZSB3aWxsIGJlIGluaXRpYXRlZCBmcm9t IE1OLkJ1dCBpbiBmYWN0LCB0aGVyZSBhcmUgc3RpbGwgc29tZSB0eXBpY2FsIHNlcnZpY2Ugc2hv dWxkIGJlIG1hbmFnZWQgZnJvbSBuZXR3b3JrIHNpZGUuRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBv ZiB0aGUgTU4gaXQgaXMgbGlrZSBhIFRWIGJyb2FkY2FzdCBtb2RlbC4gSXQgaXMgd29ydGggdG8g aGFuZGxlIHRoaXMgY2FzZSB0b28gYmVjYXVzZSBpdCBtYXkgY29ycmVzcG9uZHMgdG8gRFZCLUgg bW9iaWxlIFRWIHNlcnZpY2UgdXNlLWNhc2UuPGJyPgombmJzcDsxLjIpQ29zdCBhZGRpdGlvbmFs IHdpcmVsZXNzIHJlc291cmNlIGluIHdpcmVsZXNzIHNpdHVhdGlvbi4gV2l0aG91dCBpdCAsIHdl IGNhbiBzYXZlIG1vcmUgcmVzb3VyY2Ugbm90IG9ubHkgZHVyaW5nIGhhbmRvdmVyIGJ1dCBhbHNv IGluIG5ldHdvcmsgZW50cnkgcHJvZ3Jlc3MuIEVzcGljYWxseSwgaXQgaXMgdXNlZnVsIHRvIHRo b3NlIHN0YXRpYyBtdWx0aWNhc3QgdHJlZSBzY2VuYXJpby48YnI+CiZuYnNwOyZuYnNwOyZuYnNw OyBGcm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUsIHRoZSBzdXBwb3J0IG9mIG5ldHdv cmsgbWFuYWdlbWVudCBpcyB0aGUgYmFzZSBvZiBNTiBtYW5hZ2VtZW50LiBTaW5jZSBvdGhlciBz aWduYWwgZmxvdyB3aWxsIGJlIHRoZSBzYW1lIGV4Y2VwdCBNQUcgbmVlZCBoYXZlIHRoZSBhYmls aXR5IHRvIGRlYWwgd2l0aCBhZGRpdGlvbmFsIE1MRCByZXBvcnQgc2VudCBmcm9tIE1OLlNvIGl0 IGlzIG5vIG1vcmUgYWRkaXRpb25hbCBjb3N0IG9uIGN1cnJlbnQgZGVzaWduIGJ1dCBicmluZyBh IGJldHRlciBzY2FiaWxpdHkuPC9mb250Pjwvc3Bhbj48L2Rpdj4KPHNwYW4+CjxkaXY+PGJyPjxm b250IHNpemU9IjIiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiBkZXRhaWwsIHRoZSBwcm9ncmVzcyBv ZiB0aGUgbWFuYWdlbWVudCBvZiBtdWx0aWNhc3Qgc2VydmljZSBieSBuZXR3b3JrIGp1c3QgbGlr ZSB0aGUgZm9sbG93aW5nOjxicj4mbmJzcDtXaGVuIHRoZSBNTiBqdXN0IGF0dGFjaHMgdG8gYSBN QUcsIHRoZSBNQUcgd2lsbCBnZXQgdGhlIE1OJiMzOTtzIHByb2ZpbGUgYW5kIHdpbGwga25vdyBz b21lIHByZS1jb25maWd1cmVkIG11bHRpY2FzdCBzZXJ2aWNlcyBuZWVkIHRvIGJlIGVzdGFibGlz aGVkLCB0aGVuIGl0IHdpbGwgYXNrIExNQSB0byBwcm92aWRlIHRoZSByZXNwZWN0aXZlIHNlcnZp Y2UsIGluIHRoaXMgY2FzZSwgdGhlIG1ldGhvZCB1c2VkIHRvIGNvbW11bmljYXRlIHRvIExNQSBm cm9tIE1BRyBjYW4gYmUgZWl0aGVyIFBNSVAgc2lnbmFscyBvciBNTEQgcmVwb3J0KGpvaW4pIG1l c3NhZ2VzIGV0Yy4gTE1BIHdpbGwgY2hlY2sgYWJvdXQgdGhpcyByZXF1ZXN0IGFuZCBkbyB0aGUg ZGVjaXNpb24gYmFzZWQgb24gaXQmIzM5O3MgYWNrbm93bGVkZ2VzIGFib3V0IGl0Ljxicj4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IER1cmluZyBoYW5kb3ZlciwgaXQgd2lsbCBiZSB2ZXJ5IGxp a2UgY3VycmVudCBkZXNpZ24uIFRoZSBDWFQgaXMgZXhwZWN0IHRvIHByb3ZpZGUgbmVjZXNzYXJ5 IG11bHRpY2FzdCBpbmZvbWF0aW9uIGFuZCBpZiBuZWVkLCBhIDMtcmQgcGFydHkgcG9saWN5IHN0 b3JlIGlzIHJlcXVpcmVkLiA8L2ZvbnQ+PC9kaXY+CjxkaXY+PGZvbnQgc2l6ZT0iMiI+PC9mb250 PiZuYnNwOzwvZGl2Pgo8ZGl2PjwvZGl2Pjwvc3Bhbj48c3Bhbj48Zm9udCBzaXplPSIyIj4mbmJz cDsmbmJzcDsmbmJzcDsgT24gc3VtbWFyeSwgY29uc2lkZXJpbmcgYW5kIGFsbG93aW5nIG5ldHdv cmsgYWRtaW5pc3RyYXRpdmx5IHN1YnNjcmlwdGlvbiBkaWRuJiMzOTt0IGltcGFjdCBvbiBhbnl0 aGluZyBjdXJyZW50IHdlIGhhdmUgY29uc2lkZXJlZCBhbmQgaW4gYWRkaXRpb24gLCBpdCBjYW4g YnJpbmcgYSBzY2FsYWJpbGl0eSB0byBjdXJyZW50IHJlcXVpcmVtZW50IG9mIHByb3h5IG11bHRp Y2FzdCBtb2JpbGl0eS48L2ZvbnQ+PC9zcGFuPjwvZGl2PgoKPGRpdj48c3Bhbj48Zm9udCBzaXpl PSIyIj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuPiZuYnNwOyZuYnNwOyZu YnNwOyA8Zm9udCBzaXplPSIyIj5CZXN0IFJnZHMsPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdj48 c3Bhbj48Zm9udCBzaXplPSIyIj5UaGFua3MsPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdj48Zm9u dCBzaXplPSIyIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+PGZvbnQgY29sb3I9IiM4ODg4ODgiPgo8cD48 L3A+CjxwPjwvcD48Zm9udCBmYWNlPSK7qs7Ez7i62iIgc2l6ZT0iMiI+am9obi56aGFvPGJyPjwv Zm9udD4KPGRpdj48Zm9udCBzaXplPSIyIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+PC9mb250PjwvYmxv Y2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_49580_227199.1225504147590-- --===============1475112873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1475112873==-- From multimob-bounces@ietf.org Fri Oct 31 20:08:20 2008 Return-Path: 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 E19803A6805; Fri, 31 Oct 2008 20:08:20 -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 1E89D3A6805 for ; Fri, 31 Oct 2008 20:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599, HTML_MESSAGE=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 L-+s9CEmc2Yc for ; Fri, 31 Oct 2008 20:08:18 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 30C313A67AD for ; Fri, 31 Oct 2008 20:08:17 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so733733nfh.39 for ; Fri, 31 Oct 2008 20:08:15 -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=adGgi+QUAY4OxLGM+FUS0w4oNHAdJfD4I/NFRrrkKLI=; b=cLtgCb/kIsejveYCLHaui7Ds6KRcwu/hungOXL/IMDeMCh1cyhQ3eZKT1oI+Yxvikd 0py0Zz0RhJ6jb9GpIcLDHGWCqqxk8M/3EFVMZE8/8lsm3+8uEj9oC9kPExiI1mvJbQcx ugtvtgtIj0jwcNKQv9NEBh24SeWuNCm88bQCU= 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=QLhCF0+1+SgTHVespoKR4tGFGIYiJWfqti5xfIVm7JncwGHBpmV7YKHN6dK5NXq25M 3ssTecC2TBaAh8ugFCX64QuT19iN2KRlCGDDj6dCoaEBjSveXNFxopVUjreJ79AQT5RQ y5QD1AvQx0ue/01x7305ORpyKtXG2ZMxCUUl4= Received: by 10.210.89.4 with SMTP id m4mr9843943ebb.107.1225508895024; Fri, 31 Oct 2008 20:08:15 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Fri, 31 Oct 2008 20:08:14 -0700 (PDT) Message-ID: <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com> Date: Sat, 1 Nov 2008 11:08:14 +0800 From: "Hui Deng" To: "Thomas C. Schmidt" In-Reply-To: <4900E5A0.9050306@informatik.haw-hamburg.de> MIME-Version: 1.0 References: <352065.68132.qm@web38808.mail.mud.yahoo.com> <4900E5A0.9050306@informatik.haw-hamburg.de> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0569847639==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0569847639== Content-Type: multipart/alternative; boundary="----=_Part_49863_33243204.1225508895003" ------=_Part_49863_33243204.1225508895003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Thomas, I agree this scenario works for some deployment, but question here is whether we need extend any pmip6 protocol to support this scenario? thanks -Hui 2008/10/24 Thomas C. Schmidt > Hi Behcet, > > Behcet Sarikaya wrote: > > [thomas] RFC5213 does not address multicast routing (that's why we are >> discussing it). The scenario described in fig 2 is *not* addressing >> mobile multicast senders, >> >> [behcet] Then I think the text and figure on the local routing is not >> needed because local routing in PMIPv6 refers to the routing of packets >> coming from the uplink and as you said this would be multicast sender >> situation which you left out in the requirements draft. >> >> > [thomas] This is a misunderstanding: Fig 2 does *not* refer to sender > mobility. > > but a typical content distribution setting as >> for instance used in a provider-centric IPTV service. This means, a >> provider issues multicast streams from within his network domain, aiming >> at an efficient way to preserve (his own) network resources. >> >> From the minimal perspective of RFC5213 (unicast routing) there is no >> efficient way to do this. That's why we are trying to identify protocol >> extensions that smoothly cooperate with RFC 5213. >> >> [behcet] The situation you are talking about could become valid if route >> optimization is used with PMIPv6. In that case the content server in bet= ween >> MAG and LMA would send directly to MAG. If route optimization is not use= d >> then all traffic goes through LMA-MAG tunnel. Route optimization for PMI= Pv6 >> is some future work, there are drafts but we don't know if the >> standardization will go ahead. >> Route optimization with multicasting is even more complicated problem. I= f >> you wish to state some requirements for this very complicated case pleas= e go >> ahead. >> > > [thomas] Hmm, I'm not trying to add complicated requirements. This is the > overview about possible scenarios. > We're all just trying to think of a reasonable scope to address and solv= e > the problem (so does the recent pmip6-extension-draft ... see also the la= st > mail from Hitoshi). > > If multicast on PMIPv6 is supposed to serve as a solution for large-scale > content distribution (like in IPTV applications), then we should not just > propose to tunnel all traffic from one LMA to the MAGs. That's a bitter p= ill > for those who have to pay for the infrastructure. > > > Best regards, > > Thomas > > -- > > =B0 Prof. Dr. Thomas C. Schmidt > =B0 HAW Hamburg, Dept. Informatik > =B0 University of Applied Sciences > =B0 Berliner Tor 7, D 20099 Hamburg, Germany > =B0 Fon: +49-40-42875-8452, Fax: -8409 > =B0 http://www.informatik.haw-hamburg.de/~schmidt > ------=_Part_49863_33243204.1225508895003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,  Thomas,
 
I agree this scenario works for some deployment, but question here is = whether we need extend any pmip6 protocol to support this scenario?
 
thanks
 
-Hui

2008/10/24 Thomas C. Schmidt &= lt;schmidt@informatik.= haw-hamburg.de>
Hi Behcet,

Behcet Sarikaya wrote:

[thomas] RFC5213 does not addres= s multicast routing (that's why we are
discussing it). The scenario = described in fig 2 is *not* addressing
mobile multicast senders,

[behcet] Then I think the text and figure = on the local routing is not needed because local routing in PMIPv6 refers t= o the routing of packets coming from the uplink and as you said this would = be multicast sender situation which you left out in the requirements draft.=


[thomas] This is a misunderstanding: Fig 2 does = *not* refer to sender mobility.=20


but a typical content distributi= on setting as
for instance used in a provider-centric IPTV service. This= means, a
provider issues multicast streams from within his network domain, aimingat an efficient way to preserve (his own) network resources.

 = >From the minimal perspective of RFC5213 (unicast routing) there is no
ef= ficient way to do this. That's why we are trying to identify protocol extensions that smoothly cooperate with RFC 5213.

[behcet] The situa= tion you are talking about could become valid if route optimization is used= with PMIPv6. In that case the content server in between MAG and LMA would = send directly to MAG. If route optimization is not used then all traffic go= es through LMA-MAG tunnel. Route optimization for PMIPv6 is some future wor= k, there are drafts but we don't know if the standardization will go ah= ead.
Route optimization with multicasting is even more complicated problem. If y= ou wish to state some requirements for this very complicated case please go= ahead.

[thomas] Hmm, I'm not trying to add c= omplicated requirements. This is the overview about possible scenarios.
 We're all just trying to think of a reasonable scope to address a= nd solve the problem (so does the recent pmip6-extension-draft ... see also= the last mail from Hitoshi).

If multicast on PMIPv6 is supposed to = serve as a solution for large-scale content distribution (like in IPTV appl= ications), then we should not just propose to tunnel all traffic from one L= MA to the MAGs. That's a bitter pill for those who have to pay for the = infrastructure.=20


Best regards,

Thomas

--
=B0 Prof. Dr. Thomas C. Schmidt
=B0 HAW Hamburg, Dept. Informatik
= =B0 University of Applied Sciences
=B0 Berliner Tor 7, D 20099 Hamburg, = Germany
=B0 Fon: +49-40-42875-8452, Fax: -8409
=B0 http://www.informatik.haw-ha= mburg.de/~schmidt

------=_Part_49863_33243204.1225508895003-- --===============0569847639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0569847639==-- From multimob-bounces@ietf.org Fri Oct 31 22:31:43 2008 Return-Path: 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 2377A3A6A5D; Fri, 31 Oct 2008 22:31:43 -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 460903A6A5D for ; Fri, 31 Oct 2008 22:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.619 X-Spam-Level: *** X-Spam-Status: No, score=3.619 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] 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 7iNlINoNTqXI for ; Fri, 31 Oct 2008 22:31:41 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 5C02A3A6892 for ; Fri, 31 Oct 2008 22:31:40 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id B3C2313D03D6; Sat, 1 Nov 2008 14:09:09 +0900 (JST) Date: Sat, 01 Nov 2008 14:31:37 +0900 (JST) Message-Id: <20081101.143137.247155156.asaeda@sfc.wide.ad.jp> To: denghui02@gmail.com From: Hitoshi Asaeda In-Reply-To: <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com> References: <352065.68132.qm@web38808.mail.mud.yahoo.com> <4900E5A0.9050306@informatik.haw-hamburg.de> <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi, > I agree this scenario works for some deployment, but question here is > whether we need extend any pmip6 protocol to support this scenario? The protocol extension should be as simple as possible. And if the base protocols such as PMIPv6/MLD/PIM do not support the functions we have been discussing, then we should carefully identify the issues. The key for identifying the issues is to recognize not only the effectiveness of the protocol extension but also the generality and independency of multicast services. I mean, the protocol extension must be generally applicable and beneficial in a common mobile multicast communication scenario, not only for some special cases/ services. So, I'd like to again ask the question especially to operators who plan to or may prepare PMIPv6 multicast services; Is there a big impact or problem if all multicast traffic goes through an LMA-MAG tunnel? Note that our PMIPv6 multicast extension draft tentatively supports the local routing, but I personally think it can be removed if consensus. Regards, -- Hitoshi Asaeda > >> [behcet] The situation you are talking about could become valid if route > >> optimization is used with PMIPv6. In that case the content server in between > >> MAG and LMA would send directly to MAG. If route optimization is not used > >> then all traffic goes through LMA-MAG tunnel. Route optimization for PMIPv6 > >> is some future work, there are drafts but we don't know if the > >> standardization will go ahead. > >> Route optimization with multicasting is even more complicated problem. If > >> you wish to state some requirements for this very complicated case please go > >> ahead. > >> > > > > [thomas] Hmm, I'm not trying to add complicated requirements. This is the > > overview about possible scenarios. > > We're all just trying to think of a reasonable scope to address and solve > > the problem (so does the recent pmip6-extension-draft ... see also the last > > mail from Hitoshi). > > > > If multicast on PMIPv6 is supposed to serve as a solution for large-scale > > content distribution (like in IPTV applications), then we should not just > > propose to tunnel all traffic from one LMA to the MAGs. That's a bitter pill > > for those who have to pay for the infrastructure. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Fri Oct 31 22:41:11 2008 Return-Path: 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 5B0A73A6902; Fri, 31 Oct 2008 22:41:11 -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 A08053A684E for ; Fri, 31 Oct 2008 22:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.016 X-Spam-Level: *** X-Spam-Status: No, score=3.016 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] 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 I25gLpmjM0f3 for ; Fri, 31 Oct 2008 22:41:08 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 4E4333A6B8A for ; Fri, 31 Oct 2008 22:41:07 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id CD73D13D03D6 for ; Sat, 1 Nov 2008 14:18:37 +0900 (JST) Date: Sat, 01 Nov 2008 14:41:05 +0900 (JST) Message-Id: <20081101.144105.134221856.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20081101.143137.247155156.asaeda@sfc.wide.ad.jp> References: <4900E5A0.9050306@informatik.haw-hamburg.de> <1d38a3350810312008x377ea91aw2739355335d2a207@mail.gmail.com> <20081101.143137.247155156.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org > So, I'd like to again ask the question especially to operators who > plan to or may prepare PMIPv6 multicast services; Is there a big > impact or problem if all multicast traffic goes through an LMA-MAG > tunnel? > > Note that our PMIPv6 multicast extension draft tentatively supports > the local routing, but I personally think it can be removed if > consensus. Well, it may not be necessary to completely remove the possibility from the document, but specify "optional" as the minor case. Same for the requirement draft. -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob