From luisc@it.uc3m.es Sat Jul 3 03:17:28 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA18E3A6828 for ; Sat, 3 Jul 2010 03:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 LOitn4a58NtI for ; Sat, 3 Jul 2010 03:17:27 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 831433A67A5 for ; Sat, 3 Jul 2010 03:17:26 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 5708EBB367A; Sat, 3 Jul 2010 12:17:32 +0200 (CEST) Received: from 21.pool85-49-217.dynamic.orange.es (21.pool85-49-217.dynamic.orange.es [85.49.217.21]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Sat, 03 Jul 2010 12:17:30 +0200 Message-ID: <20100703121730.rliu6tb400wcww4o@webcartero01.uc3m.es> Date: Sat, 03 Jul 2010 12:17:30 +0200 From: "Luis M. Contreras" To: Hitoshi Asaeda References: <20100630150951.7kh4n8dw0ckgggs0@webcartero01.uc3m.es> <20100701.123505.142878551.asaeda@sfc.wide.ad.jp> In-Reply-To: <20100701.123505.142878551.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17482.006 Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification for draft-contreras-multimob-rams-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 10:17:28 -0000 Hi Hitoshi, thank you very much for pointing me out your draft. However, I'm afraid we are dealing with very distinct topics. I think I have not been very lucky choosing the wording for my draft, and this can drive to some confussion, but it has been accidental. In summary, my draft is focused on speeding-up the MAG acquisition of the IP addresses (S,G) of the multicast content being received by the MN before a handover event. This is quite different from the RAMS aim in AVT group. Sorry for the possible confussion, and thank you very much for your link. Best regards. Luis Hitoshi Asaeda dijo: > Hi Luis, > >> a new draft proposing a PMIPv6 protocol extension for rapid >> acquisition of the MN multicast subscription after handover has been >> submitted as contribution for Multimob working group. >> >> The draft can be found following this link: >> http://www.ietf.org/id/draft-contreras-multimob-rams-00.txt > > I've not looked at this draft, but just FYI. > > The following draft may be relevant to your draft. > > http://tools.ietf.org/html/draft-xia-avt-proxy-rapid-acquisition-01 > > Mutual reference may achieve the goal. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Luis M. Contreras Profesor Asociado Dpto. de Ingenier=EDa Telem=E1tica Universidad Carlos III de Madrid ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From behcetsarikaya@yahoo.com Sun Jul 4 14:47:12 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590D13A67B1 for ; Sun, 4 Jul 2010 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 9ch-G+Fxkhxq for ; Sun, 4 Jul 2010 14:47:11 -0700 (PDT) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id 85AB43A6403 for ; Sun, 4 Jul 2010 14:47:11 -0700 (PDT) Received: (qmail 12577 invoked by uid 60001); 4 Jul 2010 21:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1278280029; bh=zpcO6FevGQ17aYyxIgCqP53yRLBh2yWQ3IKQwOiBx4M=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YVykjTXuCXHOzLkJ98uDhIXW7zxI0MSxrK6IyvBqGC41n7W7SpSR0OLbEj1dk1x51gwha4BHZumL8TxjaW7RbX8KRq8A0sf0w7L3/wEIDF8ik7A+8CbHDK0TgiIpVhSeYCXroyofrJsQd7m9U/yadZC/GKdjYQB+Ep/+KerrzPk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LTTNMFWqd6A+ScGpSZg3d0kZ5be+ed4YDdV6RB/Ncbc8VRi3kRcK3zm9qFFixrrNmAj5DD17ce9axbZyuRHy0DGYqtE8lbt2WLmZOj8oPy/wWj14iAIst+85LbJl4hDBOPSCO7qKstqBlU2gS7AnUEsoYIhYrScdcYqDI5bHC8M=; Message-ID: <300733.12510.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: gmwNNwUVM1m8cCEfI12bfq1KUlcWPw0cJrVlz8rg1Ka4p7L Ib.lugYTlYqQlsKLhi9tCOpXIWbgitOk6OdXo.yz6KVNrEfs1FBgKJvi35Ce iwp7tN_6UDkcowhH4mY3L3A2meO9OGWhuvaZWD17Y2FYCRUURicPzEnKtaKy MCChGl232LVDv_eODVTCWrPm5tAYR5HNqaHttS5qOejsxXA4_B_T_PY_WG73 cv8XE2jc_F_rI5KgchIb.Hy3V6FJOiHiHCl_mt_xlvHNnDGyXcr_5wKB115J DAGXgMFmSohV2SGDHm_9M2MIqMZrhVvtbwv6yzb3n.x1dhULCks6QP3aVZ5C c2GoCq2GkiW47 Received: from [72.64.108.212] by web111401.mail.gq1.yahoo.com via HTTP; Sun, 04 Jul 2010 14:47:09 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <95096.87617.qm@web111414.mail.gq1.yahoo.com> Date: Sun, 4 Jul 2010 14:47:09 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org, Jari Arkko In-Reply-To: <95096.87617.qm@web111414.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] 2nd WGLC for draft-ietf-multimob-pmipv6-base-solution 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: , X-List-Received-Date: Sun, 04 Jul 2010 21:47:12 -0000 Folks,=0A The authors of draft-ietf-multimob-pmipv6-base-solution will tak= e care of both Jari's comments and any others arising from this 2nd WGLC no= t Carlos.=0A=0A Sorry for the confusion and thank you all for your attenti= on and thanks again Carlos for availing yourself to serve Multimob!.=0A=0AR= egards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: Behcet= Sarikaya =0A> To: multimob@ietf.org=0A> Sent: We= d, June 23, 2010 2:57:23 PM=0A> Subject: [multimob] 2nd WGLC for draft-ietf= -multimob-pmipv6-base-solution=0A> =0A> Hi all,=0A This mail starts a 2nd = WGLC on our PMIPv6 Base Solution draft. This =0A> call will end on June 29.= =0A We asked Carlos to be an editor and he =0A> gracefully agreed. Thanks= Carlos!=0A Please post your comments on the list or =0A> use the issue tr= acker as follows:=0A1. To submit an issue in TRAC, you =0A> first nee= d to login to the Multimob WG site on the tools server: =0A> http://tools.= ietf.org/wg/multimob/trac/login =0A=0A2. If you don=E2=80=99t =0A> al= ready have a login ID, you can obtain one by navigating to this site: =0A= > http://trac.tools.ietf.org/newlogin=0A=0A3. Once you have obtained = an =0A> account, and have logged in, you can file an issue by navigating to= the ticket =0A> entry form: =0A> http://trac.tools.ietf.org/wg/multimob/t= rac/newticket=0A=0AThanks,=0A=0AChairs=0A=0A=0A =0A> =0A______________= _________________________________=0Amultimob =0A> mailing list=0A=0A> href= =3D"mailto:multimob@ietf.org">multimob@ietf.org=0A=0A> href=3D"https://www.= ietf.org/mailman/listinfo/multimob" target=3D_blank =0A> >https://www.ietf.= org/mailman/listinfo/multimob=0A=0A=0A From jari.arkko@piuha.net Mon Jul 5 00:31:38 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9F33A68E0 for ; Mon, 5 Jul 2010 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.73 X-Spam-Level: X-Spam-Status: No, score=0.73 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_50=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 cM8Gkkuzl0n8 for ; Mon, 5 Jul 2010 00:31:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 873AA3A68D0 for ; Mon, 5 Jul 2010 00:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4ED842CED3; Mon, 5 Jul 2010 10:31:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLLb8IXdWn4a; Mon, 5 Jul 2010 10:31:32 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 98FF42CC62; Mon, 5 Jul 2010 10:31:31 +0300 (EEST) Message-ID: <4C318A52.1000103@piuha.net> Date: Mon, 05 Jul 2010 10:31:30 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4C232AF3.7030707@piuha.net> <4C2333B9.5090405@informatik.haw-hamburg.de> In-Reply-To: <4C2333B9.5090405@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 07:31:38 -0000 Thomas, >>> With these entities in place, the mobile node loses transparent >>> end- >>> to-end connectivity to the static Internet, and in the particular >>> case of multicast communication, group membership management as >>> signaled by the Multicast Listener Discovery protocol (MLD) >>> [RFC3810 ], [RFC2710 >>> ] requires dedicated treatment >>> at the network >>> side, see [I-D.deng-multimob-pmip6-requirement >>> ]. >>> >>> >> >> The loss of transparenet e2e connectivity is a strong claim. What basis >> is there for making this statement? Its not like there is a NAT on the >> path, or if the mobile node would be prevented from sending some >> packets. I do agree though that group membership management requires >> care. Also, perhaps the reference to the draft can be moved to an >> acknowledgment section as prior work, since you do describe the issues >> yourself later in the document. >> > > The "loss of transparent e2e connectivity"-argument is referring to > the setup that the MAG (tunnel entry) introduces a routing hop in > situations, were the LMA architecturally acts as the next hop (or > designated) router for the MN. This plays the particular role > mentioned in MLD signaling (but may be relevant in other situations). > > Suggestion for clarification/improvement: > > "With these entities in place, the mobile node loses transparent end- > to-end connectivity to the static Internet in the sense that the MAG > introduces a routing hop also in situations, were the LMA > architecturally acts > as the next hop (or designated) router for the MN. In the particular > case of multicast communication, group membership ... " OK (Though I must say that if I was writing this, I would probably just talk about the actual effect and leave the term transparent end-to-end connectivity out.) > As for the draft reference: This was only to indicate that some > requirements-work has been done. We will move it to the acknowledgment. OK > >> >>> It therefore needs to >>> implement an instance of the MLD proxy function [RFC4605 >>> ] for each >>> upstream tunnel interface that has been established with an LMA. >>> >>> >>> 4.4. IPv4 Support >>> >> >> Question: Are there any special things that you have to take care of for >> overlapping IPv4 address space situations and GRE-keyed tunnels? >> > > Good point: we will have to think about this and will be back on the > question later. > > >>> >>> 7. A Note on Explicit Tracking >>> >>> >>> >>> IGMPv3/MLDv2 [RFC3376 ], >>> [RFC3810 ] may operate in >>> combination with >>> explicit tracking, which allows routers to monitor each multicast >>> receiver. This mechanism is not standardized yet, but widely >>> implemented by vendors as it supports faster leave latencies and >>> reduced signaling. >>> >>> Enabling explicit tracking on downstream interfaces of the LMA and >>> MAG would track a single MAG and MN respectively per interface. It >>> may be used to preserve bandwidth on the MAG-MN link. >>> >> >> This does not tell me what explicit tracking is. Is there any reference >> that could be used here? If there is no clear description of the what >> explicit tracking is, perhaps this part should not be in the document. >> > > Explicit tracking is discussed in "A.2. Host Suppression" of RFC 3810 > (MLDv2). However, it is not a standardized procedure and I agree that > the term is somewhat colloquial. We will review the exact wording and > propose a more concise formulation in the following mail. > > The technique of explicit multicast state tracking at routers > facilitates a fast reaction of routers on state changes (without > querying), which is useful (not only) in mobile regimes and actually > used a lot in deployed systems. This is why we felt it is important to > mention. OK, but then make this draft have some pointer for further information. >>> At the MAG, MLD queries and multicast data will arrive on the >>> (tunnel) interface that is assigned to a group of access links as >>> identified by its Binding Update List (cf.,section 6 of >>> [RFC5213] ). >>> >> Does this specification handle the case of multicast traffic originating >> from the mobile host? If not, please state so. > > No, it doesn't according to the current Multimob charter. We will add > the straight-forward statement in the abstract and the introduction. OK Jari From luisc@it.uc3m.es Mon Jul 5 12:14:35 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF6C3A69F3 for ; Mon, 5 Jul 2010 12:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] 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 Hah5ofvLI0eY for ; Mon, 5 Jul 2010 12:14:34 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2CE4D3A67F0 for ; Mon, 5 Jul 2010 12:14:33 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id BB614836F28 for ; Mon, 5 Jul 2010 21:14:34 +0200 (CEST) Received: from 21.pool85-49-217.dynamic.orange.es (21.pool85-49-217.dynamic.orange.es [85.49.217.21]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 05 Jul 2010 21:14:32 +0200 Message-ID: <20100705211432.jqpmighy0gskkocs@webcartero01.uc3m.es> Date: Mon, 05 Jul 2010 21:14:32 +0200 From: "Luis M. Contreras" To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17488.000 Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 19:14:35 -0000 Dear chairs, we would like to request one slot for presenting our last I-D entitled "Rapid acquisition of the MN multicast subscription after handover". Carlos J. Bernardos would present some slides on this at Maastricht IETF meeting. Thanks in advance, Regards, Luis From JuanCarlos.Zuniga@InterDigital.com Mon Jul 5 14:04:26 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DCA28C0F2 for ; Mon, 5 Jul 2010 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 f2igg7XyM23m for ; Mon, 5 Jul 2010 14:04:25 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id B76FB28C0F0 for ; Mon, 5 Jul 2010 14:04:25 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 17:04:26 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 17:04:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jul 2010 17:04:25 -0400 Message-ID: In-Reply-To: <20100705211432.jqpmighy0gskkocs@webcartero01.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Request for agenda items Thread-Index: AcscdlIYH0d2r8mzRR65q2zCv5oG1QADw3kA References: <20100705211432.jqpmighy0gskkocs@webcartero01.uc3m.es> From: "Zuniga, Juan Carlos" To: X-OriginalArrivalTime: 05 Jul 2010 21:04:26.0676 (UTC) FILETIME=[A6E9CF40:01CB1C85] Subject: Re: [multimob] Request for agenda items X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 21:04:26 -0000 Behcet, Stig, We would also like to request a slot at the IETF78 to present an update to our draft for enhancing multicast operation using the Dedicated Multicast LMA approach. =20 Best regards, Juan Carlos and Akbar > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Luis M. Contreras > Sent: Monday, July 05, 2010 3:15 PM > To: multimob@ietf.org > Subject: Re: [multimob] Request for agenda items >=20 > Dear chairs, >=20 > we would like to request one slot for presenting our last I-D entitled > "Rapid acquisition of the MN multicast subscription after handover". >=20 > Carlos J. Bernardos would present some slides on this at Maastricht > IETF meeting. >=20 > Thanks in advance, >=20 > Regards, >=20 > Luis >=20 >=20 >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Thu Jul 8 01:06:13 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAA13A6842 for ; Thu, 8 Jul 2010 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 DHrRsNNiOnbS for ; Thu, 8 Jul 2010 01:06:12 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B0C193A6862 for ; Thu, 8 Jul 2010 01:06:12 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231225073.adsl.alicedsl.de ([92.231.225.73] helo=[192.168.178.121]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWm7b-000LJf-4u; Thu, 08 Jul 2010 10:06:15 +0200 Message-ID: <4C3586F0.6070902@informatik.haw-hamburg.de> Date: Thu, 08 Jul 2010 10:06:08 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko References: <4C232AF3.7030707@piuha.net> <4C2333B9.5090405@informatik.haw-hamburg.de> <4C318A52.1000103@piuha.net> In-Reply-To: <4C318A52.1000103@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 08:06:13 -0000 Hi Jari, many thanks for the feedback. On 05.07.2010 09:31, Jari Arkko wrote: >>> >>> The loss of transparenet e2e connectivity is a strong claim. What basis >>> is there for making this statement? Its not like there is a NAT on the >>> path, or if the mobile node would be prevented from sending some >>> packets. I do agree though that group membership management requires >>> care. Also, perhaps the reference to the draft can be moved to an >>> acknowledgment section as prior work, since you do describe the issues >>> yourself later in the document. >>> >> >> The "loss of transparent e2e connectivity"-argument is referring to >> the setup that the MAG (tunnel entry) introduces a routing hop in >> situations, were the LMA architecturally acts as the next hop (or >> designated) router for the MN. This plays the particular role >> mentioned in MLD signaling (but may be relevant in other situations). >> >> Suggestion for clarification/improvement: >> >> "With these entities in place, the mobile node loses transparent end- >> to-end connectivity to the static Internet in the sense that the MAG >> introduces a routing hop also in situations, were the LMA >> architecturally acts >> as the next hop (or designated) router for the MN. In the particular >> case of multicast communication, group membership ... " > > OK > > (Though I must say that if I was writing this, I would probably just > talk about the actual effect and leave the term transparent end-to-end > connectivity out.) > Then let's weaken the statement. How about "With these entities in place, the mobile node experiences an exceptional access topology towards the static Internet in the sense that the MAG introduces a routing hop also in situations, were the LMA architecturally acts as the next hop (or designated) router for the MN. In the particular case of multicast communication, group membership ... " Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jari.arkko@piuha.net Thu Jul 8 03:06:24 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9263A6A1C for ; Thu, 8 Jul 2010 03:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.616, 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 dIgXku60Y1IJ for ; Thu, 8 Jul 2010 03:06:23 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 686353A6A25 for ; Thu, 8 Jul 2010 03:06:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 418CB2CED7; Thu, 8 Jul 2010 13:06:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjjpEufxeiE6; Thu, 8 Jul 2010 13:06:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D93932CEB5; Thu, 8 Jul 2010 13:06:24 +0300 (EEST) Message-ID: <4C35A320.90005@piuha.net> Date: Thu, 08 Jul 2010 13:06:24 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4C232AF3.7030707@piuha.net> <4C2333B9.5090405@informatik.haw-hamburg.de> <4C318A52.1000103@piuha.net> <4C3586F0.6070902@informatik.haw-hamburg.de> In-Reply-To: <4C3586F0.6070902@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 10:06:24 -0000 Thomas, > Then let's weaken the statement. How about > > "With these entities in place, the mobile node experiences an > exceptional > access topology towards the static Internet in the sense that the MAG > introduces a routing hop also in situations, were the LMA > architecturally acts as the next hop (or designated) router for the MN. > In the particular case of multicast communication, group membership > ... " Good. Thanks. Jari From huimin.cmcc@gmail.com Thu Jul 8 19:42:27 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E0A3A6B4F for ; Thu, 8 Jul 2010 19:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 in-Xq2NM9LL9 for ; Thu, 8 Jul 2010 19:42:26 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id ED8DB3A6B43 for ; Thu, 8 Jul 2010 19:42:25 -0700 (PDT) Received: by gxk3 with SMTP id 3so1015195gxk.31 for ; Thu, 08 Jul 2010 19:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eFkQ4Fr4DHS3vZdyThfULHvOzeV7KIDINVv3qwwx5Ws=; b=I/Kyj+Qf0buFD17tMD6uuEFomrm98yoA7jOhKJyZB4120kiKVcwR9/1nu46KGTYTJk /k4M5MVGgfhkze9UXi6+rJLlGx2oHc6hhHqX7H0iOKPaKaajZXvaK/9oYrloiY/h+Bbw Di2IKiP37FdxHUFB0H50F3m1PAR2ldfXW3FTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=qd0eNNBwczsG8hrXYEo8tML0Ybx4kizTYFQ1L7TqWOas7QJgjmPSF9HpPwHLnIp/3s wlBxnyYJxrw1awOgE1tMPd6erUDsjgT1sQihniS/yWWrEZLzi7VCeG6DmAZSnaYZ8uu+ co7QYKBO0ABBSYm64AFw2m97BZMp+3PJ0BSXQ= MIME-Version: 1.0 Received: by 10.229.216.130 with SMTP id hi2mr5074105qcb.181.1278643347682; Thu, 08 Jul 2010 19:42:27 -0700 (PDT) Received: by 10.229.227.140 with HTTP; Thu, 8 Jul 2010 19:42:27 -0700 (PDT) In-Reply-To: <20100701104045.0F8DC28C124@core3.amsl.com> References: <20100701104045.0F8DC28C124@core3.amsl.com> Date: Fri, 9 Jul 2010 10:42:27 +0800 Message-ID: From: Min Hui To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] New Version Notification for draft-hui-multimob-fast-handover-02 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 02:42:27 -0000 Hi, all A new version of I-D, draft-hui-multimob-fast-handover-02.txt has been successfully submitted by Min Hui and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-hui-multimob-fast-handover Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Fast Handover for Multicast in Proxy Mobile IPv6 Creation_date: =A0 2010-07-01 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 16 Abstract: This document specifies the predictive fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Necessary extensions are specified for Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to support multicast handover procedure. The IETF Secretariat. From root@core3.amsl.com Mon Jul 12 14:45:04 2010 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 549A13A6885; Mon, 12 Jul 2010 14:45:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712214504.549A13A6885@core3.amsl.com> Date: Mon, 12 Jul 2010 14:45:04 -0700 (PDT) Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-04.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: , X-List-Received-Date: Mon, 12 Jul 2010 21:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-04.txt Pages : 20 Date : 2010-07-12 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12144032.I-D@ietf.org> --NextPart-- From schmidt@informatik.haw-hamburg.de Mon Jul 12 14:51:18 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D183A6BA4 for ; Mon, 12 Jul 2010 14:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 2ARpD+-e+TXv for ; Mon, 12 Jul 2010 14:51:17 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 484A93A6A05 for ; Mon, 12 Jul 2010 14:51:17 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178119163.adsl.alicedsl.de ([85.178.119.163] helo=[192.168.178.128]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OYQuK-000Pdm-JS for multimob@ietf.org; Mon, 12 Jul 2010 23:51:24 +0200 Message-ID: <4C3B8E59.9090500@informatik.haw-hamburg.de> Date: Mon, 12 Jul 2010 23:51:21 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 21:51:18 -0000 Hi all, we just submitted a new version of draft-ietf-multimob-pmipv6-base-solution that includes the comments and improvements of the latest reviews: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 Looking forward to your feedback, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04 Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC: schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-ietf-multimob-pmipv6-base-solution Revision: 04 Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains Creation_date: 2010-07-12 WG ID: multimob Number_of_pages: 20 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. The IETF Secretariat. From asaeda@sfc.wide.ad.jp Wed Jul 14 04:11:01 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCAE3A6914 for ; Wed, 14 Jul 2010 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.981 X-Spam-Level: **** X-Spam-Status: No, score=4.981 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, 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 3GXSs+WQlno3 for ; Wed, 14 Jul 2010 04:11:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 936B53A6774 for ; Wed, 14 Jul 2010 04:11:00 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0B094278088 for ; Wed, 14 Jul 2010 20:11:07 +0900 (JST) Date: Wed, 14 Jul 2010 20:11:06 +0900 (JST) Message-Id: <20100714.201106.67906163.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jul_14_20_11_06_2010_848)--" Content-Transfer-Encoding: 7bit Subject: [multimob] Fw: New Version Notification for draft-asaeda-multimob-igmp-mld-optimization-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 11:11:01 -0000 ----Next_Part(Wed_Jul_14_20_11_06_2010_848)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello folks, I've submitted the revised version of our IGMP/MLD tuning draft. While I'd like to improve the quality more in the further revision, this draft has better form than the previous one and includes some concrete values according to our simulation results. Please read it carefully, and give me comments. ;) Thank you, -- Hitoshi Asaeda ----Next_Part(Wed_Jul_14_20_11_06_2010_848)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Original-To: asaeda@sfc.wide.ad.jp Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.142.150]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPS id 4F523278084 for ; Tue, 13 Jul 2010 02:43:04 +0900 (JST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAIrwOkzLsolVZGdsb2JhbACDHZBWAQGMRAgYDQoGEiKuYZE9gSmDDHIEg3uEUQ X-IronPort-AV: E=Sophos;i="4.55,189,1278255600"; d="scan'208";a="9916872" Received: from sh.wide.ad.jp ([203.178.137.85]) by ironport1.sfc.wide.ad.jp with ESMTP; 13 Jul 2010 02:43:04 +0900 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.20) with ESMTP id o6CHh2ds029368 for ; Tue, 13 Jul 2010 02:43:03 +0900 (JST) Received: by core3.amsl.com (Postfix, from userid 30) id 81E1A3A6B35; Mon, 12 Jul 2010 10:42:50 -0700 (PDT) From: IETF I-D Submission Tool To: Asaeda@wide.ad.jp Cc: asaeda@wide.ad.jp, uchida@sfc.wide.ad.jp Subject: New Version Notification for draft-asaeda-multimob-igmp-mld-optimization-03 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100712174253.81E1A3A6B35@core3.amsl.com> Date: Mon, 12 Jul 2010 10:42:49 -0700 (PDT) A new version of I-D, draft-asaeda-multimob-igmp-mld-optimization-03.txt has been successfully submitted by Hitoshi Asaeda and posted to the IETF repository. Filename: draft-asaeda-multimob-igmp-mld-optimization Revision: 03 Title: Tuning the Behavior of IGMP and MLD for Mobile Hosts and Routers Creation_date: 2010-07-12 WG ID: Independent Submission Number_of_pages: 15 Abstract: IGMP and MLD are the protocols used by hosts to report their IP multicast group memberships to neighboring multicast routers. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility, mainly for a query timer tuning. The IETF Secretariat. ----Next_Part(Wed_Jul_14_20_11_06_2010_848)---- From Akbar.Rahman@InterDigital.com Wed Jul 14 07:10:40 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC7A3A6AB2 for ; Wed, 14 Jul 2010 07:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VAnYrSEmr1Qo for ; Wed, 14 Jul 2010 07:10:39 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 13F0B3A6959 for ; Wed, 14 Jul 2010 07:10:38 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 10:10:47 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 10:10:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 10:08:58 -0400 Message-ID: In-Reply-To: <4C3B8E59.9090500@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 Thread-Index: AcsiDIL9px1YFFpFSEKFO5FhZB4+xABUPSew References: <4C3B8E59.9090500@informatik.haw-hamburg.de> From: "Rahman, Akbar" To: "Thomas C. Schmidt" X-OriginalArrivalTime: 14 Jul 2010 14:10:47.0801 (UTC) FILETIME=[5B6DC690:01CB235E] Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:10:40 -0000 Hi Thomas, Overall the draft looks in very good shape. Just two final comments: - In Figure 2, suggest that you change from "Movement to MAG2 ..." to "Movement of MN2 to MAG2 ..." for improved readability. - In the last sentence of section 3, it states that "multicast traffic to one MN will always remain unique, i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN". However, if the MN is multi-homed (as per section 4.5) is it not possible that in a simply designed MN implementation that membership to the same multicast group may be made on multiple interfaces?. This can be done without breaking any protocols. So, in this multicast traffic to one MN in fact will NOT remain unique (though of course this is not a fault of the multicast distribution system). Do you agree? Sincerely, Akbar and Juan-Carlos -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt Sent: Monday, July 12, 2010 5:51 PM To: multimob@ietf.org Subject: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 Hi all, we just submitted a new version of=20 draft-ietf-multimob-pmipv6-base-solution that includes the comments and=20 improvements of the latest reviews: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 Looking forward to your feedback, Thomas -------- Original Message -------- Subject: New Version Notification for=20 draft-ietf-multimob-pmipv6-base-solution-04 Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC:=20 schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericss on.com A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt=20 has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-ietf-multimob-pmipv6-base-solution Revision: 04 Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains Creation_date: 2010-07-12 WG ID: multimob Number_of_pages: 20 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. =20 The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Wed Jul 14 11:36:47 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374DE3A69DE for ; Wed, 14 Jul 2010 11:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, NO_RELAYS=-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 Gp1Ed2HeH1Yz for ; Wed, 14 Jul 2010 11:36:46 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 0CD783A69CE for ; Wed, 14 Jul 2010 11:36:46 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:c1a6:cd82:d934:434f] (unknown [IPv6:2001:420:4:ea0c:c1a6:cd82:d934:434f]) by ufisa.uninett.no (Postfix) with ESMTPSA id 31553812C; Wed, 14 Jul 2010 20:36:54 +0200 (CEST) Message-ID: <4C3E03C4.2010002@venaas.com> Date: Wed, 14 Jul 2010 11:36:52 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] Input needed for rechartering discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 18:36:47 -0000 At our working group meeting we will discuss possible new charter items. Please all of you suggest items that you would be interested in working on. For each item we would like someone to give us a slide describing the problem, why it is important, whether it has been discussed in the wg (meetings or on the list) and pointer to drafts on the topic if any. Then during the session the chairs will show all those slides, and for each slide we'll have discussion to see how much interest we have in the room, how many are interested in working on it etc. Based on this discussion we will then try to see if we can conclude on what topics we should pick for the charter. So please start suggesting new items on the list, and be prepared to give us a slide. Stig From schmidt@informatik.haw-hamburg.de Wed Jul 14 16:10:02 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D548A3A68A3 for ; Wed, 14 Jul 2010 16:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.375, 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 4HAZlIQMeaMj for ; Wed, 14 Jul 2010 16:10:00 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id F31EB3A6814 for ; Wed, 14 Jul 2010 16:09:59 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178058190.adsl.alicedsl.de ([85.178.58.190] helo=[192.168.178.128]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OZB5b-000KdN-Ka; Thu, 15 Jul 2010 01:10:08 +0200 Message-ID: <4C3E43C4.6040703@informatik.haw-hamburg.de> Date: Thu, 15 Jul 2010 01:09:56 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Rahman, Akbar" References: <4C3B8E59.9090500@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 23:10:02 -0000 Hi Akbar, thanks for overlooking the draft and your comments. Please see answers inline: On 14.07.2010 16:08, Rahman, Akbar wrote: > > Overall the draft looks in very good shape. Just two final comments: > > - In Figure 2, suggest that you change from "Movement to MAG2 ..." to > "Movement of MN2 to MAG2 ..." for improved readability. > O.K. - we will try to fit this in. > - In the last sentence of section 3, it states that "multicast traffic > to one MN will always remain unique, i.e., the mobile multicast > distribution system will never cause duplicate packets arriving at an > MN". However, if the MN is multi-homed (as per section 4.5) is it not > possible that in a simply designed MN implementation that membership to > the same multicast group may be made on multiple interfaces?. This can > be done without breaking any protocols. So, in this multicast traffic > to one MN in fact will NOT remain unique (though of course this is not a > fault of the multicast distribution system). Do you agree? > Yes, that's correct. But if a node (mobile or not) subscribes to the same group on multiple interfaces of possibly disjoint paths, it will always receive duplicate traffic (on its own will). So this is neither specific to (PMIP) mobility nor to the distribution system. Actually, this is just the correct behavior (which the multihomed node actively asks for). IMHO it would be misleading to stress this in the characterization of mobile multicast routing behavior, as this is just a transparent reaction for multihomed nodes. Thanks, Thomas > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Monday, July 12, 2010 5:51 PM > To: multimob@ietf.org > Subject: [multimob] Fwd: New Version Notification > fordraft-ietf-multimob-pmipv6-base-solution-04 > > Hi all, > > we just submitted a new version of > draft-ietf-multimob-pmipv6-base-solution that includes the comments and > improvements of the latest reviews: > > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 > > Looking forward to your feedback, > > Thomas > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-multimob-pmipv6-base-solution-04 > Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC: > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericss > on.com > > > A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt > has been successfully submitted by Thomas Schmidt and posted to the IETF > > repository. > > Filename: draft-ietf-multimob-pmipv6-base-solution > Revision: 04 > Title: Base Deployment for Multicast Listener Support in > PMIPv6 Domains > Creation_date: 2010-07-12 > WG ID: multimob > Number_of_pages: 20 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. A support for mobile > multicast senders is outside the scope of this document. > > > > > The IETF Secretariat. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Dirk.von-Hugo@telekom.de Thu Jul 15 07:24:47 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B201C3A6AC1 for ; Thu, 15 Jul 2010 07:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2FhhKvFi4Hx for ; Thu, 15 Jul 2010 07:24:45 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id BED9C3A6AA1 for ; Thu, 15 Jul 2010 07:24:44 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 15 Jul 2010 16:24:54 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 16:24:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 16:24:53 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802608906@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4C3B8E59.9090500@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 thread-index: AcsiDIUji+3oPq4GSTGEv5maENYAOQCGd/xA References: <4C3B8E59.9090500@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 15 Jul 2010 14:24:54.0177 (UTC) FILETIME=[7E524110:01CB2429] Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:24:47 -0000 Dear Thomas, Matthias, Suresh, Thanks for the progress!=20 As usual ;-) only very minor comments on the document: P.3, 3rd section: ... re-initiate such a tunnel ('re-' as it initiates = a tunnel already before movement?) P.5, 1st section: ... forwarded _after_ aggregation (for me more clear = instead of 'under') ? 2nd section: ... traffic _aimed at/dedicated for_ subscribed groups = will arrive (instead of twice 'arriving for ... arrive') P.8, 5th section: ...send an aggregated Report _via_ the upstream = tunnel to the LMA (insteda of 'to') P.10, 1st section: ... multicast forwarding information base (MFIB). = (add acronym used on p.11) P.11, 5th section: ... from which network the LMA pulls multicast = traffic from. (delete one of both 'from') =20 Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Thomas C. Schmidt Gesendet: Montag, 12. Juli 2010 23:51 An: multimob@ietf.org Betreff: [multimob] Fwd: New Version Notification = fordraft-ietf-multimob-pmipv6-base-solution-04 Hi all, we just submitted a new version of=20 draft-ietf-multimob-pmipv6-base-solution that includes the comments and=20 improvements of the latest reviews: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 Looking forward to your feedback, Thomas -------- Original Message -------- Subject: New Version Notification for=20 draft-ietf-multimob-pmipv6-base-solution-04 Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC:=20 schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsso= n.com A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt=20 has been successfully submitted by Thomas Schmidt and posted to the IETF = repository. Filename: draft-ietf-multimob-pmipv6-base-solution Revision: 04 Title: Base Deployment for Multicast Listener Support in PMIPv6 = Domains Creation_date: 2010-07-12 WG ID: multimob Number_of_pages: 20 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. =20 The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From liuhui47967@huawei.com Thu Jul 15 19:04:57 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490823A67B3 for ; Thu, 15 Jul 2010 19:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.175 X-Spam-Level: ** X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[AWL=-2.671, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 XOr8NOzKSvbY for ; Thu, 15 Jul 2010 19:04:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CE30C3A63D3 for ; Thu, 15 Jul 2010 19:04:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5M006WZOGFT1@szxga04-in.huawei.com> for multimob@ietf.org; Fri, 16 Jul 2010 10:05:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5M00LRHOGF1Y@szxga04-in.huawei.com> for multimob@ietf.org; Fri, 16 Jul 2010 10:05:03 +0800 (CST) Received: from [172.24.1.33] (Forwarded-For: [10.110.98.139]) by szxmc04-in.huawei.com (mshttpd); Fri, 16 Jul 2010 10:05:03 +0800 Date: Fri, 16 Jul 2010 10:05:03 +0800 From: liuhui 47967 In-reply-to: <4C3E03C4.2010002@venaas.com> To: Stig Venaas Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <4C3E03C4.2010002@venaas.com> Cc: multimob@ietf.org Subject: [multimob] =?gb2312?b?u9i4tCA6IElucHV0IG5lZWRlZCBmb3IgcmVjaGFy?= =?gb2312?b?dGVyaW5nIGRpc2N1c3Npb24=?= X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 02:04:57 -0000 Hi,Stig We have a work focusing on gaining reliablity of IGMP/MLD in wireless and mobile network.The URL link for it is available at: http://tools.ietf.org/html/draft-liu-multimob-reliable-igmp-mld-00 As we know, IGMP is not a reliable protocol and packet loss is very high when we employ IGMP in a radio environment,therefore it is difficult to gain reliability for IGMP by sending several copies of IGMP messages. This issue has been observed by INTEL Wimax lab and discussed by IPMSI at the following URL link: http://www.ipmulticast.com/content/view/20/2/. Also there are a few discussions in the multimob WG before. As it is not listed in the current charter, we raise this issue again and hope WG to work on this topic. Best Regards, Liu Hui > At our working group meeting we will discuss possible new charter > items. Please all of you suggest items that you would be interested > in working on. > > For each item we would like someone to give us a slide describing the > problem, why it is important, whether it has been discussed in the > wg (meetings or on the list) and pointer to drafts on the topic if > any. > > Then during the session the chairs will show all those slides, and > for each slide we'll have discussion to see how much interest we > have in the room, how many are interested in working on it etc. > > Based on this discussion we will then try to see if we can conclude > on what topics we should pick for the charter. > > So please start suggesting new items on the list, and be prepared > to give us a slide. > > Stig > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Thu Jul 15 21:31:20 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989C23A6405 for ; Thu, 15 Jul 2010 21:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.527 X-Spam-Level: X-Spam-Status: No, score=-96.527 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kD2XJE1P3Io for ; Thu, 15 Jul 2010 21:31:19 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CF2B93A6452 for ; Thu, 15 Jul 2010 21:31:19 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:0:8801:225:ff:feee:626f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EDFCC278088 for ; Fri, 16 Jul 2010 13:31:23 +0900 (JST) Date: Fri, 16 Jul 2010 13:31:23 +0900 (JST) Message-Id: <20100716.133123.185909511.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <4C3E03C4.2010002@venaas.com> References: <4C3E03C4.2010002@venaas.com> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Input needed for rechartering discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 04:31:20 -0000 Stig, > At our working group meeting we will discuss possible new charter > items. Please all of you suggest items that you would be interested > in working on. I think Dirk's "future work" draft already summarizes the future working items and would become the good input as part of the new charter. Regards, -- Hitoshi Asaeda From Dirk.von-Hugo@telekom.de Fri Jul 16 01:58:43 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C233A6949 for ; Fri, 16 Jul 2010 01:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dJAzjO3jJHr for ; Fri, 16 Jul 2010 01:58:42 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 464E33A68C5 for ; Fri, 16 Jul 2010 01:58:42 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 16 Jul 2010 10:57:04 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 10:57:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 10:57:02 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802608A9C@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <20100716.133123.185909511.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [multimob] Input needed for rechartering discussion thread-index: Acskn8b4sKPdCj3USVmklEEzqPtOiAAISOzA References: <4C3E03C4.2010002@venaas.com> <20100716.133123.185909511.asaeda@sfc.wide.ad.jp> From: To: , X-OriginalArrivalTime: 16 Jul 2010 08:57:03.0935 (UTC) FILETIME=[DC5B44F0:01CB24C4] Cc: multimob@ietf.org Subject: Re: [multimob] Input needed for rechartering discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 08:58:43 -0000 Dear Stig, Hitoshi, all, Actually it's a whole teams draft meanwhile and is proceeding towards a = new requirements draft. Here currently we see the issues of=20 * Enhancement of base multimob solution in terms of: =20 - PMIPv6 modification (MAG and LMA as MLD proxy or multicast router) - Introduction of dedicated multicast tunnels=20 - support of optimal local (direct) routing - IGMP/MLD enhancement=20 - operational improvements by parameter tuning (e.g. default timer) = and message modification (e.g. specific query message introduction, = standard (query) reaction suppression) - introducing multicast router attendance control (e.g. specification = of a Listener Hold message)=20 * Application of (existing) advanced protocol features (e.g. from MEXT, = MIPSHOP, ...): - impact of mobility related connectivity changes (handover) to be = minimized (i.e. delay, packet loss, and packet re-ordering effort = etc.) e.g. Mobile IPv6 Fast Handovers (RFC 5568) and Fast Handovers = for Proxy Mobile IPv6 (PFMIPv6) applied to PMIPv6 in Multimob - Adaptation of unicast traffic handling to multicast group management = (e.g. including multicast group messaging in context transfer, etc.) * Further deployment specific issues:=20 - LMA functionality enhancement (dedicated multicast LMA) - dynamic and/or automatic tunnel configuration - direct or local routing approach (AKA local break-out) * Future extensions (?) - source mobility - support of multiple flows on multihomed mobile nodes - mobile multicast for multi-hop transmission - ... For the first three * topics there are in general already drafts = available ... Please comment! Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Hitoshi Asaeda Gesendet: Freitag, 16. Juli 2010 06:31 An: multimob@ietf.org Betreff: Re: [multimob] Input needed for rechartering discussion Stig, > At our working group meeting we will discuss possible new charter > items. Please all of you suggest items that you would be interested > in working on. I think Dirk's "future work" draft already summarizes the future working items and would become the good input as part of the new charter. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From Akbar.Rahman@InterDigital.com Fri Jul 16 10:06:25 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4046A3A6A6A for ; Fri, 16 Jul 2010 10:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f3FlwTNsqiCB for ; Fri, 16 Jul 2010 10:06:20 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id AB9F93A69C8 for ; Fri, 16 Jul 2010 10:06:19 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:06:31 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:06:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 13:03:49 -0400 Message-ID: In-Reply-To: <4C3E43C4.6040703@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 Thread-Index: AcsjqbXJ8PG8YHw6Qz6Hny0Xq1CBKgBXl3ew References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <4C3E43C4.6040703@informatik.haw-hamburg.de> From: "Rahman, Akbar" To: "Thomas C. Schmidt" X-OriginalArrivalTime: 16 Jul 2010 17:06:31.0315 (UTC) FILETIME=[3CADD630:01CB2509] Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:06:25 -0000 Hi Thomas, Thank you for your replying. Please see below my one response. As usual, I leave it to your best judgment on how to close the issue as I do not want to hold up the draft at this stage. --- snip ---- > - In the last sentence of section 3, it states that "multicast traffic > to one MN will always remain unique, i.e., the mobile multicast > distribution system will never cause duplicate packets arriving at an > MN". However, if the MN is multi-homed (as per section 4.5) is it not > possible that in a simply designed MN implementation that membership to > the same multicast group may be made on multiple interfaces?. This can > be done without breaking any protocols. So, in this multicast traffic > to one MN in fact will NOT remain unique (though of course this is not a > fault of the multicast distribution system). Do you agree? > Yes, that's correct. But if a node (mobile or not) subscribes to the=20 same group on multiple interfaces of possibly disjoint paths, it will=20 always receive duplicate traffic (on its own will). So this is neither=20 specific to (PMIP) mobility nor to the distribution system. Actually,=20 this is just the correct behavior (which the multihomed node actively=20 asks for). IMHO it would be misleading to stress this in the=20 characterization of mobile multicast routing behavior, as this is just a transparent reaction for multihomed nodes. Thanks, Thomas ----- end snip ---- The point though is that the original text captures two ideas. The first is that "multicast traffic to one MN will always remain unique". This we both agreed above may not be true in simple MN implementations. The second point in the text is that "... i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN". This point is always true. So my recommendation is that you delete the first phrase ("multicast traffic to one MN will always remain unique") and leave only the second phrase in the document (" the mobile multicast distribution system will never cause duplicate packets arriving at an MN"). What do you think? Akbar From behcetsarikaya@yahoo.com Fri Jul 16 13:34:52 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4081D3A6B5C for ; Fri, 16 Jul 2010 13:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 X-nLO6p7DeW3 for ; Fri, 16 Jul 2010 13:34:51 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 240983A6B47 for ; Fri, 16 Jul 2010 13:34:51 -0700 (PDT) Received: (qmail 7949 invoked by uid 60001); 16 Jul 2010 20:35:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279312500; bh=tQEm+0YU5TKoCfVzqLdKGDhH+Qbw2OX9kL44az3Tpbw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b+BqFeyenG2X366C7BoBjaRpr1oH3IzjpLh/5nUay1Im8WMcwiW9eKnieyWApFKCk7Umikhyycm/ocnfo5d9ffeRmR/D8hYOjDSCFEtkd/BO6VevN9B1avmpP3rlASL0OuZK2l0e2980MT/BPwdThEZZ9WcEadz5DEJqrl4aNb4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LBRnaGtzjDJ69jOAoACx5Cf65HD4A3Fo4/yCFjLKbNSbVGXrqMXOKKREwVl+MR9wRFXH+1bVB2tXMtFmruxpUPfBkv1AiaczIIXnWv5BhyWyntYBk5kT1u6cFC1NFbMwbfg4+d6Fadqc9k5Nm1NF/sGuYQfEmpR/36T2fVYmnEA=; Message-ID: <521001.7168.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: .qLsPYIVM1nf1VzcR.M.7BtTWrWCJzMYbEhz41cWElcF692 g8FrPSFlOAFEI7EWUVu3xK1fC_092159n9NZBCCphhRsg0pCgmMtb6aHFNyz R7gEH1wXdmFqQpPgB3kb7_Z1kixagJmoqgCs0XqduHW8jBX06so53Y9WzMYa 5k4hDdVV3.JQ6esmsri.L6jLBhWogSSBaM8JDW0hsAMDrqEYPhwEiFkQr89D 1OoRGJV5ad6HwApCp1qZsuPnU7N1tT8hql0SJKbfobZmVuqNKyFtFym0n8Ys 3POc..vQaNnLE5m.fgyw6Wrk2pkHW5ufg8Dlpzc1RBTnLUcWLUhHdxWBr4Zp MViEE6Jgs6ZuB Received: from [79.220.149.31] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 16 Jul 2010 13:35:00 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <4C3E03C4.2010002@venaas.com> <20100716.133123.185909511.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC802784802608A9C@S4DE8PSAAQC.mitte.t-com.de> Date: Fri, 16 Jul 2010 13:35:00 -0700 (PDT) From: Behcet Sarikaya To: Dirk.von-Hugo@telekom.de In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802608A9C@S4DE8PSAAQC.mitte.t-com.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Input needed for rechartering discussion 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: , X-List-Received-Date: Fri, 16 Jul 2010 20:34:52 -0000 Hi all,=0A Please send one slide to the chairs as per Stig's mail describi= ng the problem. =0AIt is not enough to say that everything is in the future= work draft :-).=0A=0ASend it by July 24.=0A=0AChairs=0A=0A=0A=0A----- Orig= inal Message ----=0A> From: "Dirk.von-Hugo@telekom.de" =0A> To: asaeda@sfc.wide.ad.jp; stig@venaas.com=0A> Cc: multimob@ietf= .org=0A> Sent: Fri, July 16, 2010 3:57:02 AM=0A> Subject: Re: [multimob] In= put needed for rechartering discussion=0A> =0A> Dear Stig, Hitoshi, all,=0A= > Actually it's a whole teams draft meanwhile and is proceeding towards a = new =0A>requirements draft. Here currently we see the issues of =0A>=0A> = =0A> * Enhancement of base multimob solution in terms of: =0A> - PMIPv= 6 modification (MAG and LMA as MLD proxy or multicast router)=0A> = - Introduction of dedicated multicast tunnels =0A> - support of o= ptimal local (direct) routing=0A> - IGMP/MLD enhancement =0A> -= operational improvements by parameter tuning (e.g. default timer) =0A>and= message modification (e.g. specific query message = =0A>introduction, standard (query) reaction suppression)= =0A> - introducing multicast router attendance control (e.g. speci= fication =0A>of a Listener Hold message) =0A>=0A>= * Application of (existing) advanced protocol features (e.g. from MEXT, = =0A>MIPSHOP, ...):=0A> - impact of mobility related connectivity chang= es (handover) to be =0A>minimized (i.e. delay, packet loss, and p= acket re-ordering effort etc.) =0A>e.g. Mobile IPv6 Fast Handovers (RFC 55= 68) and Fast Handovers for =0A>Proxy Mobile IPv6 (PFMIPv6) app= lied to PMIPv6 in Multimob=0A> - Adaptation of unicast traffic handli= ng to multicast group management =0A>(e.g. including multicast gro= up messaging in context transfer, etc.)=0A> * Further deployment specific = issues: =0A> - LMA functionality enhancement (dedicated multicast LMA)= =0A> - dynamic and/or automatic tunnel configuration=0A> - direct = or local routing approach (AKA local break-out)=0A> =0A> * Future extensio= ns (?)=0A> - source mobility=0A> - support of multiple flows on m= ultihomed mobile nodes=0A> - mobile multicast for multi-hop transmissi= on=0A> - ...=0A> =0A> For the first three * topics there are in genera= l already drafts available =0A>...=0A> =0A> Please comment!=0A> =0A> Best = regards=0A> Dirk =0A> =0A> -----Urspr=FCngliche Nachricht-----=0A> Von: mul= timob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag =0A>v= on Hitoshi Asaeda=0A> Gesendet: Freitag, 16. Juli 2010 06:31=0A> An: multim= ob@ietf.org=0A> Betreff: Re: [multimob] Input needed for rechartering disc= ussion=0A> =0A> Stig,=0A> =0A> > At our working group meeting we will disc= uss possible new charter=0A> > items. Please all of you suggest items that= you would be interested=0A> > in working on.=0A> =0A> I think Dirk's "fut= ure work" draft already summarizes the future=0A> working items and would = become the good input as part of the new=0A> charter.=0A> =0A> Regards,=0A= > --=0A> Hitoshi Asaeda=0A> ______________________________________________= _=0A> multimob mailing list=0A> multimob@ietf.org=0A> https://www.ietf.org= /mailman/listinfo/multimob=0A> ____________________________________________= ___=0A> multimob mailing list=0A> multimob@ietf.org=0A> https://www.ietf.o= rg/mailman/listinfo/multimob=0A> =0A=0A=0A From stig@venaas.com Sun Jul 18 21:28:21 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BCC3A63C9 for ; Sun, 18 Jul 2010 21:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 i5mS8vmnS7VX for ; Sun, 18 Jul 2010 21:28:08 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id B2A133A67B4 for ; Sun, 18 Jul 2010 21:28:07 -0700 (PDT) Received: from [192.168.1.104] (cm-84.209.163.61.getinternet.no [84.209.163.61]) by ufisa.uninett.no (Postfix) with ESMTPSA id E96AF8088; Mon, 19 Jul 2010 06:28:18 +0200 (CEST) Message-ID: <4C43D45D.8040608@venaas.com> Date: Sun, 18 Jul 2010 21:28:13 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Behcet Sarikaya References: <4C3E03C4.2010002@venaas.com> <20100716.133123.185909511.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC802784802608A9C@S4DE8PSAAQC.mitte.t-com.de> <521001.7168.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <521001.7168.qm@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [multimob] Input needed for rechartering discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 04:28:21 -0000 Behcet Sarikaya wrote: > Hi all, > Please send one slide to the chairs as per Stig's mail describing the problem. > It is not enough to say that everything is in the future work draft :-). Dirk's document certainly has a good list, but it's better for focusing the discussion to have a slide per topic. We know many of you have topics you have been working on, or want to work on. There are many drafts that have been presented etc. So please, if you want them to be considered in the charter discussion, we would like a slide per topic. Dirk, you would of course also be welcome to provide us with a slide per topic. It's not so important now exactly which drafts. It might be good if there already are drafts, but we are really interested in the topics. The idea for the charter discussion is to discuss the topics you guys are suggesting, one by one, and try to see which ones are of the most interest/need. Stig > Send it by July 24. > > Chairs > > > > ----- Original Message ---- >> From: "Dirk.von-Hugo@telekom.de" >> To: asaeda@sfc.wide.ad.jp; stig@venaas.com >> Cc: multimob@ietf.org >> Sent: Fri, July 16, 2010 3:57:02 AM >> Subject: Re: [multimob] Input needed for rechartering discussion >> >> Dear Stig, Hitoshi, all, >> Actually it's a whole teams draft meanwhile and is proceeding towards a new >> requirements draft. Here currently we see the issues of >> >> >> * Enhancement of base multimob solution in terms of: >> - PMIPv6 modification (MAG and LMA as MLD proxy or multicast router) >> - Introduction of dedicated multicast tunnels >> - support of optimal local (direct) routing >> - IGMP/MLD enhancement >> - operational improvements by parameter tuning (e.g. default timer) >> and message modification (e.g. specific query message >> introduction, standard (query) reaction suppression) >> - introducing multicast router attendance control (e.g. specification >> of a Listener Hold message) >> >> * Application of (existing) advanced protocol features (e.g. from MEXT, >> MIPSHOP, ...): >> - impact of mobility related connectivity changes (handover) to be >> minimized (i.e. delay, packet loss, and packet re-ordering effort etc.) >> e.g. Mobile IPv6 Fast Handovers (RFC 5568) and Fast Handovers for >> Proxy Mobile IPv6 (PFMIPv6) applied to PMIPv6 in Multimob >> - Adaptation of unicast traffic handling to multicast group management >> (e.g. including multicast group messaging in context transfer, etc.) >> * Further deployment specific issues: >> - LMA functionality enhancement (dedicated multicast LMA) >> - dynamic and/or automatic tunnel configuration >> - direct or local routing approach (AKA local break-out) >> >> * Future extensions (?) >> - source mobility >> - support of multiple flows on multihomed mobile nodes >> - mobile multicast for multi-hop transmission >> - ... >> >> For the first three * topics there are in general already drafts available >> ... >> >> Please comment! >> >> Best regards >> Dirk >> >> -----Ursprüngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag >> von Hitoshi Asaeda >> Gesendet: Freitag, 16. Juli 2010 06:31 >> An: multimob@ietf.org >> Betreff: Re: [multimob] Input needed for rechartering discussion >> >> Stig, >> >>> At our working group meeting we will discuss possible new charter >>> items. Please all of you suggest items that you would be interested >>> in working on. >> I think Dirk's "future work" draft already summarizes the future >> working items and would become the good input as part of the new >> charter. >> >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From sunseawq@huawei.com Tue Jul 20 01:22:30 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9813A6C36 for ; Tue, 20 Jul 2010 01:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.952 X-Spam-Level: * X-Spam-Status: No, score=1.952 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_75=0.6, J_CHICKENPOX_81=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e83uZpijjNv5 for ; Tue, 20 Jul 2010 01:22:27 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AE27E3A6C38 for ; Tue, 20 Jul 2010 01:22:26 -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 <0L5U0037RKKRQE@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 20 Jul 2010 16:22:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5U00EJRKKR6L@szxga03-in.huawei.com> for multimob@ietf.org; Tue, 20 Jul 2010 16:22:03 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5U00ES9KKQBP@szxml04-in.huawei.com> for multimob@ietf.org; Tue, 20 Jul 2010 16:22:03 +0800 (CST) Date: Tue, 20 Jul 2010 16:22:02 +0800 From: Qin Wu To: multimob@ietf.org Message-id: <029d01cb27e4$a19d52e0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <007d01cb09cf$a7477730$23548a0a@china.huawei.com> <19474.58847.713334.36551@weesan-t61.juniper.net> <04e301cb23cf$0c46f390$23548a0a@china.huawei.com> <19519.41752.867978.587033@weesan-t61.juniper.net> Subject: Re: [multimob] Fw: Some comments on draft-wu-multimob-igmp-mld-tuning-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: , X-List-Received-Date: Tue, 20 Jul 2010 08:22:30 -0000 Hi, Weesan: Thank for your valuable comments and detailed input. please see my feedback belows. Regards! -Qin ----- Original Message ----- From: To: "Qin Wu" Sent: Friday, July 16, 2010 8:08 AM Subject: Re: Fw: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt > Hi Qin, > > Sorry for the long delay. Please find below my comments/questions > regarding your draft in the diff format. Feel free to address those > privately or repost it to the mailing list. > You may need to mention in this document that you are focusing > only on the last hop router where the mobile nodes will be > communicating to. In the document, you mentioned wired multicast and > wireless multicast, in fact, this document focuses only on IGMP/MLD, > which is one part of the multicast protocol suites. [Qin]: You are right. but multicast routing protocol is out scope of this document. Any changes to the multicast routing protocol should be beyond scope of multimob WG, if my understanding is correct. > -- > Thanks, > -WeeSan > > --------- begin diff ------------ > *** draft-wu-multimob-igmp-mld-tuning-02.txt.orig 2010-06-20 17:21:38.000000000 -0700 > --- draft-wu-multimob-igmp-mld-tuning-02.txt 2010-07-15 16:55:43.000000000 -0700 > *************** > *** 123,154 **** > > 1. Introduction > > ! Multicasting is more efficient a method of supporting group > communication than unicasting. However, it has seen slow commercial > deployment by ISPs and carriers for limited number of applications > ! and the complexity of the architecture design [DEPLOY]. Along With > ! the wide deployment of different wireless networks, multicast > ! communication over wireless network comes to attract more and more > ! interests from content and service providers, but still faces great > ! challenges when considering it to keep up with node movement and > ! frequent topology change and providing efficient service in the new > ! wireless environment, e.g., dynamic group membership and constant > update of delivery path due to node movement is highly required in > the wireless network. > > ! On the other hand, unlike shared-medium wired LAN, some of wireless > ! networks, e.g. Wireless 802.11 WLAN offer limited reliability and > ! consume more power and cost more transmission overhead, in the worse > case, it is more prone to cause congestion. > > ! Considering the existing multicast communications is designed only > ! for fixed users using wired link, it does not work well for all the > ! wireless link types. Therefore IGMP/MLD protocol should be enhanced > or tuned to adapt to wireless environment to meet the reliability > and efficiency requirements in the scenarios described in [REQUIRE]. > > ! This memo proposes a variety of optimization approaches for tuning > ! IGMP/MLD protocols in wireless or mobile communication environment. > It aims to make the minimum tuning without introducing obvious > changes on the protocol behavior. These solutions can also be used > in wired network when efficiency and reliability are required. They > --- 123,159 ---- > > 1. Introduction > > ! Multicasting is a more efficient method of supporting group > communication than unicasting. However, it has seen slow commercial > deployment by ISPs and carriers for limited number of applications > ! and the complexity of the architecture design [DEPLOY]. This is > ! going to change with > ! the wide deployment of different wireless networks. Although multicast > ! communication over the wireless networks has become more attractive > ! to the content and service providers, it is still facing great > ! challenges such as rapid and frequent topology changes, as well as > ! striving for providing efficient service in the new > ! wireless environment. For example, dynamic group membership and constant > update of delivery path due to node movement is highly required in > the wireless network. > > ! Additionally, unlike shared-medium wired LAN, some of wireless > ! networks, e.g. Wireless 802.11 WLAN offers limited reliability, > ! consumes more power and costs more transmission overhead. In the worse > case, it is more prone to cause congestion. > > ! Given the fact that the existing multicast protocols were designed only > ! for using wired networks, they do not work well for > ! wireless environment. Therefore IGMP/MLD protocol should be enhanced > or tuned to adapt to wireless environment to meet the reliability > and efficiency requirements in the scenarios described in [REQUIRE]. > > ! weesan: You should mention this document focuses only the last mile of > ! the multcast forwarding path. [Qin]: Thanks, but we mostly focus on multicast management protocol like IGMP/MLD instead of multicast routing protocol like PIM/SIM. > ! This memo proposes various optimization approaches for tuning > ! IGMP/MLD protocols that will fit in wireless or mobile > ! communication environment. > It aims to make the minimum tuning without introducing obvious > changes on the protocol behavior. These solutions can also be used > in wired network when efficiency and reliability are required. They > *************** > *** 177,201 **** > IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication > mode. They do not support SSM subscription, which may limit their > widespread deployment in practical multicast network. IGMPv3 > [RFC3376] and MLDv2 [RFC3810] and their lightweight version LW- > IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM > ! communication. Comparing with ASM mode, SSM [RFC4607] mode allows > ! only sources specific multicast delivery and reduce the demand on > ! the network and improve security by so limiting the source. > Therefore SSM mode is much better to be candidates for wireless and > ! mobile networks than their previous versions. > > IGMPv3/MLDv2 Explicit join and leave Reports are the messages sent > ! unsolicitedly when a host intends to join or leave a group. They > are beneficial for ensuring satisfactory user experience and must be > guaranteed to improve service performance and to optimize resource > use. Current IGMPv3 and MLDv2 provide the reliability for these > ! messages by non responsive retransmission, which is not guaranteed > the messages to be retransmitted is received and may be not adequate > from both the robustness and efficiency aspects [ROBUST]. This issue > could be enhanced by acknowledgement-retransmission in [ACK][IGMP- > ACK]. > > In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to > suppress duplicated multicast listener reports on the link. In > IGMPv3 and MLDv2, there is no such host suppression and explicit > --- 182,225 ---- > IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication > mode. They do not support SSM subscription, which may limit their > widespread deployment in practical multicast network. IGMPv3 > + > + weesan: I'm not sure if this is true. When PIM switches to SPT, it > + essentially is in SSM mode. IGMPv3 simply provides a way to > + jump to SSM mode without going through the RP. [Qin]: What I am saying here is: in contrast with ASM, SSM has more widely deployment. Is that true? > [RFC3376] and MLDv2 [RFC3810] and their lightweight version LW- > IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM > ! communication. Unlike ASM mode, SSM [RFC4607] mode allows > ! only sources specific multicast delivery and reduces the demand on > ! the network and improve security by limiting the source. > ! > ! weesan: how does to SSM reduce the demand on the network? Did you > ! mean it eliminates the needs of creating (*,g) routes and thus > ! reduces the overhead of maintaining them? [Qin]: Yes, By limiting the source, SSM reduces demands on the network. > ! > Therefore SSM mode is much better to be candidates for wireless and > ! mobile networks than ASM mode. > > IGMPv3/MLDv2 Explicit join and leave Reports are the messages sent > ! unsolicitedly when a host intends to join and leave a group > ! respectively. They > are beneficial for ensuring satisfactory user experience and must be > guaranteed to improve service performance and to optimize resource > use. Current IGMPv3 and MLDv2 provide the reliability for these > ! messages by non-responsive retransmission, which is not guaranteed > the messages to be retransmitted is received and may be not adequate > from both the robustness and efficiency aspects [ROBUST]. This issue > could be enhanced by acknowledgement-retransmission in [ACK][IGMP- > ACK]. > ! > ! weesan: I think I understand what you're saying, but, what is a > ! "non-responsive retransmission"? [Qin]: No-responsive retransmission means the host join or leave group by sending unsolicited report and can not get response from the router. >! I don't think neither IGMPv3 > ! nor MLDv2 provide any reliability. They are soft-state > ! protocols. They increase the robustness by retransmission. [Qin]: Isn't that what I am saying in the document? > > + weesan: The ack would provide reliability. [Qin]: Yes. > + > In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to > suppress duplicated multicast listener reports on the link. In > IGMPv3 and MLDv2, there is no such host suppression and explicit > *************** > *** 210,215 **** > --- 234,247 ---- > leave messages and simplify the Query mechanism by reducing both the > unnecessary Queries and reports generated on a network. > > + weesan: From the tone from the 2 paragraphs above, I'm not sure if > + host suppression and explicit tracking are good things or not. > + It sounded like you were trying to convince the readers that > + explicit tracking is a good thing, and we can use that to > + reduce unnecessary queries and reports. Am I correct? If so, > + what if explicit tracking is enabled on a router, and a mobile > + host joins a group and then is turned off, what would happen > + then? [Qin]: Explicit tracking is a good feature when IGMP/MLD works in the wireless environment while host supression is not. We can benefit a lot from using Explicit tracking, e.g., 1. minimizing packet number and packet burst 2. Minimal leave latencies 3.Faster channel changing 4.Reducing Power consumption Also explicit tracking can be used with report suppression and query supression mechanism to minimize the packet number. Suppose one mobile host joins a group and left, what the explicit tracking on the router is doing is to remove the membership state for this mobile host from the table, which reduces unecessary query from upstream router and the report from the host. > *************** > *** 232,240 **** > to adapt to wireless and mobile scenarios. Also some enhanced > mechanism with no protocol changes can be employed as well. > Considering an enhancement in one direction might introduce side > ! effects in another one, balances should be taken carefully to avoid > ! defects and improve protocol performance as a whole, the comparison > ! between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated in figure 2. > > +---------------------+----------------------+-------------------+ > | Issues | IGMPv2/MLDv1 | IGMPv3/MLDv2 | > --- 264,272 ---- > to adapt to wireless and mobile scenarios. Also some enhanced > mechanism with no protocol changes can be employed as well. > Considering an enhancement in one direction might introduce side > ! effects in another one, balance should be taken carefully to avoid > ! defects and improve protocol performance as a whole. The comparison > ! between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated in Figure 2. > > +---------------------+----------------------+-------------------+ > | Issues | IGMPv2/MLDv1 | IGMPv3/MLDv2 | > *************** > *** 244,250 **** > | | Need to be tuned | Need to be tuned| > +---------------------+----------------------+-------------------+ > | | | | > ! | Explicit Tracking | Not Support | Support | > | | | | > +---------------------+----------------------+-------------------+ > | ASM and SSM | Only Support ASM | | > --- 276,282 ---- > | | Need to be tuned | Need to be tuned| > +---------------------+----------------------+-------------------+ > | | | | > ! | Explicit Tracking | Not Supported | Supported | > | | | | > +---------------------+----------------------+-------------------+ > | ASM and SSM | Only Support ASM | | > *************** > *** 260,266 **** > +---------------------+----------------------+-------------------+ > Figure 1. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2 > > ! > --- 292,299 ---- > +---------------------+----------------------+-------------------+ > Figure 1. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2 > > ! weesan: Figure 1 should be mentioned in the text somewhere but it's > ! not. [Qin]: Okay. The change will be reflected in the new version. > *************** > *** 275,313 **** > 3. Impact of wireless and mobility on IGMP/MLD > > This section first evaluates the impact of wireless on mobility on > ! IGMP/MLD by comparing wireless multicast with wired multicast and > comparing different wireless link models. And then gives the > characteristics requirement of wireless multicast. > > 3.1. Comparison analysis between wired and wireless multicast > > ! Existing multicast support for fixed user can be extended to mobile > users in wireless environments. However applying such support to > ! wireless multicast is difficult for the following five reasons. > > ! O Limited Bandwidth: In contrast with wired multicast, wireless > multicast usually has limited bandwidth. Also the bandwidth > available in upstream direction and downstream direction may not > be equal. > > ! O Large packets Loss: In contrast with wired multicast, wireless > multicast has large packet loss that range between 1%~30% based on > the links. > > ! O Frequent Membership change: In the wired multicast, membership > change only happens when a user leave or joins a group while in > the wireless multicast, membership changes may also occur when a > ! user changes the location. > > ! O Reliability: Due to possible unwanted interaction of protocols > across layers and user movement, the wireless network may be > overwhelmed with more excessive traffic than wired network. In > worse case, this may lead to network performance degrading and > ! network connection complete loss. > > ! O Increased Leave Latency: Unlike wired multicast, the leave latency > in the wireless multicast will be increased with user movement. > > --- 308,353 ---- > 3. Impact of wireless and mobility on IGMP/MLD > > This section first evaluates the impact of wireless on mobility on > ! IGMP/MLD by comparing wired and wireless multicast, and > comparing different wireless link models. And then gives the > characteristics requirement of wireless multicast. > > 3.1. Comparison analysis between wired and wireless multicast > > ! Existing multicast support for fixed users can be extended to mobile > ! > ! weesan: what are "fixed" users? Did you mean users of wired network? [Qin]: Yes, any ambiguity introduced? > users in wireless environments. However applying such support to > ! wireless multicast is difficult for the following five reasons: > > ! o Limited Bandwidth: In contrast with wired multicast, wireless > multicast usually has limited bandwidth. Also the bandwidth > available in upstream direction and downstream direction may not > be equal. > > ! o Large packets Loss: In contrast with wired multicast, wireless > multicast has large packet loss that range between 1%~30% based on > the links. > > ! o Frequent Membership change: In the wired multicast, membership > change only happens when a user leave or joins a group while in > the wireless multicast, membership changes may also occur when a > ! user changes the location (ie. move from one cell tower to > ! another). > > ! o Reliability: Due to possible unwanted interaction of protocols > across layers and user movement, the wireless network may be > overwhelmed with more excessive traffic than wired network. In > worse case, this may lead to network performance degrading and > ! a complete network connection loss. > > ! o Increased Leave Latency: Unlike wired multicast, the leave latency > in the wireless multicast will be increased with user movement. > > + weesan: why is it related to user mobility? I thought the increase > + was due to more packet losses (and thus missing leave reports) > + in wireless environment. > > > > *************** > *** 361,366 **** > --- 401,409 ---- > Figure 2. Comparison between wired multicast > and wireless multicast > > + weesan: why does the wired multicast have "frequent" packet losses? > + Did you mean "infrequent"? > + > 3.2. Link models analysis for wireless multicast > > There are various type of wireless links. Each link type has > *************** > *** 369,376 **** > by unicast retransmission. In this document, we categorize the > wireless link type into three typical link models: > > ! O PTP link model > ! O PTMP link model > > --- 412,419 ---- > by unicast retransmission. In this document, we categorize the > wireless link type into three typical link models: > > ! o PTP link model > ! o PTMP link model > > > > *************** > *** 379,396 **** > Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior June 2010 > > > ! O Broadcast link model > > Point to Point link model is the model with one dedicated link that > connects exactly two communication facilities. In this model, each > ! link has only one receiver and the bandwidth is dedicated for each > receiver. Also one unique prefix or set of unique prefixes will be > assigned to each receiver. Such link model can be accomplished by > running PPP on the link or having separate VLAN for each receiver. > > PTMP link model is the model with multipoint link which consist of a > series of receivers and one centralized transmitter. Unlike P2P link > ! model, Bandwidth and prefix in this model are shared by all the > receivers on the same link. Therefore Duplicate Address Detection (DAD) > should be performed to check whether the assigned address is used by > other receivers. > --- 422,439 ---- > Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior June 2010 > > > ! o Broadcast link model > > Point to Point link model is the model with one dedicated link that > connects exactly two communication facilities. In this model, each > ! link has only one receiver and the bandwidth is dedicated for the > receiver. Also one unique prefix or set of unique prefixes will be > assigned to each receiver. Such link model can be accomplished by > running PPP on the link or having separate VLAN for each receiver. > > PTMP link model is the model with multipoint link which consist of a > series of receivers and one centralized transmitter. Unlike P2P link > ! model, bandwidth and prefix in this model are shared by all the > receivers on the same link. Therefore Duplicate Address Detection (DAD) > should be performed to check whether the assigned address is used by > other receivers. > *************** > *** 514,520 **** > these characteristics requirement into account, we will discuss > several optimization approaches for tuning of IGMP and MLD in the > wireless environment. The optimizations try to minimize the packet > ! transmission for both the Reports and Queries, and at the meanwhile > take the factor of improving reliability into account, with minimum > cost. The different link types are also considered when varying > behavior and parameters. > --- 557,563 ---- > these characteristics requirement into account, we will discuss > several optimization approaches for tuning of IGMP and MLD in the > wireless environment. The optimizations try to minimize the packet > ! transmission for both the Reports and Queries, and at the sametime > take the factor of improving reliability into account, with minimum > cost. The different link types are also considered when varying > behavior and parameters. > *************** > *** 526,533 **** > sent when a receiver leaves a (*,G) group, and Source-and-Group > Specific Query sent when a receiver leaves an (S,G) group. These > Queries have different functional scope. They are used to fetch and > ! refresh the downstream membership information by being responded by > ! solicited reports. > > This section lists the possible optimization approaches for Query > messages. The solutions are not intended to be adopted altogether > --- 569,576 ---- > sent when a receiver leaves a (*,G) group, and Source-and-Group > Specific Query sent when a receiver leaves an (S,G) group. These > Queries have different functional scope. They are used to fetch and > ! refresh the downstream membership information by responding to > ! unsolicited reports. > > This section lists the possible optimization approaches for Query > messages. The solutions are not intended to be adopted altogether > *************** > *** 545,555 **** > > In the IGMPv2/MLDv1, the multicast listener reports are suppressed > if the same report has already been sent by another host in the > ! network which is also referred to as host suppression. As described > in the A.2 of [RFC3810], the suppression of multicast listener > reports has been removed in MLDv2 due to the following reasons: > > ! O Routers may want to track per-host multicast listener status on an > interface. This enables the router to track each individual host > that is joined to a particular group or channel and allow minimal > leave latencies when a host leaves a multicast group or channel. > --- 588,598 ---- > > In the IGMPv2/MLDv1, the multicast listener reports are suppressed > if the same report has already been sent by another host in the > ! network which is also known as host suppression. As described > in the A.2 of [RFC3810], the suppression of multicast listener > reports has been removed in MLDv2 due to the following reasons: > > ! o Routers may want to track per-host multicast listener status on an > interface. This enables the router to track each individual host > that is joined to a particular group or channel and allow minimal > leave latencies when a host leaves a multicast group or channel. > *************** > *** 568,591 **** > In comparison, the previous version of MLD required that each > multicast address be reported in a separate message. > > ! In these reasons, one important reason is for per-host tracking at > ! the router which is also referred to as explicit tracking. Explicit > tracking is used to explicitly keep track the membership of all > multicast hosts in the access network which simplifies the Query > ! mechanism by reducing both the unnecessary Queries and reports > generated on a network. > > When explicit tracking is enabled on a router, the local replication > can be used by the router to inspect incoming join and leave > requests, record or refresh the membership state for each host on > the interface, and take appropriate action to each received report. > ! In the meanwhile, the router builds a table to track which channel > ! being forwarded to each port. If the channel being requested to view > ! is already being received at the router, it can replicate the stream > ! and forward to this new requester which ensure good response time, > ! but we should note that the router must ensure enough bandwidth > available to service the request. > > --- 611,637 ---- > In comparison, the previous version of MLD required that each > multicast address be reported in a separate message. > > ! Among these reasons, one important reason is for per-host tracking at > ! the router which is also known as explicit tracking. Explicit > tracking is used to explicitly keep track the membership of all > multicast hosts in the access network which simplifies the Query > ! mechanism by reducing both the unnecessary Queries and Reports > generated on a network. > > When explicit tracking is enabled on a router, the local replication > can be used by the router to inspect incoming join and leave > requests, record or refresh the membership state for each host on > the interface, and take appropriate action to each received report. > ! Meanwhile, the router builds a table to track which channel is > ! being forwarded to which port. If the requested channel > ! has already been received on the router, the router can replicate > ! and forward the stream > ! to this new requester. This will ensures good response time. > ! We should note that the router must ensure enough bandwidth > available to service the request. > > + weesan: I don't quite get this. My understanding of explicit tracking > + is used for leave requests rather than joins. [Qin]: Not exactly, when one new host joins, the membeship state for this new host need to be added into table maintained by the router. This table will be used to keep track of hosts. > > > *************** > *** 609,615 **** > explicit tracking is used. But this does not mean that explicit > tracking can not be used with General periodical Query and current > state report in response to General Query. In some cases (e.g., > ! explicit join and leave message from hosts are lost), the Explicit > tracking may depend on current state report to refresh the > membership state by sending General Query. But different from using > Group specific Query, General Query is periodical message sent by a > --- 655,661 ---- > explicit tracking is used. But this does not mean that explicit > tracking can not be used with General periodical Query and current > state report in response to General Query. In some cases (e.g., > ! explicit join and leave messages from hosts are lost), the Explicit > tracking may depend on current state report to refresh the > membership state by sending General Query. But different from using > Group specific Query, General Query is periodical message sent by a > *************** > *** 618,643 **** > explicit tracking may update membership state periodically by using > periodical IGMP/MLD Query. > > The main benefits of using explicit tracking without Group specific > Query or Source-and-Group Specific Queries are that it provides: > > ! O minimizing packet number and packet burst: Elimination of Group and > ! Source-Group specific Queries in case a member leaves a group will > ! reduce the great number of transmitted Group Specific Queries. And > finally the total number of Reports in response to Group Specific > Queries can be drastically reduced. > > ! O Minimal leave latencies: That is to say, a router configured with > IGMPv3/MLDv2 and explicit tracking can immediately stop forwarding > traffic if the last host to request to receive traffic from the > router indicates that it no longer wants to receive traffic. > > ! O Faster channel changing: The channel change time of the receiver > application depends on the leave latency, that is to say, single host > can not receive the new multicast stream before forwarding of the old > stream has stopped. > > ! O Reducing Power consumption: Due to elimination of the suppression > of multicast listener reports, the host does not need to spend > processing power to hear and determine if the same report has already > been sent by another host in the network and therefore suppress the > --- 664,695 ---- > explicit tracking may update membership state periodically by using > periodical IGMP/MLD Query. > > + weesan: you should consider breaking long sentences into smaller ones > + in the paragraph above. [Qin]: Okay. > + > The main benefits of using explicit tracking without Group specific > Query or Source-and-Group Specific Queries are that it provides: > > ! o minimizing packet number and packet burst: Elimination of Group and > ! Source-Group specific Queries in case a member leaves a group. This will > ! reduce the number of transmitted Group Specific Queries. And > finally the total number of Reports in response to Group Specific > Queries can be drastically reduced. > > ! o Minimal leave latencies: That is to say, a router configured with > IGMPv3/MLDv2 and explicit tracking can immediately stop forwarding > traffic if the last host to request to receive traffic from the > router indicates that it no longer wants to receive traffic. > > ! o Faster channel changing: The channel change time of the receiver > application depends on the leave latency, that is to say, single host > can not receive the new multicast stream before forwarding of the old > stream has stopped. > > ! weesan: not necessary true. The old stream might keep coming while > ! the new stream starts. [Qin]: Okay, But My assumption is each host has one interface used to receive the data packets. Also it is hard to forward the old stream to the mobile host without awareness of current location of mobile host. > ! > ! o Reducing Power consumption: Due to elimination of the suppression > of multicast listener reports, the host does not need to spend > processing power to hear and determine if the same report has already > been sent by another host in the network and therefore suppress the > *************** > *** 656,666 **** > can be mitigated by aggregating the multicast group records in one > single report message. > > On the other hand, when explicit tracking is enabled at the router, > the router may consume more memory and processing overhead to store > the membership state of all hosts on the interface, especially when > explicit tracking is used with General Query. This issue can be > ! optimized by separation of processing state changing report and > current state report. That means the router with explicit tracking > support will not send General Query to refresh membership state at > this router and only take action to the state change report, e.g., > --- 708,722 ---- > can be mitigated by aggregating the multicast group records in one > single report message. > > + weesan: it depends. Usually, the control messages such as membership > + reports are far less than the data itself. I'm not sure how > + much you can save power here. [Qin]: yes, it depends on the deployment scale. > 4.1.2. Report Suppression for the hosts > > ! A large number of Reports on the bad links may result in > ! packets burst. This problem can be mitigated by having the > router aggregate the responses (membership reports) from multiple > clients. The router can intercept IGMP/MLD reports coming from hosts, > and forwards a summarized version to the router only when necessary. > Typically this means that the router will forward IGMP/MLD membership > reports as follows: > > + weesan: I didn't follow. Report suppression is supposed to work on > + the hosts, not the routers. [Qin]: Report Suppression is done in the intermediate router between the host and upstream router. The intermediate router can be DSLAM. > The large number of Queries and bad link condition may result in > packets burst. This packet burst can be mitigated by having the > downstream router stop forwarding IGMP/MLD Queries packets sent to > the hosts and respond with report as proxy to the upstream router. > Typically this means that the router will: > > + weesan: I'm confused. The upstream router doesn't have to know the > + group membership. It's the last hop router's responsibility. [Qin]: The upstream router can be last hop router. The downstream router can be DSLAM. So I don't think any issue here. > > *************** > *** 716,721 **** > --- 781,789 ---- > address listener information from an attached link. This General > Query can be slowed down when a router can not collect successfully > all the members' report responses in the meanwhile the network > + > + weesan: how do you know "all" the members? Is it by explicit tracking? [Qin]: Yes, one possible way is through explicit tracking. > congestion is going to happen [ADAPTIVE]. Its basic behavior is: the > router after sending a Query, if acquires the response from the > receiver, refreshes its state database and stop the querying > *************** > *** 727,732 **** > --- 795,805 ---- > receiver is unreachable and then stops the sending of the Query > ultimately. > > + weesan: let's say if a wireless node is experiencing congestion > + because the lost of leave message to the router and the node > + is bombarded with unwanted data packets. Backing up the > + General Queries would only make it worst, right? [Qin]: You can not abandon or eliminate General Queries. In many cases, the General Queries has its value used to refresh the membership state. What we are doing to General Queries is just to slow down the interval for Query retransmission. Nothing Else. > This query retransmission with incremental interval enables the > router to reduce the total packet retransmission times in the same > time period comparing with retransmission for multiple times with > *************** > *** 771,778 **** > Group-and-Source specific Query, can be retransmitted several times > within a given time interval. And also described in [RFC3376] and > [RFC3810], General Query can be retransmitted [Startup Query Count] > ! with [Startup Query Interval].In some case, a router which keeps > ! track of all its active receivers, if after sending a Query, may fail > to get any response from any receiver. And it may derive that this > Query might have been lost before reaching the other end of the link. > In such case, the router could choose to compensate this situation by > --- 844,851 ---- > Group-and-Source specific Query, can be retransmitted several times > within a given time interval. And also described in [RFC3376] and > [RFC3810], General Query can be retransmitted [Startup Query Count] > ! with [Startup Query Interval].In some cases, a router which keeps > ! track of all its active receivers, after sending a Query, may fail > to get any response from any receiver. And it may derive that this > Query might have been lost before reaching the other end of the link. > In such case, the router could choose to compensate this situation by > *************** > *** 781,789 **** > retransmission timer expires and the response from receiver has not > arrived, then another Query will be retransmitted. > > 4.1.7. Filtering unwanted multicast packets based on link type > > ! When the network needs to deliver packets to the receiver, the > receiver may be in the dormant mode. In such case, Paging capability > will be used to establish connection with the network when the > receiver is waken up. Before the connection is established, packets > --- 854,865 ---- > retransmission timer expires and the response from receiver has not > arrived, then another Query will be retransmitted. > > + weesan: how do you differentiate if a General Query with no responses > + is the result of congestion or no receiver at all? [Qin]: Explicit tracking can be used to learn whether there still one receiver on the attached link. As for congestion, extra mechanism is required,e g, link state indication to the router. > 4.1.7. Filtering unwanted multicast packets based on link type > > ! When a router needs to deliver packets to a mobile receiver, the > receiver may be in the dormant mode. In such case, Paging capability > will be used to establish connection with the network when the > receiver is waken up. Before the connection is established, packets > *************** > *** 811,817 **** > > reduce possibility of MLD traffic burstiness. However, a longer > Maximum Response Delay in Multicast Address Specific and Multicast > ! Address and Source Specific Queries extends the leave latency (the > time between when the last listener stops listening to a source or > multicast address and when the traffic stops flowing.) In order to > avoid burstiness of MLD traffic and reduce leave latency, we can > --- 887,893 ---- > > reduce possibility of MLD traffic burstiness. However, a longer > Maximum Response Delay in Multicast Address Specific and Multicast > ! Address and Source Specific Queries increases the leave latency (the > time between when the last listener stops listening to a source or > multicast address and when the traffic stops flowing.) In order to > avoid burstiness of MLD traffic and reduce leave latency, we can > *************** > *** 822,829 **** > the expected number of Reporters for each Query and link type and > link status. > > ! O If the expected number of Reporters is large and link condition is > bad, the system administrator MUST choose the longer Maximum > Response Delay; If the expected number of Reporters is small and the > link condition is good, the administrator may choose the smaller > Maximum response Delay. In this case, the MLD traffic burstieness > --- 898,911 ---- > the expected number of Reporters for each Query and link type and > link status. > > ! o If the expected number of Reporters is large and link condition is > bad, the system administrator MUST choose the longer Maximum > + > + weesan: by "choose", did you mean a preset value? The thing is > + multicast is very dynamic, a choosen value for this hour might > + not good for the next hour. Do you have a way to dynamically > + derive a "good enough" value? [Qin]: Good question. I believe more testing results are required to derive good enough value. Currently we don't have. > Response Delay; If the expected number of Reporters is small and the > link condition is good, the administrator may choose the smaller > Maximum response Delay. In this case, the MLD traffic burstieness > *************** > *** 841,849 **** > destination addresses are multicast addresses and also allow use of > unicast Queries with unicast destination. The unicast Query is sent > only for one destination and has the advantages of not affecting > ! other host on the same link. But in some cases(e.g., during the > Queries on startup)using unicast Query instead of multicast > ! Query ,the number the valid multicast receiver on the same link may > be large, i.e., numerous Queries will be generated for each member, > which will not be an efficient use of link resources. In this case > the normal multicast Query will be a good choice because only one > --- 923,931 ---- > destination addresses are multicast addresses and also allow use of > unicast Queries with unicast destination. The unicast Query is sent > only for one destination and has the advantages of not affecting > ! other hosts on the same link. But in some cases(e.g., during the > Queries on startup)using unicast Query instead of multicast > ! Query, the number the valid multicast receiver on the same link may > be large, i.e., numerous Queries will be generated for each member, > which will not be an efficient use of link resources. In this case > the normal multicast Query will be a good choice because only one > *************** > *** 853,859 **** > according to the practical network conditions. For example, if the > receiver number is small, the router could send unicast Queries > respectively to each receiver to solicit their membership states, > ! without arousing other host which is in the dormant state. when the > receiver number reaches a predefined level, the router could change > > > --- 935,941 ---- > according to the practical network conditions. For example, if the > receiver number is small, the router could send unicast Queries > respectively to each receiver to solicit their membership states, > ! without waking other dormant hosts. when the > receiver number reaches a predefined level, the router could change > > > *************** > *** 866,871 **** > --- 948,964 ---- > to use multicast Queries. The router could make the switching > flexibly according to practical conditions to improve the efficiency. > > + weesan: can you propose new variables or an equation for this? For > + example, let's say the number of byte for the Queries is Q, > + the number of hosts being explicitly tracked is H, and the max > + bandwidth of a certain type of the wireless is B, then: > + > + if (Q * H >= B) > + use multicast query > + else > + use unicast query [Qin]: Sounds good idea, we will try to reflect this in the new version. > + > 5. Security Considerations > > They will be described in the later version of this draft. > --------- end diff --------- From luisc@it.uc3m.es Wed Jul 21 11:25:25 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C733A68A3 for ; Wed, 21 Jul 2010 11:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LiTayMlZ4wxN for ; Wed, 21 Jul 2010 11:25:24 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 0DFA43A691A for ; Wed, 21 Jul 2010 11:25:12 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp03.uc3m.es (Postfix) with ESMTP id 40FD8840341; Wed, 21 Jul 2010 20:25:23 +0200 (CEST) Received: from 87.pool85-54-48.dynamic.orange.es (87.pool85-54-48.dynamic.orange.es [85.54.48.87]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 21 Jul 2010 20:25:21 +0200 Message-ID: <20100721202521.97j32pzfcwccg4cg@webcartero01.uc3m.es> Date: Wed, 21 Jul 2010 20:25:21 +0200 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4C3B8E59.9090500@informatik.haw-hamburg.de> In-Reply-To: <4C3B8E59.9090500@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17520.000 Cc: "multimob@ietf.org" Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:25:25 -0000 Hi Thomas, two very minor comments, just in case you consider them as relevant: 1/ on page 5, third paragraph, when talking about the Binding Update List you provide the reference "section 6 of [RFC5213]", while on page 8, first paragraph of point 4.2, you provide the reference "section 6.1 of [RFC5213]" when talking also about the Binding Update List. 2/ on page 6, step 8 of the handover process by the MAG: I would suggest to include some wording about the case the MN has no active multicast subscription when receiving the MLD Queries from MAG (that is, the link of the MN is removed from the MLD proxy instance.) Regards, Luis "Thomas C. Schmidt" dijo: > Hi all, > > we just submitted a new version of > draft-ietf-multimob-pmipv6-base-solution that includes the comments > and improvements of the latest reviews: > > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 > > Looking forward to your feedback, > > Thomas > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-multimob-pmipv6-base-solution-04 > Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC: > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com > > > A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt > has been successfully submitted by Thomas Schmidt and posted to the > IETF repository. > > Filename: draft-ietf-multimob-pmipv6-base-solution > Revision: 04 > Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains > Creation_date: 2010-07-12 > WG ID: multimob > Number_of_pages: 20 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. A support for mobile > multicast senders is outside the scope of this document. > > > > > The IETF Secretariat. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From behcetsarikaya@yahoo.com Sun Jul 25 03:21:17 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC9C3A659B for ; Sun, 25 Jul 2010 03:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 U1kjVDRhcHju for ; Sun, 25 Jul 2010 03:21:16 -0700 (PDT) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id A50FA3A680A for ; Sun, 25 Jul 2010 03:21:15 -0700 (PDT) Received: (qmail 27287 invoked by uid 60001); 25 Jul 2010 10:21:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280053292; bh=MNJ/5tYCKKAIysskb3CljdXUEmkA9CzTvfUJKj014Gk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1zP96r0qc8/BQ0nUQr8QqOSvLSfprb8IP4d/DoOPj9ihSTJvQQV6uyui86+XwuzeGP3nuG6JaAUX2Nur49UmGpJNzGO8SvPnW0Z9rmh1kSHu7+btEG/oA1PeqLhdbalwtRUQM7apCux4sGOVpVHhBN9nnCcVF35ou/rowrkUHA8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=kTdiGy3UX1ecVUIISYPb0smMuBSDPJiMXF4k7/KNInqP4AxPqXrH/wJFi3s9zWCO4zrMwShHAL81jRf6UTYpaAxdXHGG0yjvqOqLZS5hJq78bXTfBnEbnPm8P/95oYIr6dJdm8oGW+PFOdBjHrhMjA+D5TpYlzOAYinwNxkYZ4Q=; Message-ID: <522747.25874.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: hZzRteMVM1nDVnyp8j8txoBsu2CdqTPPkDGIG8Hg2cfcTU6 .M5Wk6G_qWvdw4QagUH8Uu7D7pszQHfbR6jeo9BOJpJVaolfunZAqItmXfvv vmklPqSw02NoMppjdd56P8CKVpfPol.aIrZ6gTeADe2UEvTHA7VNoHA2NKJg oDV9MgpYhv.3VygD.Kh3VWvvU8jIVyGXFVbErwOGNCpS3tK6GcuHFqmA2eCD q.X9vueJ1.rIXrC4sNAWxi7NZhdRAHSqlLJKswdiWLnxb4gZqopjUZvhfezq M3cQKfAbUs3LXbhYqV4SIPnW72hVclOa5gB8aepvcsbx9aXyjfszHEA-- Received: from [130.129.112.247] by web111416.mail.gq1.yahoo.com via HTTP; Sun, 25 Jul 2010 03:21:32 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 Date: Sun, 25 Jul 2010 03:21:32 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Presentations, Minute-takers and Jabber scribes 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: , X-List-Received-Date: Sun, 25 Jul 2010 10:21:17 -0000 Hi all, If you have not sent your presentation/one slide problem description, please do so immediately to the chairs. Please volunteer for minute-taking and Jabber scribing. Regards, Behcet From huimin.cmcc@gmail.com Sun Jul 25 07:15:42 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BF73A696E for ; Sun, 25 Jul 2010 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 DADLbh-tsELl for ; Sun, 25 Jul 2010 07:15:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0681F3A6968 for ; Sun, 25 Jul 2010 07:15:39 -0700 (PDT) Received: by qwe5 with SMTP id 5so1390133qwe.31 for ; Sun, 25 Jul 2010 07:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sIDxuFgEXkTBFB/q12CCgu0M1m0k9YXS1I5816ML4MU=; b=dOzJX4mD8hG6kqSQaz3HqAUIkWLrf4ADQBMqdVodu0JV/YoJKOw9GWa4+8eZWTwxjV 1kTKlsqNxt+WXMuscQjvGqKgztUKVxIuhhl63vMXye5tWvIqyedwr8EbzAs5XWy07p2F YblYeAZFw0jssaGbp/qSKrDW9dEKf3wM3ijyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q3qk/d6VKV3j+84HP4y4fwYfh2ezIPGX+bGfCE+nT97tF25beCNAre0Ro+VrGPXhUk tWXTw3jqjyQqhZJxnJfrQ/mJPngqwIYbe0gEwlWaNXucvUcpVNtGF/K+gHkrJxE2SYgf Q0OkziZW9F2j52TTdohaM96zpSg9/aLZpEjRQ= MIME-Version: 1.0 Received: by 10.224.19.205 with SMTP id c13mr4943023qab.215.1280067359745; Sun, 25 Jul 2010 07:15:59 -0700 (PDT) Received: by 10.229.192.195 with HTTP; Sun, 25 Jul 2010 07:15:59 -0700 (PDT) In-Reply-To: <4C3E03C4.2010002@venaas.com> References: <4C3E03C4.2010002@venaas.com> Date: Sun, 25 Jul 2010 22:15:59 +0800 Message-ID: From: Min Hui To: Stig Venaas Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Input needed for rechartering discussion X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 14:15:42 -0000 Hi Stig=A3=AC We suggest to add fast handover issue, which has been talked a lot in the mailing list. Without supporting fast handover, it inevitably causes the latency and loss of packet during multicast handover process. BR, Hui Min 2010/7/15 Stig Venaas : > At our working group meeting we will discuss possible new charter > items. Please all of you suggest items that you would be interested > in working on. > > For each item we would like someone to give us a slide describing the > problem, why it is important, whether it has been discussed in the > wg (meetings or on the list) and pointer to drafts on the topic if > any. > > Then during the session the chairs will show all those slides, and > for each slide we'll have discussion to see how much interest we > have in the room, how many are interested in working on it etc. > > Based on this discussion we will then try to see if we can conclude > on what topics we should pick for the charter. > > So please start suggesting new items on the list, and be prepared > to give us a slide. > > Stig > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From schmidt@informatik.haw-hamburg.de Mon Jul 26 03:08:18 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FCE3A69E8 for ; Mon, 26 Jul 2010 03:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Cw3B9tO8vXJa for ; Mon, 26 Jul 2010 03:08:12 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3DC733A6833 for ; Mon, 26 Jul 2010 03:08:11 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-30fd.meeting.ietf.org ([130.129.48.253]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OdKbn-000AZB-O9; Mon, 26 Jul 2010 12:08:31 +0200 Message-ID: <4C4D5E9A.7000804@informatik.haw-hamburg.de> Date: Mon, 26 Jul 2010 12:08:26 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Rahman, Akbar" References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <4C3E43C4.6040703@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:08:18 -0000 Hi Akbar, thanks for your additional comment, please see below: On 16.07.2010 19:03, Rahman, Akbar wrote: > Hi Thomas, > > > Thank you for your replying. Please see below my one response. As > usual, I leave it to your best judgment on how to close the issue as I > do not want to hold up the draft at this stage. > > --- snip ---- > > >> - In the last sentence of section 3, it states that "multicast traffic >> to one MN will always remain unique, i.e., the mobile multicast >> distribution system will never cause duplicate packets arriving at an >> MN". However, if the MN is multi-homed (as per section 4.5) is it not >> possible that in a simply designed MN implementation that membership > to >> the same multicast group may be made on multiple interfaces?. This > can >> be done without breaking any protocols. So, in this multicast traffic >> to one MN in fact will NOT remain unique (though of course this is not > a >> fault of the multicast distribution system). Do you agree? >> > > Yes, that's correct. But if a node (mobile or not) subscribes to the > same group on multiple interfaces of possibly disjoint paths, it will > always receive duplicate traffic (on its own will). So this is neither > specific to (PMIP) mobility nor to the distribution system. Actually, > this is just the correct behavior (which the multihomed node actively > asks for). IMHO it would be misleading to stress this in the > characterization of mobile multicast routing behavior, as this is just a > > transparent reaction for multihomed nodes. > > Thanks, > > Thomas > > ----- end snip ---- > > The point though is that the original text captures two ideas. The > first is that "multicast traffic to one MN will always remain unique". > This we both agreed above may not be true in simple MN implementations. > The second point in the text is that "... i.e., the mobile multicast > distribution system will never cause duplicate packets arriving at an > MN". This point is always true. So my recommendation is that you > delete the first phrase ("multicast traffic to one MN will always remain > unique") and leave only the second phrase in the document (" the mobile > multicast distribution system will never cause duplicate packets > arriving at an MN"). What do you think? > You're right in pointing us to be as precise and correct as possible :-) There is an important point in clearly stating that traffic remains unique as it traverses the distribution system towards the MN, but you are right that uniqueness only holds per interface. So we propose to change: "However, multicast traffic arriving at one interface of the MN will always remain unique, i.e., the mobile multicast distribution system will never cause duplicate packets arriving at an MN" Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Mon Jul 26 04:06:38 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1483A67EF for ; Mon, 26 Jul 2010 04:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.562, 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 0d5fhOgV7lOo for ; Mon, 26 Jul 2010 04:06:37 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A56DB3A6836 for ; Mon, 26 Jul 2010 04:06:37 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-30fd.meeting.ietf.org ([130.129.48.253]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OdLWL-000P9o-Ps for multimob@ietf.org; Mon, 26 Jul 2010 13:06:57 +0200 Message-ID: <4C4D6C4C.5070403@informatik.haw-hamburg.de> Date: Mon, 26 Jul 2010 13:06:52 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: multimob@ietf.org References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <643B0A1D1A13AB498304E0BBC802784802608906@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802608906@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:06:39 -0000 Hi Dirk, many thanks for your comments ... and sorry for answering late. On 15.07.2010 16:24, Dirk.von-Hugo@telekom.de wrote: > Dear Thomas, Matthias, Suresh, > Thanks for the progress! > As usual ;-) only very minor comments on the document: > P.3, 3rd section: ... re-initiate such a tunnel ('re-' as it initiates a tunnel already before movement?) ?? I'm a bit puzzled by this: on P.3, 3rd section I see: "...a mobility-unaware node will not initiate such a tunnel after movement" ... but no re-initiate ??? > P.5, 1st section: ... forwarded _after_ aggregation (for me more clear instead of 'under') ? O.k. ... that's a language question, I'm uncertain. How about "MLD Report messages will be aggregated and then forwarded up the tunnel interface to its corresponding LMA." ? > 2nd section: ... traffic _aimed at/dedicated for_ subscribed groups will arrive (instead of twice 'arriving for ... arrive') Good point: How about "Traffic of the subscribed groups will arrive at the LMA" ? > P.8, 5th section: ...send an aggregated Report _via_ the upstream tunnel to the LMA (insteda of 'to') O.K., changed. > P.10, 1st section: ... multicast forwarding information base (MFIB). (add acronym used on p.11) Thanks, yes, you're right: it's added now. > P.11, 5th section: ... from which network the LMA pulls multicast traffic from. (delete one of both 'from') > Yes, deleted. Thanks & best regards, Thomas > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Thomas C. Schmidt > Gesendet: Montag, 12. Juli 2010 23:51 > An: multimob@ietf.org > Betreff: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 > > Hi all, > > we just submitted a new version of > draft-ietf-multimob-pmipv6-base-solution that includes the comments and > improvements of the latest reviews: > > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 > > Looking forward to your feedback, > > Thomas > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-multimob-pmipv6-base-solution-04 > Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC: > schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com > > > A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt > has been successfully submitted by Thomas Schmidt and posted to the IETF > repository. > > Filename: draft-ietf-multimob-pmipv6-base-solution > Revision: 04 > Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains > Creation_date: 2010-07-12 > WG ID: multimob > Number_of_pages: 20 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. A support for mobile > multicast senders is outside the scope of this document. > > > > > The IETF Secretariat. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Mon Jul 26 04:44:22 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D623A679F for ; Mon, 26 Jul 2010 04:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.238, 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 vlLBrFE8k+Ar for ; Mon, 26 Jul 2010 04:44:20 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 6F23E3A6909 for ; Mon, 26 Jul 2010 04:44:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-84e4.meeting.ietf.org ([130.129.132.228]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OdM6q-0009FM-BX; Mon, 26 Jul 2010 13:44:40 +0200 Message-ID: <4C4D7523.7040308@informatik.haw-hamburg.de> Date: Mon, 26 Jul 2010 13:44:35 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Luis M. Contreras" References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <20100721202521.97j32pzfcwccg4cg@webcartero01.uc3m.es> In-Reply-To: <20100721202521.97j32pzfcwccg4cg@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: "multimob@ietf.org" Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:44:22 -0000 Hi Luis, thanks for looking at the details and sorry for answering late. On 21.07.2010 20:25, Luis M. Contreras wrote: > two very minor comments, just in case you consider them as relevant: > > 1/ on page 5, third paragraph, when talking about the Binding Update > List you provide the reference "section 6 of [RFC5213]", while on page > 8, first paragraph of point 4.2, you provide the reference "section 6.1 > of [RFC5213]" when talking also about the Binding Update List. > O.K., you're right: 6.1 is more specific and has been placed on page 5. > 2/ on page 6, step 8 of the handover process by the MAG: I would suggest > to include some wording about the case the MN has no active multicast > subscription when receiving the MLD Queries from MAG (that is, the link > of the MN is removed from the MLD proxy instance.) > Well, if no MLD Report is received, the proxy essentially does nothing (that was indicated by "if necessary". Actually, the link to the MN is not removed, it remains a regular downstream link of the MLD Proxy jut without forwarding entries. So I don't see a lot content to add except the remark that "no active multicast subscriptions will lead to no MLD reports which in turn will lead to no reaction at the MAG" - or are you referring to anything I might have missed? Thanks, Thomas > "Thomas C. Schmidt" dijo: > >> Hi all, >> >> we just submitted a new version of >> draft-ietf-multimob-pmipv6-base-solution that includes the comments >> and improvements of the latest reviews: >> >> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04 >> >> Looking forward to your feedback, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-ietf-multimob-pmipv6-base-solution-04 >> Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC: >> schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com >> >> >> >> A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt >> has been successfully submitted by Thomas Schmidt and posted to the >> IETF repository. >> >> Filename: draft-ietf-multimob-pmipv6-base-solution >> Revision: 04 >> Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains >> Creation_date: 2010-07-12 >> WG ID: multimob >> Number_of_pages: 20 >> >> Abstract: >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards. Similar to Home Agents in >> Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as >> multicast subscription anchor points, while Mobile Access Gateways >> provide MLD proxy functions. In this scenario, Mobile Nodes remain >> agnostic of multicast mobility operations. A support for mobile >> multicast senders is outside the scope of this document. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > > > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Mon Jul 26 05:46:55 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AA53A6ACA for ; Mon, 26 Jul 2010 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] 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 wOBVWs6V0ltW for ; Mon, 26 Jul 2010 05:46:54 -0700 (PDT) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 224AE3A6AD7 for ; Mon, 26 Jul 2010 05:46:39 -0700 (PDT) Received: (qmail 80316 invoked by uid 60001); 26 Jul 2010 12:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280148417; bh=60DJleUPF+ocMu4P1/piucaN+1XCvDcUCY4RsqojxmI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=lmck/n0O6hdMJJZ/fojEpK8K5BG6KcR2rUtFDBquy3oKLaZ4n5crvdqG2udFq6qmOkVkizYWQZqnUAQmKozDwk3tQsD+VEDi3ZtPqC2TA1WwnYsUKfWJUdsJtqe5KZ+oK1yCWsbN3mG4eURpiSNmwsee3VC7ifjeWBDbJJSe+hA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=OohFp8U4ASHIzSV9EIF1dgfPkR8BrvSbIm3gz/83GiNn6mro48XcMtQPL+2eN/TpZQPHuXhqxYgqfvMWavh+uB8I6GfXDMB47AfJHy5vlwp9TUilJqJh6AV/5wwOZ8Pt51YQhAhjmSss8Ri6DNMdEOLK67wWrxJHWdawgL3AjGg=; Message-ID: <648195.80095.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: iILFeUwVM1nsWcT45D1DLGPky.tU2hlTdI1zrj4eMNMFxon r_vdikswi3KZErnZSqiUKPpBqxpB_t2yGguBf08kQsAyH66izlQvkLinhuvO FigBnGBwp7R5omjGJ.6YAr7uOrALbWk2xU3oEaKbbODCoPPukcUd6ro2bfeS CoR9piwvbZyhj2S1ji4vRBNyv6UZG1mgZEDp7CNgRMNOWIkCr9vuA8zXcRnQ 1IrD5MhtAeiJ1GAHotiWNgLNr93t33Yqxi5d4zb3MO8d56PE1irzIoYDTNc9 6XgvdNvlOIdQFNN35.24wLdv_DIEvp6ylP9FJipA- Received: from [130.129.112.247] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 26 Jul 2010 05:46:57 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 Date: Mon, 26 Jul 2010 05:46:57 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] MLD/IGMP Tuning 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: , X-List-Received-Date: Mon, 26 Jul 2010 12:46:55 -0000 Hi Folks, As you know in tomorrow's session we are going to discuss the two documents on MLD/IGMP tuning (draft-asaeda-multimob-igmp-mld-optimization-03 and draft-wu-multimob-igmp-mld-tuning-02). In order to have a productive session it is important that people read these documents before the meeting. Regards, Chairs From Akbar.Rahman@InterDigital.com Mon Jul 26 06:48:37 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925CA3A6C14 for ; Mon, 26 Jul 2010 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 mcpO3dx-a+-W for ; Mon, 26 Jul 2010 06:48:35 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id D7B213A69F8 for ; Mon, 26 Jul 2010 06:48:34 -0700 (PDT) Received: from interdigital.com ([10.0.128.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:48:55 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:48:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 09:48:54 -0400 Message-ID: In-Reply-To: <4C4D5E9A.7000804@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 Thread-Index: AcssqoPNpl4mQh+eTwydIH8/x699fgAHo0Yw References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <4C3E43C4.6040703@informatik.haw-hamburg.de> <4C4D5E9A.7000804@informatik.haw-hamburg.de> From: "Rahman, Akbar" To: "Thomas C. Schmidt" X-OriginalArrivalTime: 26 Jul 2010 13:48:55.0515 (UTC) FILETIME=[4A33D2B0:01CB2CC9] Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:48:37 -0000 Hi Thomas, I agree with your proposed text. Thanks for taking the time to answer = all our questions! Akbar and Juan Carlos. -----Original Message----- From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20 Sent: Monday, July 26, 2010 6:08 AM To: Rahman, Akbar Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification = fordraft-ietf-multimob-pmipv6-base-solution-04 Hi Akbar, thanks for your additional comment, please see below: On 16.07.2010 19:03, Rahman, Akbar wrote: > Hi Thomas, > > > Thank you for your replying. Please see below my one response. As > usual, I leave it to your best judgment on how to close the issue as I > do not want to hold up the draft at this stage. > > --- snip ---- > > >> - In the last sentence of section 3, it states that "multicast = traffic >> to one MN will always remain unique, i.e., the mobile multicast >> distribution system will never cause duplicate packets arriving at an >> MN". However, if the MN is multi-homed (as per section 4.5) is it = not >> possible that in a simply designed MN implementation that membership > to >> the same multicast group may be made on multiple interfaces?. This > can >> be done without breaking any protocols. So, in this multicast = traffic >> to one MN in fact will NOT remain unique (though of course this is = not > a >> fault of the multicast distribution system). Do you agree? >> > > Yes, that's correct. But if a node (mobile or not) subscribes to the > same group on multiple interfaces of possibly disjoint paths, it will > always receive duplicate traffic (on its own will). So this is neither > specific to (PMIP) mobility nor to the distribution system. Actually, > this is just the correct behavior (which the multihomed node actively > asks for). IMHO it would be misleading to stress this in the > characterization of mobile multicast routing behavior, as this is just = a > > transparent reaction for multihomed nodes. > > Thanks, > > Thomas > > ----- end snip ---- > > The point though is that the original text captures two ideas. The > first is that "multicast traffic to one MN will always remain unique". > This we both agreed above may not be true in simple MN = implementations. > The second point in the text is that "... i.e., the mobile multicast > distribution system will never cause duplicate packets arriving at an > MN". This point is always true. So my recommendation is that you > delete the first phrase ("multicast traffic to one MN will always = remain > unique") and leave only the second phrase in the document (" the = mobile > multicast distribution system will never cause duplicate packets > arriving at an MN"). What do you think? > You're right in pointing us to be as precise and correct as possible :-) There is an important point in clearly stating that traffic remains=20 unique as it traverses the distribution system towards the MN, but you=20 are right that uniqueness only holds per interface. So we propose to = change: "However, multicast traffic arriving at one interface of the MN will=20 always remain unique, i.e., the mobile multicast distribution system=20 will never cause duplicate packets arriving at an MN" Best regards, Thomas --=20 Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From asaeda@sfc.wide.ad.jp Mon Jul 26 06:59:25 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6CC3A69F8 for ; Mon, 26 Jul 2010 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.607 X-Spam-Level: X-Spam-Status: No, score=-97.607 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jepY4BJAK2bg for ; Mon, 26 Jul 2010 06:59:24 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 8DA803A691D for ; Mon, 26 Jul 2010 06:59:24 -0700 (PDT) Received: from localhost (dhcp-7770.meeting.ietf.org [130.129.119.112]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8F246278060 for ; Mon, 26 Jul 2010 22:59:41 +0900 (JST) Date: Mon, 26 Jul 2010 22:59:37 +0900 (JST) Message-Id: <20100726.225937.104291800.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <648195.80095.qm@web111413.mail.gq1.yahoo.com> References: <648195.80095.qm@web111413.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] MLD/IGMP Tuning X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:59:25 -0000 Hi Folks, > As you know in tomorrow's session we are going to discuss the two > documents on > MLD/IGMP tuning (draft-asaeda-multimob-igmp-mld-optimization-03 and > draft-wu-multimob-igmp-mld-tuning-02). > In order to have a productive session it is important that people > read these documents before the meeting. And if you have time, please also read a new draft, whose title is; "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers". The intention of this draft is to specify the explicit tracking function separately from my tuning draft, because it is not only useful for mobile communication, and I thought the specific function should be clearly defined. The draft submission was just delayed and hence I temporary put it in my web page; http://www.sfc.wide.ad.jp/~asaeda/paper/draft-asaeda-mboned-explicit-tracking-00.txt This draft will be proposed in either mboned or multimob, but will be shown in both mboned and multimob briefly. See you soon. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Tue Jul 27 06:42:33 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED693A6A24 for ; Tue, 27 Jul 2010 06:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_20=-0.74, 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 WE2uvT25w5Hg for ; Tue, 27 Jul 2010 06:42:32 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 736523A6995 for ; Tue, 27 Jul 2010 06:42:32 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-84e4.meeting.ietf.org ([130.129.132.228]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OdkQo-00065t-1C for multimob@ietf.org; Tue, 27 Jul 2010 15:42:54 +0200 Message-ID: <4C4EE258.1060803@informatik.haw-hamburg.de> Date: Tue, 27 Jul 2010 15:42:48 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] draft-ietf-multimob-pmipv6-base-solution-04 - any further comments ? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 13:42:33 -0000 Hi all, we are about to update draft-ietf-multimob-pmipv6-base-solution-04 in response to the recent WG feedback. If there are any further comments in the pipe, please let us know so that we can include those in the update. Thanks, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From sijeon79@gmail.com Tue Jul 27 06:53:14 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C911C3A6A38 for ; Tue, 27 Jul 2010 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_FONT_FACE_BAD=0.884, 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 m55yPp0k7vXk for ; Tue, 27 Jul 2010 06:53:13 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AB24B3A6995 for ; Tue, 27 Jul 2010 06:53:13 -0700 (PDT) Received: by pxi20 with SMTP id 20so550810pxi.31 for ; Tue, 27 Jul 2010 06:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:subject:date :organization:message-id:mime-version:content-type:x-mailer :x-mimeole:thread-index; bh=HPrfje14R6oX233zb+Lqb8ONrDCVl+Qu+V268rp49Do=; b=pJZ430Pijg0Ab7vzVjAJo4L2kPwwTs1fyb2u03Z2BPUgmSuaATU2RC3kRIGNYrjGqe x6DUK34KTGrxElab770BiwYt/4bEjIjaYp1eEvjQF1WfHFMGJ+19cBxk/H+F5irxB/Ia yYqcdcoGa3m/ah7sV+eDH3Ja7HzL8Y2+DOOks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:subject:date:organization:message-id:mime-version :content-type:x-mailer:x-mimeole:thread-index; b=lFyuoyfJN3FYOb0ui6DVHnzt48eEIeVa1qtMstwh8qLF70I3VP9lEB15XD5yXTg3SL Xy+6oEUmXPtnwxrX31nDzPyAnlSyWuVfNJr6JxswEKzP1U9CygR0BDtz6+cPCIsC7Pxm //DT1MeGsZi9ri4fu7eWts49c2XRZWQ2skch0= Received: by 10.142.171.7 with SMTP id t7mr10440297wfe.212.1280238815512; Tue, 27 Jul 2010 06:53:35 -0700 (PDT) Received: from dcn2c060bed2b9 ([125.152.200.44]) by mx.google.com with ESMTPS id 33sm5683621wfg.9.2010.07.27.06.53.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 06:53:34 -0700 (PDT) From: "Seil Jeon" To: Date: Tue, 27 Jul 2010 22:53:25 +0900 Organization: dcn Message-ID: <863982A7E3274670BE8DA8863287F784@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CB2DDE.88144310" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcstkxU73oRKxDENT8K12Chynvh0bQ== Subject: [multimob] directing routing approach as a next step X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 13:53:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01CB2DDE.88144310 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, multimob folks, I'm not at meeting place so I want to briefly talk about direct routing solution discussed as a next rechartering issue in today meeting. A direct routing approach can reduce "essentially" network load and tunnel/bandwidth problems without "modification" of PMIPv6. It can be accepted as evolutionary solution to current ISP. A WiMAX or 3GPP can have native solution for multicasting. In certain point, this method can be coordinated with their solution. Additionally, I think this solution could be used as complete set with WG tunnel-based approach for mobile multicasting. Welcome comments, Welcome cooperation.. Best regards, Seil Jeon ------=_NextPart_000_003A_01CB2DDE.88144310 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
 
Hi, multimob=20 folks,

I'm not at meeting place so I want = to briefly talk about direct routing = solution discussed as a next rechartering issue in today=20 meeting.
 
A=20 direct routing approach can=20 reduce "essentially" network load and tunnel/bandwidth problems=20 without "modification" of PMIPv6.
 
It can be accepted = as=20 evolutionary solution to current ISP.
 
A WiMAX or 3GPP can have = native solution for=20 multicasting. In certain point, this=20 method can be coordinated with their solution.
 
Additionally, I think this=20 solution could be used as complete = set=20 with WG=20 tunnel-based approach for=20 mobile multicasting.
 
 
 
Welcome=20 comments, Welcome cooperation..
 
 
Best=20 regards,
 
Seil=20 Jeon
------=_NextPart_000_003A_01CB2DDE.88144310-- From luisc@it.uc3m.es Wed Jul 28 05:10:59 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAAF3A6A68 for ; Wed, 28 Jul 2010 05:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 0Kr7ugRzR0JW for ; Wed, 28 Jul 2010 05:10:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5C3063A6A69 for ; Wed, 28 Jul 2010 05:10:48 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 1706D703C8A; Wed, 28 Jul 2010 14:11:09 +0200 (CEST) Received: from 85.62.13.195.static.abi.uni2.es (85.62.13.195.static.abi.uni2.es [85.62.13.195]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 28 Jul 2010 14:11:08 +0200 Message-ID: <20100728141108.yk206ezmccwcwos4@webcartero01.uc3m.es> Date: Wed, 28 Jul 2010 14:11:08 +0200 From: "Luis M. Contreras" To: "Thomas C. Schmidt" References: <4C3B8E59.9090500@informatik.haw-hamburg.de> <20100721202521.97j32pzfcwccg4cg@webcartero01.uc3m.es> <4C4D7523.7040308@informatik.haw-hamburg.de> In-Reply-To: <4C4D7523.7040308@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17534.007 Cc: "multimob@ietf.org" Subject: Re: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 12:10:59 -0000 Thanks Thomas, regarding my second point: > >> 2/ on page 6, step 8 of the handover process by the MAG: I would suggest >> to include some wording about the case the MN has no active multicast >> subscription when receiving the MLD Queries from MAG (that is, the link >> of the MN is removed from the MLD proxy instance.) >> > > Well, if no MLD Report is received, the proxy essentially does > nothing (that was indicated by "if necessary". Actually, the link to > the MN is not removed, it remains a regular downstream link of the > MLD Proxy jut without forwarding entries. > > So I don't see a lot content to add except the remark that "no active > multicast subscriptions will lead to no MLD reports which in turn > will lead to no reaction at the MAG" - or are you referring to > anything I might have missed? > I think I had misunderstood the "Non Listeners Present" state on MLD router side according to RFC2710. There, it is stated that no storage is needed for those links without multicast activity (the forwarding entries that you mention, I guess) but in some way the association between downstream intrerface and proxy instance has to be kept (e.g., from the BUL). It is clear now. The text you propose is good for me, if you consider it relevant to be included. Thanks, regards, Luis From behcetsarikaya@yahoo.com Thu Jul 29 04:35:53 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BFC28C108 for ; Thu, 29 Jul 2010 04:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] 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 226-62VlP0Ya for ; Thu, 29 Jul 2010 04:35:52 -0700 (PDT) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 1711B3A69DA for ; Thu, 29 Jul 2010 04:35:52 -0700 (PDT) Received: (qmail 10238 invoked by uid 60001); 29 Jul 2010 11:36:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280403372; bh=Co6saJxr6mfJYezA8XXbYypAKX3WuGSrl0mE4QDlUO8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=hVH37lT75AQd8N7OFZasSUJJpsxIwM22s0U5bt1LFJxkAxegGdaSH+npowr2bas/BpO5Uy/tlxqjhvZlkUzsmhKeo7Hitk/CuksC2fDqRDptRg0ic4ZvYfdZPo2Ih1bSGxyJcvnDQHHWabIeBij+fanMmCyTbDldWGhQgsjIrH0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qDsG5R2VCVut1dA8H6U9yWRZRxy9IlZmdWwSY7D4xnVNNLZe7VMY0N+gno1m7VO2roDJBGNMT9/QLbBCtw3LH+qe1fUFz2oQomgp894LUF/m59BYCr7ozxhpscYC6OV1zXGiiM48WumNTf4U6Lo7wWr0xpBN+lXwLVnQ+hzFyUc=; Message-ID: <916656.9774.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: oKX4sTAVM1npyKvsor.pfUQLUVgNEMl.uPvXSNF7M2_MYVN FCYhc7U8miPjkwjmgK7bXsKNzeF5OILY1JramEtWTvsjMNzLl7bbllFogJZo uN0Y7yVZ4vIMKWWOBXhPWHu4GhaYS43ufvkTwTvvD8cB.l2sd24zKh0cvpXi BUKwZxJoDDpaYD_QSQaJ53GILeb8JcLRToFZXrz3A1dUuVKzaBZjwh7xF8aq diCItXgrcQ7ivNP_tTFBSOCyCuRiGbe7eEVNFf.mbyUPUJ2ipa6tKhUP_5XV gm9vJx5F2jNTfkliTOcpkuMwYA.3VynTj0a05XCqS8dOqKY9Fnb790QV4C1U 1CO2K2aMTSbg- Received: from [130.129.112.247] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 29 Jul 2010 04:36:12 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 Date: Thu, 29 Jul 2010 04:36:12 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] IETF 78 Minutes 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: , X-List-Received-Date: Thu, 29 Jul 2010 11:35:53 -0000 Hi all, Minutes are posted at http://www.ietf.org/proceedings/78/minutes/multimob.txt Please check it to see if any changes are needed. Many thanks to Matthias and Gorry! Regards, Chairs From asaeda@sfc.wide.ad.jp Thu Jul 29 04:50:18 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11C428C159 for ; Thu, 29 Jul 2010 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.33 X-Spam-Level: X-Spam-Status: No, score=-97.33 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfICB86s0n2q for ; Thu, 29 Jul 2010 04:50:11 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id F2E6028C153 for ; Thu, 29 Jul 2010 04:50:10 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:df8:0:112:226:8ff:feec:a255]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0DFBE278079; Thu, 29 Jul 2010 20:50:30 +0900 (JST) Date: Thu, 29 Jul 2010 20:50:28 +0900 (JST) Message-Id: <20100729.205028.173416156.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <916656.9774.qm@web111404.mail.gq1.yahoo.com> References: <916656.9774.qm@web111404.mail.gq1.yahoo.com> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] IETF 78 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 11:50:19 -0000 There is one mistake for my comment. The minutes says; Hitoshi: Good idea to use unciast query, but it is impossible to do this without changing the protocol. but I said, Hitoshi: Good idea to mix unciast and multicast queries by different timers, but it is impossible to do this without changing the protocol. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Thu Jul 29 04:52:25 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BC128C118 for ; Thu, 29 Jul 2010 04:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.352 X-Spam-Level: X-Spam-Status: No, score=-98.352 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrhG6R67BYXg for ; Thu, 29 Jul 2010 04:52:24 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 75F5F28C178 for ; Thu, 29 Jul 2010 04:52:24 -0700 (PDT) Received: from localhost (dhcp-7770.meeting.ietf.org [130.129.119.112]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B6EF2278132 for ; Thu, 29 Jul 2010 20:52:44 +0900 (JST) Date: Thu, 29 Jul 2010 20:52:41 +0900 (JST) Message-Id: <20100729.205241.247839065.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20100729.205028.173416156.asaeda@sfc.wide.ad.jp> References: <916656.9774.qm@web111404.mail.gq1.yahoo.com> <20100729.205028.173416156.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] IETF 78 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 11:52:25 -0000 > The minutes says; > > Hitoshi: Good idea to use unciast query, but it is impossible to do this > without changing the protocol. > > but I said, > > Hitoshi: Good idea to mix unciast and multicast queries by different > timers, but it is impossible to do this without changing the protocol. Sorry, but more precisely, Hitoshi: Good idea to mix unciast and multicast general queries by different timers, but it is impossible to do this without changing the protocol. Thanks, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Thu Jul 29 09:26:39 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0D33A679F for ; Thu, 29 Jul 2010 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.191, 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 Qtoenz2sO54v for ; Thu, 29 Jul 2010 09:26:38 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 557693A6862 for ; Thu, 29 Jul 2010 09:26:38 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-84e4.meeting.ietf.org ([130.129.132.228]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OeVwi-000PFF-7o for multimob@ietf.org; Thu, 29 Jul 2010 18:27:00 +0200 Message-ID: <4C51ABC8.2060901@informatik.haw-hamburg.de> Date: Thu, 29 Jul 2010 18:26:48 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 16:26:39 -0000 Hi all, we have now updated the draft to include the latest WG comments and reviews. The new version should be available shortly at http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05 Best regards, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-05 Date: Thu, 29 Jul 2010 09:19:19 -0700 (PDT) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC: schmidt@informatik.haw-hamburg.de,mw@link-lab.net,suresh.krishnan@ericsson.com A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-05.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-ietf-multimob-pmipv6-base-solution Revision: 05 Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains Creation_date: 2010-07-28 WG ID: multimob Number_of_pages: 21 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. The IETF Secretariat. From root@core3.amsl.com Thu Jul 29 09:30:08 2010 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0C98E3A68DA; Thu, 29 Jul 2010 09:30:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100729163008.0C98E3A68DA@core3.amsl.com> Date: Thu, 29 Jul 2010 09:30:07 -0700 (PDT) Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-05.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: , X-List-Received-Date: Thu, 29 Jul 2010 16:30:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-05.txt Pages : 21 Date : 2010-07-29 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-05.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-29091919.I-D@ietf.org> --NextPart-- From sheheryar125@gmail.com Fri Jul 30 00:26:37 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CBD3A6A94 for ; Fri, 30 Jul 2010 00:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, 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 74rfnLgUX47h for ; Fri, 30 Jul 2010 00:26:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3EC053A6A97 for ; Fri, 30 Jul 2010 00:26:36 -0700 (PDT) Received: by iwn38 with SMTP id 38so1173049iwn.31 for ; Fri, 30 Jul 2010 00:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=lIO+dlFu3I71q5AtIF+murrG4QvD+XSJIjIOeOM25YY=; b=UeyO/kc2C4mXDzeizsUw8r+ikOMigImGJlTfN6wS8BDEL1wFaRCtJY7d/6IKRt0VEA k3h2B6eJ2qNLdsEJ0EEnaSyltGg2s5HF7NH2qhwHGTZpI9CdWf7N55j3pEQ6Ij4YhYzp DpOsW/CzUzXEYNlNeFh5/5106TC4H1SaOsgtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h/DO8s4KJ36saFwgOJ9ZXETEvnfw9E5RzqPBGV4DIDMWNiYYGf6kK1b230mlxBOaI1 0DL3S/eOBjHW8gsQPFIFxdCEM9SlZY4YiO/CCmTZJQ647adEujux7i9ZVR7a5lynTRay PbZGerB613Sp4bzxUlfQ0aFyhwEmXScizlXYk= MIME-Version: 1.0 Received: by 10.231.174.84 with SMTP id s20mr1478941ibz.94.1280474820669; Fri, 30 Jul 2010 00:27:00 -0700 (PDT) Received: by 10.231.17.66 with HTTP; Fri, 30 Jul 2010 00:27:00 -0700 (PDT) Date: Fri, 30 Jul 2010 12:27:00 +0500 Message-ID: From: shery sheryar To: "multimob@ietf.org" Content-Type: multipart/alternative; boundary=0016364ece56d47225048c95c6ef Subject: [multimob] About draft-ietf-multimob-pmipv6-base-solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 07:26:37 -0000 --0016364ece56d47225048c95c6ef Content-Type: text/plain; charset=ISO-8859-1 Hi all, Can you please guide me, for using MLD messages over IPSec tunnel. I mean if MAG and Mobile Node (MN) have established IPSec over the tunnel through some non-trusted access network. Thanks Sheheryar --0016364ece56d47225048c95c6ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
=A0Can you please guide me, for using MLD messages over IPSec tunnel. = I mean if MAG and Mobile Node (MN) have established IPSec over the tunnel t= hrough some non-trusted access network.
=A0
Thanks
=A0
Sheheryar
--0016364ece56d47225048c95c6ef-- From behcetsarikaya@yahoo.com Fri Jul 30 02:12:11 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D24528C2BE for ; Fri, 30 Jul 2010 02:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] 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 lw3f-7M6lIa4 for ; Fri, 30 Jul 2010 02:12:10 -0700 (PDT) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 1F69F28C2C4 for ; Fri, 30 Jul 2010 02:12:09 -0700 (PDT) Received: (qmail 73521 invoked by uid 60001); 30 Jul 2010 09:12:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280481151; bh=CM8bY/amhlFl3HA/WL9LagGtDPPzm9Bz1JKVKtv7GtU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KUlaRaXaLeNdXb+26iQR2ZDqcsGif+hb2xrk3oFsD2qzo1S+XOpOylo4t5knCoMaVvzfvxIsug5UVRuQnd98okjWIJRDGd1FU1UEfNf6OrHDa1Do7ebrJcdbNomILxWaQBAAfOTXDha/pCBegLErBKEC4iwGv4EGlIvn07jlAgw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cCOsTHAu1TlN4ZWHIhAreEvHShC83PQMi1AVTT7C4i9lca/HbWyZBj0WOmLarr+SSAfbxmUXZqn3/OwRGX+SghPXTA6qc+OXJdIfUI7pMCH2L+dMB4Cv4pP9mXsXEX1okWGfNh0dCx0wzy7/kyefTsMqM8WIbVnGTSq4Dc1LDf0=; Message-ID: <183696.72958.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: dlsUjdwVM1mvmFEoMCn8hgBCQ3o1F1a.7qLwIdPFHtC0ArZ KpAbc7bemF40JjjmubB8NvUWES2FTB7GYWo_PyTIkZ4Zvg0q8fk5FgLBQ6vs hD6XvWGdKcR6JgAgDMR4nYddyNu6F9O6preJAwjTwGandyQlzVzzqy5gpYUQ T.88gtPzgv.2bcqapdw5npQoY95pT8ItR7.uTr8RloBwnbZTWeh8IfHrLNLx GQZeIE4wzrj00oFPanACBspAWIkkmIVL_3PKsx2bHroOpvKo_TDbNmG2DCFc w_r8YLVqz48nppa2W8vspHHb8Ixk1AlyAdNGaqW26BAgXWfXVYuxFHodvFZs SZgjSHKGTeBOQfxAoyGtLk3Iv8R.GG9OZ Received: from [130.129.112.247] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 30 Jul 2010 02:12:30 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: Date: Fri, 30 Jul 2010 02:12:30 -0700 (PDT) From: Behcet Sarikaya To: shery sheryar , "multimob@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] About draft-ietf-multimob-pmipv6-base-solution 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: , X-List-Received-Date: Fri, 30 Jul 2010 09:12:11 -0000 Hi Sherry, > >From: shery sheryar >To: "multimob@ietf.org" >Sent: Fri, July 30, 2010 2:27:00 AM >Subject: [multimob] About draft-ietf-multimob-pmipv6-base-solution > > >Hi all, > > Can you please guide me, for using MLD messages over IPSec tunnel. I mean if >MAG and Mobile Node (MN) have established IPSec over the tunnel through some >non-trusted access network. > I think this is 3GPP kind of deployment. MLD messages should be sent back and forth over the IPSec tunnel as payload. I don't see any problems. It could also be a way of securing MLD messages. To shed more light, I found this draft: http://tools.ietf.org/html/draft-tschofenig-v6ops-secure-tunnels-03 which talks about SPD are used for protecting link-local traffic. Regards, Behcet From sijeon79@gmail.com Fri Jul 30 06:09:24 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496913A69A6 for ; Fri, 30 Jul 2010 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 dflGlNukEyIa for ; Fri, 30 Jul 2010 06:09:22 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E02113A6909 for ; Fri, 30 Jul 2010 06:09:22 -0700 (PDT) Received: by pvd12 with SMTP id 12so597668pvd.31 for ; Fri, 30 Jul 2010 06:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :thread-index:in-reply-to; bh=bgOUGoAIRpU7in8HKH4mbwbK+BusS6A12RWT/ciWJQc=; b=FwGT6XfXTItYDl+lADJnDv3ViNzH/ni2PeZHr/KSvRtwj6wBG4kgsNGqbhTBHooDPO zwEJZs4N83uHE9aWhFvyJ71S2dewwA7o1jAMuCI2Q6CfyezeRF6Is+pFC6KG9/hxDX+I 2Q5ugP6e8r2/1MOidMAQZhxT9WHtGeGu1jqWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :x-mimeole:thread-index:in-reply-to; b=vgaOx2S2L4F5tLn1/GDW/EqWKZUqOa08SvuorK1hU5mDLPT+AWINI33bM9ciQB8HIG PpMAxb+pWY0dwhKS7wk3pUBAHFG/vt159kG7WE7fmsh5VJrHlpTtNOQLKxJnzFsunMz3 SchvJ0j3fJJH19iSqD3mlrzOX3wPUsht4qPF8= Received: by 10.114.24.1 with SMTP id 1mr2237762wax.76.1280495387558; Fri, 30 Jul 2010 06:09:47 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id s5sm3727846wak.0.2010.07.30.06.09.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Jul 2010 06:09:46 -0700 (PDT) From: "Seil Jeon" To: "'Thomas C. Schmidt'" References: <4C51ABC8.2060901@informatik.haw-hamburg.de> Date: Fri, 30 Jul 2010 22:09:56 +0900 Organization: dcn Message-ID: <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsvOuqO42Gf0DsQRV61VU+Md9frCAArB0cA In-Reply-To: <4C51ABC8.2060901@informatik.haw-hamburg.de> Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:09:24 -0000 Dear Schmidt, Now, I'm developing several PMIPv6 multicasting system to compare performance. But I have a question in the case of multiple MNs and multiple LMAs. There are LMA1, LMA2, MN1, MN2. These nodes are connected at same MAG. The PMIPv6 tunnel of MAG-LMA1, MAG-LMA2 is established. When MAG receives MLD report message from MN1, how can MAG determine MN's LMA because there's no information in upstream interface in MAG. Best Regards Seil Jeon -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt Sent: Friday, July 30, 2010 1:27 AM To: multimob@ietf.org Subject: [multimob] Fwd: New Version Notification fordraft-ietf-multimob- pmipv6-base-solution-05 Hi all, we have now updated the draft to include the latest WG comments and reviews. The new version should be available shortly at http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05 Best regards, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-05 Date: Thu, 29 Jul 2010 09:19:19 -0700 (PDT) From: IETF I-D Submission Tool To: Schmidt@informatik.haw-hamburg.de CC: schmidt@informatik.haw-hamburg.de,mw@link- lab.net,suresh.krishnan@ericsson.com A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-05.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-ietf-multimob-pmipv6-base-solution Revision: 05 Title: Base Deployment for Multicast Listener Support in PMIPv6 Domains Creation_date: 2010-07-28 WG ID: multimob Number_of_pages: 21 Abstract: This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A support for mobile multicast senders is outside the scope of this document. The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Fri Jul 30 12:57:23 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA82E3A6B05 for ; Fri, 30 Jul 2010 12:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ia-HVXyCwZ9k for ; Fri, 30 Jul 2010 12:57:22 -0700 (PDT) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id BDEA93A6B0D for ; Fri, 30 Jul 2010 12:57:21 -0700 (PDT) Received: (qmail 20599 invoked by uid 60001); 30 Jul 2010 19:57:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280519864; bh=/OsDOcx/AxM8/gqt8Y/ie34GX3LtH1GjxjYAFL7Xgmc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vGkguv03c4u8XL0Q8SkgOZoSxLB0uq8m7+bzmFpWB/OJkoNsIU7EiPKas1SW/ikuVQF3e/+Pa/LlUojZPLMtK6bz17enA2xydBhR8U0hmrFpaGNGWZTApfDk/4SxjKQpw7RSn+/ymEgoK/Ys2L0EynviEwsZJO4+bpuujY2M1TQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EajLPVyo3hl7Uqm7rZYTXQzazzCL8SGYBV+DX6Ea6x755mJPIrkUgeSBoRTdVEHve5YQJ8A33RkHD8WSrvGAn47fbHqsYi+DdLUDcsZoqx6K573wuuRbNLQB2IluPYPiC60uw1M5b8581aPl5Bd6c1vxfTE7/X0osssRjj+hdpY=; Message-ID: <114747.19603.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: KZBAYqoVM1nZqEjQ7UVVgUTrcs8TUoqHcnQHvLsnLUCZ1VC j.GvaRIgVlWlUNwlBDg68QSrMke_aC39HD5IYexCWDSKyeaQxXlqSqnpmfX_ ZhEQIhpDc2N9UFnPZasvxPF0ErNNG0klYDwst6_Pth93GWtj_75e4V8Fka3N q2qengMKnkcVFNPneWzgF2RRRKDMqRZaHrgqoMntM.RPzOH73G6Lcr.C0WAX aVQ6FXr_npf112AUkmPeR61nnihxGUBmRD4C4KNSFXlD5NlOuP40T3Zi.WMa iee8ITTqLnT.XJrzmwQAyBfsLlDCuaKmbbScGW85H4bPEEWfSKYrolFGA01t wINRG.gzJqx_7mqgrzA-- Received: from [79.220.163.144] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 30 Jul 2010 12:57:43 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> Date: Fri, 30 Jul 2010 12:57:43 -0700 (PDT) From: Behcet Sarikaya To: sijeon79@gmail.com, "Thomas C. Schmidt" In-Reply-To: <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-05 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: , X-List-Received-Date: Fri, 30 Jul 2010 19:57:23 -0000 Hi Seil, The way it works is a bit complicated. In http://tools.ietf.org/html/draft-ietf-netlmm-lma-discovery-04 MN goes thru access authentication possibly triggered by MLD Report message. AAA server returns LMA address to the NAS which is colocated with MAG. There are other ways though. In http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-02.txt stateless DHCP is used by MAG to request LMA address for this MN from DHCP server. Also it could be DNS based, like in http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-03.txt MAG uses DNS service name to get LMA addresses and pick one for this MN. Hope this helps. Regards, Behcet ----- Original Message ---- > From: Seil Jeon > To: Thomas C. Schmidt > Cc: multimob@ietf.org > Sent: Fri, July 30, 2010 8:09:56 AM > Subject: Re: [multimob] Fwd: New Version Notification >fordraft-ietf-multimob-pmipv6-base-solution-05 > > > Dear Schmidt, > > Now, I'm developing several PMIPv6 multicasting system to compare > performance. > > But I have a question in the case of multiple MNs and multiple LMAs. > > There are LMA1, LMA2, MN1, MN2. These nodes are connected at same MAG. > > The PMIPv6 tunnel of MAG-LMA1, MAG-LMA2 is established. > > When MAG receives MLD report message from MN1, how can MAG determine MN's > LMA > > because there's no information in upstream interface in MAG. > > > > Best Regards > > Seil Jeon > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Friday, July 30, 2010 1:27 AM > To: multimob@ietf.org > Subject: [multimob] Fwd: New Version Notification fordraft-ietf-multimob- > pmipv6-base-solution-05 > > Hi all, > > we have now updated the draft to include the latest WG comments and reviews. > > The new version should be available shortly at > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05 > > Best regards, > > Thomas > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-multimob-pmipv6-base-solution-05 > Date: Thu, 29 Jul 2010 09:19:19 -0700 (PDT) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC: > schmidt@informatik.haw-hamburg.de,mw@link- > lab.net,suresh.krishnan@ericsson.com > > > A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-05.txt > has been successfully submitted by Thomas Schmidt and posted to the IETF > repository. > > Filename: draft-ietf-multimob-pmipv6-base-solution > Revision: 05 > Title: Base Deployment for Multicast Listener Support in PMIPv6 > Domains > Creation_date: 2010-07-28 > WG ID: multimob > Number_of_pages: 21 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. A support for mobile > multicast senders is outside the scope of this document. > > > > > The IETF Secretariat. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From sijeon79@gmail.com Fri Jul 30 21:45:45 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64C03A6937 for ; Fri, 30 Jul 2010 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 iV5fTT8JURDV for ; Fri, 30 Jul 2010 21:45:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 06DB73A6820 for ; Fri, 30 Jul 2010 21:45:43 -0700 (PDT) Received: by pwj1 with SMTP id 1so894939pwj.31 for ; Fri, 30 Jul 2010 21:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :in-reply-to:thread-index; bh=5j7w/2LjvbFc3gqbJv11FwJHlMmeEmUBWEMrH8Hux1w=; b=DhoQ4A+GCfgjOzCmmgCDt70lPz2hWp8jCi9JQA0I+8mrSyN3DNU+jL7jW+dLLl2TP4 569H4b/FKt6t4us/St81SPkyoC+XIRDW7tvoY3SeMNgXaQ6u+p+x8VLWXtTORxWHBEBq oTsXjhVIDPZ5OiOK3dLoyF35kaz3S/CZmIpTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :x-mimeole:in-reply-to:thread-index; b=U/7XBM7dj3wZc44RX03OQWSPaDGs2QGJbcZrCdgO6AcmHRl5EzxW5gO1lw24QnUndA 1Vvlv71Djg11s/9EOiVg0BtJdyVS+863Qn7d4sA/RBQPYQNTFhumslgsw9a8yiGzcApz tqc0fUqP/qLrjQTWc6uUpfRCfkCMAfHT39FCQ= Received: by 10.114.74.7 with SMTP id w7mr3424814waa.85.1280551568426; Fri, 30 Jul 2010 21:46:08 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id c10sm5228151wam.13.2010.07.30.21.46.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Jul 2010 21:46:07 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" , "'Thomas C. Schmidt'" References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> Date: Sat, 31 Jul 2010 13:45:59 +0900 Organization: dcn Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <114747.19603.qm@web111408.mail.gq1.yahoo.com> Thread-Index: AcswIXqm0MtY9P0dQn262ujBdWK6vwARkiyw Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 04:45:45 -0000 Hi Behcet, Now, I assume that PBU/PBA procedure already done for unicasting so LMA #1 has BCE for MN #1, LMA #2 has BCE for MN #2. In dedicated case, it could be what you say because multicasting LMA is designated. However, in combined case (WG document), it could be? Because AAA server should return the registered LMA #1 address according to the MN #1. How can AAA know MN's currently registered LMA? Because MLD report message has no MN-id information. Best Regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Saturday, July 31, 2010 4:58 AM To: sijeon79@gmail.com; Thomas C. Schmidt Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf- multimob-pmipv6-base-solution-05 Hi Seil, The way it works is a bit complicated. In http://tools.ietf.org/html/draft-ietf-netlmm-lma-discovery-04 MN goes thru access authentication possibly triggered by MLD Report message. AAA server returns LMA address to the NAS which is colocated with MAG. There are other ways though. In http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-02.txt stateless DHCP is used by MAG to request LMA address for this MN from DHCP server. Also it could be DNS based, like in http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-03.txt MAG uses DNS service name to get LMA addresses and pick one for this MN. Hope this helps. Regards, Behcet ----- Original Message ---- > From: Seil Jeon > To: Thomas C. Schmidt > Cc: multimob@ietf.org > Sent: Fri, July 30, 2010 8:09:56 AM > Subject: Re: [multimob] Fwd: New Version Notification >fordraft-ietf-multimob-pmipv6-base-solution-05 > > > Dear Schmidt, > > Now, I'm developing several PMIPv6 multicasting system to compare > performance. > > But I have a question in the case of multiple MNs and multiple LMAs. > > There are LMA1, LMA2, MN1, MN2. These nodes are connected at same MAG. > > The PMIPv6 tunnel of MAG-LMA1, MAG-LMA2 is established. > > When MAG receives MLD report message from MN1, how can MAG determine > MN's LMA > > because there's no information in upstream interface in MAG. > > > > Best Regards > > Seil Jeon > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Thomas C. Schmidt > Sent: Friday, July 30, 2010 1:27 AM > To: multimob@ietf.org > Subject: [multimob] Fwd: New Version Notification > fordraft-ietf-multimob- > pmipv6-base-solution-05 > > Hi all, > > we have now updated the draft to include the latest WG comments and reviews. > > The new version should be available shortly at > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05 > > Best regards, > > Thomas > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-multimob-pmipv6-base-solution-05 > Date: Thu, 29 Jul 2010 09:19:19 -0700 (PDT) > From: IETF I-D Submission Tool > To: Schmidt@informatik.haw-hamburg.de > CC: > schmidt@informatik.haw-hamburg.de,mw@link- > lab.net,suresh.krishnan@ericsson.com > > > A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-05.txt > has been successfully submitted by Thomas Schmidt and posted to the > IETF repository. > > Filename: draft-ietf-multimob-pmipv6-base-solution > Revision: 05 > Title: Base Deployment for Multicast Listener Support in PMIPv6 > Domains > Creation_date: 2010-07-28 > WG ID: multimob > Number_of_pages: 21 > > Abstract: > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. A support for mobile > multicast senders is outside the scope of this document. > > > > > The IETF Secretariat. > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From schmidt@informatik.haw-hamburg.de Sat Jul 31 01:29:06 2010 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63973A695B for ; Sat, 31 Jul 2010 01:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 8NkuxvOd-g6O for ; Sat, 31 Jul 2010 01:29:05 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 999293A6987 for ; Sat, 31 Jul 2010 01:29:02 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178061179.adsl.alicedsl.de ([85.178.61.179] helo=[192.168.178.39]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Of7Re-000NfP-Uz; Sat, 31 Jul 2010 10:29:27 +0200 Message-ID: <4C53DED9.9070708@informatik.haw-hamburg.de> Date: Sat, 31 Jul 2010 10:29:13 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: sijeon79@gmail.com References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 08:29:06 -0000 Hi Seil, I'm not exactly sure about understanding you correctly. However, it appears to me that you do not consider the point-to-point link model currently in use by PMIPv6: An MLD message arrives at such a ptp link. Even though the MLD has no identification record of the MN (after address configuration it of course contains a source address), each message can be associated with the MN via the link (downstream interface of the MLD proxy at MAG). At the LMA, you don't need MN-specific multicast operations: LMA learns about multicast forwarding from aggregated reports obtained via the MLD proxy at the MAG. The latter seems perfectly fine, as multicast data is meant not to reach a single MN alone. Ideally, Mcast data is received by a (possibly large) group of receivers. In case you are looking for individual accounting of mcast data for each MN, the PMIP protocol would need extensions. An example could be, that AAA returns an admission record to the MAG so that an extended MLD proxy instance could decide on whether to include MN's downlink in operation or not. However, this is beyond the scope of the current charter, but could be an interesting extension - even though it is not clear to me, whether operators would want to do accounting on an individual basis instead of just offering multicast as a flat rate service. Best regards, Thomas On 31.07.2010 06:45, Seil Jeon wrote: > > Hi Behcet, > > Now, I assume that PBU/PBA procedure already done for unicasting > > so LMA #1 has BCE for MN #1, LMA #2 has BCE for MN #2. > > > In dedicated case, it could be what you say because multicasting LMA is > designated. > > However, in combined case (WG document), it could be? > > Because AAA server should return the registered LMA #1 address according to > the MN #1. > > > How can AAA know MN's currently registered LMA? > > Because MLD report message has no MN-id information. > > > > Best Regards, > > Seil Jeon > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Saturday, July 31, 2010 4:58 AM > To: sijeon79@gmail.com; Thomas C. Schmidt > Cc: multimob@ietf.org > Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf- > multimob-pmipv6-base-solution-05 > > Hi Seil, > The way it works is a bit complicated. In > http://tools.ietf.org/html/draft-ietf-netlmm-lma-discovery-04 > MN goes thru access authentication possibly triggered by MLD Report > message. AAA server returns LMA address to the NAS which is colocated with > MAG. > > There are other ways though. In > http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-02.txt > stateless DHCP is used by MAG to request LMA address for this MN from DHCP > server. > > Also it could be DNS based, like in > http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-03.txt > > MAG uses DNS service name to get LMA addresses and pick one for this MN. > > Hope this helps. > > Regards, > > Behcet > > > > ----- Original Message ---- >> From: Seil Jeon >> To: Thomas C. Schmidt >> Cc: multimob@ietf.org >> Sent: Fri, July 30, 2010 8:09:56 AM >> Subject: Re: [multimob] Fwd: New Version Notification >> fordraft-ietf-multimob-pmipv6-base-solution-05 >> >> >> Dear Schmidt, >> >> Now, I'm developing several PMIPv6 multicasting system to compare >> performance. >> >> But I have a question in the case of multiple MNs and multiple LMAs. >> >> There are LMA1, LMA2, MN1, MN2. These nodes are connected at same MAG. >> >> The PMIPv6 tunnel of MAG-LMA1, MAG-LMA2 is established. >> >> When MAG receives MLD report message from MN1, how can MAG determine >> MN's LMA >> >> because there's no information in upstream interface in MAG. >> >> >> >> Best Regards >> >> Seil Jeon >> >> >> -----Original Message----- >> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On >> Behalf Of Thomas C. Schmidt >> Sent: Friday, July 30, 2010 1:27 AM >> To: multimob@ietf.org >> Subject: [multimob] Fwd: New Version Notification >> fordraft-ietf-multimob- >> pmipv6-base-solution-05 >> >> Hi all, >> >> we have now updated the draft to include the latest WG comments and > reviews. >> >> The new version should be available shortly at >> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-05 >> >> Best regards, >> >> Thomas >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-ietf-multimob-pmipv6-base-solution-05 >> Date: Thu, 29 Jul 2010 09:19:19 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: Schmidt@informatik.haw-hamburg.de >> CC: >> schmidt@informatik.haw-hamburg.de,mw@link- >> lab.net,suresh.krishnan@ericsson.com >> >> >> A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-05.txt >> has been successfully submitted by Thomas Schmidt and posted to the >> IETF repository. >> >> Filename: draft-ietf-multimob-pmipv6-base-solution >> Revision: 05 >> Title: Base Deployment for Multicast Listener Support in PMIPv6 >> Domains >> Creation_date: 2010-07-28 >> WG ID: multimob >> Number_of_pages: 21 >> >> Abstract: >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards. Similar to Home Agents in >> Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as >> multicast subscription anchor points, while Mobile Access Gateways >> provide MLD proxy functions. In this scenario, Mobile Nodes remain >> agnostic of multicast mobility operations. A support for mobile >> multicast senders is outside the scope of this document. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °