From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue May 1 17:13:52 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10401 for ; Tue, 1 May 2001 17:13:46 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f41JL7H13606 for ; Tue, 1 May 2001 12:21:09 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f41JMbq16258 for ; Tue, 1 May 2001 12:22:38 -0700 (PDT) Received: from ktic ([211.234.26.101]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f41JMr918111 for ; Tue, 1 May 2001 12:22:53 -0700 (PDT) Received: from 211.234.26.101 (lsbgflxa-as-14-ip-144.ATLANTIC.NET [209.208.97.81]) by ktic (2.5 Build 2630 (Berkeley 8.8.6)/8.8.4) with SMTP id EAA01581; Wed, 02 May 2001 04:00:13 +0900 From: yevonilstock@excite.com To: newsmarkets@sraihb.sra.co.jp Message-ID: <196452154865.GAA55354@sraihb.sra.co.jp> Date: Tue, 01 May 01 04:46:20 EST Subject: OUR NEXT STOCK PICK: HZPR $.35 OUR NEXT STOCK PICK: HZPR $.35 OTCBB: HZPR Price: $ .35 Target Price: $2.50-$3.00 Float: 100k HZPR provides instant analysis and loan decisions on mortgages and consumer loans in all 50 states. The Company intends to provide an Internet portal through which homeowners and potential homeowners can receive a full line of mortgage financing, including first and second mortgages. the Company also intends to offer a full line of home-related products and services, including banking and insurance services, chat rooms, message boards and personalized content. In addition the company intends to offer Home furnishing and appliances, along with support services to real estate agents. We consider HZPR a STRONG BUY! for details go to: http://quote.yahoo/q?s=hzpr.ob&d=v1 DISCLAIMER: newpennies cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed on the featured company are the opinions of newpennies. All information concerning the companies is received directly from the companies profiled and/or outside interviews conducted by newpennies. newpennies PROFILES recommends you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. newpennies assumes all information to be truthful and reliable; however, we cannot and do not warrant or guarantee the accuracy of this information. All statements contained herein are deemed to be factual as of the date of this report and as such are subject to change without notice. newpennies is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such newpennies is not offering investment advice or promoting any investment strategies. newpennies is not offering securities for sale or solicitation of any offer to buy or sell securities. An offer to buy or sell can be made only with accompanying disclosure documents and only in the states and provinces for which they are approved. Any reference in the newsletter to past performance(s) of companies previously profiled in the newsletter are specially selected to be referenced based on the favorable performance of said companies and the companies referenced may not be representative of all past profiles as not all past profiles have performed as well. Please remember that past performance does not predict future results which is why it's called past performance”. On occasion newpennies receives compensation from a third party in relation to the company being profiled in its newsletter sent to our subscribers. In such a case, newpennies directly mentions this in its newsletter sent to our subscribers along with the exact form and amount of compensation. newpennies holds forty thousand shares of this company profile. newpennies, its affiliates, associates, relatives and anyone associated with newpennies in any manner reserves the right to either buy or sell shares in the profiled company's stock, either before the date of the profile, during the date of the profile or at any time after the date of the profile. We have an inherent conflict of interest by sending the newsletter at the same time we may own stock in the same company or even have been paid compensation at the time of the profile/promotion. We reserve the right to sell shares at anytime, even during the time period in which we are profiling a company. newpennies may profile companies trading in fast moving, volatile markets, and any reader of this newsletter should observe the trading behavior of any profiled company prior to investing. unsubscribe at yevoni@excite.com From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Wed May 2 10:37:04 2001 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 SMTP id KAA12891 for ; Wed, 2 May 2001 10:37:03 -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.11.3/8.9.1) with ESMTP id f42D0KK12247 for ; Wed, 2 May 2001 06:00:20 -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 ESMTP id f42CxwJ25219 for ; Wed, 2 May 2001 05:59:58 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f42Cxmj04217 for ; Wed, 2 May 2001 05:59:49 -0700 (PDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA02325 for ; Wed, 2 May 2001 14:46:19 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA22781 for ; Wed, 2 May 2001 14:46:19 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 14:46:18 +0200 Message-ID: From: Hummel Heinrich To: ssm-interest@external.cisco.com Subject: 232-Addresses not only for current SSM model Date: Wed, 2 May 2001 14:46:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Hello, The 232/24-address space is reserved for source-specific multicast. An address G from this address space only uniquly identifies a multicast channel together with a particular source's unicast address S. Application: multicast model according to the SSM WG. 1) This is really great for many very good reasons. 2) A particular source of unicast address S does not head 2**24 SSM-multicast channels. Therefore, a subrange would do as well. 3) I can imagine further multicast models in the future, which would be happy to use a 232/24-address, but which would use different protocol procedures, protocol messages, protocol TLVs. Just one example: A completely different mulitcast delivery channel could be a ring. As a matter of fact, a ring needs only about 20 % more hops than a Dijkstra-tree. The information can be sent out in two directions so that in case of a link failure, each receiver node would get the information at least once. Furthermore, in case of optical networks, the power of light is preserved in a better way. Of course, a ring could be extended to a "tree of rings" or a "ring of rings". I am quite sure that other folks have further ideas. People do not stop thinking about multicast just because the SSM work is done. For all such reasons: Isn't it appropriate to reserve a subrange of the 232/24- address space for SSM? Regards, Heinrich Hummel Siemens AG From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Wed May 2 12:11:29 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15917 for ; Wed, 2 May 2001 12:11:28 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f42EjaH24709 for ; Wed, 2 May 2001 07:45:40 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f42EkxU18429 for ; Wed, 2 May 2001 07:46:59 -0700 (PDT) Received: from exchil01.BANDWIZ ([212.150.220.35]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f42EkeB17180 for ; Wed, 2 May 2001 07:46:40 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: 232-Addresses not only for current SSM model Date: Wed, 2 May 2001 17:50:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: 232-Addresses not only for current SSM model Thread-Index: AcDTHli98zGXh5+UT3KLGuj+ufGuswAACutA From: "Doron Rajwan" To: "Hummel Heinrich" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15917 I guess you mean 232/8 (the range 232/24 is 232.0.0.xxx). I tend to agree that 16M addresses seems a lot. However, keep in mind that: 1. Reverse-IGMP, or On-Demand Multicast, will cause a server to use a lot of addresses, about one address per URL per rate. This can be a lot. 2. In order not to have too many Ethernet MAC layer collisions, we should have some bits in the address field, selected randomly by the server. Doron. ____________________________________________________ Doron Rajwan, Chief Technology Officer, Bandwiz Inc. 11 Bareket St. Herzlia 46511 Israel mailto:doron@bandwiz.com Office: +972-(9)-9515116, ext. 122 Fax: +972-(9)-9515117 Cell: +972-(56)-507799 Home: +972-(3)-6736614 -----Original Message----- From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] Sent: Wednesday, May 02, 2001 2:46 PM To: ssm-interest@external.cisco.com Subject: 232-Addresses not only for current SSM model Hello, The 232/24-address space is reserved for source-specific multicast. An address G from this address space only uniquly identifies a multicast channel together with a particular source's unicast address S. Application: multicast model according to the SSM WG. 1) This is really great for many very good reasons. 2) A particular source of unicast address S does not head 2**24 SSM-multicast channels. Therefore, a subrange would do as well. 3) I can imagine further multicast models in the future, which would be happy to use a 232/24-address, but which would use different protocol procedures, protocol messages, protocol TLVs. Just one example: A completely different mulitcast delivery channel could be a ring. As a matter of fact, a ring needs only about 20 % more hops than a Dijkstra-tree. The information can be sent out in two directions so that in case of a link failure, each receiver node would get the information at least once. Furthermore, in case of optical networks, the power of light is preserved in a better way. Of course, a ring could be extended to a "tree of rings" or a "ring of rings". I am quite sure that other folks have further ideas. People do not stop thinking about multicast just because the SSM work is done. For all such reasons: Isn't it appropriate to reserve a subrange of the 232/24- address space for SSM? Regards, Heinrich Hummel Siemens AG From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed May 2 13:04:51 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17393 for ; Wed, 2 May 2001 13:04:50 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f42FbId09067 for ; Wed, 2 May 2001 08:37:18 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f42FbCU04936 for ; Wed, 2 May 2001 08:37:12 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f42Fb8j01344 for ; Wed, 2 May 2001 08:37:09 -0700 (PDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA29586; Wed, 2 May 2001 17:23:39 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA29263; Wed, 2 May 2001 17:23:38 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:23:37 +0200 Message-ID: From: Hummel Heinrich To: "'Doron Rajwan'" , Hummel Heinrich Cc: ssm-interest@external.cisco.com Subject: AW: 232-Addresses not only for current SSM model Date: Wed, 2 May 2001 17:23:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Doron answered: > I guess you mean 232/8 (the range 232/24 is 232.0.0.xxx). Thanks. you are right. > I tend to agree that 16M addresses seems a lot. However, keep in mind > that: > > 1. Reverse-IGMP, or On-Demand Multicast, will cause a server to use a > lot of addresses, about one address per URL per rate. This can be a lot. Sure. But 1 million or 500 000 is still sufficient, isn't it ? > 2. In order not to have too many Ethernet MAC layer collisions, we > should have some bits in the address field, selected randomly by the > server. My point is another one or maybe I should ask this question: When a node in the middle of the network receives a particular "multicast" message, how can he recognize which evtly. present (S,G) -multicast channel is meant in case there are multiples of (S,G)-models, and not just SSM ? Heinrich > Subject: 232-Addresses not only for current SSM model > > > Hello, > > The 232/24-address space is reserved for source-specific > multicast. An address G from this address space only uniquly identifies > a multicast channel > together with a particular source's unicast address S. > > Application: multicast model according to the SSM WG. > > 1) > This is really great for many very good reasons. > > 2) > A particular source of unicast address S does not head 2**24 > SSM-multicast channels. Therefore, a subrange would do as well. > > 3) > I can imagine further multicast models in the future, which > would be happy to use a 232/24-address, but which > would use different protocol procedures, protocol messages, > protocol TLVs. > Just one example: > A completely different mulitcast delivery channel could be a > ring. As a matter of fact, a ring needs only about 20 % more hops than a > Dijkstra-tree. > The information can be sent out in two directions so that in > case of a link failure, each receiver node would get the information at > least once. > Furthermore, in case of optical networks, the power of light is > preserved in a better way. > Of course, a ring could be extended to a "tree of rings" or a > "ring of rings". > > I am quite sure that other folks have further ideas. People do > not stop thinking about multicast just because the SSM work is done. > > For all such reasons: Isn't it appropriate to reserve a > subrange of the 232/24- address space for SSM? > > Regards, > Heinrich Hummel > Siemens AG From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Wed May 2 14:43:31 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19772 for ; Wed, 2 May 2001 14:43:30 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f42HBKH09612 for ; Wed, 2 May 2001 10:11:21 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f42HChb04796 for ; Wed, 2 May 2001 10:12:43 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f42HCev01426 for ; Wed, 2 May 2001 10:12:40 -0700 (PDT) Received: from nsamail01.us.newbridge.com (nsamail01.us.newbridge.com [138.120.244.77]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA01759 for ; Wed, 2 May 2001 11:57:36 -0500 (CDT) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA12D8; Wed, 2 May 2001 12:56:18 -0400 Message-ID: <3AF03D51.F86AB02F@alcatel.com> Date: Wed, 02 May 2001 13:01:05 -0400 From: "Nagesh Chintada" Organization: Carrier Internetworking Division, Alcatel X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Doron Rajwan CC: Hummel Heinrich , ssm-interest@external.cisco.com Subject: Re: 232-Addresses not only for current SSM model References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Doron, Can you point out the draft(s) that discuss the Reverse-IGMP? Thanks, Nagesh Doron Rajwan wrote: > I guess you mean 232/8 (the range 232/24 is 232.0.0.xxx). > > I tend to agree that 16M addresses seems a lot. However, keep in mind > that: > > 1. Reverse-IGMP, or On-Demand Multicast, will cause a server to use a > lot of addresses, about one address per URL per rate. This can be a lot. > > 2. In order not to have too many Ethernet MAC layer collisions, we > should have some bits in the address field, selected randomly by the > server. > > Doron. > > ____________________________________________________ > Doron Rajwan, Chief Technology Officer, Bandwiz Inc. > 11 Bareket St. Herzlia 46511 Israel > mailto:doron@bandwiz.com > Office: +972-(9)-9515116, ext. 122 > Fax: +972-(9)-9515117 > Cell: +972-(56)-507799 > Home: +972-(3)-6736614 > > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Wednesday, May 02, 2001 2:46 PM > To: ssm-interest@external.cisco.com > Subject: 232-Addresses not only for current SSM model > > Hello, > > The 232/24-address space is reserved for source-specific > multicast. An address G from this address space only uniquly identifies > a multicast channel > together with a particular source's unicast address S. > > Application: multicast model according to the SSM WG. > > 1) > This is really great for many very good reasons. > > 2) > A particular source of unicast address S does not head 2**24 > SSM-multicast channels. Therefore, a subrange would do as well. > > 3) > I can imagine further multicast models in the future, which > would be happy to use a 232/24-address, but which > would use different protocol procedures, protocol messages, > protocol TLVs. > Just one example: > A completely different mulitcast delivery channel could be a > ring. As a matter of fact, a ring needs only about 20 % more hops than a > Dijkstra-tree. > The information can be sent out in two directions so that in > case of a link failure, each receiver node would get the information at > least once. > Furthermore, in case of optical networks, the power of light is > preserved in a better way. > Of course, a ring could be extended to a "tree of rings" or a > "ring of rings". > > I am quite sure that other folks have further ideas. People do > not stop thinking about multicast just because the SSM work is done. > > For all such reasons: Isn't it appropriate to reserve a > subrange of the 232/24- address space for SSM? > > Regards, > Heinrich Hummel > Siemens AG From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed May 2 16:07:49 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21906 for ; Wed, 2 May 2001 16:07:49 -0400 (EDT) Received: from holbrook-laptop.cisco.com (dhcp-171-69-41-13.cisco.com [171.69.41.13]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f42IhMd12569; Wed, 2 May 2001 11:43:22 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 79F84C3A71; Wed, 2 May 2001 11:43:29 -0700 (PDT) From: Hugh Holbrook To: "Nagesh Chintada" Cc: Doron Rajwan , Hummel Heinrich , ssm-interest@external.cisco.com In-reply-to: <3AF03D51.F86AB02F@alcatel.com> Subject: Re: Re: 232-Addresses not only for current SSM model Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010502184329.79F84C3A71@holbrook-laptop.cisco.com> Date: Wed, 2 May 2001 11:43:29 -0700 (PDT) > Doron, > Can you point out the draft(s) that discuss the Reverse-IGMP? > > Thanks, > Nagesh Here you go. -Hugh ---------------------------------------------------------------- Message-Id: <200102281158.GAA02972@ietf.org> To: IETF-Announce: ; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-msnip-00.txt,.ps Date: Wed, 28 Feb 2001 06:58:48 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Multicast Source Notification of Interest Protocol (MSNIP) Author(s) : B. Fenner ET AL. Filename : draft-ietf-idmr-msnip-00.txt,.ps Pages : 18 Date : 27-Feb-01 This document discusses the Multicast Source Interest Notification Protocol (MSNIP). MSNIP is an extension to IGMPv3 [1] that provides membership notification services for sources of multicast traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-msnip-00.txt 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-idmr-msnip-00.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-idmr-msnip-00.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. From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Wed May 2 16:41:38 2001 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22813 for ; Wed, 2 May 2001 16:41:38 -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.11.3/8.9.1) with ESMTP id f42JLCj28216 for ; Wed, 2 May 2001 12:21:12 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f42JLIp17469 for ; Wed, 2 May 2001 12:21:19 -0700 (PDT) Received: from exchil01.BANDWIZ ([212.150.220.35]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f42JLQY06585 for ; Wed, 2 May 2001 12:21:29 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: AW: 232-Addresses not only for current SSM model Date: Wed, 2 May 2001 22:24:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: AW: 232-Addresses not only for current SSM model Thread-Index: AcDTREmzgpbbSC/7Qb2WTuRCM6V4swAAEwQQ From: "Doron Rajwan" To: "Hummel Heinrich" , "Hugh Holbrook (E-mail)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA22813 I think that Heinrich means that 232/8 is reserved for SSM service model in general, but not for PIM-SSM specific protocol. Is this the case? Does it matter? thanks, Doron. ____________________________________________________ Doron Rajwan, Chief Technology Officer, Bandwiz Inc. 11 Bareket St. Herzlia 46511 Israel mailto:doron@bandwiz.com Office: +972-(9)-9515116, ext. 122 Fax: +972-(9)-9515117 Cell: +972-(56)-507799 Home: +972-(3)-6736614 -----Original Message----- From: Marshall Eubanks [mailto:tme@21rst-century.com] Sent: Wednesday, May 02, 2001 9:08 PM To: Hummel Heinrich Cc: Doron Rajwan; ssm-interest@external.cisco.com Subject: Re: AW: 232-Addresses not only for current SSM model Hummel Heinrich wrote: > Doron answered: > > > I guess you mean 232/8 (the range 232/24 is 232.0.0.xxx). > Thanks. you are right. > > I tend to agree that 16M addresses seems a lot. However, keep in mind > > that: > > > > 1. Reverse-IGMP, or On-Demand Multicast, will cause a server to use a > > lot of addresses, about one address per URL per rate. This can be a lot. > Sure. But 1 million or 500 000 is still sufficient, isn't it ? > > > 2. In order not to have too many Ethernet MAC layer collisions, we > > should have some bits in the address field, selected randomly by the > > server. > > My point is another one or maybe I should ask this question: > When a node in the middle of the network receives a particular "multicast" message, how can he > recognize which evtly. present (S,G) -multicast channel is meant in case there are multiples of (S,G)-models, and not just SSM ? > > Heinrich > Dear Heinrich; This should not happen. (Another way of putting it is that there should not need to be any protocol dicovery.) 232/8 is reserved for SSM. The ONLY other address ranges that should be used for SSM are the administratatively scoped ones, where it is up to the domain administrator to keep SSM and ASM traffic separated. See draft-albanna-iana-ipv4-mcast-guidelines-01.txt and RFC 2365. -- Regards Marshall Eubanks > > > > Subject: 232-Addresses not only for current SSM model > > > > > > Hello, > > > > The 232/24-address space is reserved for source-specific > > multicast. An address G from this address space only uniquly identifies > > a multicast channel > > together with a particular source's unicast address S. > > > > Application: multicast model according to the SSM WG. > > > > 1) > > This is really great for many very good reasons. > > > > 2) > > A particular source of unicast address S does not head 2**24 > > SSM-multicast channels. Therefore, a subrange would do as well. > > > > 3) > > I can imagine further multicast models in the future, which > > would be happy to use a 232/24-address, but which > > would use different protocol procedures, protocol messages, > > protocol TLVs. > > Just one example: > > A completely different mulitcast delivery channel could be a > > ring. As a matter of fact, a ring needs only about 20 % more hops than a > > Dijkstra-tree. > > The information can be sent out in two directions so that in > > case of a link failure, each receiver node would get the information at > > least once. > > Furthermore, in case of optical networks, the power of light is > > preserved in a better way. > > Of course, a ring could be extended to a "tree of rings" or a > > "ring of rings". > > > > I am quite sure that other folks have further ideas. People do > > not stop thinking about multicast just because the SSM work is done. > > > > For all such reasons: Isn't it appropriate to reserve a > > subrange of the 232/24- address space for SSM? > > > > Regards, > > Heinrich Hummel > > Siemens AG 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@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Wed May 2 16:58:38 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23282 for ; Wed, 2 May 2001 16:58:37 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f42Jcrd20230 for ; Wed, 2 May 2001 12:38: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 ESMTP id f42Jcs404313 for ; Wed, 2 May 2001 12:38:54 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f42JYxv04303 for ; Wed, 2 May 2001 12:35:00 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 883305; Wed, 02 May 2001 15:07:31 -0400 Message-ID: <3AF05B0E.4AFC2FF1@21rst-century.com> Date: Wed, 02 May 2001 15:07:56 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Hummel Heinrich CC: "'Doron Rajwan'" , ssm-interest@external.cisco.com Subject: Re: AW: 232-Addresses not only for current SSM model References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hummel Heinrich wrote: > Doron answered: > > > I guess you mean 232/8 (the range 232/24 is 232.0.0.xxx). > Thanks. you are right. > > I tend to agree that 16M addresses seems a lot. However, keep in mind > > that: > > > > 1. Reverse-IGMP, or On-Demand Multicast, will cause a server to use a > > lot of addresses, about one address per URL per rate. This can be a lot. > Sure. But 1 million or 500 000 is still sufficient, isn't it ? > > > 2. In order not to have too many Ethernet MAC layer collisions, we > > should have some bits in the address field, selected randomly by the > > server. > > My point is another one or maybe I should ask this question: > When a node in the middle of the network receives a particular "multicast" message, how can he > recognize which evtly. present (S,G) -multicast channel is meant in case there are multiples of (S,G)-models, and not just SSM ? > > Heinrich > Dear Heinrich; This should not happen. (Another way of putting it is that there should not need to be any protocol dicovery.) 232/8 is reserved for SSM. The ONLY other address ranges that should be used for SSM are the administratatively scoped ones, where it is up to the domain administrator to keep SSM and ASM traffic separated. See draft-albanna-iana-ipv4-mcast-guidelines-01.txt and RFC 2365. -- Regards Marshall Eubanks > > > > Subject: 232-Addresses not only for current SSM model > > > > > > Hello, > > > > The 232/24-address space is reserved for source-specific > > multicast. An address G from this address space only uniquly identifies > > a multicast channel > > together with a particular source's unicast address S. > > > > Application: multicast model according to the SSM WG. > > > > 1) > > This is really great for many very good reasons. > > > > 2) > > A particular source of unicast address S does not head 2**24 > > SSM-multicast channels. Therefore, a subrange would do as well. > > > > 3) > > I can imagine further multicast models in the future, which > > would be happy to use a 232/24-address, but which > > would use different protocol procedures, protocol messages, > > protocol TLVs. > > Just one example: > > A completely different mulitcast delivery channel could be a > > ring. As a matter of fact, a ring needs only about 20 % more hops than a > > Dijkstra-tree. > > The information can be sent out in two directions so that in > > case of a link failure, each receiver node would get the information at > > least once. > > Furthermore, in case of optical networks, the power of light is > > preserved in a better way. > > Of course, a ring could be extended to a "tree of rings" or a > > "ring of rings". > > > > I am quite sure that other folks have further ideas. People do > > not stop thinking about multicast just because the SSM work is done. > > > > For all such reasons: Isn't it appropriate to reserve a > > subrange of the 232/24- address space for SSM? > > > > Regards, > > Heinrich Hummel > > Siemens AG 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@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Wed May 2 17:44:12 2001 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24420 for ; Wed, 2 May 2001 17:44:11 -0400 (EDT) Received: from cactus.cisco.com (cactus.cisco.com [161.44.19.100]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42KPo729779 for ; Wed, 2 May 2001 16:25:51 -0400 (EDT) Received: from glock (dhcp-161-44-19-65.cisco.com [161.44.19.65]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA14801; Wed, 2 May 2001 13:18:49 -0700 (PDT) Message-ID: <011001c0d345$198a92d0$41132ca1@glock> From: "Stephen Sprunk" To: "Hummel Heinrich" , "'Doron Rajwan'" Cc: References: Subject: Re: 232-Addresses not only for current SSM model Date: Wed, 2 May 2001 15:18:47 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Thus spake "Hummel Heinrich" > My point is another one or maybe I should ask this question: > When a node in the middle of the network receives a particular > "multicast" message, how can he recognize which evtly. present > (S,G) -multicast channel is meant in case there are multiples of > (S,G)-models, and not just SSM ? A node in the middle of the network forwards a packet based on the (S,G) state already stored in that node; this behavior is independent of how exactly that (S,G) state is created (eg. DVMRP, MOSPF, PIM). Using 232/8 addresses declares that the sender(s) and recipient(s) want the SSM delivery model (versus the default ISM). It does not mandate the use of PIM; PIM just happens to be the only protocol (AFAIK) that offers SSM delivery so far. I can't tell from your first message if you're looking to develop a different delivery model than either ISM or SSM, or if you're looking to develop a different protocol to provide ISM and/or SSM delivery. > Heinrich S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, ANS :|||: :|||: RCDN2 in Richardson, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Wed May 2 18:00:03 2001 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24866 for ; Wed, 2 May 2001 18:00:02 -0400 (EDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42Kjk701150 for ; Wed, 2 May 2001 16:45:47 -0400 (EDT) Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA18560; Wed, 2 May 2001 13:38:48 -0700 (PDT) Date: Wed, 2 May 2001 13:38:48 -0700 From: Toerless Eckert To: Doron Rajwan Cc: Hummel Heinrich , "Hugh Holbrook (E-mail)" , ssm-interest@external.cisco.com Subject: Re: AW: 232-Addresses not only for current SSM model Message-ID: <20010502133848.S26921@cypher.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from doron@BANDWIZ.COM on Wed, May 02, 2001 at 10:24:17PM +0200 On Wed, May 02, 2001 at 10:24:17PM +0200, Doron Rajwan wrote: > > I think that Heinrich means that 232/8 is reserved for SSM service model > in general, but not for PIM-SSM specific protocol. > > Is this the case? Does it matter? Yes, no, not practially, maybe theoretically. The SSM architecture mandates that SSM is based on a receiver driven channel subscription mechanism, which translates into an explicit join model within the network. What protocol you want to use within some parts of the path is really insignificant. For example, you could imagine that some path segments may use IGMP (proxying/mapping from/to PIM or other protocols) for whatever obscure reasons they might choose to do that. The only issue really is that if you start out with some other protocol and can not map from/to PIM path segments, you'll start out having two islands, which would mean one had to make the decision which of the two islands would have to be called the real global 232/8 address space and which would just be a private reuse of global addresses outside of the scope of the IETF/IANA. So better avoid that situation if the goal here is to establish a framework for easy scalable global reachability of ip multicast delievered content. Cheers Toerless From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu May 3 10:05:49 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24521 for ; Thu, 3 May 2001 10:05:49 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f43Cqld01454 for ; Thu, 3 May 2001 05:52:47 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f43CqfX10480 for ; Thu, 3 May 2001 05:52:41 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f43Cqbb02330 for ; Thu, 3 May 2001 05:52:38 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id OAA00574 for ; Thu, 3 May 2001 14:37:38 +0200 (MET DST) Message-ID: <3AF15112.2C698AE7@irisa.fr> Date: Thu, 03 May 2001 14:37:38 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: SSM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, In the draft : A Framework for Source-Specific Multicast Deployment 3. Limitations of Current Service Model There exist several service model limitations associated with ASM: A) Handling Well Known Sources via Shortest Path Forwarding In cases where the address of the source is well known in advance of the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then shared tree mechanisms and MSDP only represent unnecessary interim mechanisms, contributing to join latency and operational overhead. So in which cases address of the source is well known in advance of the receiver joining the group?? can u give me a simple example ?? just I want to understand it well. thanx From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu May 3 12:02:45 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28380 for ; Thu, 3 May 2001 12:02:44 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f43Ecfd21689 for ; Thu, 3 May 2001 07:38:41 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f43EchM13153 for ; Thu, 3 May 2001 07:38:43 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f43EcwD14815 for ; Thu, 3 May 2001 07:38:58 -0700 (PDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA03125; Thu, 3 May 2001 16:24:52 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA24556; Thu, 3 May 2001 16:24:51 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 16:24:50 +0200 Message-ID: From: Hummel Heinrich To: "'Stephen Sprunk'" , "'Doron Rajwan'" Cc: ssm-interest@external.cisco.com Subject: AW: 232-Addresses not only for current SSM model Date: Thu, 3 May 2001 16:24:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain About my motivations regarding this issue: In the past (see Pittsburgh-draft draft-hummel-ssm-00.txt) I expressed two major concerns: #1: to have a global (i.e. not source specific) multicast address G #2: to build/extend the delivery tree reversely. The 232-Address overcomes concern #1 perfectly. But can it be used also by future multicast models which do not use the current JOIN message? In case this is assured: great. In case this is assured even without the need for subranges of the 232-address space: even better. In Minneapolis I learnt that there will be no further SSM session. While this is ok with regard to the SSM model, it won't be the end of working on multicast. At the same time, I think, no one will ever come up with a multicast model which uses a non-source specific multicast address G. Do you agree? Am I looking to develop a different protocol ? Well, I would like to, though I must admit I am neither THE expert on classical multicast nor on the new technologies which should be integrated /utilized like Optical networking, path protection, OAM. IMHO: Path protection makes a lot of sense if any path failure affected thousands/millions of receivers (--> big multicast applications such as internet-TV). Building a bi-directional ring (or tree of rings) may allow that each designated receiver node gets the data twice via two different pathes. In case any link breaks, it will receive the data at least once. Some costs are involved: double bandwidth, some more links I did some simulations: in a network of 300 nodes and 550 links I computed the delivery channel from 1 root node to 99 leaf nodes. a) a Dijkstra-Shortest path tree took 204 links, b) a ring took 213 links, c) a minimal-sized tree took 160 links. These figures show: The ring was not too bad compared with the Dijkstra-Shortest path tree (which is state of the art in all existing multicast models). The minimal-sized tree is pretty impressive. Different potential concepts: The delivery tree shall be a a) minimal tree b) ring c) ring with attached trees (its a ring of RPs :-) ) d) tree of rings Enough work for the next ten years. Regards, Heinrich > Thus spake "Hummel Heinrich" > > My point is another one or maybe I should ask this question: > > When a node in the middle of the network receives a particular > > "multicast" message, how can he recognize which evtly. present > > (S,G) -multicast channel is meant in case there are multiples of > > (S,G)-models, and not just SSM ? > > A node in the middle of the network forwards a packet based on the (S,G) > state already stored in that node; this behavior is independent of how > exactly that (S,G) state is created (eg. DVMRP, MOSPF, PIM). > > Using 232/8 addresses declares that the sender(s) and recipient(s) want > the SSM delivery model (versus the default ISM). It does not mandate > the use of PIM; PIM just happens to be the only protocol (AFAIK) that > offers SSM delivery so far. > > I can't tell from your first message if you're looking to develop a > different delivery model than either ISM or SSM, or if you're looking to > develop a different protocol to provide ISM and/or SSM delivery. > > > | | Stephen Sprunk, K5SSS, CCIE #3723 > :|: :|: Network Design Consultant, ANS > :|||: :|||: RCDN2 in Richardson, TX > .:|||||||:..:|||||||:. Email: ssprunk@cisco.com > From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu May 3 12:54:34 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00029 for ; Thu, 3 May 2001 12:54:33 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f43FU2H09330 for ; Thu, 3 May 2001 08:30:16 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f43FVPc21874 for ; Thu, 3 May 2001 08:31:26 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f43FVLb29055 for ; Thu, 3 May 2001 08:31:22 -0700 (PDT) Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id RAA17256 for ; Thu, 3 May 2001 17:16:21 +0200 (MET DST) Message-ID: <3AF17646.FF914A0F@irisa.fr> Date: Thu, 03 May 2001 17:16:22 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: ssm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, How a reciever consider itself a member in a group G.?? and if a reciever after choosing from a web page a (S, G) channel, it can recieve data through the channel. that mean that the reciever should choose from the (S, G) channels belonging to the same group. is there anything wrong in that ?? Thanx From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu May 3 13:04:17 2001 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 SMTP id NAA00324 for ; Thu, 3 May 2001 13:04:16 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f43FfPK05467; Thu, 3 May 2001 08:41:25 -0700 (PDT) Received: from cisco.com (dhcp-171-69-127-181.cisco.com [171.69.127.181]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AJX06164 (AUTH jmeylor); Thu, 3 May 2001 08:40:54 -0700 (PDT) Message-ID: <3AF17C34.86273DB8@cisco.com> Date: Thu, 03 May 2001 08:41:40 -0700 From: John Meylor X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: SSM References: <3AF15112.2C698AE7@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > > Hello, > In the draft : > > A Framework for Source-Specific Multicast Deployment > > 3. Limitations of Current Service Model > There exist several service model limitations associated with ASM: > A) Handling Well Known Sources via Shortest Path Forwarding > In cases where the address of the source is well known in advance > > of the receiver joining the group, and when the shortest > forwarding path is the preferred forwarding mode, then shared tree > > mechanisms and MSDP only represent unnecessary interim mechanisms, > > contributing to join latency and operational overhead. > > So in which cases address of the source is well known in advance of the > receiver joining the group?? > can u give me a simple example ?? > just I want to understand it well. streaming content available via web. The server may be known and static for years. application can access that information (eg via file available via web) and initiate process to request the information from that source,group directly and explicity. previously with ASM, even if the source was well-known and could be made available on web page, IGMPv2 had no mechanism to convey that exclusive source interest to the PIM forwarding service and the PIM service had no way to ensure delivery was limited to the source(s) explicity requested. John From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri May 4 08:18:22 2001 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10330 for ; Fri, 4 May 2001 08:18:22 -0400 (EDT) Received: from cactus.cisco.com (cactus.cisco.com [161.44.19.100]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f43Gm3j24702 for ; Thu, 3 May 2001 09:48:03 -0700 (PDT) Received: from glock (dhcp-161-44-19-65.cisco.com [161.44.19.65]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with SMTP id JAA26796; Thu, 3 May 2001 09:40:06 -0700 (PDT) Message-ID: <000d01c0d3ef$b5b69460$41132ca1@glock> From: "Stephen Sprunk" To: "Hummel Heinrich" , "'Doron Rajwan'" Cc: References: Subject: Re: 232-Addresses not only for current SSM model Date: Thu, 3 May 2001 11:39:58 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Thus spake "Hummel Heinrich" > About my motivations regarding this issue: > In the past (see Pittsburgh-draft draft-hummel-ssm-00.txt) I > expressed two major concerns: Reading your draft (now expired) shows that sections 1 and 2 specify the SSM delivery model and IGMPv3. Section 3 rehashes the debate between MOSPF/DVMRP and PIM. > #1: to have a global (i.e. not source specific) multicast address G > #2: to build/extend the delivery tree reversely. > The 232-Address overcomes concern #1 perfectly. But can it be used > also by future multicast models which do not use the current JOIN > message? In case this is assured: great. In case this is assured > even without the need for subranges of the 232-address space: > even better. The SSM delivery model specified by using 232/8 addresses does NOT require PIM or any other specific mrouting protocol, as you imply it does above. If you wish to develop a ring-based or minimal tree mrouting protocol that provides the SSM delivery model, that is certainly possible. > In Minneapolis I learnt that there will be no further SSM session. > While this is ok with regard to the SSM model, it won't be the end of > working on multicast. At the same time, I think, no one will ever come > up with a multicast model which uses a non-source specific > multicast address G. Do you agree? The ASM delivery model is not source-specific. > Am I looking to develop a different protocol ? > Well, I would like to, though I must admit I am neither THE expert on > classical multicast nor on the new technologies which should be > integrated /utilized like Optical networking, path protection, OAM. The problem with trying to optimize for these specific technologies is that layer 3 can't see them. > IMHO: Path protection makes a lot of sense if any path failure > affected thousands/millions of receivers (--> big multicast > applications such as internet-TV). Unicast path protection has the exact same issue; any given link failing in the Internet may affect millions of users. > Building a bi-directional ring (or tree of rings) may allow that each > designated receiver node gets the data twice via two different pathes. > In case any link breaks, it will receive the data at least once. > Some costs are involved: double bandwidth, some more links Any such technology can be implemented below layer 3 if desired to prevent a link from failing in the first place (from layer 3's perspective). Carriers have shown a strong adversity to this approach in the past, so making it mandatory at a higher layer is unlikely to be popular. > These figures show: The ring was not too bad compared with the > Dijkstra-Shortest path tree (which is state of the art in all existing > multicast models). > The minimal-sized tree is pretty impressive. The utilization is impressive yes, but the protocol complexity required to achieve it is unwieldy, not to mention the additional latency introduced by minimal trees over shortest-path trees. > Regards, > Heinrich S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, ANS :|||: :|||: RCDN2 in Richardson, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri May 4 22:35:47 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25746 for ; Fri, 4 May 2001 22:35:41 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f451fRf00522 for ; Fri, 4 May 2001 18:41:27 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f451gx215923 for ; Fri, 4 May 2001 18:42:59 -0700 (PDT) Received: from postal.jnpr.net (natint.juniper.net [207.17.136.129]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f451hG423613 for ; Fri, 4 May 2001 18:43:16 -0700 (PDT) Received: by postal.jnpr.net with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 18:41:14 -0700 Message-ID: From: Brian Edwards To: "'Ali Boudani'" , ssm-interest@external.cisco.com Subject: RE: ssm Date: Fri, 4 May 2001 18:41:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Ali, A host can subscribe to multiple SSM channels that share the same group-part of the channel address. It does so independently; i.e. there is no more relation between (S1,G1) and (S2,G1), than there is between (S1,G1) and (S2,G2). -Brian -----Original Message----- From: Ali Boudani [mailto:aboudani@irisa.fr] Sent: Thursday, May 03, 2001 8:16 AM To: ssm-interest@external.cisco.com Subject: ssm Hello, How a reciever consider itself a member in a group G.?? and if a reciever after choosing from a web page a (S, G) channel, it can recieve data through the channel. that mean that the reciever should choose from the (S, G) channels belonging to the same group. is there anything wrong in that ?? Thanx From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue May 8 14:57:28 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04771 for ; Tue, 8 May 2001 14:57:23 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f48GUnf18199; Tue, 8 May 2001 09:30:58 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f48GWMd28119; Tue, 8 May 2001 09:32:22 -0700 (PDT) Received: from nm. ([61.140.254.9]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f48E6CH08772; Tue, 8 May 2001 07:06:12 -0700 (PDT) Received: from yahoo.com by nm. (SMI-8.6/SMI-SVR4) id VAA15153; Tue, 8 May 2001 21:42:30 +0900 From: Subject: Puzzles Date: Tue, 8 May 2001 09:52:29 Message-Id: <186.370255.301836@yahoo.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-3.cisco.com id f48GaEf20063 Content-Transfer-Encoding: quoted-printable WORD PUZZLE LOVERS=97 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20

= ~ WORD=20 PUZZLE LOVERS ~

 
=20

Do you like double acrostics?

We=20 Want To Send You, a FREE Sample?
=20

 

  • Do you like them big with lots of meat= in them?=20

Our puzzles average well over 250 letters. Most= published=20 puzzles have around 200.

 

  • Do you like them really tough and chal= lenging?=20

We dig deep for our clues and once in a while = we stick=20 in a real off-the-wall doozer

 
=20
If you answer YES,= we have=20 the acrostics for you!
=20

 

 

* We offer a subscription service.<= /u> *
=20
=20

Our= Subscribers=20 receive five new mind-ben= ders every=20 month

and they are delivered right into their m= ailbox.

 
=20
Would You Like us to Send= You, a FREE=20 Sample?
=20
=20

Yes, I want=20 to learn more about your Puzzles= .

Please click below

=20
=20

I am not interested; take me off your lis= t.

Please click=20 below
=20 =20
  =20     =20  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
=20
=20

 

 

 

 =20

Our=20 puzzles, [word puzzles for the connoisseur] start out with a lite= rary=20 quote. We use all the letters in the quote and create clues. The = first=20 letters of the clues spell out the author=92s name and the title = of the=20 source of the quote. The letters of the clue words are numbered a= nd correspond=20 to squares in the accompanying grid. Filling in the grid reveals = the quotation.=20

Sound=20 complicated?

Well=20 maybe a little, but that's where the solving fun comes in.

 

 

  
=20
=20
=20

Yes,=20 I want to learn more about your Puzzles and=20 I want to receive a FREE = sample.

Please=20 click below

 =20
=20

 
=20
=20  
=20 =20
=20

Please=20 include your Name and US Mailing Address including Zip Code.

 
=20
=20

 

I=20 am not interested; take me off your list.

Please=20 click below

  
=20
=20  

 

 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0   =20

From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri May 11 10:46:28 2001 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11768 for ; Fri, 11 May 2001 10:46:28 -0400 (EDT) Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.90]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with SMTP id f4BDlQd16715 for ; Fri, 11 May 2001 06:47:26 -0700 (PDT) Received: (daemon@localhost) by cliff.cisco.com (8.6.12/8.6.5) id GAA29147; Fri, 11 May 2001 06:47:27 -0700 Date: Fri, 11 May 2001 06:47:27 -0700 Message-Id: <200105111347.GAA29147@cliff.cisco.com> To: ssm-interest@external.cisco.com From: Mailer-Owner@cisco.com Subject: Welcome to ssm-interest Precedence: bulk Reply-To: Mailer-Owner@cisco.com -- Welcome to the ssm-interest mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "mailer@cisco.com" with the following command in the body of your email message: unsubscribe ssm-interest [] or (if you are internal to Cisco) you can use the web version of mailer at: http://www-mailer.cisco.com Here's the general information for the list you've subscribed to, in case you don't already have it: [Last updated on: Tue Apr 18 8:40:06 PDT 2000] IETF discussion about the design, implementation, and standardization of source-specific multicast for IP. From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue May 15 15:59:50 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05910 for ; Tue, 15 May 2001 15:59:49 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4FIout00602 for ; Tue, 15 May 2001 11:53:21 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4FIqMf16871 for ; Tue, 15 May 2001 11:52:22 -0700 (PDT) Received: from zdnet_compaq.zdnet_2000 ([211.101.240.2]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f4FIqHg24198 for ; Tue, 15 May 2001 11:52:18 -0700 (PDT) Received: from net.auckland.ac.nz ([216.97.194.1]) by zdnet_compaq.zdnet_2000 (Netscape Messaging Server 3.56) with SMTP id 552; Wed, 16 May 2001 02:42:31 +0800 Message-ID: <000027f5271a$00007a3d$000046e4@net.auckland.ac.nz> To: From: ophrea123@excite.com Subject: CAREER AND INVESTMENT OPPORTUNITY Date: Tue, 15 May 2001 07:33:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 7bit VENTURE CAPITAL BUSINESS, CAREER AND INVESTMENT OPPORTUNITY Our company, through our expanding partner network and in conjunction with varied and substantial investment groups, provides venture capital, capital leasing services, equity and debt funding to corporate clients nationwide. We are currently expanding our system and are seeking a professional person as a partner, who in turn will qualify clients for our services in their geographic area. There is no selling involved. Qualified clients come to us. This opportunity will appeal to an entrepreneurial individual that is seriously seeking a potential six figure income, along with a challenging and satisfying career and one that can led to financial security in an extraordinary and exciting growth industry. A strong general business background is a necessity. Our program entails interacting with CEO's of emerging growth companies and assessing and qualifying their financial needs. If accepted as a partner, there is an $9,750 investment required. To review an extensive package of information, please call our voice mail system at 214-346-2138 and leave your complete name, telephone number and email address. We will email you back with complete information so you may review our partnership program in extensive detail. To be removed you must put your email address in the subject line and send e-mail to : lando85@excite.com From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu May 17 05:28:14 2001 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 SMTP id FAA12554 for ; Thu, 17 May 2001 05:28:14 -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.11.3/8.9.1) with ESMTP id f4H8WJ903291 for ; Thu, 17 May 2001 01:32:19 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f4H8WSo14170 for ; Thu, 17 May 2001 01:32:28 -0700 (PDT) Received: from blade.interact.lu ([194.154.218.180]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f4H8WmL04445 for ; Thu, 17 May 2001 01:32:48 -0700 (PDT) Received: from tnt-8-351.easynet.co.uk ([195.40.205.95] helo=194.154.218.180) by blade.interact.lu with smtp (Exim 3.16 #6) id 14zlxj-0007kW-00; Tue, 15 May 2001 23:02:38 +0200 To: winnpennies@bird.nakanishi.ac.jp Date: Tue, 15 May 01 09:37:56 EST From: winnpennies1@excite.com Subject: MAJOR STOCK PLAY: DIDA (otcbb) $0.27 Message-Id: MAJOR STOCK PLAY: DIDA (otcbb) $0.27 SYMBOL: DIDA (otcbb) Current Price: $ .27 New Target Price: $2.00 - $2.25 Float: 1.6million Insiders of DIDA are accumulating shares. We feel this stock has serious upside potential. We consider DIDA a STRONG BUY!! for details go to: http://quote.yahoo.com/q?s=dida.ob&d=v1 DISCLAIMER: newpennies cautions that small and micro-cap stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed in this newsletter are the opinions of newpennies. All information concerning the company is received directly from company press releases. We recommend you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. newpennies assumes all information to be truthful and reliable; however, we cannot and do not warrant or guarantee the accuracy of this information. All statements contained herein are deemed to be factual as of the date of this report and as such are subject to change without notice. newpennies is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such newpennies is not offering investment advice or promoting any investment strategies. newpenniesis not offering securities for sale or solicitation of any offer to buy or sell securities. newpennies holds forty thousand shares of this company profile. newpennies, its affiliates, associates, relatives and anyone associated with newpennies in any manner reserves the right to either buy or sell shares in the profiled company's stock, either before the date of the profile, during the date of the profile or at any time after the date of the profile. We have an inherent conflict of interest by sending the newsletter at the same time we may own stock in the same company. newpennies sincerely beleives that the company profiled is a strong buy however we reserve the right to sell shares at anytime, even during the time period in which we are profiling a company. newpennies may profile companies trading in fast moving, volatile markets, and any reader of this newsletter should observe the trading behavior of any profiled company prior to investing. if you wish to unsubscribe from this mailing please email us at unsub992@excite.com From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue May 22 09:32:34 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17513 for ; Tue, 22 May 2001 09:32:33 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4MCjXc20495 for ; Tue, 22 May 2001 05:45:33 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f4MClDZ23987 for ; Tue, 22 May 2001 05:47:14 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f4MCkRv13032 for ; Tue, 22 May 2001 05:46:27 -0700 (PDT) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 May 2001 08:45:18 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445446@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'ssm-interest@external.cisco.com'" Date: Tue, 22 May 2001 08:45:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" subscribe ssm-interest From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu May 24 03:32:04 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09158 for ; Thu, 24 May 2001 03:32: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-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4O6g5U15364 for ; Wed, 23 May 2001 23:42:05 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f4O6gFX20492 for ; Wed, 23 May 2001 23:42:15 -0700 (PDT) Received: from ns1.intecel.net (customer-148-223-134-157.uninet.net.mx [148.223.134.157] (may be forged)) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f4O6fOd18373 for ; Wed, 23 May 2001 23:41:24 -0700 (PDT) Message-Id: <200105240641.f4O6fOd18373@proxy2.cisco.com> Received: from host (02-107.044.popsite.net [64.24.247.107]) by ns1.intecel.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KXWYH9LV; Thu, 24 May 2001 01:41:52 -0600 From: "Greg Ardente" Subject: No Fee listings #1876 To: nof45m@cisco.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VРЯD.1712.3 Mime-Version: 1.0 Date: Wed, 23 May 2001 23:01:35 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Candidate,

You were recently selected by The Office of The Managing Director
for a free listing on The International Executive Guild's CD-ROM=2E

Our researchers gather information from many recognized
sources, including professional associations and societies, trade
organizations, newspaper and magazine publications, web
presence, and referrals from existing members=2E

As a highly respected professional in your field of expertise, we
believe your contributions merit very serious consideration for
inclusion on The International Executive Guild's CD-ROM=2E
To maintain the level of accuracy, we ask you to click on the
web address highlighted below and fill out the brief bit of
information required for inclusion=2E

There is no cost or obligation to be listed on The International
Executive Guild's CD-ROM=2E

Remember, this site is for executives, professionals, & entrepreneurs<= br> only!

Congratulations,
Office of the Managing Director




If you wish to be removed from our list, please submit your request
at= the bottom of this email=2E

 

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E

Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included in the  registry=2E= For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed in The  Registry=2E=
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

Your Business
(Fi= nancial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(Mf= g, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Co= rp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortg= age Banking, etc=2E)
Major Product Line
(In= tegrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form = will be made by email, not by use of  www=2E  Confirmation of its del= ivery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E=

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu May 24 03:42:53 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09223 for ; Thu, 24 May 2001 03:42:52 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4MNnhU26887 for ; Tue, 22 May 2001 16:49:43 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4MNna219359 for ; Tue, 22 May 2001 16:49:36 -0700 (PDT) Received: from polpot.cityline.ru (polpot.cityline.ru [195.46.160.60]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f4MNn0v14614 for ; Tue, 22 May 2001 16:49:00 -0700 (PDT) Received: from relay3.cityline.ru (233.162.38.dn.dialup.cityline.ru [195.46.162.233]) by polpot.cityline.ru (8.11.3/t/08-Oct-1998) with SMTP id f4MNY7s52750; Wed, 23 May 2001 03:34:08 +0400 (MSD) Message-Id: <200105230243.KWD5056@relay3.cityline.ru> Date: Ср, 23 май 2001 2:43:33 +0300 Content-Type: text/plain; charset=us-ascii X-Mailer: Dynamic Opt-In Emailer (Win95/98/NT) Subject: From: taxconsultnig@mail.ru ВНИМАНИЮ ПЕРВЫХ ЛИЦ ОРГАНИЗАЦИИ . Уважаемые господа! Московское представительство английской компании “Tax Consulting” приглашает Вас принять участие в семинаре-практикуме. 28-29 мая 2001 г. на тему : “НОВЫЕ АСПЕКТЫ ВЭД НА 2001 Г." 28 мая 2001 г. "ИЗМЕНЕНИЕ ТАМОЖЕННОГО ЗАКОНОДАТЕЛЬСТВА” Часть 1. 1. ИЗМЕНЕНИЕ ТАМОЖЕННОГО ЗАКОНОДАТЕЛЬСТВА В 2001 Г. · ГОСУДАРСТВЕННЫЙ ТАМОЖЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ (приказы, распоряжения, письма, постановления) · ПОШЛИНЫ - Изменение ввозных и вывозных ставок в 2001 г. · ЛИЦЕНЗИИ - На ввоз, вывоз - Пакет документов на получение лицензий при работе с таможенными организациями 2. ВАЛЮТА - Ввоз, вывоз валюты, рублей, ценных бумаг - Документы для оформления в таможенных органах 3. ПРИНЦИПЫ НАЛОГООБЛОЖЕНИЯ ВЭД - НДС - Акцизы Основные принципы налогообложения экспорта-импорта. Порядок подтверждения экспорта товаров (работ, услуг), необходимые документы и требования налоговых органов при рассмотрении вопросов экспорта и обоснования экспортных льгот. Экспорт через комиссионера. Бартерные операции при внешнеэкономической деятельности. Возмещение входного НДС при экспорте. Порядок взимания НДС в торговле между странами - участниками СНГ. Проблема, практика и основные вопросы перспективного характера в связи с введением Налогового кодекса. 29 мая 2001 г. "Новые аспекты ВЭД на 2001 г.".1.НОВЫЕ ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ВЭД КОНТРАКТОВ. · Порядок заключения. Обязательные условия и формы внеэкономических сделок. Порядок регистрации. Бартер. Договор международного порядка (услуги). Особенности применения международных конвенций о международной купле-продаже товаров и услуг. Безопасные условия экспортных и импортных поставок (условия "Е", "С", "F", "D"). 2.ТРЕБОВАНИЯ К РАСЧЕТАМ ВЭД ОПЕРАЦИЙ. КОНТРОЛЬ ЗА ПРОВЕДЕНИЕМ ВАЛЮТНЫХ ОПЕРАЦИЙ. Приемлемые схемы расчетов. Документарный аккредитив. Документарное · Инкассо. Авансовые платежи и платежи по открытому счету. Чек в международных расчетах. Порядок ввоза и вывоза валюты. Индивидуальное лицензирование. · Контроль за расчетами и порядок открытия банковских счетов и размещение валютных средств за рубежом. Уголовная, административная и финансовая ответственность за нарушение правил проведения валютных операций. Порядок нарушения налога на регистрацию · Избежание ответственности за нарушение резидента и оков возврата валютной выручки. Реальные схемы. · Получение кредитов от нерезидентов. Порядок регистрации кредитных договоров. 3. БЕЗОПАСНОСТЬ ПРОВЕДЕНИЯ ВЭД СДЕЛОК. · Получение реалистической информации о зарубежном партнере. Виды и порядок направления запросов. · Хранение конфиденциальной информации документов. 4. КОНФЛИКТЫЕ СИТУАЦИИ. КОНТРАГЕНТЫ. КОНТРОЛИРУЮЩИЕ ОРГАНЫ. · Исчезновение или порча груза - Ваши действия? · Арбитраж. Регламент. Порядок подачи и иска и его рассмотрение. Особенности применения сроков новой давности. Судебные прецеденты. 5. ПРЕДСТАВИТЕЛЬСТВА НЕРЕЗИДЕНТОВ И СОВЕМЕСТНОЕ ПРЕДПРИЯТИЯ. · Порядок регистрации и налогообложения. Назначение и функционирование. Проведение торговых и посреднических операций, Инвестиции за границей. Преподаватели семинара – начальники управлений ГТК Государственного таможенногог комитета, Московской налоговой службы и других организаций, специализирующихся по внешнеэкономической деятельсности (ВЭД). Программа семинара очень интенсивна и потребует Вашего полного внимания и отдачи. Участники семинара обеспечиваются нормативными документами по тематике практикума. В перерывах – кофе, чай, напитки. Обед Стоимость семинара для одного слушателя на один день участия: $150 Стоимость семинара для одного слушателя на два дня участия: $250 Тел. для справок: (095) 204 - 80 -67, 204-80-68, 204-81-27. Место проведения: Гостинично-офисный комплекс "Спутник", Ленинский проспект, 38, м.Ленинский проспект Если Вы хотите отписаться от рассылки, отправьте пустое письмо по адресу: mailto:taxconsulting_uk@yahoo.com?subject=unsubscribe To unsubscribe from this mailing list, send a blank e-mail from your address to: mailto:taxconsulting_uk@yahoo.com?subject=unsubscribe From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu May 24 18:56:20 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22343 for ; Thu, 24 May 2001 18:56:19 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4OM5xc24580 for ; Thu, 24 May 2001 15:06:02 -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 ESMTP id f4OM7KE02412 for ; Thu, 24 May 2001 15:07:20 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f4OM7sr02355 for ; Thu, 24 May 2001 15:07:54 -0700 (PDT) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Thu, 24 May 2001 15:04: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.2652.78) id KT1D8FTG; Thu, 24 May 2001 15:04:11 -0700 From: Supratik Bhattacharyya To: ssm-interest@external.cisco.com Message-ID: <3B0D8504.BB224E37@sprintlabs.com> Date: Thu, 24 May 2001 15:02:44 -0700 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Subject: SSM Overview draft WG last call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As per the consensus reached at the Minnesota IETF meeting, I would like to do a WG last call for the SSM Deployment Overview draft (draft-bhattach-ssm-overview-02.txt) before it is advanced to the IESG with a request for Informational RFC status. Please comment by Monday June 11, 2001 on the WG mailing list or to me directly (supratik@sprintlabs.com). The draft is available from the SSM Working Group Web page : http://sith.maoz.com/SSM/ I have re-submitted this version to the IETF as well. Thanks, --Supratik From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri May 25 07:07:23 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14806 for ; Fri, 25 May 2001 07:07:23 -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.11.3/8.9.1) with ESMTP id f4PAKnU25857 for ; Fri, 25 May 2001 03:20:49 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f4PAKxU28170 for ; Fri, 25 May 2001 03:20:59 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f4PAHar14817 for ; Fri, 25 May 2001 03:17:37 -0700 (PDT) Received: (qmail 24430 invoked by alias); 25 May 2001 10:12:47 -0000 Delivered-To: GMX delivery to claudia%carmendorn@gmx.de Received: (qmail 24423 invoked by uid 0); 25 May 2001 10:12:47 -0000 Date: Fri, 25 May 2001 12:12:46 +0200 (MEST) From: Carmen Dornbach MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated-Sender: #0010896236@gmx.net X-Authenticated-IP: [195.93.64.171] Message-ID: <27440.990785566@www31.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="iso-8859-1" To: claudia%CarmenDorn@gmx.de X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-2.cisco.com id f4PALbU25858 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14806 Hallo, wir sind 9 heiЯe und hemmungslose Girls, nдmlich Babette, Moni, Carola, Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses Telefonat, oder bei gefallen einen heiЯen Seitensprung suchen. Ganz wie Du willst :o) Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794* Am Telefon kцnnen wir uns gleich ein Date ausmachen. Oder hast Du etwa keine Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich .... fg Wenn Du uns vorher sehen mцchtest, dann schau einfach mal auf unserer Homepage vorbei ... dort erfдhrst Du einiges mehr ьber uns ... www.datingfon.de Unsere intimsten Geheimnisse verraten wir Dir natьrlich nur direkt ... wir kцnnen sie Dir ja am Telefon ins Ohr flьstern ... Also alles ist mцglich weil wir auf alles Lust haben und noch so vieles ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794* Lass uns nicht so lange warten .... Bussi bis gleich Deine sьssen Girls (* E.p. DM 3,63/min.) -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- U2 Konzertreisen inkl. VIP-Package Hier Eventreisen zur U2-Tour bei Getgo.de online buchen! http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue May 29 18:53:58 2001 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12354 for ; Tue, 29 May 2001 18:53:57 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4TM2QU29337 for ; Tue, 29 May 2001 15:02:26 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4TM2IP10126 for ; Tue, 29 May 2001 15:02:18 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f4TM2El08580 for ; Tue, 29 May 2001 15:02:14 -0700 (PDT) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Tue, 29 May 2001 14:59:13 -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.2652.78) id KT1D8MQL; Tue, 29 May 2001 14:59:10 -0700 From: Supratik Bhattacharyya To: ssm-interest@external.cisco.com Message-ID: <3B141B53.81F984B3@sprintlabs.com> Date: Tue, 29 May 2001 14:57:39 -0700 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Name Change. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In accordance with the IETF naming convention for working group documents, I have renamed the SSM Deployment Overview draft as : draft-ietf-ssm-overview-00.txt I have updated the SSM working group web page at http://sith.maoz.com/SSM/ to reflect this change. Thanks, --Supratik From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu May 31 08:15:32 2001 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21580 for ; Thu, 31 May 2001 08:15:30 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4VBF4c03329 for ; Thu, 31 May 2001 04:15:05 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4VBGYe08472 for ; Thu, 31 May 2001 04:16:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f4VBCjB14507 for ; Thu, 31 May 2001 04:12:46 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19767; Thu, 31 May 2001 06:59:15 -0400 (EDT) Message-Id: <200105311059.GAA19767@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ssm-interest@external.cisco.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ssm-overview-00.txt Date: Thu, 31 May 2001 06:59:15 -0400 Sender: nsyracus@cnri.reston.va.us --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 : An Overview of Source-Specific Multicast(SSM) Deployment Author(s) : S. Bhattacharyya et al. Filename : draft-ietf-ssm-overview-00.txt Pages : 13 Date : 30-May-01 This document provides an overview of the Source-Specific Multicast (SSM) service and its deployment using the PIM-SM and IGMP/MLD protocols. The network layer service provided by SSM is a 'channel', identified by an SSM destination IP address (G) and a source IP address S. The IP address range 232/8 has been designated as SSM addresses by IANA for IPv4. An SSM address range already exists for IPv6. A source S transmits IP datagrams to an SSM address G. A receiver can receive these datagrams by subscribing to the channel (S,G). Channel subscription is supported by version 3 of the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. The interdomain tree for forwarding UDP datagrams is rooted at the source S. Although a number of protocols exists for constructing source- rooted forwarding trees, this document discusses the most widely implemented one - PIM Sparse Mode [PIM-SM-NEW]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ssm-overview-00.txt 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-overview-00.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-overview-00.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: <20010530130720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ssm-overview-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ssm-overview-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010530130720.I-D@ietf.org> --OtherAccess-- --NextPart--