From shane@onesec.net Tue Aug 1 17:27:13 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09385 for ; Tue, 1 Aug 2000 17:27:13 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA15562 for ; Tue, 1 Aug 2000 13:07:11 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e71K6wh10596 for ; Tue, 1 Aug 2000 13:06:59 -0700 (PDT) Received: from onesec.net ( [208.169.18.46]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 01 Aug 2000 13:05:49 -0700 Received: (qmail 26617 invoked by uid 6002); 1 Aug 2000 20:06:53 -0000 Date: Tue, 1 Aug 2000 20:06:53 +0000 From: Shane Amante To: ssm-interest@external.cisco.com Subject: subscribe Message-ID: <20000801200653.A22608@onesec.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organization: OneSecure, Inc. X-SMTP-HELO: onesec.net X-SMTP-MAIL-FROM: shane@onesec.net X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [208.169.18.46] subscribe From satkumar@hss.hns.com Wed Aug 2 17:56:59 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07021 for ; Wed, 2 Aug 2000 17:56:58 -0400 (EDT) From: satkumar@hss.hns.com Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28416 for ; Wed, 2 Aug 2000 13:33:57 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e72KXej26202 for ; Wed, 2 Aug 2000 13:33:40 -0700 (PDT) Received: from mars.hss.co.in ( [202.54.26.197]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 02 Aug 2000 13:33:47 -0700 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e72KYqq21800 for ; Thu, 3 Aug 2000 02:04:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525692F.00709653 ; Thu, 3 Aug 2000 01:54:15 +0530 X-Lotus-FromDomain: HSS To: ssm-interest@external.cisco.com Message-ID: <6525692F.00701356.00@sandesh.hss.hns.com> Date: Thu, 3 Aug 2000 01:59:02 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-SPAM: Yes X-SPAM-REASON: Blank Subject Line X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: mars.hss.co.in X-SMTP-MAIL-FROM: satkumar@hss.hns.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [202.54.26.197] subscribe ssm-interest From umac@future.futsoft.com Thu Aug 3 00:48:15 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08189 for ; Thu, 3 Aug 2000 00:48:15 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA09715 for ; Wed, 2 Aug 2000 20:16:38 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e733GLi28465 for ; Wed, 2 Aug 2000 20:16:21 -0700 (PDT) Received: from fsnt.future.futusoft.com ( [203.197.140.35]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 02 Aug 2000 20:16:28 -0700 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 03 Aug 2000 08:58:41 +0530 Received: from umac.future.futsoft.com ([10.0.14.32]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id IAA32139 for ; Thu, 3 Aug 2000 08:34:00 +0530 Received: by localhost with Microsoft MAPI; Thu, 3 Aug 2000 08:47:32 +0530 Message-Id: <01BFFD27.76CD9680.umac@future.futsoft.com> From: Uma Chandrasekaran Reply-To: "umac@future.futsoft.com" To: "ssm-interest@external.cisco.com" Date: Thu, 3 Aug 2000 08:47:31 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SPAM: Yes X-SPAM-REASON: Blank Subject Line X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: fsnt.future.futusoft.com X-SMTP-MAIL-FROM: umac@future.futsoft.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [203.197.140.35] Content-Transfer-Encoding: 7bit subscribe ssm-interest From Doron@bandwiz.com Fri Aug 4 22:36:40 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02344 for ; Fri, 4 Aug 2000 22:36:40 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA03563 for ; Fri, 4 Aug 2000 18:27:30 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e751REO25962 for ; Fri, 4 Aug 2000 18:27:14 -0700 (PDT) Received: from davis.bandwiz.com ( [212.150.220.34]) by proxy3.cisco.com with SMTP (MailShield v1.5); Fri, 04 Aug 2000 18:27:26 -0700 Received: by DAVIS with Internet Mail Service (5.5.2650.21) id ; Sat, 5 Aug 2000 04:27:12 +0200 Message-ID: From: Doron Rajwan To: ssm-interest@external.cisco.com Subject: Reserved addresses in the SSM range Date: Sat, 5 Aug 2000 04:27:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: davis.bandwiz.com X-SMTP-MAIL-FROM: Doron@bandwiz.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [212.150.220.34] Regarding Hugh question about reserving addresses in the SSM address space, I would suggest to reserve at least 255 addresses, or even more. First, we have nothing to loose. Second, we all know that UDP and TCP reserved ports is proven to be helpful. Third, especially if my suggestion about "Multicast on-demand" will be accepted, a multicast server will have the ability to know if it has at least one connected client to any given multicast address. In this case, we can think of the following services, each given in a different, predefined, multicast address: 1. Time service. The server's local time and time zone every second. Support packet-loss rate detection. Support "ping" for multicast. I suggest address 232.0.0.1 for this one. 2. CA service. Send certification about the server every 5 seconds. 3. Quote of the day service. Actually, quote of the minute. 4. Directory service. Send some information regarding the current server. Probably the most important service. 5. ... Doron. From dmm@sj-core.cisco.com Mon Aug 7 12:19:48 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21218 for ; Mon, 7 Aug 2000 12:19:47 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16382 for ; Mon, 7 Aug 2000 07:56:32 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e77EuFd01142 for ; Mon, 7 Aug 2000 07:56:15 -0700 (PDT) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 07:56:29 -0700 Received: (from dmm@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA13869; Mon, 7 Aug 2000 07:56:06 -0700 (PDT) From: David Meyer Message-Id: <200008071456.HAA13869@sigma.cisco.com> Subject: Re: Reserved addresses in the SSM range To: zalbanna@mci.net (zaid) Date: Mon, 7 Aug 2000 07:56:06 -0700 (PDT) Cc: ssm-interest@external.cisco.com In-Reply-To: <015501c00081$eeaefb00$e70e3ca6@Gandoo> from "zaid" at Aug 07, 2000 11:12:41 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sigma.cisco.com X-SMTP-MAIL-FROM: dmm@cisco.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: sigma.cisco.com [171.69.63.142] Content-Transfer-Encoding: 7bit No, why would you need it? Addresses in 232/8 are local to the a source. Dave According to zaid: > > Is there a plan to use the GLOB mechanism > for SSM address allocation ? > > Zaid > -----Original Message----- > From: Doron Rajwan > To: ssm-interest@external.cisco.com > Date: Friday, August 04, 2000 11:03 PM > Subject: Reserved addresses in the SSM range > > > > Regarding Hugh question about reserving addresses in the SSM address > space, > I would suggest to reserve at least 255 addresses, or even more. > > First, we have nothing to loose. > > Second, we all know that UDP and TCP reserved ports is proven to be > helpful. > > Third, especially if my suggestion about "Multicast on-demand" will be > accepted, a multicast server will have the ability to know if it has > at > least one connected client to any given multicast address. In this > case, we > can think of the following services, each given in a different, > predefined, > multicast address: > > 1. Time service. The server's local time and time zone every second. > Support packet-loss rate detection. > Support "ping" for multicast. > I suggest address 232.0.0.1 for this one. > > 2. CA service. Send certification about the server every 5 seconds. > > 3. Quote of the day service. Actually, quote of the minute. > > 4. Directory service. Send some information regarding the current > server. > Probably the most important service. > > 5. ... > > > Doron. > > > > > From zalbanna@MCI.NET Mon Aug 7 12:27:55 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25282 for ; Mon, 7 Aug 2000 12:27:54 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA09098 for ; Mon, 7 Aug 2000 07:53:38 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e77ErKR12123 for ; Mon, 7 Aug 2000 07:53:20 -0700 (PDT) Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 07:53:26 -0700 Received: from Gandoo ([166.60.14.231]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JSOPILUS849LVA8B@shoe.reston.mci.net> for ssm-interest@external.cisco.com; Mon, 7 Aug 2000 10:53:14 EST Date: Mon, 07 Aug 2000 11:12:41 -0400 From: zaid Subject: Re: Reserved addresses in the SSM range To: ssm-interest@external.cisco.com Message-id: <015501c00081$eeaefb00$e70e3ca6@Gandoo> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: NOD.RESTON.MCI.NET X-SMTP-MAIL-FROM: zalbanna@MCI.NET X-SMAP-Received-From: outside X-SMTP-PEER-INFO: nod.reston.mci.net [166.60.6.38] Content-Transfer-Encoding: 7BIT Is there a plan to use the GLOB mechanism for SSM address allocation ? Zaid -----Original Message----- From: Doron Rajwan To: ssm-interest@external.cisco.com Date: Friday, August 04, 2000 11:03 PM Subject: Reserved addresses in the SSM range Regarding Hugh question about reserving addresses in the SSM address space, I would suggest to reserve at least 255 addresses, or even more. First, we have nothing to loose. Second, we all know that UDP and TCP reserved ports is proven to be helpful. Third, especially if my suggestion about "Multicast on-demand" will be accepted, a multicast server will have the ability to know if it has at least one connected client to any given multicast address. In this case, we can think of the following services, each given in a different, predefined, multicast address: 1. Time service. The server's local time and time zone every second. Support packet-loss rate detection. Support "ping" for multicast. I suggest address 232.0.0.1 for this one. 2. CA service. Send certification about the server every 5 seconds. 3. Quote of the day service. Actually, quote of the minute. 4. Directory service. Send some information regarding the current server. Probably the most important service. 5. ... Doron. From jhall@UU.NET Mon Aug 7 15:12:34 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04404 for ; Mon, 7 Aug 2000 15:12:32 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA01935 for ; Mon, 7 Aug 2000 11:03:15 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e77I2vc29926 for ; Mon, 7 Aug 2000 11:02:57 -0700 (PDT) Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 11:03:07 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQjbga12485; Mon, 7 Aug 2000 18:01:52 GMT Received: by neserve0.corp.us.uu.net id QQjbga19037; Mon, 7 Aug 2000 14:01:32 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Reserved addresses in the SSM range In-Reply-To: <015501c00081$eeaefb00$e70e3ca6@Gandoo> from zaid at "Aug 7, 2000 11:12:41 am" To: zaid Date: Mon, 7 Aug 2000 14:01:32 -0400 (EDT) CC: ssm-interest@external.cisco.com X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SMTP-HELO: wodc7-1.corprelay.mail.uu.net X-SMTP-MAIL-FROM: jhall@UU.NET X-SMAP-Received-From: outside X-SMTP-PEER-INFO: wodc7-1.corprelay.mail.uu.net [192.48.96.68] Content-Transfer-Encoding: 7bit Hi, I am finding it difficult to know why one would wish to reserve addresses. _J In the new year, zaid wrote: > Is there a plan to use the GLOB mechanism > for SSM address allocation ? > > Zaid > -----Original Message----- > From: Doron Rajwan > To: ssm-interest@external.cisco.com > Date: Friday, August 04, 2000 11:03 PM > Subject: Reserved addresses in the SSM range > > > > Regarding Hugh question about reserving addresses in the SSM address > space, > I would suggest to reserve at least 255 addresses, or even more. > > First, we have nothing to loose. > > Second, we all know that UDP and TCP reserved ports is proven to be > helpful. > > Third, especially if my suggestion about "Multicast on-demand" will be > accepted, a multicast server will have the ability to know if it has > at > least one connected client to any given multicast address. In this > case, we > can think of the following services, each given in a different, > predefined, > multicast address: > > 1. Time service. The server's local time and time zone every second. > Support packet-loss rate detection. > Support "ping" for multicast. > I suggest address 232.0.0.1 for this one. > > 2. CA service. Send certification about the server every 5 seconds. > > 3. Quote of the day service. Actually, quote of the minute. > > 4. Directory service. Send some information regarding the current > server. > Probably the most important service. > > 5. ... > > > Doron. > > > > From hsandick@nortelnetworks.com Mon Aug 7 15:22:31 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10672 for ; Mon, 7 Aug 2000 15:22:30 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA14571 for ; Mon, 7 Aug 2000 11:05:49 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e77I5XY11974 for ; Mon, 7 Aug 2000 11:05:33 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 11:05:39 -0700 Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Mon, 7 Aug 2000 12:56:48 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id QHJPZWQF; Mon, 7 Aug 2000 10:56:27 -0700 Received: from nortelnetworks.com (sandicknt.corpeast.baynetworks.com [132.245.252.97]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N70C74RT; Mon, 7 Aug 2000 13:55:36 -0400 Message-ID: <398EF816.D56A121A@nortelnetworks.com> Date: Mon, 07 Aug 2000 13:55:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Hal Sandick" Reply-To: "Hal Sandick" Organization: Nortel Networks X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ssm-interest@external.cisco.com CC: Rob Coltun , David Oran Subject: licensing of SSM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: smtprch1.nortel.com X-SMTP-MAIL-FROM: hsandick@nortelnetworks.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: smtprch1.nortelnetworks.com [192.135.215.14] Content-Transfer-Encoding: 7bit The issue was raised that Apple has a patent that applies to SSM. What is the appropriate way to proceed with this? As a a vendor I'm concerned about advancing a standard where licensing issues are unresolved. Thanks. Regards, Hal From oran@cisco.com Mon Aug 7 15:23:11 2000 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11082 for ; Mon, 7 Aug 2000 15:23:10 -0400 (EDT) Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id LAA25464; Mon, 7 Aug 2000 11:07:45 -0700 (PDT) From: "David R. Oran" To: "Hal Sandick" , Cc: "Rob Coltun" , "Scott Bradner" Subject: RE: licensing of SSM Date: Mon, 7 Aug 2000 14:07:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <398EF816.D56A121A@nortelnetworks.com> Content-Transfer-Encoding: 7bit Ask Apple to put an IPR disclosure on the IETF web site. That's the first step. If they fail to do so then we just proceed and document that they were asked. IPR holders are in general responsible for notifying people, if they don't this can weigh against them in future disputes. Scott Bradner may wish to comment, contradict me, or refer you to the ISOC legal beagles. Dave. > -----Original Message----- > From: Hal Sandick [mailto:hsandick@nortelnetworks.com] > Sent: Monday, August 07, 2000 1:56 PM > To: ssm-interest@external.cisco.com > Cc: Rob Coltun; David Oran > Subject: licensing of SSM > > > The issue was raised that Apple has a patent that applies to SSM. What > is the appropriate way to proceed with this? As a a vendor I'm > concerned about advancing a standard where licensing issues are > unresolved. > > Thanks. > > Regards, > > Hal > > > From ssprunk@cisco.com Mon Aug 7 15:25:48 2000 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12720 for ; Mon, 7 Aug 2000 15:25:48 -0400 (EDT) Received: from glock (dallas-nt-56.cisco.com [171.68.37.56]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id LAA25575; Mon, 7 Aug 2000 11:08:40 -0700 (PDT) Message-ID: <012501c0009a$8635f2e0$382544ab@glock> From: "Stephen Sprunk" To: "Doron Rajwan" Cc: References: Subject: Re: Reserved addresses in the SSM range Date: Mon, 7 Aug 2000 12:59:49 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit 232.0/16 would be my choice for a reserved block. My reasoning: o Use of 232.0.0/24 may disrupt essential services on 224.0.0/24. o Most users/admins are already wary of addresses with zeroes. o SSM addresses are reusable since they are source-specific, so there is little danger of reserving too much space (1/256th in my case). Is there any interest in "default" group addresses based on port numbers? For instance, if I somehow know my NTP server's address but not the group number, then I could try 232.x.0.123:123, and then switch to unicast if that fails. In regard to sender notification of receiver presence, shouldn't that be handled at the transport or application layer? For example, we could modify RTCP such that responses to RTP streams sent to an SSM address would be directed to the sender instead of the group. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, GSE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com ----- Original Message ----- From: "Doron Rajwan" To: Sent: Friday, August 04, 2000 21:27 Subject: Reserved addresses in the SSM range > > Regarding Hugh question about reserving addresses in the SSM address space, > I would suggest to reserve at least 255 addresses, or even more. > > First, we have nothing to loose. > > Second, we all know that UDP and TCP reserved ports is proven to be helpful. > > Third, especially if my suggestion about "Multicast on-demand" will be > accepted, a multicast server will have the ability to know if it has at > least one connected client to any given multicast address. In this case, we > can think of the following services, each given in a different, predefined, > multicast address: > > 1. Time service. The server's local time and time zone every second. > Support packet-loss rate detection. > Support "ping" for multicast. > I suggest address 232.0.0.1 for this one. > > 2. CA service. Send certification about the server every 5 seconds. > > 3. Quote of the day service. Actually, quote of the minute. > > 4. Directory service. Send some information regarding the current server. > Probably the most important service. > > 5. ... > > > Doron. From tme@21rst-century.com Mon Aug 7 16:23:21 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12846 for ; Mon, 7 Aug 2000 16:23:20 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA17852 for ; Mon, 7 Aug 2000 12:17:20 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e77JH4e20602 for ; Mon, 7 Aug 2000 12:17:04 -0700 (PDT) Received: from sjc3-1.relay.mail.uu.net (sjc3-1.relay.mail.uu.net [199.171.54.122]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 12:17:17 -0700 Received: from 21rst-century.com by sjc3sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjbgf11217; Mon, 7 Aug 2000 19:16:31 GMT Message-ID: <398F0AB9.675E4FA9@21rst-century.com> Date: Mon, 07 Aug 2000 15:15:05 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeremy Hall CC: ssm-interest@external.cisco.com Subject: Re: Reserved addresses in the SSM range References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-SMTP-HELO: sjc3-1.relay.mail.uu.net X-SMTP-MAIL-FROM: tme@21rst-century.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: sjc3-1.relay.mail.uu.net [199.171.54.122] Content-Transfer-Encoding: 7bit Jeremy Hall wrote: > Hi, > > I am finding it difficult to know why one would wish to reserve addresses. > > _J > > Dear Jeremy; Which kind of reservation ? At the IETF, the proposal was that a small number of addresses in 232/8 be reserved for special purposes, "just in case,'" although no-one really seemed to know what those might be. I regard this as not likely to be useful, although not too objectionable either. If you're talking about GLOP type addresses, I think that there is something to be said for this, in the sense of avoiding MAC address collisions in ethernet type networks. Clearly, if everyone uses 232.0.0.1 as their favorite SSM address, this is asking for trouble. Rather that use a random address, using your GLOP address (mapped to 232/8) would make sense IMHO. It would be cleaner, and it might help in identifying the source of errant multicasts. This could be done informally without involving IANA by just making it recommended. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From cabo@tzi.org Mon Aug 7 16:35:38 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19064 for ; Mon, 7 Aug 2000 16:35:37 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23917 for ; Mon, 7 Aug 2000 12:25:22 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e77JP6d24853 for ; Mon, 7 Aug 2000 12:25:06 -0700 (PDT) Received: from (bettina.informatik.uni-bremen.de [134.102.224.3]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 12:25:19 -0700 Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e77JOoE13964; Mon, 7 Aug 2000 21:24:52 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "Stephen Sprunk" , "Doron Rajwan" Cc: Subject: RE: Reserved addresses in the SSM range Date: Mon, 7 Aug 2000 21:24:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <012501c0009a$8635f2e0$382544ab@glock> X-SMTP-HELO: bettina.informatik.uni-bremen.de X-SMTP-MAIL-FROM: cabo@tzi.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: bettina.informatik.uni-bremen.de [134.102.224.3] Content-Transfer-Encoding: 7bit > For example, we could > modify RTCP such that responses to RTP streams sent to an SSM address > would be directed to the sender instead of the group. Just remember that the RTCP receiver reporting algorithms depend on seeing every other report to gauge the group size and adjust the reporting bandwidth appropriately (see section 6.2 of RFC1889 or, better, draft-ietf-avt-rtp-new-08.txt). RTCP currently has no way to reflect this information back from the sender (which is the only one who will have it if RTCP is unicast). For NORM (NAK oriented reliable multicast, rmt working group), we will probably put a sender-based group size estimation scheme into the protocol to make this work. Gruesse, Carsten From csp@hafez.east.isi.edu Mon Aug 7 17:12:15 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07169 for ; Mon, 7 Aug 2000 17:12:14 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA26710 for ; Mon, 7 Aug 2000 13:06:34 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e77K6GH23702 for ; Mon, 7 Aug 2000 13:06:18 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 13:06:22 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id QAA03798; Mon, 7 Aug 2000 16:03:09 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id BAA15402; Tue, 8 Aug 2000 01:02:44 +0500 Message-Id: <200008072002.BAA15402@hafez.east.isi.edu> To: "Dr. Carsten Bormann" cc: Stephen Sprunk , Doron Rajwan , ssm-interest , casner@acm.org Subject: Re: Reserved addresses in the SSM range In-Reply-To: Your message of "Mon, 07 Aug 2000 21:24:50 +0200." Date: Mon, 07 Aug 2000 16:02:44 -0400 From: Colin Perkins X-SMTP-HELO: east.isi.edu X-SMTP-MAIL-FROM: csp@hafez.east.isi.edu X-SMAP-Received-From: outside X-SMTP-PEER-INFO: east.isi.edu [38.245.76.2] --> "Dr. Carsten Bormann" writes: >> For example, we could >> modify RTCP such that responses to RTP streams sent to an SSM address >> would be directed to the sender instead of the group. > >Just remember that the RTCP receiver reporting algorithms depend on seeing >every other report to gauge the group size and adjust the reporting >bandwidth appropriately (see section 6.2 of RFC1889 or, better, >draft-ietf-avt-rtp-new-08.txt). >RTCP currently has no way to reflect this information back from the sender >(which is the only one who will have it if RTCP is unicast). >For NORM (NAK oriented reliable multicast, rmt working group), we will >probably put a sender-based group size estimation scheme into the protocol >to make this work. We did figure out a way of making this work during a side discussion at the Oslo IETF, but I don't think it ever got written down.. Maybe it's time to resurrect those ideas? Colin From sob@newdev.harvard.edu Mon Aug 7 18:00:01 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00811 for ; Mon, 7 Aug 2000 18:00:00 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22036 for ; Mon, 7 Aug 2000 13:52:58 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e77KqeA15354 for ; Mon, 7 Aug 2000 13:52:40 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 13:52:46 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA25194; Mon, 7 Aug 2000 16:51:44 -0400 (EDT) Date: Mon, 7 Aug 2000 16:51:44 -0400 (EDT) From: Scott Bradner Message-Id: <200008072051.QAA25194@newdev.harvard.edu> To: hsandick@nortelnetworks.com, oran@cisco.com, ssm-interest@external.cisco.com Subject: RE: licensing of SSM Cc: rcoltun@siara.com, sob@harvard.edu X-SMTP-HELO: newdev.harvard.edu X-SMTP-MAIL-FROM: sob@newdev.harvard.edu X-SMAP-Received-From: outside X-SMTP-PEER-INFO: newdev.eecs.harvard.edu [140.247.60.212] > Scott Bradner may wish to comment, contradict me no contradicting needed - that was correct Scott From Heinrich.Hummel@icn.siemens.de Tue Aug 8 08:14:21 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03836 for ; Tue, 8 Aug 2000 08:14:20 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA26760 for ; Mon, 7 Aug 2000 23:26:54 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e786QgB18813 for ; Mon, 7 Aug 2000 23:26:42 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy1.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 23:25:21 -0700 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA15358; Tue, 8 Aug 2000 08:25:45 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA04845; Tue, 8 Aug 2000 08:23:03 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Aug 2000 08:26:16 +0200 Message-ID: From: Hummel Heinrich To: "'Stephen Sprunk'" , Doron Rajwan Cc: ssm-interest@external.cisco.com Subject: AW: Reserved addresses in the SSM range Date: Tue, 8 Aug 2000 08:26:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: beamer.mchh.siemens.de X-SMTP-MAIL-FROM: Heinrich.Hummel@icn.siemens.de X-SMAP-Received-From: outside X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA03836 If there is so much trouble with the multicast address space, why is everyone happy with this awful limitation? Why can't every unicast address S assign as many multicast-IDs (MC-IDs) by itself as to host as many TV-like webpages as it may create? Each pair (S,MC-ID) will unambiguously identify the respective delivery tree! The SSM-WG is a standardization body and can therefore define what is necessary to go with such a change. It shouldn't be a big task to define the "destination" in the IP-header : dest. addr=S, option field =MC-ID, type=SSM. It wouldn't be a big task either to adjust IGMP. And in the internet: there is no big difference if you identify the delivery tree by (S, MC-ID) rather than by (S,G). For more, see draft-hummel-ssm-00.txt Heinrich > -----Urspr> üngliche Nachricht----- > Von: Stephen Sprunk [SMTP:ssprunk@cisco.com] > Gesendet am: Montag, 7. August 2000 20:00 > An: Doron Rajwan > Cc: ssm-interest@external.cisco.com > Betreff: Re: Reserved addresses in the SSM range > > 232.0/16 would be my choice for a reserved block. My reasoning: > > o Use of 232.0.0/24 may disrupt essential services on 224.0.0/24. > o Most users/admins are already wary of addresses with zeroes. > o SSM addresses are reusable since they are source-specific, so there > is little danger of reserving too much space (1/256th in my case). > > Is there any interest in "default" group addresses based on port > numbers? For instance, if I somehow know my NTP server's address but > not the group number, then I could try 232.x.0.123:123, and then switch > to unicast if that fails. > > In regard to sender notification of receiver presence, shouldn't that be > handled at the transport or application layer? For example, we could > modify RTCP such that responses to RTP streams sent to an SSM address > would be directed to the sender instead of the group. > > S > > | | Stephen Sprunk, K5SSS, CCIE #3723 > :|: :|: Network Design Consultant, GSE > :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX > .:|||||||:..:|||||||:. Email: ssprunk@cisco.com > > > > > ----- Original Message ----- > From: "Doron Rajwan" > To: > Sent: Friday, August 04, 2000 21:27 > Subject: Reserved addresses in the SSM range > > > > > > Regarding Hugh question about reserving addresses in the SSM address > space, > > I would suggest to reserve at least 255 addresses, or even more. > > > > First, we have nothing to loose. > > > > Second, we all know that UDP and TCP reserved ports is proven to be > helpful. > > > > Third, especially if my suggestion about "Multicast on-demand" will be > > accepted, a multicast server will have the ability to know if it has > at > > least one connected client to any given multicast address. In this > case, we > > can think of the following services, each given in a different, > predefined, > > multicast address: > > > > 1. Time service. The server's local time and time zone every second. > > Support packet-loss rate detection. > > Support "ping" for multicast. > > I suggest address 232.0.0.1 for this one. > > > > 2. CA service. Send certification about the server every 5 seconds. > > > > 3. Quote of the day service. Actually, quote of the minute. > > > > 4. Directory service. Send some information regarding the current > server. > > Probably the most important service. > > > > 5. ... > > > > > > Doron. From jhall@UU.NET Tue Aug 8 08:27:55 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12471 for ; Tue, 8 Aug 2000 08:27:54 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id EAA09586 for ; Tue, 8 Aug 2000 04:17:34 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e78BHKN22058 for ; Tue, 8 Aug 2000 04:17:20 -0700 (PDT) Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 08 Aug 2000 04:15:59 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQjbir21159; Tue, 8 Aug 2000 11:17:14 GMT Received: by neserve0.corp.us.uu.net id QQjbir05590; Tue, 8 Aug 2000 07:16:56 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Reserved addresses in the SSM range In-Reply-To: from Doron Rajwan at "Aug 8, 2000 11:14:50 am" To: Doron Rajwan Date: Tue, 8 Aug 2000 07:16:56 -0400 (EDT) CC: "'Hugh LaMaster'" , "'ssm-interest@external.cisco.com'" X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SMTP-HELO: wodc7-1.corprelay.mail.uu.net X-SMTP-MAIL-FROM: jhall@UU.NET X-SMAP-Received-From: outside X-SMTP-PEER-INFO: wodc7-1.corprelay.mail.uu.net [192.48.96.68] Content-Transfer-Encoding: 7bit I can say beyond a shadow of a doubt that we will not wish to implement a feature where one packet can generate many responses. The Internet as a whole is still trying to rid of the problems with DOS attacks and directed broadcast. _J In the new year, Doron Rajwan wrote: > > Hugh LaMaster might be right that the addition of the reserved addresses > mechanism might not worth it. Still, I think that we have (almost) nothing > to loose by reserving addresses. We might gain from being able to tell if a > multicast source is alive, using the "ping" address I suggested. > > I do not have a strong opinion on this issue. > > Doron. > > > > -----Original Message----- > From: Hugh LaMaster [mailto:lamaster@nren.nasa.gov] > Sent: Tuesday, August 08, 2000 1:12 AM > To: SSM List > Subject: Re: Reserved addresses in the SSM range > > > > On Mon, 7 Aug 2000, Jeremy Hall wrote: > > > I am finding it difficult to know why one would wish to reserve addresses. > > I agree completely. I see no reason to reserve *any* SSM groups. > > > > First, we have nothing to loose. > > Not true. We have excess documentation. Look at all the current > IANA multicast address assignments that were made, sit there taking > up space in the documents, people have to read at various times, > and 99% of which are never used. > > > > Second, we all know that UDP and TCP reserved ports is proven to be > > > helpful. > > And harmful. Look at all the unnecessary port assignments in the > IANA documents. 380K worth of port assignments, almost all of > which could easily have been assigned dynamically. > > > > can think of the following services, each given in a different, > > > predefined, > > > multicast address: > > IMHO, static address and port assignments should only be used > for unavoidable bootstrap mechanisms or where a well-known port > is used to support a universal service (e.g. NTP). All other > addresses and ports should be dynamically assigned. If this > policy were followed, about 99% of these assignments could > go away. > > > > > > > 1. Time service. The server's local time and time zone every second. > > > Support packet-loss rate detection. > > > Support "ping" for multicast. > > > I suggest address 232.0.0.1 for this one. > > OK, I changed my mind. This is one that should be "reserved" > so that no one will ever use it. > > > -- > Hugh LaMaster, M/S 233-21, Email: lamaster@nren.nasa.gov > NASA Ames Research Center Or: lamaster@nas.nasa.gov > Moffett Field, CA 94035-1000 Or: lamaster@george.arc.nasa.gov > Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. > > From lamaster@nren.nasa.gov Tue Aug 8 09:11:45 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26594 for ; Mon, 7 Aug 2000 23:42:58 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA14284 for ; Mon, 7 Aug 2000 16:19:57 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e77NJjS28878 for ; Mon, 7 Aug 2000 16:19:45 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy1.cisco.com with SMTP (MailShield v1.5); Mon, 07 Aug 2000 16:18:21 -0700 Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id QAA27775 for ; Mon, 7 Aug 2000 16:11:32 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Mon, 7 Aug 2000 16:11:32 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: SSM List Subject: Re: Reserved addresses in the SSM range In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: kinkajou.arc.nasa.gov X-SMTP-MAIL-FROM: lamaster@nren.nasa.gov X-SMAP-Received-From: outside X-SMTP-PEER-INFO: kinkajou.arc.nasa.gov [128.102.132.150] On Mon, 7 Aug 2000, Jeremy Hall wrote: > I am finding it difficult to know why one would wish to reserve addresses. I agree completely. I see no reason to reserve *any* SSM groups. > > First, we have nothing to loose. Not true. We have excess documentation. Look at all the current IANA multicast address assignments that were made, sit there taking up space in the documents, people have to read at various times, and 99% of which are never used. > > Second, we all know that UDP and TCP reserved ports is proven to be > > helpful. And harmful. Look at all the unnecessary port assignments in the IANA documents. 380K worth of port assignments, almost all of which could easily have been assigned dynamically. > > can think of the following services, each given in a different, > > predefined, > > multicast address: IMHO, static address and port assignments should only be used for unavoidable bootstrap mechanisms or where a well-known port is used to support a universal service (e.g. NTP). All other addresses and ports should be dynamically assigned. If this policy were followed, about 99% of these assignments could go away. > > > > 1. Time service. The server's local time and time zone every second. > > Support packet-loss rate detection. > > Support "ping" for multicast. > > I suggest address 232.0.0.1 for this one. OK, I changed my mind. This is one that should be "reserved" so that no one will ever use it. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nren.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@george.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From ssprunk@cisco.com Tue Aug 8 09:11:46 2000 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01401 for ; Tue, 8 Aug 2000 05:49:45 -0400 (EDT) Received: from glock (dallas-nt-56.cisco.com [171.68.37.56]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with SMTP id AAA00094; Tue, 8 Aug 2000 00:52:27 -0700 (PDT) Message-ID: <007201c0010d$9afedb10$382544ab@glock> From: "Stephen Sprunk" To: "Hummel Heinrich" , "Doron Rajwan" Cc: References: Subject: Re: Reserved addresses in the SSM range Date: Tue, 8 Aug 2000 02:52:20 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Thus spake "Hummel Heinrich" > If there is so much trouble with the multicast address space, why is > everyone happy with this awful limitation? What limitation? > Why can't every unicast address S assign as many multicast-IDs (MC- > IDs) by itself as to host as many TV-like webpages as it may create? > Each pair (S,MC-ID) will unambiguously identify the respective delivery > tree! The SSM-WG is a standardization body and can therefore define > what is necessary to go with such a change. > It shouldn't be a big task to define the "destination" in the IP-header : dest. > addr=S, option field =MC-ID, type=SSM. > It wouldn't be a big task either to adjust IGMP. And in the internet: there is > no big difference if you identify the delivery tree by (S, MC-ID) rather than > by (S,G). I think you're in violent agreement with the SSM work already established. The addresses allocated for SSM use will function in the exact same way as the MC-ID you describe above, except with backwards compatibility to the existing IP header format and address space. Allowing a 32-bit address space for SSM groups may have some utility, however this would inherently require modification to the IP header, handling mechanisms, etc. The current SSM allocation of 232/8 from the Class D address space provides 24 bits of group identification, which is arguably far in excess of what any given host can be expected to make use of. The discussion at hand is how many and which addresses should be reserved, as you pointed out is necessary in the first paragraph of section 2.1 in your draft. > For more, see draft-hummel-ssm-00.txt The majority of concerns you raise are addressed by IGMPv3 and PIM-SSM, or other various mechanisms (eg. RSVP). Others, such as admission control, can be easily solved by application mechanisms. Some, such as fewest-links distribution trees are admittedly not handled by PIM's tree-building model, but the complexity involved in creating a system to handle such trees isn't generally worth the negligible or minimal gain over a shortest-path tree. > Heinrich S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, GSE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com From Doron@bandwiz.com Tue Aug 8 09:11:47 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02617 for ; Tue, 8 Aug 2000 07:13:12 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA03409 for ; Tue, 8 Aug 2000 01:16:44 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e788GPY12424 for ; Tue, 8 Aug 2000 01:16:25 -0700 (PDT) Received: from davis.bandwiz.com ( [212.150.220.34]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 08 Aug 2000 01:16:38 -0700 Received: by DAVIS with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Aug 2000 11:14:50 +0200 Message-ID: From: Doron Rajwan To: "'Hugh LaMaster'" Cc: "'ssm-interest@external.cisco.com'" Subject: RE: Reserved addresses in the SSM range Date: Tue, 8 Aug 2000 11:14:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-SMTP-HELO: davis.bandwiz.com X-SMTP-MAIL-FROM: Doron@bandwiz.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [212.150.220.34] Hugh LaMaster might be right that the addition of the reserved addresses mechanism might not worth it. Still, I think that we have (almost) nothing to loose by reserving addresses. We might gain from being able to tell if a multicast source is alive, using the "ping" address I suggested. I do not have a strong opinion on this issue. Doron. -----Original Message----- From: Hugh LaMaster [mailto:lamaster@nren.nasa.gov] Sent: Tuesday, August 08, 2000 1:12 AM To: SSM List Subject: Re: Reserved addresses in the SSM range On Mon, 7 Aug 2000, Jeremy Hall wrote: > I am finding it difficult to know why one would wish to reserve addresses. I agree completely. I see no reason to reserve *any* SSM groups. > > First, we have nothing to loose. Not true. We have excess documentation. Look at all the current IANA multicast address assignments that were made, sit there taking up space in the documents, people have to read at various times, and 99% of which are never used. > > Second, we all know that UDP and TCP reserved ports is proven to be > > helpful. And harmful. Look at all the unnecessary port assignments in the IANA documents. 380K worth of port assignments, almost all of which could easily have been assigned dynamically. > > can think of the following services, each given in a different, > > predefined, > > multicast address: IMHO, static address and port assignments should only be used for unavoidable bootstrap mechanisms or where a well-known port is used to support a universal service (e.g. NTP). All other addresses and ports should be dynamically assigned. If this policy were followed, about 99% of these assignments could go away. > > > > 1. Time service. The server's local time and time zone every second. > > Support packet-loss rate detection. > > Support "ping" for multicast. > > I suggest address 232.0.0.1 for this one. OK, I changed my mind. This is one that should be "reserved" so that no one will ever use it. -- Hugh LaMaster, M/S 233-21, Email: lamaster@nren.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@george.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From supratik@sprintlabs.com Tue Aug 8 15:53:17 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03009 for ; Tue, 8 Aug 2000 15:53:16 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA28838 for ; Tue, 8 Aug 2000 11:40:22 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e78Ie4e03656 for ; Tue, 8 Aug 2000 11:40:04 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 08 Aug 2000 11:40:16 -0700 Received: from sprintlabs.com (10.64.202.57 [10.64.202.57]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id P3BFR4FJ; Tue, 8 Aug 2000 11:39:10 -0700 Sender: supratik@cisco.com Message-ID: <399053CB.3B887216@sprintlabs.com> Date: Tue, 08 Aug 2000 11:39:07 -0700 From: Supratik Bhattacharyya Reply-To: linux-igmpv3@sprintlabs.com X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: IGMPv3 for Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailman.sprintlabs.com X-SMTP-MAIL-FROM: supratik@sprintlabs.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: mx.sprintlabs.com [208.30.174.2] Content-Transfer-Encoding: 7bit Greetings, We would like to announce the initial release of SprintLabs' implementation of the Internet Group Management Protocol(IGMP) version 3 for Linux. The implementation is available as a patch for either 2.4.0 kernels or 2.2.14. SprintLabs is making the implementation available under the terms of the GNU General Public License. For more details or to download the software, please visit : http://www.sprintlabs.com/Department/IP-Interworking/multicast/linux-igmpv3/index.html Regards, Christos Gkantsidis Timothy Roscoe Supratik Bhattacharyya From wfs@djinesys.com Tue Aug 8 16:33:10 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27491 for ; Tue, 8 Aug 2000 16:33:04 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA28584 for ; Tue, 8 Aug 2000 12:18:16 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e78JI4M19718 for ; Tue, 8 Aug 2000 12:18:04 -0700 (PDT) Received: from presque.djinesys.com ( [198.108.6.10]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 08 Aug 2000 12:16:39 -0700 Received: from hyper (dhcp60-03.merit.edu [198.108.60.203]) by presque.djinesys.com (8.9.3/8.9.3) with SMTP id PAA35026 for ; Tue, 8 Aug 2000 15:15:30 -0400 (EDT) (envelope-from wfs@djinesys.com) Message-Id: <3.0.6.32.20000808152131.00c2da60@pop.djinesys.com> X-Sender: wfs@pop.djinesys.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 08 Aug 2000 15:21:31 -0400 To: ssm-interest@external.cisco.com From: William Siadak Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: presque.djinesys.com X-SMTP-MAIL-FROM: wfs@djinesys.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [198.108.6.10] subscribe From Serge.Fdida@lip6.fr Wed Aug 9 13:05:10 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13852 for ; Wed, 9 Aug 2000 13:05:10 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA02844 for ; Wed, 9 Aug 2000 08:53:20 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e79Fr3w29718 for ; Wed, 9 Aug 2000 08:53:03 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by proxy3.cisco.com with SMTP (MailShield v1.5); Wed, 09 Aug 2000 08:53:10 -0700 Received: from rp.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.9.3/jtpda-5.3.2) with ESMTP id RAA16732 for ; Wed, 9 Aug 2000 17:52:48 +0200 Received: from laios (sphinx.lip6.fr [132.227.74.253]) by rp.lip6.fr (8.8.8/jtpda-5.2) with SMTP id RAA28223 for ; Wed, 9 Aug 2000 17:52:47 +0200 (MEST) Message-Id: <200008091552.RAA28223@rp.lip6.fr> Identite-Message: <4.0.2.20000809170248.02c0c710@localhost> X-Sender: sf@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 09 Aug 2000 17:05:18 +0200 To: ssm-interest@external.cisco.com From: Serge Fdida Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SPAM: Yes X-SPAM-REASON: Blank Subject Line X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: isis.lip6.fr X-SMTP-MAIL-FROM: Serge.Fdida@lip6.fr X-SMAP-Received-From: outside X-SMTP-PEER-INFO: isis.lip6.fr [132.227.60.2] subscribe ssm-interest ---------------------------------------------------------------------------- ------------------------------------------- Professeur Serge Fdida tel: +33 (0) 1 44 27 30 58 Universite Pierre et Marie Curie fax: +33 (0) 1 44 27 53 53 Laboratoire LIP6-CNRS mailto: Serge.Fdida@lip6.fr 8, rue du Capitaine Scott web: http://www.lip6.fr/rp/~sf 75015 Paris France From cheaprates1234@earthlink.net Wed Aug 9 23:31:09 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27508; Wed, 9 Aug 2000 23:31:08 -0400 (EDT) From: cheaprates1234@earthlink.net Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA09214; Wed, 9 Aug 2000 19:11:27 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e7A2BDa29851; Wed, 9 Aug 2000 19:11:13 -0700 (PDT) Received: from mx.boston.juno.com (tnt1a-48.newyork.corecomm.net [216.214.109.48]) by proxy1.cisco.com with SMTP (MailShield v1.5); Wed, 09 Aug 2000 19:09:51 -0700 Subject: re:from Lorraine - Philippines $0.23, Japan $.09,china $.31,malaysia$.18 and more,cant bet this Date: Wed, 9 Aug 2000 18:42:53 Message-Id: <863.651912.415432@mx.boston.juno.com> X-SPAM: Yes X-SPAM-REASON: Suspicious TO Address X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: mx.boston.juno.com X-SMTP-MAIL-FROM: cheaprates1234@earthlink.net X-SMAP-Received-From: outside X-SMTP-PEER-INFO: tnt1a-48.newyork.corecomm.net [216.214.109.48] ONLY IF YOU WANT YOUR PHONE BILL CUT IN 1/2 !!!!!!!!!!!!$$$$$$$$$$$$$$ -------CLICK HERE--- http://www.hometown.aol.com/cheaprates123/advertisment/index.html _________________________________________________________________ ___________________________ As I promise ,I WILL PAY CUT YOU PHONE BILL IN 1/2 IF YOU JUST GIVE ME A CHANCE!! AT&T,SPRINT, MCI long distance carriers are getting rich off of You and ME Please take a look at My rates, we are sure I will beat their price. There are no monthly or minimum fees or any other hidden costs. You just pay for the time you are on the phone. If your paying less,I will beat what your paying no matter what!!!!!! For a complete rate chart and sign-up info http://www.hometown.aol.com/cheaprates123/advertisment/index.html Example: Germany .05+ USA .05 =.10 per minute Country Code Per Minute Algeria-----------------213 0.26 American Samoa----------684 0.16 Andorra-----------------336 0.17 Angola------------------244 0.36 Anguilla----------------264 0.34 Antigu------------------268 0.40 Aruba-------------------297 0.26 Bahamas-----------------242 0.16 Bangladesh--------------880 0.64 Barbados----------------246 0.42 Belize------------------501 0.51 Bermuda-----------------441 0.16 Canada------------------ 0.07 Cape Verde-------------238 0.43 Caymans-----------------345 0.26 Dominica----------------767 0.44 Dominican Rep.----------809 0.14 Egypt-------------------20 0.51 France------------------33 0.06 Germany-----------------49 0.05 Grand Turk--------------649 0.44 Grenada-----------------473 0.42 Jordan------------------962 0.51 Lebanon*----------------961 0.40 Papua New Guinea-------675 0.31 Saudi Arabia-----------966 0.59 St Helena---------------290 0.59 St Kitts----------------869 0.35 St Lucia----------------758 0.42 St Pierre---------------508 0.22 St Vincent--------------784 0.42 Trinidad----------------868 0.47 U S Virgin--------------340 0.07 United Arab Emirates---971 0.31 United Kingdom----------44 0.05 USA---------------------1 0.05 Add the country you're calling from to the country you're calling, to get the rate per minute Rates apply 24 hrs/day, 7 days per week NO sign-up fees, NO monthly fees, and NO surcharges You DO NOT have to SWITCH your current provider Ideal for Home and Business use Callback service is available to/from anywhere in the world. Contact ME for more information and complete rate table at: mailto:cheaprates1234@earthlink.net http://hometown.aol.com/cheaprates123 Just Tell me what you want to pay !!!!!! If you would like to be removed from our list, please reply to: mailto:cheaprates1234@earthlink.net with the word "remove" in the subject line. **************************************************** From almeroth@cs.ucsb.edu Thu Aug 10 09:38:44 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21850 for ; Thu, 10 Aug 2000 09:38:43 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA11684 for ; Thu, 10 Aug 2000 05:21:50 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with SMTP id e7ACLVn10654 for ; Thu, 10 Aug 2000 05:21:31 -0700 (PDT) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by proxy2.cisco.com with SMTP (MailShield v1.5); Thu, 10 Aug 2000 05:20:37 -0700 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id FAA19941 for ; Thu, 10 Aug 2000 05:17:40 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id FAA03319 for ssm-interest@external.cisco.com; Thu, 10 Aug 2000 05:17:28 -0700 (PDT) Date: Thu, 10 Aug 2000 05:17:28 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200008101217.FAA03319@jackson.cs.ucsb.edu> To: ssm-interest@external.cisco.com Subject: Re: Reserved addresses in the SSM range X-SMTP-HELO: hercules.cs.ucsb.edu X-SMTP-MAIL-FROM: almeroth@cs.ucsb.edu X-SMAP-Received-From: outside X-SMTP-PEER-INFO: hercules.cs.ucsb.edu [128.111.41.30] Jeremey, which message are you responding to? Your comments seem to be directed at Colin but you included a different message. Part of the side discussion in Oslo was how to deal with the security and spoofing aspects of a unicast-based RTCP. Not easy, but quite possibly doable. As for "features" where one packet can generate many responses, at least at the application layer, that's actually a goal. :-) Hmmm, at the network layer?!? Well, maybe. -Kevin >>From: jhall@UU.NET (Jeremy Hall) >> >>I can say beyond a shadow of a doubt that we will not wish to implement a >>feature where one packet can generate many responses. The Internet as a >>whole is still trying to rid of the problems with DOS attacks and directed >>broadcast. From sopera@earthlink.net Fri Aug 11 16:48:36 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04346 for ; Fri, 11 Aug 2000 16:48:35 -0400 (EDT) From: sopera@earthlink.net Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01451 for ; Fri, 11 Aug 2000 12:41:15 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e7BJewo20109 for ; Fri, 11 Aug 2000 12:40:58 -0700 (PDT) Message-Id: <200008111940.e7BJewo20109@sj-msg-av-1.cisco.com> Received: from opera (dialup-63.210.227.5.Cincinnati1.Level3.net [63.210.227.5]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 11 Aug 2000 12:39:40 -0700 Subject: Best New Trade Show Display by Opera Portables, Inc. adv Date: Fri, 11 Aug 2000 15:31:40 -0400 X-Sender: sopera@earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal X-SPAM: Yes X-SPAM-REASON: Suspicious TO Address X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: opera X-SMTP-MAIL-FROM: sopera@earthlink.net X-SMAP-Received-From: outside X-SMTP-PEER-INFO: dialup-63.210.227.5.Cincinnati1.Level3.net [63.210.227.5] Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://3518913189/ Opera Portables, Inc. All removes honored at http://3518913189/removes.htm From aopera@veriomail.com Fri Aug 25 16:31:20 2000 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29051 for ; Fri, 25 Aug 2000 16:31:20 -0400 (EDT) From: aopera@veriomail.com Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA19346 for ; Fri, 25 Aug 2000 12:24:18 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id e7PJNwi03892 for ; Fri, 25 Aug 2000 12:23:58 -0700 (PDT) Received: from opera (sdn-ar-001ohcincP050.dialsprint.net [168.191.24.34]) by proxy1.cisco.com (8.9.1b+Sun/8.8.5) with SMTP id MAA22742 for ; Fri, 25 Aug 2000 12:23:57 -0700 (PDT) Message-Id: <200008251923.MAA22742@proxy1.cisco.com> Subject: Best New Trade Show Display by Opera Portables, Inc. adv Date: Fri, 25 Aug 2000 15:15:38 -0400 X-Sender: aopera@veriomail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://3629625758/ Opera Portables, Inc. All removes honored at http://3629625758/removes.htm From holbrook@cisco.com Wed Aug 30 16:16:34 2000 Received: from sj-msg-core-crit.cisco.com (sj-msg-core-crit.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08357; Wed, 30 Aug 2000 16:16:33 -0400 (EDT) Received: from holbrook-dsl1.cisco.com (gigabit.cisco.com [10.34.2.22]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23621; Wed, 30 Aug 2000 12:05:44 -0700 (PDT) Received: by holbrook-dsl1.cisco.com (Postfix, from userid 500) id 6B4B4DAC73; Wed, 30 Aug 2000 12:06:39 -0700 (PDT) From: Hugh Holbrook To: ssm-interest@cisco.com Cc: minutes@ietf.org Subject: Minutes from the pittsburgh ssm wg meeting Reply-To: holbrook@cisco.com Message-Id: <20000830190639.6B4B4DAC73@holbrook-dsl1.cisco.com> Date: Wed, 30 Aug 2000 12:06:39 -0700 (PDT) Here are the meeting notes minutes. We are going to put up the web site this week, too. -Hugh and Supratik Meeting Notes from SSM working group meeting scribe: Isidor Kouvelas, edited by Hugh Holbrook Introduction, Charter, Agenda bashing, (Supratik Bhattacharya) ------------------------------------- Two documents as wg drafts: 1) draft-holbrook-ssm-arch-00: Architecture document that describes the SSM service model: This is a standards track RFC. 2) draft-bhattach-ssm-framework-00: Framework document that describes how SSM apps, IGMPv3, PIM-SSM, APIs all fit together to provide source-specific multicast apps. This will be an informational RFC. They will be resubmitted as working group drafts for the next IETF. Additionally, the PIM-SSM specification will be submitted jointly with the PIM-WG. Current working group milestones: summer 00: - Initial presentations of architecture and framework fall 00: - Advance architecture to proposed - Revisions of the framework document - Get IANA to bind 232/8 to architecture document Spring 01: - Framework document ready to go to Informational We have an aggressive schedule! There are a number of related drafts: draft-ietf-pim-sm-v2-new PIM protocol spec. Can serve as a routing protocol that to provide the SSM model. The protocol will, but does not yet, contain a section corresponding to SSM. draft-ietf-idmr-igmp-v3 The IGMPv3 protocol spec. With minor tweaks, will also be used for SSM. draft-holbrook-idmr-igmpv3-ssm-00: Describes tweaks to igmpv3 for SSM. draft-ietf-idmr-msf-api-01: multicast source filtering API. Describes the source filtering socket APIs that allow a host app to take advantage of source-filtering capability (e.g., IGMPv3). draft-mmusic-sdp-srcfilter-00: describes sdp format for describing source-specific multicast. draft-shepherd-ssm232-00: An operational doc, will be taken in mboned because it is operational Agenda: - Architecture draft - Framework draft - IGMPv3 mods for SSM - PIM-SSM - Binding 232/8 to SSM - Automatic tunneling and multicast on demand draft-holbrook-ssm-arch-00.txt (Hugh Holbrook) ---------------------------------------------- Status update on the architecture document. Describes SSM service model. Was previously submitted and presented (in Adelaide) as draft-holbrook-ssm-00.txt. Changes since last revision (in the meeting I said these had already been done; they are planned, but not in the latest draft): 1) MUSTs downgraded to SHOULD - drop data if not (S,G) - ignore (*,G) joins - use random allocation 2) Planning to attempt to move most of Security Considerations to v3 spec, since they are not v3-specific. 3) Split off IGMPv3 SSM section to draft-holbrook-idmr-igmpv4-smm-00.txt Comments -------- Dave Thaler: Draft will go to proposed standard and must have security consideration section. Hugh: Yes, the proposed standard will contain a security section. Tom: Multiple addresses allocated for layered codecs must start allocating at random address. Hugh: Yes, the draft currently addresses this. Remaining issues - Consensus in the room was that the document should be adopted by the working group. - Document refers explicitly to 232/8 IGMP document at least should not do that 232.0.0.0 - 232.0.0.255 is reserved (arbitrary selection) [wg chairs note: The authors have received feedback indicating that it would be better if the document did not address the 232/8 range specifically because a network admin may want to enforce SSM semantics in other parts of the address space. ] Dave Thaler: Rather not have it explicitly specified but rather reference IANA page. Reserving addresses for link local etc does not belong in 232/8. Avoid colliding with 224.0.0.1 at link layer might be a reason to avoid collisions in this range but cant think of anything else. Toerless Eckert: Random allocation section was intended to avoid collisions. Hugh: If no one objects range will be removed from the draft. someone: AH solves some security issues (denial of service attacks). Hugh: Good idea, we will mention in the security considerations draft-bhattach-ssm-framework-00 (Supratik) ------------------------------------------------------- Discussion of SSM framework document. Earlier version of document discussed sprint-specific deployment. Changes: - Cleaned up writing - Rewritten as a general framework (removed spring dependencies) Goal: - Provide overview of SSM - Starting point for deployment Topics covered: - Classic multicast and some problems - SSM and its benefits - Elements in an end-to-end SSM framework: address allocation, channel discovery, application requirement, modifications to IGMPv3, PIM-SM, interoperability (coexistence with classic multicast) Dave Thaler: - Framework should not specifically reference IGMPv3 and PIM-SM and should be generic enough (e.g. usable with IPv6 equivalents). Should there be discussion on security? YES. Should the next version have a discussion on Access Control? For example how to disable SSM at a host? (charging for SSM service) Should this be addressed? SMUG: The traditional method to provide access control to content is cryptography. Supratik: This is more from the point of the ISP who may want to control SSM access from specific receivers. Dave Thaler: This is not an SSM-specific problem. It may be the same problem for classic multicast or unicast and hence should not be part of the SSM framework draft. Jon Crowcroft: Implications for resource utilisation are different for multicast. ISP may want to think about billing taking into consideration the distribution of receivers... Supratik: Access control considerations could be avoided in this document. Brad Cain: These issues exist with any service (unicast etc). Only include section if you can find SSM specific issues that differ. More people agreeing but point out that if no different, then draft should say that the problem is the same as elsewhere. Plans: Issue as informational RFC by spring 2001. draft-holbrook-idmr-igmpv3-ssm-00.txt (Hugh) -------------------------------------------- Was previously appendix to draft-holbrook-ssm-00.txt Contains tweaks to the IGMPv3 protocol for SSM operation. One primary outstanding issue: - If a host transitions to EXCLUDE mode in 232/8 applications will stop receiving traffic. - Several proposed solutions which may impact v3 implementations - Will be presented at IDMR as solutions impact IGMPv3 implementations. (wg chair note: Brief summary of the IDMR discussion: It was decided to remove the language from the igmpv3 spec that allows hosts to transition to EXCLUDE mode when it no longer has enough memory to maintain all INCLUDE mode requests. The v3 spec will be changed to say that subsequent INCLUDE mode requests must return an error. This solves the problem when all apps perform INCLUDE-mode joins in the SSM address range, but there is still a denial-of-service possible if some other app on the same host does an exclude-mode join in the SSM address range. In IDMR, the consensus was that this was good enough to go ahead with IGMPv3 without causing grief to SSM and that we could investigate flexible host configuration mechanisms that would solve the INCLUDE/EXCLUDE problem later.) draft-pim-sm-v2-new-00.txt (Hugh) --------------------------------- Update on new PIM SM spec in relation to SSM. There is not going to be a separate PIM-SSM spec, but rather the SSM specific sections will be pointed out in the pim-sm spec. xItems not needed include: all shared tree (*,G) and (S,G,rpt) processing, bootstrap, RP processing, (*,G) asserts. Action item for working group (Hugh) ----------------------------- Need to officially define the service provided in 232/8 Proposal: - Get IANA to bind 232/8 to draft-holbrook-ssm-arch-00.txt Mark Handley: This is probably not urgent, though. Intellectual Property Issue (Hugh) --------------------------- Apple holds a patents that might possibly cover SSM. We hope Apple will donate the patents to IETF. It is not clear that SSM infringes the patent, but we are letting people know of its existence. So be nice to Apple people :-). Questions from the field ------------------------ Dino: Has anyone looked into the implications with BGMP? Dave: No changes required to BGMP protocol document. Some to SSM docs... Automatic Tunneling and Multicast on Demand (Doron Rajwan) ---------------------------------------------------------- o Automatic tunneling Suggest a simple mechanism using a tunnel so that a host outside an SSM domain can send a UDP packet asking to create a tunnel and receive SSM traffic. Use a mechanism like traceroute to query routers along the path to a source and find the closest one capable of supporting this mechanism. When multiple clients from a non-SSM domain wish to receive traffic, they hit the same border router in the SSM capable domain which has to replicate the session and unicast it to each receiver. Dave Thaler: - You cannot just modify the destination of data packets so you have to encapsulate (especially with IPSEC) - Main issue with arbitrary tunneling is access control. Alternative used in IP6bone is tunnel broker which can be located through some mechanism other than traceroute (not a router). - NGtrans WG has similar issues... Someone noted that the IDMF proposal in MSDP WG is similar. o Multicast on Demand Summary of the presentation: should we extend IGMP in some way to have the source query the router if there are any receivers before attempting to send, and/or have the router notify the host when there *are* receivers. Dave Thaler: This is a good idea but we should not slow down IGMPv3 standardisation so we should attempt to work on this independently. Jon Crowcroft: in favor of this idea.