From sijeon79@gmail.com Sun Aug 1 21:07:08 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 453903A6A01 for ; Sun, 1 Aug 2010 21:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 ZV+rXMJRFROG for ; Sun, 1 Aug 2010 21:07:06 -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 5657F3A68BF for ; Sun, 1 Aug 2010 21:07:06 -0700 (PDT) Received: by pvd12 with SMTP id 12so1387101pvd.31 for ; Sun, 01 Aug 2010 21:07:33 -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=DPK0mQhzGtfpwDoMukB2wDCNS7L8gNTb0/geGwdDyqM=; b=Fce8SUJZ2D6dfTqmIOul+xmCs/E8pD4w+xAgOF6k9nlPcsy9uB7RbaoxL+gWgIftBQ Q5siItoFSPQDffN9yb58ip4Dp4NG8pCSoWbUbx62MNiE+tfMvlOE0PdiFbOUv7ZBVrCH a1rGtUqjIsC8E6JIXKSDcpRUVuT4N0V91qK9M= 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=CHfR2+Vvui4Rq2IPtagMbAgR79oGv1KpahVIBvV7IZLklStDxtFpx8bAZ5MbrGC7Ps RQxhfQcTHo7V1rF3tl8Wf/XdV7SqMo718Egpwb9DV2wPtM1LkjidzsnEMbTVaqHtyOh5 ZMvareB6zAJfq474gsAH+0HfPLUdipCD8Ax0Q= Received: by 10.114.77.10 with SMTP id z10mr6696588waa.168.1280722053481; Sun, 01 Aug 2010 21:07:33 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id c10sm10549037wam.13.2010.08.01.21.07.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Aug 2010 21:07:32 -0700 (PDT) From: "Seil Jeon" To: "'Thomas C. Schmidt'" References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> <4C53DED9.9070708@informatik.haw-hamburg.de> Date: Mon, 2 Aug 2010 13:07:26 +0900 Organization: dcn Message-ID: <357C4435AEEF4ADDB51747D66F93496B@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4C53DED9.9070708@informatik.haw-hamburg.de> Thread-Index: Acswin4iZcoCE4QWSYSBhdfsuCuK/QBbZQ1w Cc: multimob@ietf.org Subject: Re: [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 Reply-To: sijeon79@gmail.com List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 04:07:08 -0000 Hi Thomas, Yes, a LMA doesn't need MN-specific multicast operations. (MN1, MN2 are registered to LMA1, LM2 respectively through standard PMIP procedure.) Even in this scenario, a MAG sends aggregated MLD report message to only LMA? Abstolutely No.. in combined case If you say 'Yes', I think it is 'dedicated' LMA case. My understanding about combined case is very clear. Multicasting service for MN1, MN2 should be provided by LMA1, LM2 that have BCE for each MN. IMHO, please let me know am I wrong? Your regards Seil Jeon =20 -----Original Message----- From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20 Sent: Saturday, July 31, 2010 5:29 PM To: sijeon79@gmail.com Cc: 'Behcet Sarikaya'; multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf- multimob-pmipv6-base-solution-05 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=20 > is designated. > > However, in combined case (WG document), it could be? > > Because AAA server should return the registered LMA #1 address=20 > 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=20 > message. AAA server returns LMA address to the NAS which is colocated=20 > 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=20 > 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=20 >> 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] =20 >> 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-0 >> 5 >> >> 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,=20 >> draft-ietf-multimob-pmipv6-base-solution-05.txt >> has been successfully submitted by Thomas Schmidt and posted to the=20 >> 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=20 >> listener functions in Proxy Mobile IPv6 domains without modifying=20 >> mobility and multicast protocol standards. Similar to Home Agents=20 >> in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as = >> multicast subscription anchor points, while Mobile Access Gateways=20 >> provide MLD proxy functions. In this scenario, Mobile Nodes remain=20 >> agnostic of multicast mobility operations. A support for mobile=20 >> 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 --=20 Prof. Dr. Thomas C. Schmidt =A1=C6 Hamburg University of Applied Sciences Berliner = Tor 7 =A1=C6 =A1=C6 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =A1=C6 =A1=C6 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =A1=C6 =A1=C6 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =A1=C6 From schmidt@informatik.haw-hamburg.de Mon Aug 2 03:17:08 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 818433A6A9C for ; Mon, 2 Aug 2010 03:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45] 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 gagfm9sozjqI for ; Mon, 2 Aug 2010 03:17:07 -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 B77443A6A74 for ; Mon, 2 Aug 2010 03:17:06 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from wwsx024.rz.uni-wuerzburg.de ([132.187.253.24] helo=[172.17.1.226]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ofs5L-000CMu-PD; Mon, 02 Aug 2010 12:17:32 +0200 Message-ID: <4C569B25.7080707@informatik.haw-hamburg.de> Date: Mon, 02 Aug 2010 12:17:09 +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> <4C53DED9.9070708@informatik.haw-hamburg.de> <357C4435AEEF4ADDB51747D66F93496B@dcn2c060bed2b9> In-Reply-To: <357C4435AEEF4ADDB51747D66F93496B@dcn2c060bed2b9> Content-Type: text/plain; charset=EUC-KR 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-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: Mon, 02 Aug 2010 10:17:08 -0000 Hi Seil, sorry, but I still have some trouble understanding what you are pointing at. It appears to me that you ask about the MAG <-> LMA relations for multicast. This is a many-to-many relation for the following reasons: Each LMA can serve many MAGs (as in PMIP unicast). On the other hand, each MAG runs several MLD proxy instances, each having its uplink to a different LMA. Thus, a MAG negotiates and receives multicast by several LMAs, using the MN <-> LMA associations harvested from unicast. Best regards, Thomas On 02.08.2010 06:07, Seil Jeon wrote: > > Hi Thomas, > > Yes, a LMA doesn't need MN-specific multicast operations. > > (MN1, MN2 are registered to LMA1, LM2 respectively through standard PMIP > procedure.) > > > Even in this scenario, a MAG sends aggregated MLD report message to only > LMA? > > Abstolutely No.. in combined case > > If you say 'Yes', I think it is 'dedicated' LMA case. > > My understanding about combined case is very clear. > > Multicasting service for MN1, MN2 should be provided by LMA1, LM2 that > have BCE for each MN. > > IMHO, please let me know am I wrong? > > > > Your regards > > Seil Jeon > > > > -----Original Message----- > From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Sent: Saturday, July 31, 2010 5:29 PM > To: sijeon79@gmail.com > Cc: 'Behcet Sarikaya'; multimob@ietf.org > Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf- > multimob-pmipv6-base-solution-05 > > 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-0 >>> 5 >>> >>> 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 ¡Æ From behcetsarikaya@yahoo.com Mon Aug 2 07:55: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 B5CAD3A6B89 for ; Mon, 2 Aug 2010 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.975, 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 FzBNoCraC1sA for ; Mon, 2 Aug 2010 07:55:24 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 065153A6826 for ; Mon, 2 Aug 2010 07:55:23 -0700 (PDT) Received: (qmail 70750 invoked by uid 60001); 2 Aug 2010 14:55:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280760949; bh=AdQFhj6g8fJhEgUIpDlaE8cYsXb5v+enpPzUk5d5dVY=; 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=cziuMA/dlvujjGtmus0IPzWFNS7oxPc1ZyRegpiZY7tHYvnw/Rm14f40oI+TQY/P2YcGa2mQ9W6GNLw9G73/owU5YB40oubrG0QgAUCl2S+ZFKyVCxGhyD3vOw8P5JY7aMMalSho90+EbEBhdZPiIybHejnwzbL5N4eu/B7G9KI= 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=yr6wCEDTwjM1FFVwuG3JcB0L33ct1r7KDcnH3ZbtND+gLMEufwh9aQCQmRu9905VAmLmY1Rga304UOF6CR3isK4c9gMzmCRbdayT3fJiXl+NPExHwS+wgjXGQXadyO9R0DzC3NY0XCckRuOJmlAuhooIa+77gGFCZnBhVnhtmbU=; Message-ID: <118610.70416.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: ZfZKCqwVM1lLer2nce2.unb_5_1G6dfkJmKDr.pRnR_7QjP nc8o- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 02 Aug 2010 07:55:48 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> Date: Mon, 2 Aug 2010 07:55:48 -0700 (PDT) From: Behcet Sarikaya To: sijeon79@gmail.com, "Thomas C. Schmidt" In-Reply-To: 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: Mon, 02 Aug 2010 14:55:25 -0000 Hi Seil, Sec. 6.1 of RFC 5213 says: The identifier of the attached mobile node, MN-Identifier. This identifier is acquired during the mobile node's attachment to the access link through mechanisms outside the scope of this document. So MN-Id is not obtained from MLD messages. Regards, Behcet ----- Original Message ---- > From: Seil Jeon > To: Behcet Sarikaya ; Thomas C. Schmidt > > Cc: multimob@ietf.org > Sent: Fri, July 30, 2010 11:45:59 PM > Subject: RE: [multimob] Fwd: New Version Notification >fordraft-ietf-multimob-pmipv6-base-solution-05 > > > 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 sijeon79@gmail.com Mon Aug 2 20:59: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 802BE3A6783 for ; Mon, 2 Aug 2010 20:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 F1O5BN9TcKG3 for ; Mon, 2 Aug 2010 20:59:01 -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 F2AD83A6781 for ; Mon, 2 Aug 2010 20:59:00 -0700 (PDT) Received: by pvd12 with SMTP id 12so1740002pvd.31 for ; Mon, 02 Aug 2010 20:59:29 -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=GXB3cTYTRaYsTbhgbFAexnsO5q1E2bO235Ss28sB1nI=; b=dxQcIG0Y4CfOtNTjBFynuaoiEvSe1PBJGb9P9cULA+hNFn4uiW7Oi2BHTV2IuD1DVv 5+ToN1/e4It5ncBVaplXeSmc8xFs4c//wds7MhDQYUJPCCTlslF3UT5qiUeJM8zKFcf/ j0SkBIXcThwuQuNLmjYMNNRwq0Y+6CkyAuMXw= 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=L+Q3RHRJhIvRiDt1CTKV6koqwDph7MYkKIPB4kdwssE9R0YxCAtFCCmhQ0yDkzqx5v pHr1HKPTJP8RFHNLY6hFghGwQ28HREmeHQLx4NBS+MWYjn0GW1d5K8ejzkJUIkMAIsM9 GY3FzLLehJ1E2ezFJRdDgsdzNEsMws7hVtnDw= Received: by 10.142.232.13 with SMTP id e13mr6218508wfh.133.1280807969042; Mon, 02 Aug 2010 20:59:29 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id z1sm8562488wfd.3.2010.08.02.20.59.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 20:59:27 -0700 (PDT) From: "Seil Jeon" To: "'Thomas C. Schmidt'" References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> <4C53DED9.9070708@informatik.haw-hamburg.de> Date: Tue, 3 Aug 2010 12:59:22 +0900 Organization: dcn Message-ID: <506FAD29FAB44D45962D42FB374362D9@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4C53DED9.9070708@informatik.haw-hamburg.de> Thread-Index: Acswin4iZcoCE4QWSYSBhdfsuCuK/QCNT0mQ 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: Tue, 03 Aug 2010 03:59:02 -0000 Dear Thomas, I got the point. As you said, I did not consider the ptp link model. After MN's attachment, each message is associated with the MN via the = link. So, MLD report message could be delivered corresponding upstream = interface. Thanks for your description. With your regards, Seil Jeon =20 -----Original Message----- From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20 Sent: Saturday, July 31, 2010 5:29 PM To: sijeon79@gmail.com Cc: 'Behcet Sarikaya'; multimob@ietf.org Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf- multimob-pmipv6-base-solution-05 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=20 > is designated. > > However, in combined case (WG document), it could be? > > Because AAA server should return the registered LMA #1 address=20 > 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=20 > message. AAA server returns LMA address to the NAS which is colocated=20 > 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=20 > 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=20 >> 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] =20 >> 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-0 >> 5 >> >> 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,=20 >> draft-ietf-multimob-pmipv6-base-solution-05.txt >> has been successfully submitted by Thomas Schmidt and posted to the=20 >> 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=20 >> listener functions in Proxy Mobile IPv6 domains without modifying=20 >> mobility and multicast protocol standards. Similar to Home Agents=20 >> in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as = >> multicast subscription anchor points, while Mobile Access Gateways=20 >> provide MLD proxy functions. In this scenario, Mobile Nodes remain=20 >> agnostic of multicast mobility operations. A support for mobile=20 >> 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 --=20 Prof. Dr. Thomas C. Schmidt =A1=C6 Hamburg University of Applied Sciences Berliner = Tor 7 =A1=C6 =A1=C6 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =A1=C6 =A1=C6 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =A1=C6 =A1=C6 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =A1=C6 From sijeon79@gmail.com Mon Aug 2 20:59:51 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 285703A6805 for ; Mon, 2 Aug 2010 20:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.613, 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 c9J3fRXn5qbm for ; Mon, 2 Aug 2010 20:59:49 -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 DD9E43A6783 for ; Mon, 2 Aug 2010 20:59:49 -0700 (PDT) Received: by pxi20 with SMTP id 20so1744578pxi.31 for ; Mon, 02 Aug 2010 21:00:18 -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=nVdUBUEr1Clj98ENJxHzhYZ8M2gZkUG843Tvx3yWSTc=; b=a8DoOa9v0gIzIEpo7Aj1BZd/cU2NpAPKzKHxj+G+DS9NyMPYzp0QVKi1msJvlekpLM 7J2e4tc132DmKgGtrR3zItpMiyTNFiBe1GQkFZXfknwDkGCYkG/Nr+qcDHt2gpC7B9r9 UJP3p43EkpHBk76GfA5KhQIlZVoJmf4UH0Xyc= 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=aaJ1lx8hdyXs66o9McurucwXes9xExoEH7OLjUWk0x8PCdQffMpCu2oJxk38ChnYu8 ncwsNSy6we9NCMycYMB2QQrZZOZqIYEvSqYZT5VZ4YjlHaVnbdJ0msQ4S17c1xXAqOs8 8uE4ghJdfHZ4tLU8vCvCSBdjQC6aVTqDn3Fns= Received: by 10.142.230.19 with SMTP id c19mr3434072wfh.41.1280808018100; Mon, 02 Aug 2010 21:00:18 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id q27sm8562895wfc.18.2010.08.02.21.00.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 21:00:16 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> <118610.70416.qm@web111403.mail.gq1.yahoo.com> Date: Tue, 3 Aug 2010 13:00:12 +0900 Organization: dcn Message-ID: <8DA5B31CCD824725B0835A8F5F09635B@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 In-Reply-To: <118610.70416.qm@web111403.mail.gq1.yahoo.com> Thread-Index: AcsyUsyCbVnFH1VGSoa5u3GGFv1xjgAa2KcQ Cc: multimob@ietf.org, "'Thomas C. Schmidt'" 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: Tue, 03 Aug 2010 03:59:51 -0000 Dear Behcet, Yes, I know. I didn't point out that. I got the solution..and Thank you. With your regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Monday, August 02, 2010 11:56 PM 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, Sec. 6.1 of RFC 5213 says: The identifier of the attached mobile node, MN-Identifier. This identifier is acquired during the mobile node's attachment to the access link through mechanisms outside the scope of this document. So MN-Id is not obtained from MLD messages. Regards, Behcet ----- Original Message ---- > From: Seil Jeon > To: Behcet Sarikaya ; Thomas C. Schmidt > > Cc: multimob@ietf.org > Sent: Fri, July 30, 2010 11:45:59 PM > Subject: RE: [multimob] Fwd: New Version Notification >fordraft-ietf-multimob-pmipv6-base-solution-05 > > > 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 behcetsarikaya@yahoo.com Tue Aug 3 09:51: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 B4F373A6A96 for ; Tue, 3 Aug 2010 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=0.780, 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 48Q13Oblfzek for ; Tue, 3 Aug 2010 09:51:00 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 2E2B43A69EF for ; Tue, 3 Aug 2010 09:51:00 -0700 (PDT) Received: (qmail 19218 invoked by uid 60001); 3 Aug 2010 16:51:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280854285; bh=6IlS6VU/c6HPk5CDKAQxeTX/bDkorTW981+KCaTB+x8=; 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=XbOWgAWTNYpQMY5cJX9kAUuvzK/CoErivSQWucH3tI2cB/p9OzfYsZLM0LOCy86fDaWUgeE7fwhkH4o7mpvZjZsIKPBNL0AblenDjRyraPqKjzY26QditeLbS0RhBuukiqtgCOqOZ2CFdK02Pmo6Bcvj0xk4zbkWaBa8HgSyCp8= 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=6HPGZ8+j7llgQ5Rk2fHqdWlpnPHPaoWgJDFtDrnb+KQnDGUoF7HAu4HiUlphqK+FRvil7HPNx0D6XpUm+nmG99RYP8GaF8yedpi9CRhf/6THy1119qJUxfE4N8LdauT9hdOndbOMYHtA6EgDCRpJ3NODCDpIhCVnE/j64qTsDLA=; Message-ID: <724898.18721.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: VxxNWpcVM1mJxyaed0X3ACi5bTgh7E5uwl30dea0uH4IOIv _EtHlX4gDKgMRbMBnfbF9e1cbqP8PjAwv2iqzIuPY2NFw5CqmarJFqGXB9pT OtsLALfDxKE2dT72hfqXEcsAeFcoNgkiuzml.pwv50jWJR4R1_.zgS.AztTK dlIXmtH1hiZl.ZxThGRsJ9aD68nUtFHq_u76TgiHvn8ManGeVtUGUKbrp8gv DXM70V70_VjkRyckOQCb.P0JDqOaNE3L4d8dMpnXrdSJumBfZ3oiO.HkUiJG 74hcuI5ckr0w4k.9wjeQeymR7d8qgcnk8K.uMYcgP Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Tue, 03 Aug 2010 09:51:25 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <4C51ABC8.2060901@informatik.haw-hamburg.de> <9CB5D4ADF6794E86BD2366E87F46EA8E@dcn2c060bed2b9> <114747.19603.qm@web111408.mail.gq1.yahoo.com> <4C53DED9.9070708@informatik.haw-hamburg.de> <506FAD29FAB44D45962D42FB374362D9@dcn2c060bed2b9> Date: Tue, 3 Aug 2010 09:51:25 -0700 (PDT) From: Behcet Sarikaya To: sijeon79@gmail.com, "Thomas C. Schmidt" In-Reply-To: <506FAD29FAB44D45962D42FB374362D9@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: Tue, 03 Aug 2010 16:51:01 -0000 > Dear Thomas, > > I got the point. As you said, I did not consider the ptp link model. > > After MN's attachment, each message is associated with the MN via the link. > > So, MLD report message could be delivered corresponding upstream interface. [behcet] This is how cellular links work. I am not sure if it is possible to implement this on a WiFi link which you considered. RAs can be unicast isolating each MN somehow but so-called attach procedure seems difficult to me to emulate on WiFi. Regards, Behcet From sijeon79@gmail.com Tue Aug 3 20:07: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 C29103A6B8F for ; Tue, 3 Aug 2010 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 Gp8gXYdOOGay for ; Tue, 3 Aug 2010 20:07:19 -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 4DA4F3A67B8 for ; Tue, 3 Aug 2010 20:07:19 -0700 (PDT) Received: by pwj1 with SMTP id 1so2101084pwj.31 for ; Tue, 03 Aug 2010 20:07:48 -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:in-reply-to :x-mimeole:thread-index; bh=KrpLpU/A46AelpuhCYrmlUVuB3qx6FJSjPAO7Xha6Ww=; b=MV5BJdAK7mxVet2sUGqYRBGtuNLDTvncaHS4flCXbATRiZVD4JtT3bhlvEwwyBYFfu rq4M70+GMafq1FtOxdkvd5Ui3vHYZBC/B/xocxDdJ9qS3KAPtjB5b0NUC9dPmtloRvSS 5tumLLOFByGPiPTYW0caGah1Cz1ZQiVc6Dz4I= 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 :in-reply-to:x-mimeole:thread-index; b=HKRtq/tMkBzivLi61ELNK15WGbRlKdR4QfFYHT7zLDgmOcvbWtTOvJQFm7dlaFRcwG oRExBbcPRnuUjtW0g5KIlYarlWx/PKg0jaZSk9LwSuZx/wCD1WIBoynBT8ZK4SQmPmxx IY/CLyN5acLv6dle3O1d0Uz4gpQ+aSQrewIdE= Received: by 10.114.36.1 with SMTP id j1mr2817453waj.141.1280891268461; Tue, 03 Aug 2010 20:07:48 -0700 (PDT) Received: from dcn2c060bed2b9 ([220.149.84.225]) by mx.google.com with ESMTPS id c10sm14866553wam.13.2010.08.03.20.07.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 20:07:47 -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> <4C53DED9.9070708@informatik.haw-hamburg.de> <506FAD29FAB44D45962D42FB374362D9@dcn2c060bed2b9> <724898.18721.qm@web111415.mail.gq1.yahoo.com> Date: Wed, 4 Aug 2010 12:07:46 +0900 Organization: dcn Message-ID: <3B1C30378EE44171AB1A449C3FFE7376@dcn2c060bed2b9> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <724898.18721.qm@web111415.mail.gq1.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcszLB2yK586Spn3RoyY3VmqZYqRYwAVbv4g 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: Wed, 04 Aug 2010 03:07:20 -0000 I'm not sure.. but I'm trying to apply PPPoE to linux-based MAG and MN. Regards, Seil Jeon -----Original Message----- From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] Sent: Wednesday, August 04, 2010 1:51 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 > Dear Thomas, > > I got the point. As you said, I did not consider the ptp link model. > > After MN's attachment, each message is associated with the MN via the link. > > So, MLD report message could be delivered corresponding upstream interface. [behcet] This is how cellular links work. I am not sure if it is possible to implement this on a WiFi link which you considered. RAs can be unicast isolating each MN somehow but so-called attach procedure seems difficult to me to emulate on WiFi. Regards, Behcet From behcetsarikaya@yahoo.com Fri Aug 6 07:00:09 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 0AB953A6A7D for ; Fri, 6 Aug 2010 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HTML_MESSAGE=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 D+aXCGgOokGY for ; Fri, 6 Aug 2010 07:00:08 -0700 (PDT) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 1A5D93A6A4F for ; Fri, 6 Aug 2010 07:00:08 -0700 (PDT) Received: (qmail 99627 invoked by uid 60001); 6 Aug 2010 14:00:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1281103236; bh=qSdbEct+XlKuLOlaWqhwOVX9WvJh3kN1jOAxLVGT/Jo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=zhswDTSdNet/YWD4zIP8NnTF81QtLEMbi2kIfY3MW/zPW+z+LSuTVF1KT45fgEYkygyUmEkLbMb1a1EuZGhvgBRk2A+GlLtEd5jI/H6Anx34g+x1PEFBSZB5PsASpBUp5xl3hApsxVICeR4w7f/5v8btLZ6E/4/ukyhUvCkQyzs= 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=2pO8jRBerS/7WnZqoqbl346f0N+yf0otFSycTEu4kJf7zKAD6FCArdHe97fSEjRkeiy1ho+sVUvJkkcZcIkgvkwpV08FXA8+eBuEPsuCnz/5vwOW45GtKKqwjgYopDw9ul9FTTl4rgw4EwtPZ5ZLuhj4NGmO2n8Fi1/2GvQHABQ=; Message-ID: <766768.99444.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: h2CA0aUVM1mk6G03S_GRzTuDAsaaLZMoQdxuTnUIOJFS3k. D0JtrZuW2aQLXa5KY5ddwTtqM0peTWvEWzwFgpFQLc3vI596.cm0GqydSIjD o0pXTJHuMqOROU8vdlIVGZwp.sG5rRgUZJhzxXRgJ0brIwsnUZQWAanu7Czm bgqBbA1STxPj_41DNUfNbeRKmjhn9NebUfXhfVyJQtVccdQL5KqGrYFbiOUS QUUfKjxL4AYrAQsWoNLRIBjIm.9hRGJT.WbB6pxGj.0P3DGyPCWSdUfZzl0P sQwjfZl1GNXFiKs789Gb4DTXqhrbJvJ7eqLqBT_o6x1RJlNDBl7QjxBtKAUQ vYs9zNKHc6FjSF1nDSIo3 Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Fri, 06 Aug 2010 07:00:36 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 Date: Fri, 6 Aug 2010 07:00:36 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2094894472-1281103236=:99444" Subject: [multimob] Fw: Proxy Mobile IPv6 - Open Source Initiative 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, 06 Aug 2010 14:00:09 -0000 --0-2094894472-1281103236=:99444 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A>=0A>----- Forwarded Message ----=0A>From: Sri Gundavelli =0A>To: Carlos Jes=C3=BAs Bernardos Cano ; sij= eon79@gmail.com; Romain =0A>KUNTZ ; subir@research.telcor= dia.com; liebsch@neclab.eu; =0A>ssakane@cisco.com; RYUJI WAKIKAWA ; =0A>Schmidt@informatik.haw-hamburg.de=0A>Cc: "Basavaraj.P= atil@nokia.com" ; Behcet Sarikaya =0A>; Stig Venaas (svenaas) =0A>Sent: Fri, August 6= , 2010 2:05:16 AM=0A>Subject: Proxy Mobile IPv6 - Open Source Initiative=0A= >=0A>Proxy Mobile IPv6 - Open Source Initiative Gentlemen:=0A>=0A>We have b= een getting quite a few requests for Proxy Mobile IPv6 open source =0A>impl= ementation. Essentially, an open sources for the core functions, LMA and = =0A>MAG, supporting all the key specifications, RFC-5213, 5844, 5845, 5846,= 5847.=0A>=0A>I=E2=80=99m sending this mail to all the key folks who have b= een very active in the =0A>MIPv6/NEMO/DSMIPv6 implementations, over the las= t many years working on Kame or =0A>other Linux based implementations. Sinc= e, most of you have strong university =0A>contacts, it would be very helpfu= l if we can start an initiative to develop this =0A>protocol stack and make= it available for vendors and researchers testing various =0A>extensions.= =0A>=0A>This work is getting relevant in many use-cases, such as in WLAN do= main mobility =0A>and chaining with mobile packet core.=0A>=0A>Relevance:= =0A>=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>=0A>1.) For mobility with in a WLAN doma= in=0A>2.) Chaining of mobility domains (WLAN and Mobile Packet Core), such = as over =0A>3GPP S2/a=0A>3.) Only network-based mobility protocol that is s= tandardized in IETF=0A>4.) Many new extensions such as multimob, optimized = routing ... etc are being =0A>specified.=0A>=0A>Its important that we have = freely available open source for testing. Any =0A>thoughts on how to go abo= ut will be greatly appreciated.=0A>=0A>=0A>=0A>=0A>Regards=0A>Sri=0A>=0A>= =0A>=0A> =0A=0A=0A --0-2094894472-1281103236=:99444 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


----- Forwarded Message ----
From: Sri Gundavelli <sgundave@cisc= o.com>
To: Carlos Je= s=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>; sijeon79@gmail.com; Romain= KUNTZ <kuntz@unistra.fr>; subir@research.telcordia.com; liebsch@necl= ab.eu; ssakane@cisco.com; RYUJI WAKIKAWA <ryuji@us.toyota-itc.com>; S= chmidt@informatik.haw-hamburg.de
C= c: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>; Behcet Sari= kaya <sarikaya@ieee.org>; Stig Venaas (svenaas) <svenaas@cisco.com= >
Sent: Fri, August = 6, 2010 2:05:16 AM
Subject:= Proxy Mobile IPv6 - Open Source Initiative

=0A=0A=0AProxy Mobile IPv6 - Open Source Initiative=0A=0AGentleme= n:
=0A
=0AWe have been getting quite a few requests for Proxy Mobile = IPv6 open source implementation. Essentially, an open sources for the core = functions, LMA and MAG, supporting all the key specifications, RFC-5213, 58= 44, 5845, 5846, 5847.
=0A
=0AI=E2=80=99m sending this mail to all the= key folks who have been very active in the MIPv6/NEMO/DSMIPv6 implementati= ons, over the last many years working on Kame or other Linux based implemen= tations. Since, most of you have strong university contacts, it would be ve= ry helpful if we can start an initiative to develop this protocol stack and= make it available for vendors and researchers testing various extensions.<= br>=0A
=0AThis work is getting relevant in many use-cases, such as in WL= AN domain mobility and chaining with mobile packet core.
=0A
=0ARelev= ance:
=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A
=0A1.) For mobility with = in a WLAN domain
=0A2.) Chaining of mobility domains (WLAN and Mobile Pa= cket Core), such as over 3GPP S2/a
=0A3.) Only network-based mobility pr= otocol that is standardized in IETF
=0A4.) Many new extensions such as m= ultimob, optimized routing ... etc are being specified.
=0A
=0AIts im= portant that we have freely available open source for testing. Any thoughts= on how to go about will be greatly appreciated.
=0A
=0A
=0A
= =0A
=0ARegards
=0ASri
=0A
=0A
=0A
=0A=0A
=0A

=0A=0A --0-2094894472-1281103236=:99444-- From zhoudi@h3c.com Thu Aug 19 00:01:48 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 05C073A68DD; Thu, 19 Aug 2010 00:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.884 X-Spam-Level: X-Spam-Status: No, score=0.884 tagged_above=-999 required=5 tests=[AWL=1.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 86OIhYEEkDDs; Thu, 19 Aug 2010 00:01:47 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.50]) by core3.amsl.com (Postfix) with ESMTP id 361DC3A67E5; Thu, 19 Aug 2010 00:01:40 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0L7E00ERW0GHBJ@h3cml01-in.huawei-3com.com>; Thu, 19 Aug 2010 14:53:05 +0800 (CST) Received: from H3CHUB01-EX.srv.huawei-3com.com ([10.63.16.181]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPS id <0L7E007C80GHID@h3cml01-in.huawei-3com.com>; Thu, 19 Aug 2010 14:53:05 +0800 (CST) Received: from h3cedge01-ex.h3c.com (172.25.12.73) by H3CHUB01-EX.srv.huawei-3com.com (10.63.16.181) with Microsoft SMTP Server (TLS) id 14.0.689.0; Thu, 19 Aug 2010 14:53:04 +0800 Received: from h3cimss01-ss (172.25.12.100) by h3cedge01-ex.h3c.com (172.25.12.73) with Microsoft SMTP Server id 14.0.689.0; Thu, 19 Aug 2010 15:15:31 +0800 Received: from unknown (HELO z00782a) ([10.55.72.60]) by smtp2.h3c.com with ESMTP; Thu, 19 Aug 2010 14:52:58 +0800 Date: Thu, 19 Aug 2010 14:52:44 +0800 From: zhoudi To: Indranil Bhattacharya , Greg Shepherd , pim@ietf.org, mboned@ietf.org, multimob@ietf.org, magma@ietf.org Message-id: <009201cb3f6b$206dd2f0$240a0164@h3c.huawei3com.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=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-TM-IMSS-Message-ID: <1b39a62a00150849@h3c.com> X-Mailman-Approved-At: Thu, 19 Aug 2010 07:29:11 -0700 Cc: young@h3c.com, Hui Deng Subject: [multimob] Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-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: Thu, 19 Aug 2010 07:01:48 -0000 Hi, According to your advice, I newly submitted the problem-statement for the problem of Unnecessary Multicast Flooding between sources and PIM FHRs. http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/ Welcome to comment on the problem and bring forward solutions. Thanks and Regards. ZhouDi Subject: New Version Notification for draft-dizhou-pim-umf-problem-statement-00 > > A new version of I-D, draft-dizhou-pim-umf-problem-statement-00.txt has been successfully submitted by Di Zhou and posted to the IETF repository. > > Filename: draft-dizhou-pim-umf-problem-statement > Revision: 00 > Title: Unnecessary Multicast Flooding Problem Statement > Creation_date: 2010-08-17 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This document describes the unnecessary multicast stream flooding > problem in the link layer switches between multicast source and PIM > First Hop Router (FHR). The IGMP-Snooping Switch will forward > multicast streams to router ports, and the PIM FHR must receive all > multicast streams even if there is no request from receiver. This > often leads to waste of switchs' cache and link bandwidth when the > multicast streams are not actually required. This document details > the problem and defines design goals for a generic mechanism to > restrain the unnecessary multicast stream flooding. > > > > The IETF Secretariat. > > > From maxpassion@gmail.com Thu Aug 19 08:29: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 A9D293A6956 for ; Thu, 19 Aug 2010 08:29:13 -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.186, 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 J-S0Un89KGKM for ; Thu, 19 Aug 2010 08:29:10 -0700 (PDT) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by core3.amsl.com (Postfix) with ESMTP id 8F9823A6961 for ; Thu, 19 Aug 2010 08:29:09 -0700 (PDT) Received: by qwe5 with SMTP id 5so2075306qwe.40 for ; Thu, 19 Aug 2010 08:29:44 -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; bh=cNN5DD6E8VzeozohZKHzQjthoHHxK3Ohny9enqBrgiE=; b=WESbYajju1fWzXNdbz6+TZJUZyiU68eYbzt0Nd1lLV8t2sanRYwBZtwhNOJcp1ZXcZ cT5LOSc++b5PRa94tjuwkbAv2T2BlkAoB5AqB8maIvmyYRkzFmU0GzhpsDwXskwRIeHi ouHxDfW+dnpyjW8jCRqC65pK5p6BOsNfR1oKg= 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; b=qY90B9xox4fOs9MwZRhf7wfKoogKT7+FuOGrtAsscXwT4+PfUO9TZ/2YJOwMjVKEcp CyvlRrCh2theU7Ju4GJm1hvEmGoak6rO3Ha6PCdbgWMIbL1nMJlczEByolo8lVKUHTts aiFGQKXoBJ8DZp3iUvYIHqEp07Y81EMP6FbY4= MIME-Version: 1.0 Received: by 10.224.72.195 with SMTP id n3mr6652746qaj.152.1282231783955; Thu, 19 Aug 2010 08:29:43 -0700 (PDT) Received: by 10.229.11.131 with HTTP; Thu, 19 Aug 2010 08:29:43 -0700 (PDT) In-Reply-To: References: <20100811214332.0B52E28C0CE@core3.amsl.com> Date: Thu, 19 Aug 2010 23:29:43 +0800 Message-ID: From: liu dapeng To: multimob@core3.amsl.com Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 19 Aug 2010 08:51:48 -0700 Subject: [multimob] Fwd: New Non-WG Mailing List: dmm -- Distributed Mobility Management 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, 19 Aug 2010 15:29:13 -0000 Hello all: During IETF 78, we held a DMM (Distributed Mobility Management) Barbof and many attendees have interest and want to contitue further discussions. So we create a mailing list, please refer the following information. You are welcomed if you have interest to join the discussion, thanks! . -------------------------------------------------------- List address: dmm@ietf.org Archive: http://www.ietf.org/mail-archive/web/dmm/ To subscribe: https://www.ietf.org/mailman/listinfo/dmm Description: This list is for DMM (distributed mobility management) related discussions. DMM is aimed to extend current IP mobility solution for flat network architecture. For additional information, please contact the list administrators(maxpassion@gmail.com). ----------------------------------------------------------- The presentation slides of DMM barbof could be found at: http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 attachment section. Regards, Dapeng Liu ---------- Forwarded message ---------- From: IESG Secretary Date: Wed, 11 Aug 2010 14:43:32 -0700 (PDT) Subject: New Non-WG Mailing List: dmm -- Distributed Mobility Management To: IETF Announcement list Cc: dmm@ietf.org, maxpassion@gmail.com A new IETF non-working group email list has been created. List address: dmm@ietf.org Archive: http://www.ietf.org/mail-archive/web/dmm/ To subscribe: https://www.ietf.org/mailman/listinfo/dmm Description: This list is for DMM (distributed mobility management) related discussions. DMM is aimed to extend current IP mobility solution for flat network architecture. For additional information, please contact the list administrators. From stig@venaas.com Fri Aug 20 10:59: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 9CA323A6AFC for ; Fri, 20 Aug 2010 10:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 77DSLrEy7vqd for ; Fri, 20 Aug 2010 10:59:51 -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 350A93A69A2 for ; Fri, 20 Aug 2010 10:59:51 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:18a1:3b46:626f:dc63] (unknown [IPv6:2001:420:4:ea0c:18a1:3b46:626f:dc63]) by ufisa.uninett.no (Postfix) with ESMTPSA id A045180E1 for ; Fri, 20 Aug 2010 20:00:24 +0200 (CEST) Message-ID: <4C6EC2B6.4020201@venaas.com> Date: Fri, 20 Aug 2010 11:00:22 -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] The MLD tuning milestone 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, 20 Aug 2010 17:59:52 -0000 At our meeting the general opinion seemed to be that none of the current individual MLD tuning drafts were ready to be adopted. It probably makes sense for us as a working group to figure out in more detail what we actually want from such a document. This can help authors of MLD tuning drafts to write a draft that we want to adopt. Below are some of my thoughts on this. I hope this can initiate some useful discussion. We did have some good discussion along these lines in the wg meeting, and I'm hoping we can continue it now. The parts of the charter I believe are relevant are: |Specific goals for the group are: | - Document how multicast can be supported in a Proxy Mobile IPv6 | environment | - Document the configuration of IGMPv3/MLDv2 in mobile environments Next we have: | IGMPv3/MLDv2 has been specified for wired networks with shared links. | Mobile nodes have needs that are specific to wireless networks and | mobility (e.g. entering a dormant mode to conserve battery power, | minimizing the latency for joining and leaving a group in support of | movement). | | The second task of the WG is to assess existing solutions for group | management, and determine to what extent these methods are sufficient | in a mobile environment. This will include recommending appropriate | selection of timer values and protocol parameters. And finally the milestone: |Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for mobility, |for publication as either Informational or Best Current Practice 1. What is tuning? I believe when we say tuning, there are definitely no protocol changes. The way IGMPv3/MLDv2 are designed, there are parameters like Robustness Variable, Query Interval, Maximum Response Delay that certainly can be tuned. RFC 3810 already has section 9.14 that discusses these to some extent. The most restrictive way to think of tuning would be to just look at parameters like this that are designed to be tunable. There is also a lot of flexibility and options regarding how to implement these protocols. Some of the things that have been brought up are explicit tracking and unicast of messages. Do you think such things should be considered tuning? If not tuning, should it still be considered in this document? What else should be considered tuning or appropriate for the document? 2. Recommendations for specific link types, scenarios or in general? It may be possible to talk about tuning some of these parameters in general. Some of that is already in RFC 3810 section 9.14. E.g. if high loss, consider this, if many clients consider this. If you do this you may also do that etc. Is something like this what we want? Should we try to find some real life scenarios, specific link types and test or simulate things? Or is it sufficient to say that if a link has certain characteristics (without it necessarily being related to a concrete existing technology), then based on simulation or reasoning, this is the tuning that works best? 3. What should the style of the document be? Do we want a BCP? One example of a BCP might be RFC 3819. Is that kind of document structure something like what we want? Other suggestions? Would analysis in the same style as say section 8.5.3 be reasonable? I'm not sure whether I should have picked a particular RFC here. If people can illustrate what they want by referring to existing documents or describing it in other ways, that would be great. 4. What else? These are roughly the things I can think of. Any thoughts on structure of documents, what it should contain etc. would be very welcome. My personal opinion is that we should be a bit restrictive regarding what we want from this document, in order to make forward progress. On the other hand, the document should have some useful information and go beyond the recommendations that already are there in the IGMPv3/MLDv2 RFCs. Stig From liuhui47967@huawei.com Tue Aug 24 07:19: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 A14FA3A69DF for ; Tue, 24 Aug 2010 07:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.77 X-Spam-Level: * X-Spam-Status: No, score=1.77 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 X8idhdTm54Wn for ; Tue, 24 Aug 2010 07:19:27 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2EA993A69DA for ; Tue, 24 Aug 2010 07:19:27 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7N003UAUH1FF@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 24 Aug 2010 22:19:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7N00GCBUH1AS@szxga02-in.huawei.com> for multimob@ietf.org; Tue, 24 Aug 2010 22:19:49 +0800 (CST) Received: from l47967b ([10.110.98.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7N002ZKUH15W@szxml06-in.huawei.com> for multimob@ietf.org; Tue, 24 Aug 2010 22:19:49 +0800 (CST) Date: Tue, 24 Aug 2010 22:19:49 +0800 From: Liu Hui In-reply-to: <4C6EC2B6.4020201@venaas.com> To: 'Stig Venaas' , multimob@ietf.org Message-id: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Thread-index: ActAkZoZPEp0dAZjSwa49A5mBhuB4gC3623w Subject: Re: [multimob] The MLD tuning milestone 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, 24 Aug 2010 14:19:28 -0000 Hi Stig, Please see my considerations on the issues in line: > > At our meeting the general opinion seemed to be that none of > the current individual MLD tuning drafts were ready to be adopted. > > It probably makes sense for us as a working group to figure > out in more detail what we actually want from such a > document. This can help authors of MLD tuning drafts to write > a draft that we want to adopt. > Below are some of my thoughts on this. I hope this can > initiate some useful discussion. We did have some good > discussion along these lines in the wg meeting, and I'm > hoping we can continue it now. I think this effort of clarification is beneficial. > > The parts of the charter I believe are relevant are: > > |Specific goals for the group are: > | - Document how multicast can be supported in a Proxy Mobile IPv6 > | environment > | - Document the configuration of IGMPv3/MLDv2 in mobile environments > > Next we have: > > | IGMPv3/MLDv2 has been specified for wired networks with > shared links. > | Mobile nodes have needs that are specific to wireless > networks and > | mobility (e.g. entering a dormant mode to conserve battery power, > | minimizing the latency for joining and leaving a group in > support of > | movement). > | > | The second task of the WG is to assess existing solutions > for group > | management, and determine to what extent these methods are > sufficient > | in a mobile environment. This will include recommending > appropriate > | selection of timer values and protocol parameters. > > And finally the milestone: > > |Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for > mobility, > |for publication as either Informational or Best Current Practice If I'm not wrong, it is recognized that the changing of IGMP and MLD should be cautious to avoid interoperability problems. This is why the charter on it has been revised several times. > > > 1. What is tuning? I'd like to divide the "changes" we talked into four groups: G1. of parameter values, G2. of protocol behavior without defining new messages on the media (line or wireless link) and without introducing interoperability problems G3. of protocol behavior by defining new messages but within the scope of group management protocol G4. of protocol behavior by supporting new functions which are outside the scope of group management, I believe G1 and G2 could be thought of as tuning. > > I believe when we say tuning, there are definitely no protocol > changes. The way IGMPv3/MLDv2 are designed, there are parameters > like Robustness Variable, Query Interval, Maximum Response Delay > that certainly can be tuned. RFC 3810 already has section 9.14 > that discusses these to some extent. > > The most restrictive way to think of tuning would be to just look > at parameters like this that are designed to be tunable. This belong to G1. Because they are already be covered 3810, I don't think it's necessary to redecribe it as a new work. > > There is also a lot of flexibility and options regarding how to > implement these protocols. Some of the things that have been > brought up are explicit tracking and unicast of messages. Do you > think such things should be considered tuning? If not tuning, > should it still be considered in this document? > This belongs to G2. I think they are the true tuning of IGMP/MLD protocols, if they require" the minor changes on the implementations", but "without changes of the message types" and "without the interoperability problems" (I might miss some others) . Some options proposed in the current tuning drafts might belong to this catagory. I think they should be covered within the current charter. > What else should be considered tuning or appropriate for the > document? Any optimizations (which might be proposed in the future), if they meet the three requirements above for G2 > > 2. Recommendations for specific link types, scenarios or in general? > > It may be possible to talk about tuning some of these parameters > in general. Some of that is already in RFC 3810 section 9.14. E.g. > if high loss, consider this, if many clients consider this. If > you do this you may also do that etc. Is something like this what > we want? Every parameter in IGMP/MLD is configurable. They have been covered by 3810. > > Should we try to find some real life scenarios, specific > link types > and test or simulate things? Or is it sufficient to say that if a > link has certain characteristics (without it necessarily being > related to a concrete existing technology), then based on > simulation > or reasoning, this is the tuning that works best? If we have simulation that would be better. But in some cases, soming tuing might be thought work best with simple reasoning. For example, for point to point link, Group-Specific Queries designed for multiple users can be cut without any need of simulation. The choices could be made according to the situations. > > 3. What should the style of the document be? > > Do we want a BCP? One example of a BCP might be RFC 3819. Is that > kind of document structure something like what we want? Other > suggestions? Would analysis in the same style as say section 8.5.3 > be reasonable? > > I'm not sure whether I should have picked a particular > RFC here. If > people can illustrate what they want by referring to existing > documents or describing it in other ways, that would be great. I think we should prepare a document first decribing scenarios and problems, giving the reasons why IGMP and MLD need to be tuned. Then list the possible tunning options we think reasonable to solve the problems. This doc could be BCP or be informational. Then if some of the options need to be analyzed detailedly, separate docs could be prepared. Their type could be determined according to their contents. 8.5.3 style might be useful for some of scenarios such as calculation of channel zapping speed, etc. But still there are other tuning options that do not require this calculation. I think this style could be incooperated into concrete options if needed > 4. What else? Besides, G3 should also be considered if the change deserve it. But for G4, I think they should be resolved by other control protocols rather than MLD protocols themselves. > > These are roughly the things I can think of. Any thoughts on > structure of documents, what it should contain etc. would be very > welcome. My personal opinion is that we should be a bit > restrictive > regarding what we want from this document, in order to > make forward > progress. On the other hand, the document should have some useful > information and go beyond the recommendations that > already are there > in the IGMPv3/MLDv2 RFCs. Agreed. I think the document should provide some useful informations that current RFCs don't have Best Regards, Liu Hui From bill@cse.concordia.ca Tue Aug 24 07:48:04 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 106573A6B67 for ; Tue, 24 Aug 2010 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_40=-0.185] 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 Ubny7TfLhLRV for ; Tue, 24 Aug 2010 07:47:59 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id 7C3693A6B56 for ; Tue, 24 Aug 2010 07:47:59 -0700 (PDT) Received: from [132.205.44.76] (cedar.cs.concordia.ca [132.205.44.76]) by oldperseverance.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id o7OEmRpO019936; Tue, 24 Aug 2010 10:48:27 -0400 Message-ID: <4C73DBBB.6060504@cse.concordia.ca> Date: Tue, 24 Aug 2010 10:48:27 -0400 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Liu Hui References: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> In-Reply-To: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2010/08/24 10:48:28 EDT Cc: multimob@ietf.org Subject: Re: [multimob] The MLD tuning milestone 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, 24 Aug 2010 14:48:04 -0000 One comment, which results from my discussions in Mboned about extending IGMP to carry authentication/authorization information: Given that IGMP v3 has not seen wide adoption (in spite of the fact that it has been standardized since 2002) and given the fact that IGMP v3 was seen as sufficiently "heavy" that a "lightweight" version of it was defined (RFC 5790), it is _not_ likely that an "IGMP v4" would ever gain traction. Therefore, since G3 and G4 would definitely constitute a proposal for "IGMP v4", the group should stick with what can be done in the areas of G1 and G2. Bill Liu Hui wrote: > Hi Stig, > > Please see my considerations on the issues in line: >> At our meeting the general opinion seemed to be that none of >> the current individual MLD tuning drafts were ready to be adopted. >> >> It probably makes sense for us as a working group to figure >> out in more detail what we actually want from such a >> document. This can help authors of MLD tuning drafts to write >> a draft that we want to adopt. > >> Below are some of my thoughts on this. I hope this can >> initiate some useful discussion. We did have some good >> discussion along these lines in the wg meeting, and I'm >> hoping we can continue it now. > > I think this effort of clarification is beneficial. > >> The parts of the charter I believe are relevant are: >> >> |Specific goals for the group are: >> | - Document how multicast can be supported in a Proxy Mobile IPv6 >> | environment >> | - Document the configuration of IGMPv3/MLDv2 in mobile environments >> >> Next we have: >> >> | IGMPv3/MLDv2 has been specified for wired networks with >> shared links. >> | Mobile nodes have needs that are specific to wireless >> networks and >> | mobility (e.g. entering a dormant mode to conserve battery power, >> | minimizing the latency for joining and leaving a group in >> support of >> | movement). >> | >> | The second task of the WG is to assess existing solutions >> for group >> | management, and determine to what extent these methods are >> sufficient >> | in a mobile environment. This will include recommending >> appropriate >> | selection of timer values and protocol parameters. >> >> And finally the milestone: >> >> |Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for >> mobility, >> |for publication as either Informational or Best Current Practice > > If I'm not wrong, it is recognized that the changing of IGMP and MLD should > be cautious to avoid interoperability problems. This is why the charter on > it has been revised several times. > >> >> 1. What is tuning? > > I'd like to divide the "changes" we talked into four groups: > G1. of parameter values, > G2. of protocol behavior without defining new messages on the media (line or > wireless link) and without introducing interoperability problems > G3. of protocol behavior by defining new messages but within the scope of > group management protocol > G4. of protocol behavior by supporting new functions which are outside the > scope of group management, > > I believe G1 and G2 could be thought of as tuning. > >> I believe when we say tuning, there are definitely no protocol >> changes. The way IGMPv3/MLDv2 are designed, there are parameters >> like Robustness Variable, Query Interval, Maximum Response Delay >> that certainly can be tuned. RFC 3810 already has section 9.14 >> that discusses these to some extent. >> >> The most restrictive way to think of tuning would be to just look >> at parameters like this that are designed to be tunable. > > This belong to G1. Because they are already be covered 3810, I don't think > it's necessary to redecribe it as a new work. > >> There is also a lot of flexibility and options regarding how to >> implement these protocols. Some of the things that have been >> brought up are explicit tracking and unicast of messages. Do you >> think such things should be considered tuning? If not tuning, >> should it still be considered in this document? >> > > This belongs to G2. I think they are the true tuning of IGMP/MLD protocols, > if they require" the minor changes on the implementations", but "without > changes of the message types" and "without the interoperability problems" (I > might miss some others) . Some options proposed in the current tuning drafts > might belong to this catagory. I think they should be covered within the > current charter. > > >> What else should be considered tuning or appropriate for the >> document? > > Any optimizations (which might be proposed in the future), if they meet the > three requirements above for G2 > > >> 2. Recommendations for specific link types, scenarios or in general? >> >> It may be possible to talk about tuning some of these parameters >> in general. Some of that is already in RFC 3810 section 9.14. E.g. >> if high loss, consider this, if many clients consider this. If >> you do this you may also do that etc. Is something like this what >> we want? > > Every parameter in IGMP/MLD is configurable. They have been covered by 3810. > >> Should we try to find some real life scenarios, specific >> link types >> and test or simulate things? Or is it sufficient to say that if a >> link has certain characteristics (without it necessarily being >> related to a concrete existing technology), then based on >> simulation >> or reasoning, this is the tuning that works best? > > If we have simulation that would be better. But in some cases, soming tuing > might be thought work best with simple reasoning. For example, for point to > point link, Group-Specific Queries designed for multiple users can be cut > without any need of simulation. The choices could be made according to the > situations. > >> 3. What should the style of the document be? >> >> Do we want a BCP? One example of a BCP might be RFC 3819. Is that >> kind of document structure something like what we want? Other >> suggestions? Would analysis in the same style as say section 8.5.3 >> be reasonable? >> >> I'm not sure whether I should have picked a particular >> RFC here. If >> people can illustrate what they want by referring to existing >> documents or describing it in other ways, that would be great. > > I think we should prepare a document first decribing scenarios and problems, > giving the reasons why IGMP and MLD need to be tuned. Then list the > possible tunning options we think reasonable to solve the problems. This > doc could be BCP or be informational. > > Then if some of the options need to be analyzed detailedly, separate docs > could be prepared. Their type could be determined according to their > contents. > > 8.5.3 style might be useful for some of scenarios such as calculation of > channel zapping speed, etc. But still there are other tuning options that > do not require this calculation. I think this style could be incooperated > into concrete options if needed > > >> 4. What else? > > Besides, G3 should also be considered if the change deserve it. But for G4, > I think they should be resolved by other control protocols rather than MLD > protocols themselves. > >> These are roughly the things I can think of. Any thoughts on >> structure of documents, what it should contain etc. would be very >> welcome. My personal opinion is that we should be a bit >> restrictive >> regarding what we want from this document, in order to >> make forward >> progress. On the other hand, the document should have some useful >> information and go beyond the recommendations that >> already are there >> in the IGMPv3/MLDv2 RFCs. > > Agreed. I think the document should provide some useful informations that > current RFCs don't have > > > Best Regards, > Liu Hui > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From zhoudi@h3c.com Thu Aug 26 19:55: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 1230B3A68D0; Thu, 26 Aug 2010 19:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_26=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 L3ueyQyFNA9l; Thu, 26 Aug 2010 19:55:46 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.50]) by core3.amsl.com (Postfix) with ESMTP id 181173A684D; Thu, 26 Aug 2010 19:55:39 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0L7S007FKITLN5@h3cml01-in.huawei-3com.com>; Fri, 27 Aug 2010 10:56:10 +0800 (CST) Received: from H3CHUB01-EX.srv.huawei-3com.com ([10.63.16.181]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPS id <0L7S00AUXITLV1@h3cml01-in.huawei-3com.com>; Fri, 27 Aug 2010 10:56:09 +0800 (CST) Received: from h3cedge01-ex.h3c.com (172.25.12.73) by H3CHUB01-EX.srv.huawei-3com.com (10.63.16.181) with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 27 Aug 2010 10:56:09 +0800 Received: from h3cimss01-ss (172.25.12.100) by h3cedge01-ex.h3c.com (172.25.12.73) with Microsoft SMTP Server id 14.0.689.0; Fri, 27 Aug 2010 11:22:03 +0800 Received: from unknown (HELO z00782a) ([10.55.72.60]) by smtp2.h3c.com with ESMTP; Fri, 27 Aug 2010 10:56:08 +0800 Date: Fri, 27 Aug 2010 10:56:07 +0800 From: zhoudi To: Indranil Bhattacharya Message-id: <013c01cb4593$65b54a40$100a0164@h3c.huawei3com.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: multipart/alternative; boundary="Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)" X-Priority: 3 X-MSMail-priority: Normal X-TM-IMSS-Message-ID: <439665260019a760@h3c.com> References: <009201cb3f6b$206dd2f0$240a0164@h3c.huawei3com.com> Cc: Greg Shepherd , multimob@ietf.org, young@h3c.com, Hui Deng , mboned@ietf.org, magma@ietf.org, pim@ietf.org Subject: Re: [multimob] Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-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: Fri, 27 Aug 2010 02:55:53 -0000 --Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Indranil, Thanks for your comment. My reply is as follows: Thanks and Regards ZhouDi ----- Original Message ----- From: Indranil Bhattacharya To: zhoudi Cc: Greg Shepherd ; pim@ietf.org ; mboned@ietf.org ; multimob@ietf.org ; magma@ietf.org ; Hui Deng ; young@h3c.com ; Liu Hui Sent: Thursday, August 26, 2010 10:30 PM Subject: Re: Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00 Hi ZhouDi, A few comments. 1. There must be a way to refresh the pim snooping entry in the switch. This needs to be done by pim j/p message from FHR. Without a refresh mechanism for the entry in the switch there is a problem. After receiving the first data packet FHR send PIM prune. Then the entry expires and switch forwards data again but FHR does not send PIM prune because it already has (S,G) with NULL OIF. Yeah, you are right. That is why the lifetime of pruned ports is 1/3 of the lifetime of PIM FHR's (S,G) entry. But the behaviour of periodically forwarding and pruning can be optimized. Do you have any idea about it,especially in PIM SM?Thanks. 2. This should not affect the FHR's capability of sending NULL register. Have you found some potential problems? Thanks. 3. This special pim snoop entry needs to be installed in the hash/tcam region of the switch. Otherwise all data will have to hit the cpu of the switch. So better if switch's hw-multicast-entries can be changed based on the pim snooping information. Absence of a snooping entry means forward the data to all interfaces in the same vlan. Presence of a pruned interface in the snooping entry means forward data to all interfaces in that vlan excluding the pruned interface. I will accept your suggestion. Thanks. Please let me know your thoughts. Thanks, Indranil On Thu, Aug 19, 2010 at 12:22 PM, zhoudi wrote: Hi, According to your advice, I newly submitted the problem-statement for the problem of Unnecessary Multicast Flooding between sources and PIM FHRs. http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/ Welcome to comment on the problem and bring forward solutions. Thanks and Regards. ZhouDi Subject: New Version Notification for draft-dizhou-pim-umf-problem-statement-00 > > A new version of I-D, draft-dizhou-pim-umf-problem-statement-00.txt has been successfully submitted by Di Zhou and posted to the IETF repository. > > Filename: draft-dizhou-pim-umf-problem-statement > Revision: 00 > Title: Unnecessary Multicast Flooding Problem Statement > Creation_date: 2010-08-17 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This document describes the unnecessary multicast stream flooding > problem in the link layer switches between multicast source and PIM > First Hop Router (FHR). The IGMP-Snooping Switch will forward > multicast streams to router ports, and the PIM FHR must receive all > multicast streams even if there is no request from receiver. This > often leads to waste of switchs' cache and link bandwidth when the > multicast streams are not actually required. This document details > the problem and defines design goals for a generic mechanism to > restrain the unnecessary multicast stream flooding. > > > > The IETF Secretariat. > > > --Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Indranil,
     Thanks for your comment.
     My reply is as follows:
     
     Thanks and Regards
     ZhouDi
 
----- Original Message -----
To: zhoudi
Sent: Thursday, August 26, 2010 10:30 PM
Subject: Re: Fw: New Version Notification for draft-dizhou-pim-umf-problem-statement-00

Hi ZhouDi,
 
              A few comments.
 
1. There must be a way to refresh the pim snooping entry in the switch. This needs to be done by pim j/p message from FHR.
    Without a refresh mechanism for the entry in the switch there is a problem. After receiving the first data packet FHR send PIM
    prune. Then the entry expires and switch forwards data again but FHR does not send PIM prune because it already has (S,G) with
    NULL OIF.
   Yeah, you are right. That is why the lifetime of  pruned ports is 1/3 of the lifetime of PIM FHR's (S,G) entry.
   But the behaviour of periodically forwarding and pruning can be optimized.
   Do you have any idea about it,especially in PIM SM？Thanks.
 
2. This  should not affect the FHR's capability of sending NULL register.
   Have you found some potential problems? Thanks.
 
3. This special pim snoop entry needs to be installed in the hash/tcam region of the switch. Otherwise all data will have to hit the
    cpu of the switch. So better if switch's hw-multicast-entries can be changed based on the pim snooping information.
    Absence of a snooping entry means forward the data to all interfaces in the same vlan. Presence of a pruned interface in the
    snooping entry means forward data to all interfaces in that vlan excluding the pruned interface.
    I will accept your suggestion. Thanks.
Please let me know your thoughts.
 
Thanks,
Indranil
On Thu, Aug 19, 2010 at 12:22 PM, zhoudi <zhoudi@h3c.com> wrote:
Hi,
    According to your advice, I newly submitted the problem-statement for the problem of
Unnecessary Multicast Flooding between sources and PIM FHRs.
http://datatracker.ietf.org/doc/draft-dizhou-pim-umf-problem-statement/
    Welcome to  comment on the problem and  bring forward solutions.

    Thanks and Regards.
    ZhouDi


Subject: New Version Notification for draft-dizhou-pim-umf-problem-statement-00


>
> A new version of I-D, draft-dizhou-pim-umf-problem-statement-00.txt has been successfully submitted by Di Zhou and posted to the IETF repository.
>
> Filename: draft-dizhou-pim-umf-problem-statement
> Revision: 00
> Title: Unnecessary Multicast Flooding Problem Statement
> Creation_date: 2010-08-17
> WG ID: Independent Submission
> Number_of_pages: 15
>
> Abstract:
> This document describes the unnecessary multicast stream flooding
> problem in the link layer switches between multicast source and PIM
> First Hop Router (FHR).  The IGMP-Snooping Switch will forward
> multicast streams to router ports, and the PIM FHR must receive all
> multicast streams even if there is no request from receiver.  This
> often leads to waste of switchs' cache and link bandwidth when the
> multicast streams are not actually required.  This document details
> the problem and defines design goals for a generic mechanism to
> restrain the unnecessary multicast stream flooding.
>
>
>
> The IETF Secretariat.
>
>
>

--Boundary_(ID_CMpn1vfvpHEP4t+PavdreQ)-- From behcetsarikaya@yahoo.com Mon Aug 30 09:48:44 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 5129E3A67E5 for ; Mon, 30 Aug 2010 09:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=-0.935, 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 s7xQDW9Wxyia for ; Mon, 30 Aug 2010 09:48:43 -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 12CA33A67F3 for ; Mon, 30 Aug 2010 09:48:43 -0700 (PDT) Received: (qmail 62469 invoked by uid 60001); 30 Aug 2010 16:49:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1283186953; bh=sB9FcSoK3R2gyn3ELnh2kxZEzm8QK8x/QtsVGYh+f7I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vXrsbwf6vv7DRrrhq7og+gH2ZsMF9fi6tpL9QeamBLRJzq7oj2KyOWpBa1q90pimFE9i30IMP/f+7LcVmk0GYP0H+XO79MPuqYx8YJvN9GDgnCwHQ7Y5skl46JBRb2jnBGWEwllCqEN/a04VsBvO/7HCYAu8CXYvp5KiP7V8WwM= 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=nRRACXUjroFzRx3ILuzB1pZ9IXWaBXe1Amo5lS37A5wp5QzA2J+B6Vk6/7fpPV5uKlSZIXAXhM/wV9ViOzilZF3+FlhKorJ1xxcaqJUw6catQxm+bjrne9M2p57yUVmss9MeKy6qW8JNRgs10K2uxlvj0uKIRY4qFYZ87yO0qoo=; Message-ID: <327056.56415.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: VRIPV1EVM1kANxzF.VBiqt32PqJZ3NGE0LZBB2HAljdRkO6 PERj6QVImrviObbwFf_g_qBwY8umk8ksOiX24S2FCY_U9GxD3lpvjbv.lJMt ja8G9Zu74SBnslKuhBsDgSAiEYPsydtJwLjj8AktJ8ia8UFne_onA2c1sEJ_ MiQZPojrip4mE5y_JbNnGYrrg.eRjrTtqasbJYeL0IBa8RdlFXvh2UjVAQrF uU7I4.oh.0Tba6_GTDefk12N97e_ju7Juu1Fy4fxJsBFdY_tEnH9zMuvdq9P 43aFoyreeD3OjNDlUvma5dKj6oV0cIdfErLnRhc8eatZSwCz84qAO4Uco9Gl UjqLP5biTPzql7H8- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Mon, 30 Aug 2010 09:49:13 PDT X-Mailer: YahooMailRC/470 YahooMailWebService/0.8.105.279950 References: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> Date: Mon, 30 Aug 2010 09:49:13 -0700 (PDT) From: Behcet Sarikaya To: Liu Hui , Stig Venaas , multimob@ietf.org In-Reply-To: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] The MLD tuning milestone 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, 30 Aug 2010 16:48:44 -0000 Folks, A few corrections on Hui's mail and my views: - Multimob had a single charter, no revisions/ rechartering yet. - The charter is clear on the MLD tuning milestone, we need a single document not many. G1, i.e. parameter tuning and G2, i.e. "behaviour tuning" are needed. Regarding simulations, we had a presentation about simulation results in Maastricht, they were good but applied to a single link type. WG wondered about other link types? Stig mentioned: One example of a BCP might be RFC 3819. In this RFC, several link types are covered and recommendations are given. Can we have extensive simulations for all link types? Maybe not. In the meeting it was mentioned that simple measurements could be OK. Regards, Behcet ----- Original Message ---- > From: Liu Hui > To: Stig Venaas ; multimob@ietf.org > Sent: Tue, August 24, 2010 9:19:49 AM > Subject: Re: [multimob] The MLD tuning milestone > > Hi Stig, > > Please see my considerations on the issues in line: > > > > At our meeting the general opinion seemed to be that none of > > the current individual MLD tuning drafts were ready to be adopted. > > > > It probably makes sense for us as a working group to figure > > out in more detail what we actually want from such a > > document. This can help authors of MLD tuning drafts to write > > a draft that we want to adopt. > > > Below are some of my thoughts on this. I hope this can > > initiate some useful discussion. We did have some good > > discussion along these lines in the wg meeting, and I'm > > hoping we can continue it now. > > I think this effort of clarification is beneficial. > > > > > The parts of the charter I believe are relevant are: > > > > |Specific goals for the group are: > > | - Document how multicast can be supported in a Proxy Mobile IPv6 > > | environment > > | - Document the configuration of IGMPv3/MLDv2 in mobile environments > > > > Next we have: > > > > | IGMPv3/MLDv2 has been specified for wired networks with > > shared links. > > | Mobile nodes have needs that are specific to wireless > > networks and > > | mobility (e.g. entering a dormant mode to conserve battery power, > > | minimizing the latency for joining and leaving a group in > > support of > > | movement). > > | > > | The second task of the WG is to assess existing solutions > > for group > > | management, and determine to what extent these methods are > > sufficient > > | in a mobile environment. This will include recommending > > appropriate > > | selection of timer values and protocol parameters. > > > > And finally the milestone: > > > > |Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for > > mobility, > > |for publication as either Informational or Best Current Practice > > If I'm not wrong, it is recognized that the changing of IGMP and MLD should > be cautious to avoid interoperability problems. This is why the charter on > it has been revised several times. > > > > > > > 1. What is tuning? > > I'd like to divide the "changes" we talked into four groups: > G1. of parameter values, > G2. of protocol behavior without defining new messages on the media (line or > wireless link) and without introducing interoperability problems > G3. of protocol behavior by defining new messages but within the scope of > group management protocol > G4. of protocol behavior by supporting new functions which are outside the > scope of group management, > > I believe G1 and G2 could be thought of as tuning. > > > > > I believe when we say tuning, there are definitely no protocol > > changes. The way IGMPv3/MLDv2 are designed, there are parameters > > like Robustness Variable, Query Interval, Maximum Response Delay > > that certainly can be tuned. RFC 3810 already has section 9.14 > > that discusses these to some extent. > > > > The most restrictive way to think of tuning would be to just look > > at parameters like this that are designed to be tunable. > > This belong to G1. Because they are already be covered 3810, I don't think > it's necessary to redecribe it as a new work. > > > > > There is also a lot of flexibility and options regarding how to > > implement these protocols. Some of the things that have been > > brought up are explicit tracking and unicast of messages. Do you > > think such things should be considered tuning? If not tuning, > > should it still be considered in this document? > > > > This belongs to G2. I think they are the true tuning of IGMP/MLD protocols, > if they require" the minor changes on the implementations", but "without > changes of the message types" and "without the interoperability problems" (I > might miss some others) . Some options proposed in the current tuning drafts > might belong to this catagory. I think they should be covered within the > current charter. > > > > What else should be considered tuning or appropriate for the > > document? > > Any optimizations (which might be proposed in the future), if they meet the > three requirements above for G2 > > > > > > 2. Recommendations for specific link types, scenarios or in general? > > > > It may be possible to talk about tuning some of these parameters > > in general. Some of that is already in RFC 3810 section 9.14. E.g. > > if high loss, consider this, if many clients consider this. If > > you do this you may also do that etc. Is something like this what > > we want? > > Every parameter in IGMP/MLD is configurable. They have been covered by 3810. > > > > > Should we try to find some real life scenarios, specific > > link types > > and test or simulate things? Or is it sufficient to say that if a > > link has certain characteristics (without it necessarily being > > related to a concrete existing technology), then based on > > simulation > > or reasoning, this is the tuning that works best? > > If we have simulation that would be better. But in some cases, soming tuing > might be thought work best with simple reasoning. For example, for point to > point link, Group-Specific Queries designed for multiple users can be cut > without any need of simulation. The choices could be made according to the > situations. > > > > > 3. What should the style of the document be? > > > > Do we want a BCP? One example of a BCP might be RFC 3819. Is that > > kind of document structure something like what we want? Other > > suggestions? Would analysis in the same style as say section 8.5.3 > > be reasonable? > > > > I'm not sure whether I should have picked a particular > > RFC here. If > > people can illustrate what they want by referring to existing > > documents or describing it in other ways, that would be great. > > I think we should prepare a document first decribing scenarios and problems, > giving the reasons why IGMP and MLD need to be tuned. Then list the > possible tunning options we think reasonable to solve the problems. This > doc could be BCP or be informational. > > Then if some of the options need to be analyzed detailedly, separate docs > could be prepared. Their type could be determined according to their > contents. > > 8.5.3 style might be useful for some of scenarios such as calculation of > channel zapping speed, etc. But still there are other tuning options that > do not require this calculation. I think this style could be incooperated > into concrete options if needed > > > > 4. What else? > > Besides, G3 should also be considered if the change deserve it. But for G4, > I think they should be resolved by other control protocols rather than MLD > protocols themselves. > > > > > These are roughly the things I can think of. Any thoughts on > > structure of documents, what it should contain etc. would be very > > welcome. My personal opinion is that we should be a bit > > restrictive > > regarding what we want from this document, in order to > > make forward > > progress. On the other hand, the document should have some useful > > information and go beyond the recommendations that > > already are there > > in the IGMPv3/MLDv2 RFCs. > > Agreed. I think the document should provide some useful informations that > current RFCs don't have > > > Best Regards, > Liu Hui > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Tue Aug 31 01:01:58 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 E58033A67A7 for ; Tue, 31 Aug 2010 01:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.311 X-Spam-Level: X-Spam-Status: No, score=-96.311 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508, 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 XGO3jt9viD4M for ; Tue, 31 Aug 2010 01:01:58 -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 0DF5B3A6784 for ; Tue, 31 Aug 2010 01:01:58 -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 EC4D12780C6; Tue, 31 Aug 2010 17:02:22 +0900 (JST) Date: Tue, 31 Aug 2010 17:02:22 +0900 (JST) Message-Id: <20100831.170222.123649402.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <327056.56415.qm@web111404.mail.gq1.yahoo.com> References: <00f401cb4397$694dcc20$8b626e0a@china.huawei.com> <327056.56415.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] The MLD tuning milestone 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, 31 Aug 2010 08:01:59 -0000 Hi Behcet, > A few corrections on Hui's mail and my views: > > - Multimob had a single charter, no revisions/ rechartering yet. > - The charter is clear on the MLD tuning milestone, we need a single document > not many. > G1, i.e. parameter tuning and G2, i.e. "behaviour tuning" are > needed. IMO, the word, "tuning", can be used only for changing "values" or "parameters". I may say saying "changing behavior" is reasonable but "tuning behavior" is a bit strange, because it means "protocol modification", doesn't it? > Regarding simulations, > we had a presentation about simulation results in Maastricht, they > were good but applied to > a single link type. WG wondered about other link types? Yes, we can modify and run our simulation with different link types and different scenarios. Please wait a while. Regards, -- Hitoshi Asaeda