From ssm-bounces@ietf.org Tue Oct 04 05:13:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMirx-0004tI-Ck; Tue, 04 Oct 2005 05:13:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMirw-0004tD-5u for ssm@megatron.ietf.org; Tue, 04 Oct 2005 05:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06046 for ; Tue, 4 Oct 2005 05:13:49 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMj0Z-0002Wh-Lp for ssm@ietf.org; Tue, 04 Oct 2005 05:22:48 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 02:13:42 -0700 X-IronPort-AV: i="3.97,172,1125903600"; d="scan'208"; a="663296438:sNHT25227184" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j949Dd4V005234; Tue, 4 Oct 2005 02:13:39 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA01989; Tue, 4 Oct 2005 02:13:38 -0700 (PDT) Date: Tue, 4 Oct 2005 02:13:38 -0700 From: Toerless Eckert To: holbrook@cs.stanford.edu, bcain@storigen.com, fenner@research.att.com, zinin@psg.com, ssm@ietf.org Message-ID: <20051004091338.GF9249@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: jedi@cisco.com, David Meyer Subject: [ssm] URGENT: draft-ietf-ssm-arch-06.txt X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Can somebody please tell me what needs to be done to get an SSM architecture RFC out of that draft... like: This year ? We've got a whole bloody broadband industry like in DSL and Cabl where it's extremely difficult to propose and require SSM support without having an actual IETF RFC for this still pretty badly understood model. In addition, there is at least one further IETF draft hanging on the normative reference. Is there any relationship between the amount of changes / improvement that went into this draft and it's lifetime ? Or is it rather that this draft is hanging around waiting for someone who is not spending the time to move it forward ? If so, can we please identify that roadblock and get rid of it so that this draft can move forward with a little bit accelerated speed ? Short of this: Can we simply define timeouts of let's say 5 years after which drafts that have an interested user community become an RFC even if not all bureaucracy nitpicking has been resolved ? After all, the PIM-SM RFC2362 also had 120 known bugs when we started out redoing it something like 5 years ago, but it's pure existance has helped to ensure that THE INDUSTRY HAS CONTINUED TO DO ANY FORM OF PIM DURING THE LAST 5 YEARS... *sigh* sorry for getting so loud. Just wanted to highlight that the situation in SSM is worse than in PIM - with similar waiting times - because in SSM there is no prior RFC whatsoever that could be used instad of the real thing, and i really don't see the value of indefinite postponement anymore. Thanks Toerless Eckert _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Tue Oct 04 09:24:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmm9-0002k1-Ud; Tue, 04 Oct 2005 09:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmm6-0002jX-4q for ssm@megatron.ietf.org; Tue, 04 Oct 2005 09:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17998 for ; Tue, 4 Oct 2005 09:24:04 -0400 (EDT) Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmuk-0000ZH-Uc for ssm@ietf.org; Tue, 04 Oct 2005 09:33:04 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.17275517; Tue, 04 Oct 2005 09:23:21 -0400 In-Reply-To: <20051004091338.GF9249@cisco.com> References: <20051004091338.GF9249@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Subject: Re: [ssm] URGENT: draft-ietf-ssm-arch-06.txt Date: Tue, 4 Oct 2005 09:23:20 -0400 To: Toerless Eckert X-Mailer: Apple Mail (2.623) X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: zinin@psg.com, jedi@cisco.com, David Meyer , bcain@storigen.com, fenner@research.att.com, holbrook@cs.stanford.edu, ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1066156016==" Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org --===============1066156016== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--198854727; protocol="application/pkcs7-signature" --Apple-Mail-2--198854727 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Toerless, Well, the draft is in Revised ID Needed state after IESG review. https://datatracker.ietf.org/public/pidtracker.cgi? command=print_ballot&ballot_id=1300&filename=draft-ietf-ssm-arch To my knowledge, the editors/authors have either: run out of cycles or motivation. I would love to see this draft finished as well. If needed, I could try and help resolve the DISCUSS comments. Regards, Brian On Oct 4, 2005, at 5:13, Toerless Eckert wrote: > Can somebody please tell me what needs to be done to get an SSM > architecture RFC out of that draft... like: This year ? > > We've got a whole bloody broadband industry like in DSL and Cabl > where it's extremely difficult to propose and require SSM support > without > having an actual IETF RFC for this still pretty badly understood model. > > In addition, there is at least one further IETF draft hanging on the > normative reference. > > Is there any relationship between the amount of changes / improvement > that went into this draft and it's lifetime ? Or is it rather that this > draft is hanging around waiting for someone who is not spending the > time > to move it forward ? If so, can we please identify that roadblock and > get rid of it so that this draft can move forward with a little bit > accelerated speed ? > > Short of this: Can we simply define timeouts of let's say 5 years after > which drafts that have an interested user community become an RFC even > if not all bureaucracy nitpicking has been resolved ? After all, the > PIM-SM RFC2362 also had 120 known bugs when we started out redoing it > something like 5 years ago, but it's pure existance has helped to > ensure that THE INDUSTRY HAS CONTINUED TO DO ANY FORM OF PIM DURING THE > LAST 5 YEARS... *sigh* sorry for getting so loud. Just wanted to > highlight > that the situation in SSM is worse than in PIM - with similar waiting > times - because in SSM there is no prior RFC whatsoever that could be > used instad of the real thing, and i really don't see the value of > indefinite postponement anymore. > > Thanks > Toerless Eckert > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm --Apple-Mail-2--198854727 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDA0MTMyMzIwWjAjBgkqhkiG9w0B CQQxFgQUgL4vZJbHm0ujjBKcA5AM0iwYK4wweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAfRtDeIpuCzmpqfMvu82iGoDj8V3gakYiPL/SV5pcQvEKJHsJ3X8syv1BiWjKXl64CMjN xaJLmg632grgl/N3aM+szN1fVS7BH0Kpb6/MuHT0LmDxMWSqM1Zb1RBynwOx5kLEJ5RobjyLgq6n rSqGGwrGp0J3Xfn9a2G19vZGZ9J+cqJuN+2beEnwS5QqogIGocPavRGQ9IHEKBbsQ426FtB2Hqhf qT/NBF6d+Nd3tiVlUjJmuBmml8iKOcfL46HR9cUPDzStEBexoigwHC1lwtkUdC7bijrs5acBcSzg I/NBR3/LlvwabH54n87b1riQ4JJ9cwD+r/sy2MWAY0RbsgAAAAAAAA== --Apple-Mail-2--198854727-- --===============1066156016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --===============1066156016==-- From ssm-bounces@ietf.org Tue Oct 04 13:16:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqOd-0007bl-74; Tue, 04 Oct 2005 13:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpEj-00053j-12 for ssm@megatron.ietf.org; Tue, 04 Oct 2005 12:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05650 for ; Tue, 4 Oct 2005 12:01:45 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMpNN-0007df-Hw for ssm@ietf.org; Tue, 04 Oct 2005 12:10:49 -0400 Received: by zproxy.gmail.com with SMTP id n1so96448nzf for ; Tue, 04 Oct 2005 09:01:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UW5bqI++YCbeKBGqxq/+eg64rttQXTftpI4IRhk1RLWNiWUwumrI1A9hFGmhWqJnbgFm5MZ/TbWOsakiKo/8qp9pVaQF9GNrBykMxGNNPnDEx2HvU8Jo9xok7+AIOUIkCWzpMf8qToXUp/W628vDukpVAL6mIk7f3EK8GeH8cqo= Received: by 10.36.97.9 with SMTP id u9mr358416nzb; Tue, 04 Oct 2005 09:01:33 -0700 (PDT) Received: by 10.36.47.18 with HTTP; Tue, 4 Oct 2005 09:01:33 -0700 (PDT) Message-ID: <6e0714c70510040901x2e9bc115n74b1e3ffd92ddf7c@mail.gmail.com> Date: Tue, 4 Oct 2005 09:01:33 -0700 From: Hugh Holbrook To: Toerless Eckert In-Reply-To: <20051004091338.GF9249@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051004091338.GF9249@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d2cbbe10c97d56c753ea98882cec394 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 04 Oct 2005 13:15:30 -0400 Cc: zinin@psg.com, jedi@cisco.com, bcain@storigen.com, fenner@research.att.com, David Meyer , ssm@ietf.org Subject: [ssm] Re: URGENT: draft-ietf-ssm-arch-06.txt X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hugh Holbrook List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org On 10/4/05, Toerless Eckert wrote: > Can somebody please tell me what needs to be done to get an SSM > architecture RFC out of that draft... Hi, Toerless (and the rest of the wg): Thanks for the nudge (shove? :)). I'm glad to hear that you still care about seeing all the work we've done get finished. The draft is moving again. Here's where it's at, with a little history mixed in. This draft went through an IESG review last fall, and there was a DISCUSS about the security considerations section, as well as some non-blocking comments by Pekka and others that were fairly straightforward to do. You can see the full record of comments here: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D8276&rfc_flag=3D0 Alex and Bill and I sorted out a plan back in Minneapolis, and then I got a new job and the draft stalled for lack of author time until about a month ago when Alex bugged me again. I have revised the draft and this version, I believe, addresses all of the outstanding DISCUSS comments, and it will show up in the id archives shortly. I pinged Russ (who authored the DISCUSS), and pending an ok from him, I think the draft is ready to advance. There is also a DISCUSS by Brian Carpenter, but I think, and Alex agrees, that Brian's concern is actually addressed in the document a little bit below the text he was saying was unclear. If you are interested in seeing the draft advance, please review the -07 draft changes, and let me know if you spot anything that might block a final pass through the IESG. The diffs relative to the -06 revision are attached below. I plan to optimistically submit these changes and revise to an -08 version if the DISCUSS authors aren't happy with what I've done. I'll ping the working group again when the -07 draft actually shows up in the archives, but there haven't been any changes of real substance -- just clarifications and corrections to RFC numbers, etc, so I'm not inclined to do yet another wg last call. If anyone feels that we *really* need another last call for this, please say so, but I'm hoping that we can harness the momentum provided by your push here and get this document onto the accelerated RFC track. Thanks, -Hugh --- draft-ietf-ssm-arch-06.txt=092004-09-07 22:39:33.000000000 -0700 +++ draft-ietf-ssm-arch-07.txt=092005-10-04 08:43:50.000000000 -0700 @@ -5,21 +5,21 @@ INTERNET-DRAFT Source-Specific Multicast H. Holbrook -Expires Mar 07, 2005 Cisco Systems +Expires Apr 04, 2006 Arastra, Inc. B. Cain Storigen Systems - 7 Sep 2004 + 4 Oct 2005 Source-Specific Multicast for IP - + Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of -which I become aware will be disclosed, in accordance with RFC 3667. +which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups @@ -57,19 +57,19 @@ Holbrook/Cain [Page 1] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 Abstract -IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are -designated as source-specific multicast (SSM) destination addresses and -are reserved for use by source-specific applications and protocols. For -IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for -source-specific multicast use. This document defines an extension to -the Internet network service that applies to datagrams sent to SSM -addresses and defines the host and router requirements to support this -extension. +IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to +232.255.255.255) range are designated as source-specific multicast (SSM) +destination addresses and are reserved for use by source-specific +applications and protocols. For IP version 6 (IPv6), the address prefix +FF3x::/32 is reserved for source-specific multicast use. This document +defines an extension to the Internet network service that applies to +datagrams sent to SSM addresses and defines the host and router +requirements to support this extension. 1. Introduction @@ -81,10 +81,10 @@ identified by a multicast destination address G a "host group." This model supports both one-to-many and many-to-many group communication. This document uses the term "Any-Source Multicast" (ASM) to refer to -model of multicast defined in RFC 1112. RFC 2373 [RFC2373] specifies +model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies the form of IPv6 multicast addresses with ASM semantics. -IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are +IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are currently designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOCATION]. @@ -107,13 +107,13 @@ allocation by a host, as described in [IPV6-MALLOC]. Addresses in the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM addresses. ([IPV6-MALLOC] indicates that FF3x::0000:0001 to -FF3x:3FFF:FFFF must set P=3D0 and T=3D0, but for SSM, [IPV6-UBM] mandates +FF3x::3FFF:FFFF must set P=3D0 and T=3D0, but for SSM, [IPV6-UBM] mandates Holbrook/Cain [Page 2] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 that P=3D1 and T=3D1, hence their designation as invalid). The treatment @@ -169,7 +169,7 @@ Holbrook/Cain [Page 3] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 Multicast resource discovery of the form in which a client sends a @@ -225,7 +225,7 @@ Holbrook/Cain [Page 4] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 Multiple source applications on different hosts can use the same SSM @@ -281,7 +281,7 @@ Holbrook/Cain [Page 5] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 receiver operations allowed on a channel are called "Subscribe(S,G)" and @@ -337,7 +337,7 @@ Holbrook/Cain [Page 6] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 channel is desired on multiple interfaces, Subscribe is invoked once @@ -354,6 +354,12 @@ non-source-specific request to receive multicast sent to an SSM destination address. +A host that does not support these IP module interfaces (e.g., ASM-only +hosts) and their underlying protocols can not expect to reliably receive +traffic sent on an SSM channel. As specified below in Section 5.2, +routers will not set up SSM forwarding state or forward datagrams in +response to an ASM join request. + Widespread implementations of the IP packet reception interface (e.g., the recvfrom() system call in BSD unix) do not allow a receiver to determine the destination address to which a datagram was sent. On a @@ -383,29 +389,27 @@ I, the host IP module sends an unsubscription request for that channel to interface I. -These requests will typically be Internet Group Management Protocol -version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery -Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that -supports the SSM service model MUST implement the host portion of -[IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the - Holbrook/Cain [Page 7] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 +These requests will typically be Internet Group Management Protocol +version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery +Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that +supports the SSM service model MUST implement the host portion of +[IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the IGMPv3/MLDv2 behavior described in [GMP-SSM]. 4.3. Allocation of Source-Specific Multicast Addresses -The SSM destination address 232.0.0.0 is reserved, and a system MUST NOT -send a datagram with a destination address of 232.0.0.0. The address -range 232.0.0.1-232.0.0.255 is currently reserved for allocation by -IANA. SSM destination addresses in the range FF3x::4000:0000 through -FF3x::7FFF:FFFF are similarly reserved for IANA allocation -[IPv6-MALLOC]. +The SSM destination address 232.0.0.0 is reserved, and it must not be +used as a destination address. The address range 232.0.0.1-232.0.0.255 +is currently reserved for allocation by IANA. SSM destination addresses +in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are similarly +reserved for IANA allocation [IPv6-MALLOC]. The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host. @@ -440,17 +444,18 @@ This document neither defines the interfaces for requesting or returning addresses nor specifies the host algorithms for storing those allocations. One plausible abstract API is defined in RFC 2771 -[RFC2771]. Note that RFC 2771 allows an application to request an -address within a specific range of addresses. If this interface is -used, the starting address of the range SHOULD be selected at random by -the application. Holbrook/Cain [Page 8] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 + +[RFC2771]. Note that RFC 2771 allows an application to request an +address within a specific range of addresses. If this interface is +used, the starting address of the range SHOULD be selected at random by +the application. For IPv6, administratively scoped SSM channel addresses are created by choosing an appropriate scope identifier for the SSM destination @@ -495,19 +500,19 @@ A network can concurrently support SSM in the SSM address range and any- source multicast in the rest of the multicast address space, and it is expected that this will be commonplace. In such a network, a router may -receive a non-source-specific, or "(*,G)" in conventional terminology, -request for delivery of traffic in the SSM range from a neighbor that -does not implement source-specific multicast in a manner compliant with -this document. A router that receives such a non-source-specific -request for data in the SSM range MUST NOT use the request to establish Holbrook/Cain [Page 9] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 +receive a non-source-specific, or "(*,G)" in conventional terminology, +request for delivery of traffic in the SSM range from a neighbor that +does not implement source-specific multicast in a manner compliant with +this document. A router that receives such a non-source-specific +request for data in the SSM range MUST NOT use the request to establish forwarding state and MUST NOT propagate the request to other neighboring routers. A router MAY log an error in such a case. This applies both to any request received from a host, e.g., an IGMPv1 or IGMPv2 host @@ -535,63 +540,50 @@ 7. Security Considerations This section outlines security issues pertaining to SSM. The following -topics are addressed: limitations of IPSec, denial of service attacks, -source spoofing, and security issues related to administrative scoping. - -7.1. IPSec and SSM +topics are addressed: IPsec, denial of service attacks, source spoofing, +and security issues related to administrative scoping. -The IPSec Authentication Header (AH) and Encapsulating Security Payload -(ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this -writing, however, the IPSec protocols have some limitations when used -with SSM. This section describes those limitations. +7.1. IPsec and SSM -[IPSEC] specifies that every incoming packet that requires IPSec -processing is ultimately looked up in a local Security Association -Database (SAD) to determine the Security Association (SA) that is to be -applied to the packet. The resulting SA determines the decryption -and/or authentication key to use and the anti-replay window, if one is -used. The key used for the SAD lookup is: +The IPsec Authentication Header (AH) and Encapsulating Security Payload +(ESP) can be used to secure SSM traffic, if a multicast-capable +implementation of IPsec (as required in [IPSECbis]) is used by the +receivers. - - the packet's destination IP address - - the IPSec protocol (ESP or AH) +7.2. SSM and RFC2401 IPsec caveats +For existing implementations of (the now superseded by [IPSECbis]) +RFC2401 IPsec, there are a few caveats relate to SSM. They are listed +here. In RFC2401 IPsec, the source address is not used as part of the Holbrook/Cain [Page 10] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 - - - - the Security Parameter Index (SPI) +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 -A problem arises for SSM because the source address is not included in -the SAD lookup. IPSec does not currently provide any way to ensure that -two unrelated SSM channels will have unique SAD entries at all -receivers. Two senders that happen to choose the same SSM destination -address and the same Security Parameter Index will "collide" in the SAD -at any host that is receiving both channels. Because the channel -addresses and SPIs are both allocated autonomously by the senders, there -is no reasonable means to ensure that each sender uses a unique -destination address or SPI. -In practice, this problem only arises if a receiver subscribes -simultaneously to two unrelated channels using IPSec whose sources -happen to have chosen the same IP destination address (IPDA) and the -same IPSec SPI. The tuple, however, consists of 56 bits that -are generally randomly chosen, and a conflict is unlikely to occur -through random chance. +key in the SAD lookup. As a result, two senders that happen to use the +same SSM destination address and the same Security Parameter Index will +"collide" in the SAD at any host that is receiving both channels. that +each sender uses a unique destination address or SPI. -But when this problem occurs, however unlikely, a host will not be able -to simultaneously receive IPSec-protected traffic from the two colliding -sources under the current IPSec model. +A problem arises if a receiver subscribes simultaneously to two +unrelated channels using IPsec whose sources happen to be using the same +IP destination address (IPDA) and the same IPsec SPI. Because the +channel destination addresses are allocated autonomously by the senders, +any two hosts can simultaneously use the same destination address, and +there is no reasonable means to ensure that this does not happen. The + tuple, however, consists of 56 bits that are generally +randomly chosen (24 bits of the IP destination and 32 bits of the SPI) +and a conflict is unlikely to occur through random chance. -This problem is under investigation and a solution will appear in a -separate document. One possible solution is to include the source -address in the SAD lookup when the destination is an SSM address. +If such a collision occurs, a receiver will not be able to +simultaneously receive IPsec-protected traffic from the two colliding +sources. -7.2. Denial of Service +7.3. Denial of Service A subscription request creates (S,G) state in a router to record the subscription, invokes processing on that router, and possibly causes @@ -613,13 +605,6 @@ To reduce the damage from such an attack, a router MAY have configuration options to limit, for example, the following items: - - -Holbrook/Cain [Page 11] -=0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 - - - The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks) @@ -627,6 +612,14 @@ - The total number of subscriptions that can be initiated from any single interface or host. + + + +Holbrook/Cain [Page 11] +=0C +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 + + Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may use large numbers of channels. Tight limits on the @@ -640,15 +633,16 @@ We note that these attacks are not unique to SSM -- they are also present for any-source multicast. -7.3. Spoofed Source Addresses +7.4. Spoofed Source Addresses By forging the source address in a datagram, an attacker can potentially violate the SSM service model by transmitting datagrams on a channel belonging to another host. Thus, an application requiring strong authentication should not assume that all packets that arrive on a channel were sent by the requested source without higher-layer -authentication mechanisms. The IPSEC Authentication Header [IPSEC] may -be used to authenticate the source of an SSM transmission, for instance. +authentication mechanisms. The IPSEC Authentication Header +[IPSEC,IPSECbis] may be used to authenticate the source of an SSM +transmission, for instance. Some degree of protection against spoofed source addresses in multicast is already fairly widespread, because the commonly deployed IP multicast @@ -665,7 +659,13 @@ source spoofing mechanisms such as source address filtering at the edges of the network are also strongly encouraged. +7.5. Administrative Scoping +Administrative scoping should not be relied upon as a security measure +[ADMIN-SCOPE]; however, in some cases it is part of a security solution. +It should be noted that no administrative scoping exists for IPv4 +source-specific multicast. An alternative approach is to manually +configure traffic filters to create such scoping if necessary. @@ -673,17 +673,9 @@ Holbrook/Cain [Page 12] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 -7.4. Administrative Scoping - -Administrative scoping should not be relied upon as a security measure -[ADMIN-SCOPE]; however, in some cases it is part of a security solution. -It should be noted that no administrative scoping exists for IPv4 -source-specific multicast. An alternative approach is to manually -configure traffic filters to create such scoping if necessary. - Furthermore, for IPv6, neither source nor destination address scoping should be used as a security measure. In some currently-deployed IPv6 routers (those that do not conform to [SCOPED-ARCH]), scope boundaries @@ -715,31 +707,31 @@ 9. IANA Considerations -Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses -in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services -with wide applicability that either require or would strongly benefit if -all hosts used a well-known SSM destination address for that service. -IANA shall allocate addresses in this range according to IETF Consensus -[IANA-CONSIDERATIONS]. Any proposal for allocation must consider the -fact that, on an Ethernet network, all datagrams sent to any SSM -destination address will be transmitted with the same link-layer -destination address, regardless of the source. Furthermore, the fact +IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255 +and IPv6 addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF. +These addresses are allocated according to IETF Consensus [IANA- +CONSIDERATIONS]. These address ranges are reserved for services with +wide applicability that either require or would strongly benefit if all +hosts used a well-known SSM destination address for that service. Any +proposal for allocation must consider the fact that, on an Ethernet +network, all datagrams sent to any SSM destination address will be +transmitted with the same link-layer destination address, regardless of +the source. Furthermore, the fact that SSM destinations in 232.0.0.0/24 +and 232.128.0.0/24 use the same link-layer addresses as the reserved IP +multicast group range 224.0.0.0/24 must also be considered. Similar +consideration should be given to the IPv6 reserved multicast addresses. +Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM +destination address to a particular entity or application. To do so +would compromise one of the important benefits of the source-specific -Holbrook/Cain [Page 13] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 +Holbrook/Cain [Page 13] +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 -that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same -link-layer addresses as the reserved IP multicast group range -224.0.0.0/24 must also be considered. Similar consideration should be -given to the IPv6 reserved multicast addresses. -Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM -destination address to a particular entity or application. To do so -would compromise one of the important benefits of the source-specific model: the ability for a host to simply and autonomously allocate a source-specific multicast address from a large flat address space. @@ -781,21 +773,23 @@ (Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in Progress), July 2004. +[RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program +Protocol Specification," September 1981. +[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, +August 1989. -Holbrook/Cain [Page 14] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 -[RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program -Protocol Specification," September 1981. -[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, -August 1989. +Holbrook/Cain [Page 14] -[RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing -Architecture." RFC 2373, July 1998. +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 + + +[RFC3513] Hinden, R. and Deering, S. "IP Version 6 (IPv6) Addressing +Architecture." RFC 3513, April 2003. 12. Informative References @@ -824,28 +818,31 @@ [PIM-DM] Adams, A., Nicholas, J., and Siadak, W. "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)," -draft-ietf-pim-dm-new-v2-05.txt, Work in Progress. +RFC3973, January 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. +[IPSECbis] S. Kent, K. Seo, "Security Architecture for the Internet +Protocol.", draft-ietf-ipsec-rfc2401bis-06. + [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation," RFC 2771, February 2000. +[SCOPINGV6] S. Deering, B. Haberman, T. + Jinmei, E. Nordmark, B. Zill, "IPv6 Scoped Address Architecture", +RFC4007, March 2005. Holbrook/Cain [Page 15] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 - +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 -[SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address -Architecture", Work in Progress. [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, @@ -864,15 +861,16 @@ Hugh Holbrook - Cisco Systems - 170 W. Tasman Drive - San Jose, CA 95134 - holbrook@cisco.com + Arastra, Inc. + P.O. Box 10905 + Palo Alto, CA 94303 + holbrook@arastra.com + Phone: +1 650 331-1620 Full Copyright Statement -Copyright (C) The Internet Society (2004). This document is subject to +Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. @@ -892,16 +890,15 @@ document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the +procedures with respect to rights in RFC documents can be found in BCP +78 and BCP 79. Holbrook/Cain [Page 16] =0C -INTERNET-DRAFT Source-Specific Multicast 07 Sep 2004 - +INTERNET-DRAFT Source-Specific Multicast 04 Oct 2005 -procedures with respect to rights in RFC documents can be found in BCP -78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt @@ -916,7 +913,10 @@ standard. Please address the information to the IETF at ietf- ipr@ietf.org. -This document expires Mar 07, 2005. +This document expires Apr 04, 2006. + + + _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Tue Oct 04 13:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMqOd-0007cA-Qu; Tue, 04 Oct 2005 13:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpPS-0007o8-CP for ssm@megatron.ietf.org; Tue, 04 Oct 2005 12:12:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06648 for ; Tue, 4 Oct 2005 12:12:51 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMpY6-000850-Hq for ssm@ietf.org; Tue, 04 Oct 2005 12:21:54 -0400 Received: by zproxy.gmail.com with SMTP id n1so98176nzf for ; Tue, 04 Oct 2005 09:12:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ks4T0VnVoae1mJSI0JiN0cv/cPLvEhPohSIAtC8a1uCfrtqVw0fh+xnEZivHOVpXlxBgK8i959E3Hab6DoA3FRTBeA0aHeQurK4Zzm4ouFdbT+XhNXHdVR4R7e93r7Jz2zAMkxOjUxzQmq3EbQbZZEcxNTGZd/Qz5leXVLoaJkw= Received: by 10.36.91.13 with SMTP id o13mr369817nzb; Tue, 04 Oct 2005 09:12:40 -0700 (PDT) Received: by 10.36.47.18 with HTTP; Tue, 4 Oct 2005 09:12:40 -0700 (PDT) Message-ID: <6e0714c70510040912t7c9bece0h5181d02012e111fc@mail.gmail.com> Date: Tue, 4 Oct 2005 09:12:40 -0700 From: Hugh Holbrook To: Toerless Eckert In-Reply-To: <6e0714c70510040901x2e9bc115n74b1e3ffd92ddf7c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051004091338.GF9249@cisco.com> <6e0714c70510040901x2e9bc115n74b1e3ffd92ddf7c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 04 Oct 2005 13:15:30 -0400 Cc: zinin@psg.com, jedi@cisco.com, bcain@storigen.com, fenner@research.att.com, David Meyer , ssm@ietf.org Subject: [ssm] Re: URGENT: draft-ietf-ssm-arch-06.txt X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hugh Holbrook List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org > The diffs relative to the -06 revision are attached below. Here are the diffs in rfcdiff side-by-side format, which is more readable, IMO. In case you're inclined to review them. http://thoop.net/ssm/draft-ietf-ssm-arch-from--06.diff.html Thanks, -Hugh _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 05 14:00:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDYo-00072N-Sa; Wed, 05 Oct 2005 14:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENAKm-0001Pj-RH for ssm@megatron.ietf.org; Wed, 05 Oct 2005 10:33:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27538 for ; Wed, 5 Oct 2005 10:33:26 -0400 (EDT) Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENATf-0005bH-SP for ssm@ietf.org; Wed, 05 Oct 2005 10:42:41 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id A9DA48540; Wed, 5 Oct 2005 10:33:14 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j95EXEFY017103; Wed, 5 Oct 2005 07:33:14 -0700 From: Bill Fenner Message-Id: <200510051433.j95EXEFY017103@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: "David Meyer (dmm)" Subject: RE: [ssm] URGENT: draft-ietf-ssm-arch-06.txt Date: Wed, 5 Oct 2005 07:33:14 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: zinin@psg.com, "jedi \(mailer list\)" , Brian Haberman , ssm@ietf.org, "Toerless Eckert \(eckert\)" , bcain@storigen.com X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org >Where are we now? Can someone summarize? Hugh has submitted -07, and has been in contact with reviewers to see if he has addressed their comments. We should be able to move forward with IESG re-review in the next few weeks, and pending an unexpected surprise it will be approved. Bill _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 05 16:12:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFd1-0001Mr-8X; Wed, 05 Oct 2005 16:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFH9-00052Y-If; Wed, 05 Oct 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13733; Wed, 5 Oct 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENFQ5-00063E-CN; Wed, 05 Oct 2005 15:59:17 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENFH7-0008VD-Vw; Wed, 05 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ssm@ietf.org Subject: [ssm] I-D ACTION:draft-ietf-ssm-arch-07.txt X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source-Specific Multicast Working Group of the IETF. Title : Source-Specific Multicast for IP Author(s) : H. Holbrook, B. Cain Filename : draft-ietf-ssm-arch-07.txt Pages : 18 Date : 2005-10-5 IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ssm-arch-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ssm-arch-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-5114052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssm-arch-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssm-arch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-5114052.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --NextPart-- From ssm-bounces@ietf.org Wed Oct 05 17:28:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGoc-0002vS-LL; Wed, 05 Oct 2005 17:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGob-0002vJ-Ce for ssm@megatron.ietf.org; Wed, 05 Oct 2005 17:28:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02050 for ; Wed, 5 Oct 2005 17:28:38 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENGxW-0005Sw-Aw for ssm@ietf.org; Wed, 05 Oct 2005 17:37:57 -0400 Received: by zproxy.gmail.com with SMTP id n1so106369nzf for ; Wed, 05 Oct 2005 14:28:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kpzt8FTcC0Y9NhsZMk3hwhz2UegBFpOUzycggGGh4cSjYWYleUthNVAmO7IRKRhynMMx9KEXRvraLBskIsPTUk9rbYZze0v+2yNk5YO2lYxhqZRQUypOuuBGj4FJhLyZkQ2o/Ho761mxgdS5ugk1mUVaJdwkt4LOsLoDS+yoz/E= Received: by 10.36.43.8 with SMTP id q8mr1019564nzq; Wed, 05 Oct 2005 14:28:27 -0700 (PDT) Received: by 10.36.47.18 with HTTP; Wed, 5 Oct 2005 14:28:27 -0700 (PDT) Message-ID: <6e0714c70510051428hebe18beia4bdbaf6bfbc8553@mail.gmail.com> Date: Wed, 5 Oct 2005 14:28:27 -0700 From: Hugh Holbrook To: ssm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Subject: [ssm] summary of changes in draft-ietf-ssm-arch-07.txt X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hugh Holbrook List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Ok, draft-ietf-ssm-arch-07.txt is now available in the ID archives. I am optimistic that this version can pass through the IESG review. A nice colorized rfcdiff html page indicating what changed between the -06 version and the -07 draft is available at this page: http://thoop.net/ssm/draft-ietf-ssm-arch-07-from-6.diff.html The rest of this mail summarizes all the changes in the -07 version.=20 My first submission yesterday got rejected by the idnits bot because it had stale boilerplate. I fixed that and discovered that the document is now over 15 pages, so idnits complained that it lacked a table of contents, which I added. While I was trying to convince nroff to generate a ToC, I did one more pass over the IESG review comments to identify anything that might block the passage through the IESG review. In doing so I realized that I had not yet responded fully to Spencer Dawkins' gen-arts review, so I added a few sentences in response to his review. I sent them to Spencer, and he seemed happy with my proposed changes. One of the comments he made was asking for clarification why 232.0.0.0 is a reserved address that IANA should not allocate. [The original motiviation for this was to have one "reserved" address that is unused, which can be convenient in an implementation, similar to the way that 224.0.0.0 is reserved for ASM. Steve Deering originally suggested this, I think.] So I added some text to 4.3 to clarify. While editing that section, I remembered a comment that someone made along the way (I think it was Alex or maybe Pekka) asking why there isn't an IPv6 reserved address for the same reason. This is basiclaly just an oversight, and I think this issue could legitimately come up in the IESG review, so I added some text to 4.3 (SSM address allocation) and Section 9 (IANA considerations) to give FF3x::4000:0000 consideration similar to 232.0.0.0. FF3x::4000:0000 comes out of the space that is already reserved for IANA allocation, so I don't think this has any operational or practical impact for anyone who is compliant with the current draft. But if anyone has any opinion on this (either way) I'd appreciate your input at this point, since this is the one change in this revision that is not basically a clarification. Spencer also requested a clarification as to how a receiver can detect the SPI collision problem (documented in Section 7.2). So I added one sentence to section 7 explaining this. The only other change in the -07 version that weren't in the diffs I sent out yesterday is to add a table of contents, and to update a few of the references. [And of course there are the changes I mentioned in yesterday's mail -- the primary one of which adding section 7.1 and the moving of the text that was in 7.1 to 7.2, to address the security DISCUSS.] -Hugh ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Oct 5, 2005 12:50 PM Subject: [ssm] I-D ACTION:draft-ietf-ssm-arch-07.txt To: i-d-announce@ietf.org Cc: ssm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source-Specific Multicast Working Group of the IETF. Title : Source-Specific Multicast for IP Author(s) : H. Holbrook, B. Cain Filename : draft-ietf-ssm-arch-07.txt Pages : 18 Date : 2005-10-5 IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ssm-arch-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ssm-arch-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail reader= s exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Tue Oct 18 10:47:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERskI-0005fc-RK; Tue, 18 Oct 2005 10:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERskD-0005eP-0H; Tue, 18 Oct 2005 10:47:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04927; Tue, 18 Oct 2005 10:47:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsvl-0007dK-Dh; Tue, 18 Oct 2005 10:59:09 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ERskB-00035J-R4; Tue, 18 Oct 2005 10:47:11 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 18 Oct 2005 10:47:11 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ssm chair , Internet Architecture Board , ssm mailing list , RFC Editor Subject: [ssm] Protocol Action: 'Source-Specific Multicast for IP' to Proposed Standard X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org The IESG has approved the following document: - 'Source-Specific Multicast for IP ' as a Proposed Standard This document is the product of the Source-Specific Multicast Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-07.txt Technical Summary IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. Working Group Summary The document has gone through an extensive discussion in the WG. That includes IPR-related concerns. The rough consensus within the WG was to move forward with the technology even in the presense of IPR claims. Protocol Quality The specification has been reviewed for IESG by Alex Zinin. There are a number of interoperable implementations of this technology. RFC-Editor Note: Section 7.2, para 1: OLD: For existing implementations of (the now superseded by [IPSECbis]) RFC2401 IPsec, there are a few caveats relate to SSM. They are listed here. In RFC2401 IPsec, the source address is not used as part of the key in the SAD lookup. As a result, two senders that happen to use the same SSM destination address and the same Security Parameter Index will "collide" in the SAD at any host that is receiving both channels. that each sender uses a unique destination address or SPI. NEW: For existing implementations of (the now superseded by [IPSECbis]) RFC2401 IPsec, there are a few caveats relate to SSM. They are listed here. In RFC2401 IPsec, the source address is not used as part of the key in the SAD lookup. As a result, two senders that happen to use the same SSM destination address and the same Security Parameter Index will "collide" in the SAD at any host that is receiving both channels. Because the channel addresses and SPIs are both allocated autonomously by the senders, there is no reasonable means to ensure that each sender uses a unique destination address or SPI. _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 08:48:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDNE-00023t-T7; Wed, 19 Oct 2005 08:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDND-00023L-36 for ssm@megatron.ietf.org; Wed, 19 Oct 2005 08:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13636 for ; Wed, 19 Oct 2005 08:48:41 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDYu-0002H2-Jw for ssm@ietf.org; Wed, 19 Oct 2005 09:00:59 -0400 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j9JCmgw6005548 for ; Wed, 19 Oct 2005 14:48:42 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j9JCmgB7010129 for ; Wed, 19 Oct 2005 14:48:42 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j9JCmg9B010128 for ssm@ietf.org; Wed, 19 Oct 2005 14:48:42 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Oct 2005 14:48:41 +0200 From: Stig Venaas To: ssm mailing list Message-ID: <20051019124841.GL9025@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [ssm] msnip status X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Now that magma is being shut down, what is the future of draft-ietf-magma-msnip? I know several people that are interested in seeing this work continue. Are there any plans for that, or has it more or less been decided that this is not the way to go? I know there were discussions on combining it with MRD, but don't think that went anywhere. Stig _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 12:41:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESH0A-0002py-VG; Wed, 19 Oct 2005 12:41:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESH07-0002ps-3r for ssm@megatron.ietf.org; Wed, 19 Oct 2005 12:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27544 for ; Wed, 19 Oct 2005 12:41:06 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESHBs-0000b2-Du for ssm@ietf.org; Wed, 19 Oct 2005 12:53:25 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.6509219; Wed, 19 Oct 2005 12:40:32 -0400 In-Reply-To: <20051019124841.GL9025@storhaugen.uninett.no> References: <20051019124841.GL9025@storhaugen.uninett.no> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: Brian Haberman Subject: Re: [ssm] msnip status Date: Wed, 19 Oct 2005 12:40:30 -0400 To: Stig Venaas X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0479784884==" Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org --===============0479784884== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--1038508064; protocol="application/pkcs7-signature" --Apple-Mail-5--1038508064 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Stig, The consensus is that msnip is not the solution people want. Additionally, there has been no one volunteering to work on the problem in general. Combining MSNIP with MRD doesn't make a lot of sense and any such plans were abandoned. If you have people interested in the problem, have them bring forth ideas. Regards, Brian On Oct 19, 2005, at 8:48, Stig Venaas wrote: > Now that magma is being shut down, what is the future of > draft-ietf-magma-msnip? I know several people that are > interested in seeing this work continue. Are there any > plans for that, or has it more or less been decided that > this is not the way to go? I know there were discussions > on combining it with MRD, but don't think that went > anywhere. > > Stig > > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm --Apple-Mail-5--1038508064 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDE5MTY0MDMxWjAjBgkqhkiG9w0B CQQxFgQUvTK55YNNYxR2qWlE+v4B2JKPObMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAIGHK4Gpk8sKQ2u3h2L3aOu7jHDGLLzfW2cx3v1vnVsog25q3JeVAcINWRRc5gblXPmxi Lw6uaAdmhS0KKGth4tEEN8OVQje/OMoPqux3vFEplyuslfDAVaFSWh8GGYT4IrPFT35prPNdAkZe h2xA44lGoz6K1zdmwjgMyHcr7bWSLOfzrfh7gm3gswSc6HQ7JgOvfnzX0x4mEW5wKh4QduLWsxM/ wKHWo46D0Onh1aEb4aUea0/LjtU7vv4qENh1w4M1RfiPEt++kDP/1IeifKFwnzXiTP/5IXDh+8Z0 nWIxg4XQyuHKttT57eVKosjuxk86x8OZz/oOb+OW6az+VwAAAAAAAA== --Apple-Mail-5--1038508064-- --===============0479784884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --===============0479784884==-- From ssm-bounces@ietf.org Wed Oct 19 13:55:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESI9x-0001A8-EM; Wed, 19 Oct 2005 13:55:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESI9w-0001A0-DV for ssm@megatron.ietf.org; Wed, 19 Oct 2005 13:55:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02044 for ; Wed, 19 Oct 2005 13:55:18 -0400 (EDT) Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESILi-0002u2-M8 for ssm@ietf.org; Wed, 19 Oct 2005 14:07:39 -0400 Received: from [192.168.0.216] (HELO mars.innerghost.net) by av.it.pt (CommuniGate Pro SMTP 4.3.7) with ESMTP id 3443672; Wed, 19 Oct 2005 18:54:02 +0100 Received: by mars.innerghost.net (Postfix, from userid 1000) id 5C7DB409D; Wed, 19 Oct 2005 18:55:05 +0100 (WEST) Date: Wed, 19 Oct 2005 18:55:05 +0100 From: Hugo Santos To: Brian Haberman Subject: Re: [ssm] msnip status Message-ID: <20051019175505.GL26261@innerghost.net> References: <20051019124841.GL9025@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Hi Brian, > The consensus is that msnip is not the solution people want. > Additionally, there has been no one volunteering to work on the > problem in general. I guess the question is why MSNIP isn't the solution people want and what is the alternative (if there is one). If there is no alternative, even if MSNIP isn't a perfect solution, why hasn't the work progressed? With the MSNIP draft in MAGMA reaching -05 i guess there was some interest in the past so it isn't perfectly clear why this draft was left to die a graceful/ungraceful death. > Combining MSNIP with MRD doesn't make a lot of sense > and any such plans were abandoned. As Stig, i also saw some discussions regarding this in the MAGMA mailing list, IIRC it involved some capability discovery that somewhere in time people wanted to add to MRD, and wanted to re-use that in MSNIP (to announce configured SSM ranges and others, IIRC). > If you have people interested in the problem, have them bring > forth ideas. Personally i believe it would be good to have a solution that would allow sources to be active only when there was downstream interest without explicit signaling between listeners and senders. So in that sense, i'm interested in the problem. Also, if possible, i would like to hear the original authors' ideas as why it is or isn't a good idea to continue with this work, and why. It would be good to have the reasons archived somewhere for future reference. If in the other hand the original authors believe this work should be progressed but don't have the cycles/interest to do so, please come forward and say so there might be other people available to do so. Best Regards, Hugo Santos _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 14:07:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESILC-0005jV-IV; Wed, 19 Oct 2005 14:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESILA-0005jK-76 for ssm@megatron.ietf.org; Wed, 19 Oct 2005 14:07:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02803 for ; Wed, 19 Oct 2005 14:06:54 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESIWv-0003J0-OD for ssm@ietf.org; Wed, 19 Oct 2005 14:19:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9JI6gN06716; Wed, 19 Oct 2005 21:06:42 +0300 Date: Wed, 19 Oct 2005 21:06:42 +0300 (EEST) From: Pekka Savola To: Hugo Santos Subject: Re: [ssm] msnip status In-Reply-To: <20051019175505.GL26261@innerghost.net> Message-ID: References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019175505.GL26261@innerghost.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Brian Haberman , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org On Wed, 19 Oct 2005, Hugo Santos wrote: > Personally i believe it would be good to have a solution that would > allow sources to be active only when there was downstream interest > without explicit signaling between listeners and senders. So in that > sense, i'm interested in the problem. While solving this kind of problem might be an interesting academic or engineering exercise, personally I'd prefer not to use the time and energy for this at this point. That is because I believe there is not sufficiently high demand for such a protocol, and there are WAY too many multicast protocols out there already which aren't really all that useful to be worth universal implementation, deployment, etc. (at least yet). If (SSM) multicast becomes widespread so we wouldn't be doing the work just for the fun of it, let's revisit the need for the protocol. Otherwise I think we should let it rest until the time is right. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 19:12:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESN6f-00009f-GL; Wed, 19 Oct 2005 19:12:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESN6d-000092-9V for ssm@megatron.ietf.org; Wed, 19 Oct 2005 19:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16925 for ; Wed, 19 Oct 2005 19:12:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESNIP-000547-88 for ssm@ietf.org; Wed, 19 Oct 2005 19:24:35 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2005 16:12:08 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9JNC6Jh012017; Wed, 19 Oct 2005 16:12:06 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA16444; Wed, 19 Oct 2005 16:12:04 -0700 (PDT) Date: Wed, 19 Oct 2005 16:12:04 -0700 From: Toerless Eckert To: Brian Haberman Subject: Re: [ssm] msnip status Message-ID: <20051019231203.GG29643@cisco.com> References: <20051019124841.GL9025@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Isidor Kouvelas , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Brian: What exactly where the points that stopped the last MSNIP draft from moving forward ? I unfortunately don't remember the details, and in general i'm of course annoyed that there's no good means in the IETF to keep that last work status summary alive in case it needs to get picked up again. I think MSNIP tried to solve a key functionality for the SSM architecture, and while it may be possible to ad-hoc hack something similar up once somebody requires it, i still think that it would be good to have an IETF recommendation for this functionality. If we were to release an RFC, we could make it informational. I don't think that MSNIP itself needs to be focussed on what Pekka is claiming "universal adoption". Because it only applies to sources, it will always tender only to comparably much fewer places than for example IGMP. Cheers Toerless On Wed, Oct 19, 2005 at 12:40:30PM -0400, Brian Haberman wrote: > Hi Stig, > The consensus is that msnip is not the solution people want. > Additionally, there has been no one volunteering to work on the > problem in general. > > Combining MSNIP with MRD doesn't make a lot of sense > and any such plans were abandoned. > > If you have people interested in the problem, have them bring > forth ideas. > > Regards, > Brian > > On Oct 19, 2005, at 8:48, Stig Venaas wrote: > > >Now that magma is being shut down, what is the future of > >draft-ietf-magma-msnip? I know several people that are > >interested in seeing this work continue. Are there any > >plans for that, or has it more or less been decided that > >this is not the way to go? I know there were discussions > >on combining it with MRD, but don't think that went > >anywhere. > > > >Stig > > > > > >_______________________________________________ > >ssm mailing list > >ssm@ietf.org > >https://www1.ietf.org/mailman/listinfo/ssm > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm -- Thanks Toerless Eckert _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 21:27:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPDN-0007qW-2G; Wed, 19 Oct 2005 21:27:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPDM-0007qR-Ag for ssm@megatron.ietf.org; Wed, 19 Oct 2005 21:27:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01588 for ; Wed, 19 Oct 2005 21:27:18 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESPPC-0002ur-SE for ssm@ietf.org; Wed, 19 Oct 2005 21:39:43 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2005 18:27:19 -0700 X-IronPort-AV: i="3.97,232,1125903600"; d="scan'208"; a="354355672:sNHT25866312" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9K1Qk9W007562; Wed, 19 Oct 2005 18:27:16 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 18:27:15 -0700 Received: from bwilliam-t30.cisco.com ([10.89.5.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 18:27:13 -0700 Message-Id: <6.0.0.22.2.20051019202448.03370740@email.cisco.com> X-Sender: bwilliam@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 19 Oct 2005 20:26:21 -0500 To: Toerless Eckert , Brian Haberman From: Beau Williamson Subject: Re: [ssm] msnip status In-Reply-To: <20051019231203.GG29643@cisco.com> References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Oct 2005 01:27:13.0652 (UTC) FILETIME=[66416B40:01C5D515] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ssm mailing list , Isidor Kouvelas X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Well, I think the deafening silence on this topic over the last couple of years pretty much speaks for itself. To a large degree, MSNIP is a solution in search of a problem. I'd rather see us focus our efforts elsewhere myself. Beau Williamson At 10/19/2005 06:12 PM, Toerless Eckert wrote: >Brian: What exactly where the points that stopped the last MSNIP draft >from moving forward ? I unfortunately don't remember the details, >and in general i'm of course annoyed that there's no good means in the >IETF to keep that last work status summary alive in case it needs to >get picked up again. > >I think MSNIP tried to solve a key functionality for the SSM architecture, >and while it may be possible to ad-hoc hack something similar up once >somebody requires it, i still think that it would be good to have an >IETF recommendation for this functionality. > >If we were to release an RFC, we could make it informational. I don't >think that MSNIP itself needs to be focussed on what Pekka is claiming >"universal adoption". Because it only applies to sources, it will always >tender only to comparably much fewer places than for example IGMP. > >Cheers > Toerless > > >On Wed, Oct 19, 2005 at 12:40:30PM -0400, Brian Haberman wrote: > > Hi Stig, > > The consensus is that msnip is not the solution people want. > > Additionally, there has been no one volunteering to work on the > > problem in general. > > > > Combining MSNIP with MRD doesn't make a lot of sense > > and any such plans were abandoned. > > > > If you have people interested in the problem, have them bring > > forth ideas. > > > > Regards, > > Brian > > > > On Oct 19, 2005, at 8:48, Stig Venaas wrote: > > > > >Now that magma is being shut down, what is the future of > > >draft-ietf-magma-msnip? I know several people that are > > >interested in seeing this work continue. Are there any > > >plans for that, or has it more or less been decided that > > >this is not the way to go? I know there were discussions > > >on combining it with MRD, but don't think that went > > >anywhere. > > > > > >Stig > > > > > > > > >_______________________________________________ > > >ssm mailing list > > >ssm@ietf.org > > >https://www1.ietf.org/mailman/listinfo/ssm > > > > > _______________________________________________ > > ssm mailing list > > ssm@ietf.org > > https://www1.ietf.org/mailman/listinfo/ssm > > >-- >Thanks > Toerless Eckert > > >_______________________________________________ >ssm mailing list >ssm@ietf.org >https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Wed Oct 19 21:36:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPM6-0003rX-88; Wed, 19 Oct 2005 21:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESPM4-0003rS-EA for ssm@megatron.ietf.org; Wed, 19 Oct 2005 21:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02157 for ; Wed, 19 Oct 2005 21:36:18 -0400 (EDT) Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESPXt-0003Bx-SD for ssm@ietf.org; Wed, 19 Oct 2005 21:48:43 -0400 Received: from laptop ([85.138.126.61]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j9K1b3su027487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 20 Oct 2005 02:37:04 +0100 Message-Id: <200510200137.j9K1b3su027487@smtp.dei.uc.pt> From: "Tiago Sousa" To: Date: Thu, 20 Oct 2005 02:36:00 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcXVFqAwXegINcYoQuSTQuJKcQ0j7w== X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.398, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, HTML_MESSAGE 0.00) X-FCTUC-DEI-SIC-MailScanner-From: tmas@dei.uc.pt X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [ssm] Multicast SSM throughput in 802.11 X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1967532965==" Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org This is a multi-part message in MIME format. --===============1967532965== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5D51F.02D827B0" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5D51F.02D827B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello I am testing the PIM-SSM daemon (both freebsd and linux) and mrd6 program in a wireless link. The problem I encountered, with both pim6sd daemon and mrd6, is that I'm sending multicast traffic at 4 Mbps and the throughput reaches the mobile node (which is very near from de access point) rounding 40 kbps. I am using the mad-flute tool to send the multicast SSM traffic and the tcpdump plus trpr to analyze the data. Anyone knows why the throughput decreases so much in the wireless link? I would appreciate any help/hint that helps me to explain these results. Thanks. Tiago Sousa ------=_NextPart_000_000D_01C5D51F.02D827B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

I am testing the PIM-SSM daemon (both freebsd and = linux) and mrd6 program in a wireless link.

The problem I encountered, with both pim6sd daemon = and mrd6, is that I’m sending multicast traffic at 4 Mbps and the throughput = reaches the mobile node (which is very near from de access point) rounding 40 = kbps.

I am using the mad-flute tool to send the multicast = SSM traffic and the tcpdump plus trpr to analyze the = data.

 

Anyone knows why the throughput decreases so much in = the wireless link?

 

I would appreciate any help/hint that helps me to = explain these results.

 

Thanks.

 

Tiago Sousa

 

------=_NextPart_000_000D_01C5D51F.02D827B0-- --===============1967532965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --===============1967532965==-- From ssm-bounces@ietf.org Thu Oct 20 03:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUiU-0000iT-Kd; Thu, 20 Oct 2005 03:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESUiS-0000iL-SB for ssm@megatron.ietf.org; Thu, 20 Oct 2005 03:19:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20466 for ; Thu, 20 Oct 2005 03:19:46 -0400 (EDT) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESUuL-0004yv-6n for ssm@ietf.org; Thu, 20 Oct 2005 03:32:14 -0400 Received: from e178111158.adsl.alicedsl.de ([85.178.111.158] helo=rz-thinkpad02) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42 (FreeBSD)) id 1ESUiG-000Ks6-Ma; Thu, 20 Oct 2005 09:19:44 +0200 Date: Thu, 20 Oct 2005 09:19:53 +0200 From: Matthias Waehlisch To: Tiago Sousa Subject: Re: [ssm] Multicast SSM throughput in 802.11 In-Reply-To: <200510200137.j9K1b3su027487@smtp.dei.uc.pt> Message-ID: References: <200510200137.j9K1b3su027487@smtp.dei.uc.pt> X-X-Sender: mw@mail1.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Hi Tiago, at some access points you can configure rate limiting/a threshold for multicast. Because the wlan cell is a shared segment, you have no chance to use IGMP snooping, but you want to suppress a 'complete bandwidth allocation' by the use of multicast. regards matthias On Thu, 20 Oct 2005, Tiago Sousa wrote: > Hello > > > > I am testing the PIM-SSM daemon (both freebsd and linux) and mrd6 program in > a wireless link. > > The problem I encountered, with both pim6sd daemon and mrd6, is that I'm > sending multicast traffic at 4 Mbps and the throughput reaches the mobile > node (which is very near from de access point) rounding 40 kbps. > > I am using the mad-flute tool to send the multicast SSM traffic and the > tcpdump plus trpr to analyze the data. > > > > Anyone knows why the throughput decreases so much in the wireless link? > > > > I would appreciate any help/hint that helps me to explain these results. > > > > Thanks. > > > > Tiago Sousa > > > > _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 03:51:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVCw-0005XQ-Uz; Thu, 20 Oct 2005 03:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVCv-0005XG-12 for ssm@megatron.ietf.org; Thu, 20 Oct 2005 03:51:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22469 for ; Thu, 20 Oct 2005 03:51:14 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESVOn-0006DA-0E for ssm@ietf.org; Thu, 20 Oct 2005 04:03:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2005 03:51:14 -0400 X-IronPort-AV: i="3.97,235,1125892800"; d="scan'208"; a="74070855:sNHT25317820" Received: from [192.168.1.4] (che-vpn-cluster-2-123.cisco.com [10.86.242.123]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9K7p923029662; Thu, 20 Oct 2005 03:51:10 -0400 (EDT) Message-ID: <43574C67.6050409@cisco.com> Date: Thu, 20 Oct 2005 00:51:03 -0700 From: Isidor Kouvelas User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toerless Eckert Subject: Re: [ssm] msnip status References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> In-Reply-To: <20051019231203.GG29643@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org FWIW I do not think that dropping the MRD option was a show stopper for MSNIP. The reason the work stalled was that there was no interest. I agree with Toerless that it was a key piece for SSM. Isidor Toerless Eckert wrote: > Brian: What exactly where the points that stopped the last MSNIP draft > from moving forward ? I unfortunately don't remember the details, > and in general i'm of course annoyed that there's no good means in the > IETF to keep that last work status summary alive in case it needs to > get picked up again. > > I think MSNIP tried to solve a key functionality for the SSM architecture, > and while it may be possible to ad-hoc hack something similar up once > somebody requires it, i still think that it would be good to have an > IETF recommendation for this functionality. > > If we were to release an RFC, we could make it informational. I don't > think that MSNIP itself needs to be focussed on what Pekka is claiming > "universal adoption". Because it only applies to sources, it will always > tender only to comparably much fewer places than for example IGMP. > > Cheers > Toerless > > > On Wed, Oct 19, 2005 at 12:40:30PM -0400, Brian Haberman wrote: > >>Hi Stig, >> The consensus is that msnip is not the solution people want. >>Additionally, there has been no one volunteering to work on the >>problem in general. >> >> Combining MSNIP with MRD doesn't make a lot of sense >>and any such plans were abandoned. >> >> If you have people interested in the problem, have them bring >>forth ideas. >> >>Regards, >>Brian >> >>On Oct 19, 2005, at 8:48, Stig Venaas wrote: >> >> >>>Now that magma is being shut down, what is the future of >>>draft-ietf-magma-msnip? I know several people that are >>>interested in seeing this work continue. Are there any >>>plans for that, or has it more or less been decided that >>>this is not the way to go? I know there were discussions >>>on combining it with MRD, but don't think that went >>>anywhere. >>> >>>Stig >>> >>> >>>_______________________________________________ >>>ssm mailing list >>>ssm@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ssm > > > > >>_______________________________________________ >>ssm mailing list >>ssm@ietf.org >>https://www1.ietf.org/mailman/listinfo/ssm > > > _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 05:04:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESWLV-0004Xc-Iu; Thu, 20 Oct 2005 05:04:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESWLU-0004XU-Fk for ssm@megatron.ietf.org; Thu, 20 Oct 2005 05:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26078 for ; Thu, 20 Oct 2005 05:04:09 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESWXK-0000Ej-TJ for ssm@ietf.org; Thu, 20 Oct 2005 05:16:39 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9K93mT27893; Thu, 20 Oct 2005 12:03:48 +0300 Date: Thu, 20 Oct 2005 12:03:48 +0300 (EEST) From: Pekka Savola To: Toerless Eckert Subject: Re: [ssm] msnip status In-Reply-To: <20051019231203.GG29643@cisco.com> Message-ID: References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Brian Haberman , ssm mailing list , Isidor Kouvelas X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org On Wed, 19 Oct 2005, Toerless Eckert wrote: > I think MSNIP tried to solve a key functionality for the SSM architecture, Could you elaborate a bit on what you think is this "key functionality" and why exactly it's "key" (e.g., specific scenarios you have in mind)? I'm having difficulty understanding the (relative) importance of a sender being able to stay quiet if there are no receivers. The waste of bandwidth and processing power at the DR (who'd just discard the traffic) doesn't seem to be sufficiently concinving at least in the scenarios I have in mind. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 06:08:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXLj-0004n6-CQ; Thu, 20 Oct 2005 06:08:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXLh-0004mV-M6; Thu, 20 Oct 2005 06:08:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28973; Thu, 20 Oct 2005 06:08:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESXXb-00024r-TK; Thu, 20 Oct 2005 06:20:57 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2005 03:08:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,235,1125903600"; d="scan'208"; a="13534894:sNHT21244696" Received: from [192.168.1.4] (che-vpn-cluster-2-123.cisco.com [10.86.242.123]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9KA8MEi024878; Thu, 20 Oct 2005 06:08:23 -0400 (EDT) Message-ID: <43576C95.6080403@cisco.com> Date: Thu, 20 Oct 2005 03:08:21 -0700 From: Isidor Kouvelas User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [ssm] msnip status References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Toerless Eckert , magma@ietf.org, Brian Haberman , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Pekka Savola wrote: > Could you elaborate a bit on what you think is this "key functionality" > and why exactly it's "key" (e.g., specific scenarios you have in mind)? As I believe was described in the draft MSNIP is important in the case where you have a server with a very large number of potential sessions but only a small number of active sessions. So if the server has content available on 1000 different groups and there are active receivers at any time only for 10 of them, the box / link you would need to drive this with and withhout MSNIP is totally different. Isidor _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 06:16:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXT3-0000se-He; Thu, 20 Oct 2005 06:16:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXT2-0000sX-J2 for ssm@megatron.ietf.org; Thu, 20 Oct 2005 06:16:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29417 for ; Thu, 20 Oct 2005 06:16:01 -0400 (EDT) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESXeu-0002J3-4b for ssm@ietf.org; Thu, 20 Oct 2005 06:28:29 -0400 Received: (qmail 22571 invoked for bounce); 20 Oct 2005 10:15:34 -0000 Received: from unknown (HELO ?129.241.205.105?) (hoerdt@unknown) by unknown with RC4-MD5 encrypted SMTP; 20 Oct 2005 10:15:34 -0000 Message-ID: <43576E56.4040805@clarinet.u-strasbg.fr> Date: Thu, 20 Oct 2005 12:15:50 +0200 From: hoerdt Mickael User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [ssm] msnip status References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA29417 Cc: Toerless Eckert , Brian Haberman , Isidor Kouvelas , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Hi, MSNIP (or any logical equivalent, let call it protocol X) allows=20 ressources saving at the following points of the network : 1. the DR(s). 2. the link connecting the DR to the multicast source host(s). 3. the host(s). A possible scenario showing that protocol X is (relatively) useful would=20 be the following : . Exhaust the ressources available at any of these three points,=20 sourcing multicast content without protocol X. . Activate protocol X, and replay the same scenario showing that now the=20 ressources aren't exhausted. =20 Does it make sense to define a protocol X wich do not have to be=20 deployed/implemented in the routers, using possibily unicasting and/or pooling from the=20 source ? As a multicast application developer/coder, i would say that it depends on the SSM=20 multicast service availability.... Hoerdt Micka=EBl Pekka Savola wrote: > On Wed, 19 Oct 2005, Toerless Eckert wrote: > >> I think MSNIP tried to solve a key functionality for the SSM=20 >> architecture, > > > Could you elaborate a bit on what you think is this "key=20 > functionality" and why exactly it's "key" (e.g., specific scenarios=20 > you have in mind)? > > I'm having difficulty understanding the (relative) importance of a=20 > sender being able to stay quiet if there are no receivers. The waste=20 > of bandwidth and processing power at the DR (who'd just discard the=20 > traffic) doesn't seem to be sufficiently concinving at least in the=20 > scenarios I have in mind. > _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 06:29:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXff-000640-62; Thu, 20 Oct 2005 06:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXfd-00061Q-Ie for ssm@megatron.ietf.org; Thu, 20 Oct 2005 06:29:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00195 for ; Thu, 20 Oct 2005 06:29:04 -0400 (EDT) Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESXrX-0002k3-Pi for ssm@ietf.org; Thu, 20 Oct 2005 06:41:33 -0400 Received: from waehl.dialup.fu-berlin.de ([130.133.243.126] helo=rz-thinkpad02) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42 (FreeBSD)) id 1ESXfR-000D1H-Py; Thu, 20 Oct 2005 12:29:01 +0200 Date: Thu, 20 Oct 2005 12:29:11 +0200 From: Matthias Waehlisch To: Pekka Savola Subject: Re: [ssm] msnip status In-Reply-To: Message-ID: References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> X-X-Sender: mw@mail1.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Toerless Eckert , Brian Haberman , Isidor Kouvelas , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org hi, On Thu, 20 Oct 2005, Pekka Savola wrote: > I'm having difficulty understanding the (relative) importance of a sender > being able to stay quiet if there are no receivers. The waste of bandwidth > and processing power at the DR (who'd just discard the traffic) doesn't seem > to be sufficiently concinving at least in the scenarios I have in mind. > but if you change the focus to the sender the importance of saving e.g. processing power is increasing, especially if you think about 'small' mobile devices. also there were some ideas to use MSNIP for mobile multicast. cheers matthias _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 06:33:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXjV-0007F0-5p; Thu, 20 Oct 2005 06:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXjS-0007DS-NQ for ssm@megatron.ietf.org; Thu, 20 Oct 2005 06:33:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00554 for ; Thu, 20 Oct 2005 06:33:01 -0400 (EDT) Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESXvN-0002tY-21 for ssm@ietf.org; Thu, 20 Oct 2005 06:45:30 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id KP-BRARG.6546750; Thu, 20 Oct 2005 06:32:26 -0400 In-Reply-To: <20051019231203.GG29643@cisco.com> References: <20051019124841.GL9025@storhaugen.uninett.no> <20051019231203.GG29643@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <761a27909a6b6f8015e5c22a86052f2e@innovationslab.net> From: Brian Haberman Subject: Re: [ssm] msnip status Date: Thu, 20 Oct 2005 06:32:25 -0400 To: Toerless Eckert X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Isidor Kouvelas , ssm mailing list X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2032066844==" Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org --===============2032066844== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--974193521; protocol="application/pkcs7-signature" --Apple-Mail-1--974193521 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Toerless, As has already been said, the amount of community involvement in the MSNIP work has been less than stellar. I know of several scenarios where resource problems are encountered due to lack of feedback to multicast sources. Multicast sources attached via low-speed or wireless links is an example. I could get on my soapbox and rant about how the IETF work requires active participation from many people in order to make it successful. And in this case, as well as others, the lack of active participation has been the downfall. Regards, Brian On Oct 19, 2005, at 19:12, Toerless Eckert wrote: > Brian: What exactly where the points that stopped the last MSNIP draft > from moving forward ? I unfortunately don't remember the details, > and in general i'm of course annoyed that there's no good means in the > IETF to keep that last work status summary alive in case it needs to > get picked up again. > > I think MSNIP tried to solve a key functionality for the SSM > architecture, > and while it may be possible to ad-hoc hack something similar up once > somebody requires it, i still think that it would be good to have an > IETF recommendation for this functionality. > > If we were to release an RFC, we could make it informational. I don't > think that MSNIP itself needs to be focussed on what Pekka is claiming > "universal adoption". Because it only applies to sources, it will > always > tender only to comparably much fewer places than for example IGMP. > > Cheers > Toerless > > > On Wed, Oct 19, 2005 at 12:40:30PM -0400, Brian Haberman wrote: >> Hi Stig, >> The consensus is that msnip is not the solution people want. >> Additionally, there has been no one volunteering to work on the >> problem in general. >> >> Combining MSNIP with MRD doesn't make a lot of sense >> and any such plans were abandoned. >> >> If you have people interested in the problem, have them bring >> forth ideas. >> >> Regards, >> Brian >> >> On Oct 19, 2005, at 8:48, Stig Venaas wrote: >> >>> Now that magma is being shut down, what is the future of >>> draft-ietf-magma-msnip? I know several people that are >>> interested in seeing this work continue. Are there any >>> plans for that, or has it more or less been decided that >>> this is not the way to go? I know there were discussions >>> on combining it with MRD, but don't think that went >>> anywhere. >>> >>> Stig >>> >>> >>> _______________________________________________ >>> ssm mailing list >>> ssm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ssm > > > >> _______________________________________________ >> ssm mailing list >> ssm@ietf.org >> https://www1.ietf.org/mailman/listinfo/ssm > > > -- > Thanks > Toerless Eckert > --Apple-Mail-1--974193521 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAw+FFTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwOTIxMTM1ODA5WhcNMDYwOTIxMTM1ODA5WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhicmlhbkBpbm5vdmF0aW9u c2xhYi5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDENC3Ku7xMi2aksDT7lH6s IwI58FJea6uFN5S4en+fkPJM1MY1hKlMY2sSXQ+937lvjUkJNv9ARXpe4SaATcA4reGMOZZ0OML6 mQIZOOU1+9jOxExTVfkr7aLD8PHEEoOy7qpLCsFJ76Bhh735AVcn1BnnW4Dz5wkCjtNS50DVnpdf NOoHQTVoJOTeA/NctEHswn3BIJRcltCDwfRklznEHbi4YAv4V3mgZ6Gf4r5dheBw9z530gOSVmUm eQF00Ka5aXPn5v5pSJTkdeWLt86Lv+dNGfZfdJZzCiucggyuclTaomw5mOvGY5uWjY4QPc3uMw0A wUYo/hj2/kP+UWWtAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGJyaWFuQGlubm92YXRpb25zbGFiLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAARo9StWhGnVXFSPKeY1dVV4xrUQyhrS VH8kjiQnYAlvTlco3DdE0bATIof8BrmkN+K1v2DdeLKR0siNkx1jL3d4enOFKqFitfvpW2HrrpM3 bWYa5HQJG3avYNM/B4JDHI9y2l42cNfvjp43R5TYP9VnKuhzB3OYHYAnNMvA2QtwMIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDIwMTAzMjI1WjAjBgkqhkiG9w0B CQQxFgQUKukd9XL6nw6Z/bP+/KfwrWgDmIMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw+FFTB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPhRUwDQYJKoZIhvcNAQEB BQAEggEAuy7Z3HtQ1BLEpr6VwL4N9mj7L3z0Hqeith2IFOikvX5bF78b0UmYkilkMmu3MBZdk/6P iE7Ev8BK6uZoDsRZNwiKyNOOFdfVh/Mtfz8x0p1MgOmnJsK6QLxbCmN3H8H0dWLtFbbGOZGbpwAj UFPCS2CBCULIONzWoTyRQoYiI3r+S3dSaKsfxm4gO+gVJj0Seb5TYiSxIHhOEchgVtBEXZyANUD8 Jpazey6/gzQphxrIm+Y8agMcwvvlyDz8yu/UB67Mt6dGgjQbWEMjyWGkBiI63DQHpldi4DfrwESt SgX2rb8gy3VAqFJIhUiXPLw6/igOUSzKmq7NafedooyJVAAAAAAAAA== --Apple-Mail-1--974193521-- --===============2032066844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --===============2032066844==-- From ssm-bounces@ietf.org Thu Oct 20 11:01:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESbug-0006yb-EK; Thu, 20 Oct 2005 11:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESbud-0006xC-Ts for ssm@megatron.ietf.org; Thu, 20 Oct 2005 11:01:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19023 for ; Thu, 20 Oct 2005 11:00:48 -0400 (EDT) Received: from troy.oit.umass.edu ([128.119.175.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESc6a-0003ub-7s for ssm@ietf.org; Thu, 20 Oct 2005 11:13:21 -0400 Received: from ouroborus.oit.umass.edu (ouroborus.oit.umass.edu [128.119.1.22]) by troy.oit.umass.edu (8.13.2/8.13.2) with ESMTP id j9KF0oBl022442; Thu, 20 Oct 2005 11:00:51 -0400 (EDT) Message-Id: <200510201500.j9KF0oBl022442@troy.oit.umass.edu> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: "Tiago Sousa" Subject: Re: [ssm] Multicast SSM throughput in 802.11 In-reply-to: Your message of "Thu, 20 Oct 2005 02:36:00 BST." <200510200137.j9K1b3su027487@smtp.dei.uc.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Oct 2005 11:00:50 -0400 From: Peter Gutierrez X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org tmas@dei.uc.pt wrote: > I am testing the PIM-SSM daemon (both freebsd and linux) and mrd6 > program in a wireless link. > > The problem I encountered, with both pim6sd daemon and mrd6, is that > I'm sending multicast traffic at 4 Mbps and the throughput reaches the > mobile node (which is very near from de access point) rounding 40 > kbps. > > I am using the mad-flute tool to send the multicast SSM traffic and > the tcpdump plus trpr to analyze the data. > > > > Anyone knows why the throughput decreases so much in the wireless > link? > > > > I would appreciate any help/hint that helps me to explain these > results. Although it should not have the effect of limiting traffic to 40kbps, don't forget that multicast frames must be transmitted at a rate that is included in the Basic rate set according to the IEEE 802.11 specification. The basic rate set usually includes 1Mbps, not the 11Mbps or even 54Mbps (in 802.11g radios) that your client may claim to be its rate (which it is for unicast traffic). You may want to try removing the lower rates from the Basic set on the access point, to see if your throughput increases, if this is in a test environment. If a client does not support the Basic rate, it will not associate. -- Peter Gutierrez OIT/Network Services U. Massachusetts Amherst Voice: 413 545 1606 Fax: 413 545 3203 peterg@nic.umass.edu Opinions? "Ain't nobody's business but my own" - Irving Taylor _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 13:08:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdtd-0001pm-Pq; Thu, 20 Oct 2005 13:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdtb-0001pE-CR for ssm@megatron.ietf.org; Thu, 20 Oct 2005 13:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00298 for ; Thu, 20 Oct 2005 13:07:53 -0400 (EDT) Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESe5X-0000yp-V6 for ssm@ietf.org; Thu, 20 Oct 2005 13:20:26 -0400 Received: from din-cisuc195.dei.uc.pt (din-cisuc195.dei.uc.pt [10.3.1.195]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j9KH80Px020282 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Oct 2005 18:08:00 +0100 Subject: Re: [ssm] Multicast SSM throughput in 802.11 From: Tiago Sousa To: Peter Gutierrez In-Reply-To: <200510201500.j9KF0oBl022442@troy.oit.umass.edu> References: <200510201500.j9KF0oBl022442@troy.oit.umass.edu> Content-Type: text/plain; charset=utf-8 Date: Thu, 20 Oct 2005 18:01:16 +0100 Message-Id: <1129827676.4934.30.camel@din-cisuc195.dei.uc.pt> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: tmas@dei.uc.pt Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp2.dei.uc.pt id j9KH80Px020282 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Hello to all. Thanks for the reply. I extend the gratefulness to the others that had answered.=20 My wireless access point is configured to send traffic at rate of 54Mbps (802.11g) although my mobile node receives at 11Mbps (802.11b). So, if i understand well your suggestion the Basic Rate settings are well implemented because it is only specified 54Mbps in the AP. Am i correct? I didn't understand the suggestion of Gaurav: Profiled TCP. Can you explain better? The multicast throughput (UDP based) can also depends of the TCP profile?=20 The suggestion of Matthias: check in the AP if the multicast rate is limited. I've been in the web-based interface and i didn't find any item that refer to multicast. I am using a Belkin 54g AP. My opinion is that the problem must be in the AP because the outgoing interface of the access router sends traffic at 4 Mbps. The only thing in the middle, between the router and the MN, is the AP. So, the throughput must be affected by some item in the AP.=20 I've confirmed all the possible items in the AP and i didn't find any related with multicast... =20 Do you have more suggestions? Thanks to all. Tiago Sousa Qui, 2005-10-20 =C3=A0s 11:00 -0400, Peter Gutierrez escreveu: > tmas@dei.uc.pt wrote: > > I am testing the PIM-SSM daemon (both freebsd and linux) and mrd6 > > program in a wireless link.=20 > >=20 > > The problem I encountered, with both pim6sd daemon and mrd6, is that > > I'm sending multicast traffic at 4 Mbps and the throughput reaches th= e > > mobile node (which is very near from de access point) rounding 40 > > kbps. > >=20 > > I am using the mad-flute tool to send the multicast SSM traffic and > > the tcpdump plus trpr to analyze the data. > >=20 > > =20 > >=20 > > Anyone knows why the throughput decreases so much in the wireless > > link?=20 > >=20 > > =20 > >=20 > > I would appreciate any help/hint that helps me to explain these > > results.=20 >=20 > Although it should not have the effect of limiting traffic to 40kbps,=20 > don't forget that multicast frames must be transmitted at a rate that=20 > is included in the Basic rate set according to the IEEE 802.11=20 > specification. The basic rate set usually includes 1Mbps, not the=20 > 11Mbps or even 54Mbps (in 802.11g radios) that your client may claim to= =20 > be its rate (which it is for unicast traffic). >=20 > You may want to try removing the lower rates from the Basic set on the=20 > access point, to see if your throughput increases, if this is in a test= =20 > environment. If a client does not support the Basic rate, it will not=20 > associate. >=20 _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm From ssm-bounces@ietf.org Thu Oct 20 13:49:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeXV-0001TB-7M; Thu, 20 Oct 2005 13:49:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESeXU-0001T5-28 for ssm@megatron.ietf.org; Thu, 20 Oct 2005 13:49:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03098 for ; Thu, 20 Oct 2005 13:49:06 -0400 (EDT) Received: from troy.oit.umass.edu ([128.119.175.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESejS-0002Tb-7T for ssm@ietf.org; Thu, 20 Oct 2005 14:01:39 -0400 Received: from ouroborus.oit.umass.edu (ouroborus.oit.umass.edu [128.119.1.22]) by troy.oit.umass.edu (8.13.2/8.13.2) with ESMTP id j9KHnB4W027799; Thu, 20 Oct 2005 13:49:11 -0400 (EDT) Message-Id: <200510201749.j9KHnB4W027799@troy.oit.umass.edu> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Tiago Sousa Subject: Re: [ssm] Multicast SSM throughput in 802.11 In-reply-to: Your message of "Thu, 20 Oct 2005 18:01:16 BST." <1129827676.4934.30.camel@din-cisuc195.dei.uc.pt> Date: Thu, 20 Oct 2005 13:49:11 -0400 From: Peter Gutierrez X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Peter Gutierrez , ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org tmas@dei.uc.pt wrote: > My wireless access point is configured to send traffic at rate of > 54Mbps (802.11g) although my mobile node receives at 11Mbps (802.11b). > So, if i understand well your suggestion the Basic Rate settings are > well implemented because it is only specified 54Mbps in the AP. Am i > correct? > > I didn't understand the suggestion of Gaurav: Profiled TCP. Can you > explain better? The multicast throughput (UDP based) can also depends > of the TCP profile? > > The suggestion of Matthias: check in the AP if the multicast rate is > limited. I've been in the web-based interface and i didn't find any > item that refer to multicast. I am using a Belkin 54g AP. > > My opinion is that the problem must be in the AP because the outgoing > interface of the access router sends traffic at 4 Mbps. The only thing > in the middle, between the router and the MN, is the AP. So, the > throughput must be affected by some item in the AP. I've confirmed > all the possible items in the AP and i didn't find any related with > multicast... > > Do you have more suggestions? I am not familiar with a Belkin AP, so I can only suggest you determine what rates are set as Basic. I can't suggest how you do so. The access points I use have ssh capabilities, and I can login and query about the state of the AP, e.g., AP> show controller dot11Radio 0 ! [snip] Current Rates: 2.0 basic-5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0 Active Rates: 2.0 basic-5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0 Allowed Rates: 1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0 Best Range Rates: basic-1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0 Best Throughput Rates: basic-1.0 basic-2.0 basic-5.5 basic-6.0 basic-9.0 basic-11.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 Default Rates: basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0 Note that all multicast (and broadcast and control) frames would be transmitted at 2.0Mbps on this AP. Perhaps there is a screen output from the Belkin that displays the enabled rates and specifies which are Basic. Also, you may have better results asking your questions on a different list, instead of this ssm specific IETF list. I suggest the Internet2 multicast working group list, since you appear to be from an institution that routes to Internet2. -- Peter Gutierrez OIT/Network Services U. Massachusetts Amherst Voice: 413 545 1606 Fax: 413 545 3203 peterg@nic.umass.edu Opinions? "Ain't nobody's business but my own" - Irving Taylor _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm