From owner-pim@catarina.usc.edu Fri Dec 1 07:01:42 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11873 for ; Fri, 1 Dec 2000 07:01:41 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA99964 for pim-list; Fri, 1 Dec 2000 03:36:57 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA99959 for ; Fri, 1 Dec 2000 03:36:56 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id DAA26891 for ; Fri, 1 Dec 2000 03:36:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25989; Fri, 1 Dec 2000 06:33:17 -0500 (EST) Message-Id: <200012011133.GAA25989@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pim@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pim-sm-v2-new-01.txt,.ps Date: Fri, 01 Dec 2000 06:33:16 -0500 Sender: owner-pim@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol Independent Multicast Working Group of the IETF. Title : Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised) Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas Filename : draft-ietf-pim-sm-v2-new-01.txt,.ps Pages : 127 Date : 30-Nov-00 This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-01.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-pim-sm-v2-new-01.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-pim-sm-v2-new-01.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: <20001130115259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pim-sm-v2-new-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pim-sm-v2-new-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115259.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pim@catarina.usc.edu Mon Dec 4 15:19:01 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19704 for ; Mon, 4 Dec 2000 15:19:00 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA18075 for pim-list; Mon, 4 Dec 2000 11:51:00 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA18070 for ; Mon, 4 Dec 2000 11:50:58 -0800 (PST) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA03964 for ; Mon, 4 Dec 2000 11:50:59 -0800 (PST) Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA24802 for ; Mon, 4 Dec 2000 11:49:11 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id LAA58533 for ; Mon, 4 Dec 2000 11:49:11 -0800 (PST) (envelope-from pusateri@garnet.juniper.net) Message-Id: <200012041949.LAA58533@garnet.juniper.net> To: pim@catarina.usc.edu Subject: PIM Working Group Agenda MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58530.975959351.1@garnet.juniper.net> Date: Mon, 04 Dec 2000 11:49:11 -0800 From: Tom Pusateri Sender: owner-pim@catarina.usc.edu Precedence: bulk Here is the current PIM agenda for San Diego. Please send me updates in the next day or so to get it submitted to the IETF staff by Wednesday afternoon. I noticed a new State Refresh spec but haven't had anyone ask for a timeslot. Do any of the authors want to talk about it? Thanks, Tom Charter Update - 10 min Tom Pusateri , Liming Wei Sparse Mode Spec update - 15 min Isidor Kouvelas http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-01.txt SSM for PIM Sparse Mode - 15 min Hugh Hugh Holbrook same pim sparse mode spec Bidirectional PIM - 15 min Isidor Kouvelas http://www.ietf.org/internet-drafts/draft-ietf-pim-bidir-01.txt State Refresh in PIM-DM - ? ??? http://www.ietf.org/internet-drafts/draft-ietf-pim-refresh-02.txt From owner-pim@catarina.usc.edu Tue Dec 5 14:05:31 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14334 for ; Tue, 5 Dec 2000 14:05:29 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA23099 for pim-list; Tue, 5 Dec 2000 10:30:12 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA23094 for ; Tue, 5 Dec 2000 10:30:11 -0800 (PST) Received: from multicasttech.com (IDENT:root@ns2.multicasttech.com [63.105.122.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA06691 for ; Tue, 5 Dec 2000 10:30:06 -0800 (PST) Received: from [216.8.7.29] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 574017; Tue, 05 Dec 2000 12:59:18 -0500 Message-ID: <3A2D2E2B.81304A2B@21rst-century.com> Date: Tue, 05 Dec 2000 13:04:27 -0500 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 MIME-Version: 1.0 To: pim@catarina.usc.edu, fenner@research.att.com, holbrook@cisco.com Subject: PIM-SM and SSM State Maintenance References: <200012032203.OAA14336@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello; In http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtssm.htm there is : State Maintenance Limitations In PIM-SSM, the last hop router will continue to periodically send (S, G) Join messages if appropriate (S, G) subscriptions are on the interfaces. Therefore, as long as receivers send (S, G) subscriptions, the shortest path tree (SPT) state from the receivers to the source will be maintained, even if the source is not sending traffic for longer periods of time (or even never). This case is opposite to PIM-SM, where (S, G) state is maintained only if the source is sending traffic and receivers are joining the group. If a source stops sending traffic for more than 3 minutes in PIM-SM, the (S, G) state will be deleted and only reestablished after packets from the source arrive again through the RPT. Because no mechanism in PIM-SSM notifies a receiver that source is active, the network must maintain the (S, G) state in PIM-SSM as long as there are receivers requesting receipt of that channel. I can find no mention of this in http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-01.txt nor in http://www.ietf.org/internet-drafts/draft-sandick-pimsm-ssmrules-00.txt nor in http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-05.txt nor even in http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-00.txt (BTW, this last document mentions a section 10.2 on page 2 which does not apparently exist.) Did I just miss it ? Or is this not part of the protocol ? Wouldn't this permit a DOS, where a computer would just start issuing joins to every possible group in 232/8 for the victim's IP address, thereby creating a lot of state in the victim's first hop router ? Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-pim@catarina.usc.edu Tue Dec 5 15:58:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16713 for ; Tue, 5 Dec 2000 15:58:43 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA24079 for pim-list; Tue, 5 Dec 2000 12:33:56 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA24074 for ; Tue, 5 Dec 2000 12:33:55 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA02597 for ; Tue, 5 Dec 2000 12:33:55 -0800 (PST) Received: from holbrook-laptop.cisco.com (dhcp-10-34-3-70.cisco.com [10.34.3.70]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA25095; Tue, 5 Dec 2000 12:29:31 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 00880C42B8; Tue, 5 Dec 2000 12:29:05 -0800 (PST) From: Hugh Holbrook To: tme@21rst-century.com Cc: pim@catarina.usc.edu, fenner@research.att.com, holbrook@cisco.com In-reply-to: <3A2D2E2B.81304A2B@21rst-century.com> Subject: Re: PIM-SM and SSM State Maintenance Reply-To: holbrook@cisco.com Message-Id: <20001205202905.00880C42B8@holbrook-laptop.cisco.com> Date: Tue, 5 Dec 2000 12:29:05 -0800 (PST) Sender: owner-pim@catarina.usc.edu Precedence: bulk > Did I just miss it ? Or is this not part of the protocol ? > > Wouldn't this permit > a DOS, where a computer would just start issuing joins to every possible > group in 232/8 > for the victim's IP address, > thereby creating a lot of state in the victim's first hop router ? The SSM service model spec, draft-holbrook-ssm-arch-01.txt, has a Security Considerations section (attached) that notes the DoS possibility, suggests possible ways of alleviating it, and identifies the risks of doing so. This issue applies to SSM in general (both PIM-SSM and IGMPv3 have this vulnerability, and would also apply to most future implementations of SSM that I can reasonably imagine). This is why it seemed somewhat appropriate to put it in the SSM architecture spec rather than in a specific protocol spec, but feel free to suggest otherwise. > (BTW, this last document mentions a section 10.2 on page 2 which does > not apparently exist.) Ahah -- a section-renumbering casualty due to insufficient knowledge of nroff. It should refer to section 3.5. Thanks. -Hugh ---------------------------------------------------------------- 7. Security Considerations 7.1. Denial-of-Service A subscription request creates (S,G) state in a router to record the subscription and invokes processing on that router and possibly causes processing at neighboring routers. A host can mount a denial of service attack by requesting a large number of subscriptions. A denial of service can result if: - a large amount of traffic arrives when it was otherwise undesired, consuming network resources to deliver it and host resources to drop it - a large amount of source-specific multicast state is created in network routers, using router memory and CPU resources to store and process the state - a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth To reduce the damage from such an attack, a router MAY have a configuration option to limit the following items: - The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks) - The total number of subscriptions that can be initated from any single interface. Holbrook/Cain [Page 9] INTERNET-DRAFT Source-Specific Multicast 24 November 2000 Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may use large numbers of channels. Tight limits on the rate or number of channel subscriptions would inhibit the deployment of such applications. A router SHOULD verify that the source of a subscription request is a valid address for the interface on which it was received. Failure to do so would exacerbate a spoofed-source address attack. We note that these attacks are not unique to SSM -- they are also present for Any-Source Multicast. From owner-pim@catarina.usc.edu Tue Dec 5 17:03:24 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24735 for ; Tue, 5 Dec 2000 17:03:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA24497 for pim-list; Tue, 5 Dec 2000 13:50:23 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA24492 for ; Tue, 5 Dec 2000 13:50:22 -0800 (PST) Received: from multicasttech.com (IDENT:root@ns2.multicasttech.com [63.105.122.8]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA23211 for ; Tue, 5 Dec 2000 13:50:22 -0800 (PST) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 574128; Tue, 05 Dec 2000 16:31:10 -0500 Message-ID: <3A2D5F03.48637F5C@21rst-century.com> Date: Tue, 05 Dec 2000 16:32:50 -0500 From: 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: holbrook@cisco.com CC: pim@catarina.usc.edu, fenner@research.att.com Subject: Re: PIM-SM and SSM State Maintenance References: <20001205202905.00880C42B8@holbrook-laptop.cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hugh; Thanks for the info. Hugh Holbrook wrote: > > Did I just miss it ? Or is this not part of the protocol ? > > > > Wouldn't this permit > > a DOS, where a computer would just start issuing joins to every possible > > group in 232/8 > > for the victim's IP address, > > thereby creating a lot of state in the victim's first hop router ? > > The SSM service model spec, draft-holbrook-ssm-arch-01.txt, has a Note that in http://www.ietf.org/ids.by.wg/none.html this draft has exactly the same name : "Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 11/30/2000. (27503 bytes) as does http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt : "Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 03/13/2000. (37881 bytes) wouldn't it be a good idea to give the two documents a different tag ? It took me a while to realize that they were, in fact, different documents (not just different versions of the same draft). > > Security Considerations section (attached) that notes the DoS > possibility, suggests possible ways of alleviating it, and identifies > the risks of doing so. This issue applies to SSM in general (both > PIM-SSM and IGMPv3 have this vulnerability, and would also apply to > most future implementations of SSM that I can reasonably imagine). > This is why it seemed somewhat appropriate to put it in the SSM > architecture spec rather than in a specific protocol spec, but feel > free to suggest otherwise. > But what occured to me is that if the state of the whole tree is maintained IN THE ABSENCE OF ANY SOURCE ACTIVITY, then it would be very hard to shut off, given some zombies with repeat requests. Maybe first hop routers should take note of requests to (S,G) where there isn't actually a source, and deny repeated requests. Marshall > > > (BTW, this last document mentions a section 10.2 on page 2 which does > > not apparently exist.) > > Ahah -- a section-renumbering casualty due to insufficient knowledge > of nroff. It should refer to section 3.5. Thanks. > > -Hugh > > ---------------------------------------------------------------- > > 7. Security Considerations > > 7.1. Denial-of-Service > > A subscription request creates (S,G) state in a router to record the > subscription and invokes processing on that router and possibly causes > processing at neighboring routers. A host can mount a denial of service > attack by requesting a large number of subscriptions. A denial of > service can result if: > > - a large amount of traffic arrives when it was otherwise undesired, > consuming network resources to deliver it and host resources to drop > it > > - a large amount of source-specific multicast state is created in > network routers, using router memory and CPU resources to store and > process the state > > - a large amount of control traffic is generated to manage the > source-specific state, using router CPU and network bandwidth > > To reduce the damage from such an attack, a router MAY have a > configuration option to limit the following items: > > - The total rate at which all hosts on any one interface are allowed > to initiate subscriptions (to limit the damage caused by forged > source-address attacks) > > - The total number of subscriptions that can be initated from any > single interface. > > Holbrook/Cain [Page 9] > > INTERNET-DRAFT Source-Specific Multicast 24 November 2000 > > Any decision by an implementor to artificially limit the rate or number > of subscriptions should be taken carefully, however, as future > applications may use large numbers of channels. Tight limits on the > rate or number of channel subscriptions would inhibit the deployment of > such applications. > > A router SHOULD verify that the source of a subscription request is a > valid address for the interface on which it was received. Failure to do > so would exacerbate a spoofed-source address attack. > > We note that these attacks are not unique to SSM -- they are also > present for Any-Source Multicast. 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 owner-pim@catarina.usc.edu Sat Dec 9 13:33:34 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04957 for ; Sat, 9 Dec 2000 13:33:33 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA50944 for pim-list; Sat, 9 Dec 2000 10:07:42 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA50932; Sat, 9 Dec 2000 10:07:40 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA14573; Sat, 9 Dec 2000 10:07:38 -0800 (PST) Message-Id: <200012091807.KAA14573@usc.edu> From: Mail Sender To: piewie@rocketmail.com CC: pilc@grc.nasa.gov, pim@catarina.usc.edu, pim-request@catarina.usc.edu, pindar@HK.Super.NET, Pine.GSO.3.96.971020155614.8935I-100000@cafe.berkeley.edu Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pim@catarina.usc.edu Precedence: bulk www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-pim@catarina.usc.edu Mon Dec 11 03:46:41 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15550 for ; Mon, 11 Dec 2000 03:46:40 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA56018 for pim-list; Mon, 11 Dec 2000 00:30:25 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA56013 for ; Mon, 11 Dec 2000 00:30:24 -0800 (PST) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA24711 for ; Mon, 11 Dec 2000 00:30:23 -0800 (PST) Received: from oleane (dyn-1-1-004.Vin.dialup.oleane.fr [195.25.4.4]) by smtp2.cluster.oleane.net with SMTP id eBB8Tnc99769 for ; Mon, 11 Dec 2000 09:29:49 +0100 (CET) Message-ID: <018201c0634c$d4a19f00$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: "Betond Sonet/SDH" Call for paper Date: Mon, 11 Dec 2000 09:31:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017F_01C06355.34700360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pim@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_017F_01C06355.34700360 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gigabit Ethernet Digital Wrapper Issues Implementation of newly defined functionalities: STM-64, STM-256 = (positioning beside N x 2.5 G or P x 10 G)=20 Tandem connection monitoring FEC WDM DWDM issues:=20 - Transitional step between SDH and OTN=20 - Terabit networks - WDM for metro networks=20 The call for paper for the "Betond Sonet/SDH" conference has been = extended to January 20. Please take a look on: http://www.upperside.fr/babeyondsdh.htm ------=_NextPart_000_017F_01C06355.34700360 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gigabit Ethernet
Digital Wrapper Issues
Implementation of newly defined functionalities: STM-64, STM-256=20 (positioning beside N x 2.5 G or P x 10 G)
Tandem connection = monitoring FEC=20 WDM DWDM issues:
- Transitional step between SDH and OTN
- = Terabit=20 networks
- WDM for metro networks
 
The call for paper for the "Betond Sonet/SDH" conference has been = extended=20 to January 20.
 
Please take a look on:
http://www.upperside.fr/= babeyondsdh.htm
------=_NextPart_000_017F_01C06355.34700360-- From owner-pim@catarina.usc.edu Wed Dec 13 08:25:23 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05587 for ; Wed, 13 Dec 2000 08:25:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA65562 for pim-list; Wed, 13 Dec 2000 05:01:00 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA65557 for ; Wed, 13 Dec 2000 05:00:59 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA18843 for ; Wed, 13 Dec 2000 05:00:57 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eBDCv5R16146 for ; Wed, 13 Dec 2000 13:57:05 +0100 (MET) Received: from sh.bel.alcatel.be ([138.203.194.110]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569B4.00471ABE; Wed, 13 Dec 2000 13:56:39 +0100 Message-ID: <3A377211.274593D3@sh.bel.alcatel.be> Date: Wed, 13 Dec 2000 13:56:49 +0100 From: francis arts vh624 8492 Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: Queues for multicast traffic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Does a router require / need to have separate egress queues for multicast and unicast traffic? That is, is it needed to take the unicast / multicast character of an IP packet into account when scheduling a packet on the output port / egress interface? RFC 2932 (IPv4 Multicast Routing MIB) defines the 'ipMRouteInterfaceRateLimit' object in the ipMRouteInterfaceTable. This could be achieved by using a separate queue for multicast traffic. However, the question here is whether or not this rate limiting is effectively used in practical (deployed) networks. Thanks for your answer. Kind regards, Francis. From owner-pim@catarina.usc.edu Mon Dec 18 14:05:41 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13270 for ; Mon, 18 Dec 2000 14:05:40 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA88440 for pim-list; Mon, 18 Dec 2000 10:31:55 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA88435 for ; Mon, 18 Dec 2000 10:31:53 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA12785 for ; Mon, 18 Dec 2000 10:31:51 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eBIIRmO20125; Mon, 18 Dec 2000 19:27:58 +0100 (MET) Received: from alcatel.be ([138.203.195.108]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569B9.0065689F; Mon, 18 Dec 2000 19:27:39 +0100 Message-ID: <3A3E5722.DB0278E8@alcatel.be> Date: Mon, 18 Dec 2000 19:27:47 +0100 From: Francis Arts Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: pim@catarina.usc.edu CC: "\"Natarajan \\\"Raj\\\" Vaidhyanathan\"" , Bart Batsleer , Frank Desseyn , Rudy Selderslaghs , Alex Helsen , Piet Debuysscher Subject: PIM-SM draft questions Content-Type: multipart/alternative; boundary="------------6433AE24781CA86180882DA6" Sender: owner-pim@catarina.usc.edu Precedence: bulk --------------6433AE24781CA86180882DA6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I had some questions while reading the latest version of the revised draft 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)'. Could you please have a look at them? Thank you. Kind regards, Francis Arts. ------------------- ******************************* *Terminology used in this mail* ******************************* PIM-SM tunnel ingress point --------------------------- Further on in this mail the term 'PIM-SM tunnel ingress point' refers to the source DR or the PMBR encapsulating the multicast IP packet in a PIM register message. Outer IP header --------------- The 'outer IP header' is the header of the (unicast) IP packet having the PIM-SM register message as its payload. The 'outer IP header' is sometimes also called the 'outer header' for short. ************ *Questions * ************ Note: --> Next I have also included some information I found in RFC 2003 on IP over IP tunnels. I am not sure whether or not it is relevant to compare IP over IP and PIM-SM tunnels. Please be the judge on this. 1) TOS byte in tunnel ingress point. How should the PIM-SM tunnel ingress point determine which TOS byte to use in the outer IP header: ** Should the TOS byte be copied from the multicast IP packet into the outer IP header OR ** should a fixed value be used for the TOS byte (e.g. always BE), irrespective of the value of the TOS byte in the multicast IP packet OR ** ...? Note: RFC 2003 indicates that for IP over IP tunnels the IP/IP tunnel ingress point copies the TOS byte from the multicast IP packet in the outer header. 2) TOS byte in RP. How should the TOS byte be handled in the RP: ** Is the TOS byte copied from the outer IP header in the inner (multicast) IP header OR ** Is the TOS byte of the outer IP header ignored and the TOS byte value as is in the multicast IP header used OR ** ...? Note: RFC 2003 on IP over IP tunnels is not clear on the behavior of IP over IP tunnels in this case. 3) TTL in tunnel ingress point. How should the PIM-SM tunnel ingress point determine which TTL value to use in the outer IP header: ** Is the TTL (after decrementation) copied from the multicast IP packet into the outer IP header OR ** is a fixed value used for the TTL in the outer IP header, large enough to reach the RP OR ** ...? The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP. Notes: --> RFC 2003 indicates that for IP over IP tunnels the TTL is set to a value that is large enough to reach the tunnel egress point. --> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL must be copied from the IP header to the MPLS SHIM header. 4) TTL in RP. How should the TTL be handled in the RP: ** Is the TTL copied from the outer IP header in the header of the multicast IP packet OR ** Is the TTL of the outer IP header ignored and the TTL value as is in the multicast IP header used OR ** ...? The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP. Notes: --> RFC 2003 indicates that for IP over IP tunnels the TTL of the inner IP header as is, is used. --> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL should be copied from the MPLS SHIM header to the IP header. 5) DF bit. How should the DF bit in the outer IP header be handled in the tunnel ingress point: ** Should the DF bit in the outer IP header always be set to 'don't fragment'. OR ** Should the DF bit in the outer IP header be set to the same value as the DF bit in the header of the multicast IP packet OR ** ...? Notes: --> RFC 2003 indicates that if the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header; if the "Don't Fragment" bit is not set in the inner IP header, it MAY be set in the outer IP header. 6) IP options. How should IP options be handled in the tunnel ingress point: ** Are there any IP options that have to (...) be copied from the multicast IP header to the outer IP header? ** Are there any IP options that MAY be copied from the multicast IP header to the outer IP header? ** Are there any IP options that are not present in the header of the multicast IP packet, that MAY be added to the outer IP header in the PIM-SM tunnel ingress point? Note: RFC 2003 states the following: "Any options present in the inner IP header are in general NOT copied to the outer IP header. However, new options specific to the tunnel path MAY be added. In particular, any supported types of security options of the inner IP header MAY affect the choice of security options for the outer header. It is not expected that there be a one-to-one mapping of such options to the options or security headers selected for the tunnel." --------------6433AE24781CA86180882DA6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello,

I had some questions while reading the latest version of the revised draft 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)'. Could you please have a look at them? Thank you.

Kind regards,

    Francis Arts.

-------------------

        *******************************
        *Terminology used in this mail*
        *******************************

PIM-SM tunnel ingress point
---------------------------

Further on in this mail the term 'PIM-SM tunnel ingress point' refers to the source DR or the PMBR encapsulating the multicast IP packet in a PIM register message.

Outer IP header
---------------

The 'outer IP header' is the header of the (unicast) IP packet having the PIM-SM register message as its payload. The 'outer IP header' is sometimes also called the 'outer header' for short.
 

        ************
        *Questions *
        ************

Note:
--> Next I have also included some information I found in RFC 2003 on IP over IP tunnels. I am not sure whether or not it is relevant to compare IP over IP and PIM-SM tunnels. Please be the judge on this.
 

1) TOS byte in tunnel ingress point.

How should the PIM-SM tunnel ingress point determine which TOS byte to use in the outer IP header:
** Should the TOS byte be copied from the multicast IP packet into the outer IP header
OR
** should a fixed value be used for the TOS byte (e.g. always BE), irrespective of the value of the TOS byte in the multicast IP packet
OR
** ...?

Note: RFC 2003 indicates that for IP over IP tunnels the IP/IP tunnel ingress point copies the TOS byte from the multicast IP packet in the outer header.
 
 

2) TOS byte in RP.

How should the TOS byte be handled in the RP:
** Is the TOS byte copied from the outer IP header in the inner (multicast) IP header
OR
** Is the TOS byte of the outer IP header ignored and the TOS byte value as is in the multicast IP header used
OR
** ...?

Note: RFC 2003 on IP over IP tunnels is not clear on the behavior of IP over IP tunnels in this case.
 
 

3) TTL in tunnel ingress point.

How should the PIM-SM tunnel ingress point determine which TTL value to use in the outer IP header:
** Is the TTL (after decrementation) copied from the multicast IP packet into the outer IP header
OR
** is a fixed value used for the TTL in the outer IP header, large enough to reach the RP
OR
** ...?

The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP.

Notes:
--> RFC 2003 indicates that for IP over IP tunnels the TTL is set to a value that is large enough to reach the tunnel egress point.
--> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL must be copied from the IP header to the MPLS SHIM header.
 
 

4) TTL in RP.

How should the TTL be handled in the RP:
** Is the TTL copied from the outer IP header in the header of the multicast IP packet
OR
** Is the TTL of the outer IP header ignored and the TTL value as is in the multicast IP header used
OR
** ...?

The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP.

Notes:
--> RFC 2003 indicates that for IP over IP tunnels the TTL of the inner IP header as is, is used.
--> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL should be copied from the MPLS SHIM header to the IP header.
 
 

5) DF bit.

How should the DF bit in the outer IP header be handled in the tunnel ingress point:
** Should the DF bit in the outer IP header always be set to 'don't fragment'.
OR
** Should the DF bit in the outer IP header be set to the same value as the DF bit in the header of the multicast IP packet
OR
** ...?

Notes:
--> RFC 2003 indicates that if the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header; if the "Don't Fragment" bit is not set in the inner IP header, it MAY be set in the outer IP header.
 
 

6) IP options.

How should IP options be handled in the tunnel ingress point:
** Are there any IP options that have to (...) be copied from the multicast IP header to the outer IP header?
** Are there any IP options that MAY be copied from the multicast IP header to the outer IP header?
** Are there any IP options that are not present in the header of the multicast IP packet, that MAY be added to the outer IP header in the PIM-SM tunnel ingress point?

Note:
RFC 2003 states the following:
"Any options present in the inner IP header are in general NOT copied to the outer IP header.  However, new options specific to the tunnel path MAY be added.  In particular, any supported types of security options of the inner IP header MAY affect the choice of security options for the outer header.  It is not expected that there be a one-to-one mapping of such options to the options or security headers selected for the tunnel." --------------6433AE24781CA86180882DA6-- From owner-pim@catarina.usc.edu Thu Dec 21 11:00:59 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22870 for ; Thu, 21 Dec 2000 11:00:58 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA02078 for pim-list; Thu, 21 Dec 2000 07:32:27 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA02073 for ; Thu, 21 Dec 2000 07:32:25 -0800 (PST) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA19821 for ; Thu, 21 Dec 2000 07:32:25 -0800 (PST) Received: from bwilliam-8000.cisco.com (bwilliam-isdn1.cisco.com [171.70.247.82]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA23465; Thu, 21 Dec 2000 07:30:32 -0800 (PST) Message-Id: <4.3.2.7.2.20001212110228.02a6b410@127.0.0.1> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Dec 2000 09:29:09 -0800 To: Bill Fenner , kouvelas@cisco.com, Mark Handley From: Beau Williamson Subject: PIM over NBMA LIS Cc: pim@catarina.usc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pim@catarina.usc.edu Precedence: bulk Bill, Isidor and Mark, I wanted to follow up with an issue that I raised at the PIM WG meeting regarding PIM over NBMA Logical IP Subnets (LIS). (The question I raised was that the Prune-Echo might be useful in solving some of the problems in these topologies. However, as Mark pointed out, this is only part of the puzzle.) The problem comes when PIM is running on a Logical IP Subnet (LIS) that is implemented on an NBMA network of VC's where the nodes are not fully meshed. One of the most obvious examples is when a node transmits a Prune message to the LIS. Depending on the normal underlying VC topology, this Prune message may not actual be delivered to all other nodes in the LIS. This can lead to routers failing to override a Prune message. Consider the following case: A / \ / \ LIS / \ B C | rcv If B sends a Prune message, it is not *necessarily* heard by C and hence C will not override the prune. There are two possible solutions to this problem: 1) Routers on a partial mesh NBMA LIS (such as the one above) MUST rebroadcast all multicast messages received on one VC to all other VC's in the LIS. 2) Routers on a LIS must keep track of individual Join state of the other routers on the LIS. Approach (1) has numerous problems in the area of performance as the router must replicate *all* packets using a pseudo broadcast methodology. Furthermore, replicating arriving broadcast/multicast packets on one VC to all other VC's departs from most normal implementations (that I know of). Approach (2) is probably the method of choice for dealing with this issue. The interface is configured to operate in a special NBMA Mode. When in NBMA-Mode, the OIL is populated based on individual PIM neighbors that have sent Joins via the NBMA interface instead of just by physical interface. This effectively permits the PIM implementation to have awareness of the underlying L2 topology and handle the individual VC's as if they were p2p links. Having said all of the above, I'm not sure how or even if we want to try to add a short paragraph concerning this to the spec. It may be that this should be implementation specific and we don't need anything about it in the spec. I'll let you be the judges on this. At least I've made you aware of some real world topologies that may or may not be covered by the current spec. Beau Williamson From owner-pim@catarina.usc.edu Thu Dec 21 19:12:31 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05317 for ; Thu, 21 Dec 2000 19:12:30 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id PAA06042 for pim-list; Thu, 21 Dec 2000 15:45:44 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id PAA05990; Thu, 21 Dec 2000 15:44:34 -0800 (PST) From: itoffers@yahoo.com Received: from yahoo.com (host35.pmi1.laurel.us.net [198.240.90.35]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id PAA06312; Thu, 21 Dec 2000 15:44:32 -0800 (PST) Subject: A Very Special Offer to win $3,300 Date: Thu, 21 Dec 2000 18:49:21 Message-Id: <334.146441.849540@yahoo.com> Reply-To: scholars@us.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: undisclosed-recipients:; Sender: owner-pim@catarina.usc.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by catarina.usc.edu id PAA06042 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA05317 ******************************************************************* A Very Special Offer to win $3,300 ******************************************************************* Dear Friend, Here is a very special offer to win $3,300 worth of IT Training Which will be awarded to one lucky person every week for the Next 52 weeks! The Lucky Winner will get FREE access to 650+ online courses, which include MICROSOFT, CISCO, ORACLE, COMPTIA, E-COMMERCE, and WEB-MASTER Certifications etc. This offer is from the most valued Online IT Training Website and the courses being offered have been acclaimed as "The Best of the Web" by Forbes Magazine. And are sponsored by U.S. Department of Commerce for Federal Employees Winner will also get: · FREE Online IT Library · FREE Online Certification Skill Tests · 24 X 7 Tech Support Take one minute to send an e-mail to scholars@us.net to register and you could be on the road to a Successful career in the HI-Tech Industry Drawings are held weekly, so hurry for your chance to win! ********************************************************************* If you'd not like to receive any special offers in the future, Please respond to this email with the word "unsubscribe" as The first word in the subject line. ********************************************************************* From owner-pim@catarina.usc.edu Fri Dec 22 04:51:45 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27518 for ; Fri, 22 Dec 2000 04:51:44 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA07792 for pim-list; Fri, 22 Dec 2000 01:35:18 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA07778 for ; Fri, 22 Dec 2000 01:35:15 -0800 (PST) Received: from nwcst294 (nwcst294.netaddress.usa.net [204.68.23.39]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id BAA21799 for ; Fri, 22 Dec 2000 01:35:15 -0800 (PST) Received: (qmail 1240 invoked by uid 60001); 22 Dec 2000 09:33:14 -0000 Message-ID: <20001222093314.1239.qmail@nwcst294> Received: from 204.68.23.39 by nwcst294 for [202.106.14.130] via web-mailer(34FM.0700.4B.01) on Fri Dec 22 09:33:14 GMT 2000 Date: 22 Dec 00 02:33:14 MST From: santosh vernekar To: sgverne@usa.net Subject: Regarding PIM-SM implementation X-Mailer: USANET web-mailer (34FM.0700.4B.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id BAA07781 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Dear Sir, We need reference sites where we get information about the implementation of Multicast router to support PIM-SM . Awaiting positive reply . Thanking you. Regards Santosh & Manju ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-pim@catarina.usc.edu Fri Dec 22 04:59:42 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27625 for ; Fri, 22 Dec 2000 04:59:42 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id BAA07818 for pim-list; Fri, 22 Dec 2000 01:35:39 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id BAA07799 for ; Fri, 22 Dec 2000 01:35:37 -0800 (PST) Received: from nwcst293 (nwcst293.netaddress.usa.net [204.68.23.38]) by usc.edu (8.9.3.1/8.9.3/usc) with SMTP id BAA21872 for ; Fri, 22 Dec 2000 01:35:37 -0800 (PST) Received: (qmail 8355 invoked by uid 60001); 22 Dec 2000 09:33:35 -0000 Message-ID: <20001222093335.8354.qmail@nwcst293> Received: from 204.68.23.38 by nwcst293 for [202.106.14.130] via web-mailer(34FM.0700.4B.01) on Fri Dec 22 09:33:35 GMT 2000 Date: 22 Dec 00 02:33:35 MST From: santosh vernekar To: sgverne@usa.net Subject: Regarding PIM-SM implementation X-Mailer: USANET web-mailer (34FM.0700.4B.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id BAA07801 Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Dear Sir, We need reference sites where we get information about the implementation of Multicast router to support PIM-SM . Awaiting positive reply . Thanking you. Regards Santosh & Manju ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-pim@catarina.usc.edu Sun Dec 24 06:08:12 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07316 for ; Sun, 24 Dec 2000 06:08:12 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA18888 for pim-list; Sun, 24 Dec 2000 02:54:10 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA18883 for ; Sun, 24 Dec 2000 02:54:09 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA14812 for ; Sun, 24 Dec 2000 02:54:08 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eBOAoFS19365; Sun, 24 Dec 2000 11:50:15 +0100 (MET) Received: from alcatel.be ([138.203.253.250]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569BF.003B8203; Sun, 24 Dec 2000 11:50:00 +0100 Message-ID: <3A45D3C2.65141825@alcatel.be> Date: Sun, 24 Dec 2000 11:45:22 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: pim@catarina.usc.edu CC: Raj Vaidhyanathan/Raleigh/IBM Subject: Revised PIM-SM draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Could someone share his / her point of view on the parameters (DSCP, TTL, ...) that should be used in the outer IP header of a PIM-SM register encapsulated packet? Please find more detailed questions included below. Thank you. Kind regards, Francis Arts. ------------------- ******************************* *Terminology used in this mail* ******************************* PIM-SM tunnel ingress point --------------------------- Further on in this mail the term 'PIM-SM tunnel ingress point' refers to the source DR or the PMBR encapsulating the multicast IP packet in a PIM register message. Outer IP header --------------- The 'outer IP header' is the header of the (unicast) IP packet having the PIM-SM register message as its payload. The 'outer IP header' is sometimes also called the 'outer header' for short. ************ *Questions * ************ Note: --> Next I have also included some information I found in RFC 2003 on IP over IP tunnels. I am not sure whether or not it is relevant to compare IP over IP and PIM-SM tunnels. Please be the judge on this. 1) TOS byte in tunnel ingress point. How should the PIM-SM tunnel ingress point determine which TOS byte to use in the outer IP header: ** Should the TOS byte be copied from the multicast IP packet into the outer IP header OR ** should a fixed value be used for the TOS byte (e.g. always BE), irrespective of the value of the TOS byte in the multicast IP packet OR ** ...? Note: RFC 2003 indicates that for IP over IP tunnels the IP/IP tunnel ingress point copies the TOS byte from the multicast IP packet in the outer header. 2) TOS byte in RP. How should the TOS byte be handled in the RP: ** Is the TOS byte copied from the outer IP header in the inner (multicast) IP header OR ** Is the TOS byte of the outer IP header ignored and the TOS byte value as is in the multicast IP header used OR ** ...? Note: RFC 2003 on IP over IP tunnels is not clear on the behavior of IP over IP tunnels in this case. 3) TTL in tunnel ingress point. How should the PIM-SM tunnel ingress point determine which TTL value to use in the outer IP header: ** Is the TTL (after decrementation) copied from the multicast IP packet into the outer IP header OR ** is a fixed value used for the TTL in the outer IP header, large enough to reach the RP OR ** ...? The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP. Notes: --> RFC 2003 indicates that for IP over IP tunnels the TTL is set to a value that is large enough to reach the tunnel egress point. --> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL must be copied from the IP header to the MPLS SHIM header. 4) TTL in RP. How should the TTL be handled in the RP: ** Is the TTL copied from the outer IP header in the header of the multicast IP packet OR ** Is the TTL of the outer IP header ignored and the TTL value as is in the multicast IP header used OR ** ...? The big question here seems to be whether or not the PIM-SM tunnel should be considered as 1 hop between the source DR / PMBR and the RP. Notes: --> RFC 2003 indicates that for IP over IP tunnels the TTL of the inner IP header as is, is used. --> However, the draft-ietf-mpls-label-encaps-08.txt indicates that for MPLS the TTL should be copied from the MPLS SHIM header to the IP header. 5) DF bit. How should the DF bit in the outer IP header be handled in the tunnel ingress point: ** Should the DF bit in the outer IP header always be set to 'don't fragment'. OR ** Should the DF bit in the outer IP header be set to the same value as the DF bit in the header of the multicast IP packet OR ** ...? Notes: --> RFC 2003 indicates that if the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header; if the "Don't Fragment" bit is not set in the inner IP header, it MAY be set in the outer IP header. 6) IP options. How should IP options be handled in the tunnel ingress point: ** Are there any IP options that have to (...) be copied from the multicast IP header to the outer IP header? ** Are there any IP options that MAY be copied from the multicast IP header to the outer IP header? ** Are there any IP options that are not present in the header of the multicast IP packet, that MAY be added to the outer IP header in the PIM-SM tunnel ingress point? Note: RFC 2003 states the following: "Any options present in the inner IP header are in general NOT copied to the outer IP header. However, new options specific to the tunnel path MAY be added. In particular, any supported types of security options of the inner IP header MAY affect the choice of security options for the outer header. It is not expected that there be a one-to-one mapping of such options to the options or security headers selected for the tunnel." From owner-pim@catarina.usc.edu Sun Dec 24 06:13:25 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07337 for ; Sun, 24 Dec 2000 06:13:25 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id CAA18861 for pim-list; Sun, 24 Dec 2000 02:46:44 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA18856 for ; Sun, 24 Dec 2000 02:46:42 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA14021 for ; Sun, 24 Dec 2000 02:46:42 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id eBOAgme19243 for ; Sun, 24 Dec 2000 11:42:48 +0100 (MET) Received: from alcatel.be ([138.203.253.250]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569BF.003AD39A; Sun, 24 Dec 2000 11:42:33 +0100 Message-ID: <3A45D203.381BEF36@alcatel.be> Date: Sun, 24 Dec 2000 11:37:55 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: pim@catarina.usc.edu Subject: Queueing in multicast capable networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pim@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Could someone share his / her point of view concerning queueing in multicast capable networks? More in particular, does a router require / need to have separate egress queues for multicast and unicast traffic? That is, is it needed to take the unicast / multicast character of an IP packet into account when scheduling a packet on the output port / egress interface? RFC 2932 (IPv4 Multicast Routing MIB) defines the 'ipMRouteInterfaceRateLimit' object in the ipMRouteInterfaceTable. This could be achieved by using a separate queue for multicast traffic. However, the question here is whether or not this rate limiting is effectively used in practical (deployed) networks. Thanks for your answer. Kind regards, Francis. From owner-pim@catarina.usc.edu Thu Dec 28 03:59:12 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14478 for ; Thu, 28 Dec 2000 03:59:11 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id AAA29985 for pim-list; Thu, 28 Dec 2000 00:43:26 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id AAA29980 for ; Thu, 28 Dec 2000 00:43:25 -0800 (PST) Received: from omta03.mta.everyone.net (sitemail.everyone.net [216.200.145.35]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id AAA02554 for ; Thu, 28 Dec 2000 00:43:26 -0800 (PST) Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta03.mta.everyone.net (Postfix) with ESMTP id 8BB2F48B5F; Thu, 28 Dec 2000 00:35:55 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id 25BAA36F9; Thu, 28 Dec 2000 00:35:46 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) Date: Thu, 28 Dec 2000 00:35:45 -0800 (PST) From: XVA International To: xi12282@asean-mail.com Reply-To: xi12282@asean-mail.com X-Originating-Ip: [216.191.90.154] Message-Id: <20001228083546.25BAA36F9@sitemail.everyone.net> Sender: owner-pim@catarina.usc.edu Precedence: bulk WOULD YOU STUFF ENVELOPES FOR $1,000'S WEEKLY? $2 For Each Envelope You Stuff SIMPLE, PLEASANT WORK YOU CAN DO AT HOME!!! HELP SOLVE YOUR MONEY PROBLEMS. No more worries over inflation, recession, bills, rising gasoline and other costs. If you are looking for easy extra income, to relieve financial pressures, you owe it to yourself to investigate our offer. HERE IS YOUR CHANCE to earn extra money working at home by becoming an active participant of our successful mailing association. You receive cash daily for the envelopes you stuff. There is no limit. You stuff as many as you wish. NO EXPERIENCE OR SPECIAL SKILLS REQUIRED. Our HOMEMAILER'S PROGRAM is designed especially for people with little or no business experience and provides step-by step instructions. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ WHY IS THIS POSSIBLE? There are many mail-order companies who want to expand their business, but do not want to hire more people. If they hired more employees, they would have to supervise them, rent more office space, pay more taxes and insurance, all involving more paperwork. It is much easier for them to set it up so that independent homeworkers can earn money doing the work themselves. This program is designed to help people cash in with a company who needs homeworkers. Each member is an independent homeworker. You serve a company that pays good commissions to have their circulars mailed. This program has been perfected so that it has become one of the most successful and profitable ones ever. We invite you to take part in our success. The money you earn is up to you. We do not require that you mail a certain number of pieces each week. You can take on whatever amount of business that fits your schedule, and you can quit whenever you want, there are no obligations. This work mainly consists of the securing of envelopes. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ You may work in the comfort of your own home, choose your own hours, and set your own pace. No need to leave your present job. The possibilities are unlimited - get the whole family to join in. Form workshops with your friends. We will further show you how to expand your operation and boost your new income as high as you wish to go. NOW, IT'S ALL UP TO YOU! The opportunity for the better life is here - it's waiting! But only YOU can take that all-important step that separates the achievers from the dreamers! Order NOW! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ALL BUSINESS can be done by MAIL and we give you complete assistance at every step to insure your success. You can START THE SAME DAY you receive the instructions and begin RECEIVING MONEY WITHIN TWO WEEKS and every week from then on, as long as you desire. You will be supplied with the materials to be stuffed. Envelopes will be already stamped and addressed. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ GUARANTEE: We welcome you to this program and extend to you our unconditional guarantee that everything we have said about this program is true and that you will be delighted with the money you make. Our goals and continued success depends on your 100% satisfaction with the HOMEMAILER'S PROGRAM. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ DON'T BE FOOLED There are many fraudulent envelope addressing and chain letter schemes being sold today. We recommend that you avoid them. Why fool with some questionable scheme when our program enables you to earn so much money legally. This is not an offer of employment. It is an opportunity to become an independent commission mailer for our company. Remember, unlike the others, this is not a get-rich-quick scheme. It is a proven program for making money while filling the needs of a company who need people to mail their circulars. IN ORDER TO GET YOU STARTED IMMEDIATELY, we must require a one-time fee of only $13.95. This covers our expense in showing you what to do and guarantees you can work with us as long as desired. You will not be required or asked to pay for any additional information or manuals. Inasmuch as we would like to send you our program with the small charge, we must protect ourselves from those who are not serious and have no intention other than to satisfy their own curiosity. Naturally, no business can afford to send out costly material to everyone who writes in asking for it. This small charge assures us that you are serious about wanting to earn money at home. DON'T DELAY - START IMMEDIATELY!!! This is money. You can begin now by putting your time to the best of use. The next few minutes can literally change your life. Don't let this extraordinary opportunity pass. YOUR REGISTRATION FEE REFUNDED as soon as you submit your first 100 envelopes. Send a check or money order in the amount of $13.95 to: X V A International 11948 ? 207th Street, Suite 309 Maple Ridge, BC, Canada V2X 1X7 Don?t forget to include your name, address, and an email address. Never send cash through the mail. XVA International is a licensed business operating in BC, Canada; license #14126. Please allow 4 ? 6 weeks for delivery of your starter kit. This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email with the word "remove" in the subject line. _____________________________________________________________ _________ Get your free Email address at Asean-mail.com ______________________________ Asia Hotel Network http://www.asiarooms.com From owner-pim@catarina.usc.edu Thu Dec 28 16:01:06 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19437 for ; Thu, 28 Dec 2000 16:01:05 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id MAA31832 for pim-list; Thu, 28 Dec 2000 12:36:04 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-pim@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA31827 for ; Thu, 28 Dec 2000 12:36:02 -0800 (PST) Received: from mail.routerware.com (ppp-64-161-186-193.routerware.com [64.161.186.193]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA20003 for ; Thu, 28 Dec 2000 12:36:02 -0800 (PST) Received: by mail.routerware.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 12:38:00 -0800 Message-ID: <4F48C7B31A8BD311B1D20090279C34B230A943@clavin> From: Chris Hall To: "'santosh vernekar'" Cc: "'pim@catarina.usc.edu'" , "'robert.winter@windriver.com'" Subject: RE: Regarding PIM-SM implementation Date: Thu, 28 Dec 2000 12:38:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pim@catarina.usc.edu Precedence: bulk Hi All- Again, the contact information for Wind River's PIM-SM product is: Robert Winter (972) 221-9958 robert.winter@windriver.com Please address all questions regarding this product to him. thanks- Chris Christopher J. Hall Software Engineer Wind River Networks 949.442.2066 chris.hall@windriver.com -----Original Message----- From: santosh vernekar [mailto:sgverne@usa.net] Sent: Friday, December 22, 2000 1:34 AM To: sgverne@usa.net Subject: Regarding PIM-SM implementation Dear Sir, We need reference sites where we get information about the implementation of Multicast router to support PIM-SM . Awaiting positive reply . Thanking you. Regards Santosh & Manju ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1