From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Mon Apr 2 02:01:33 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 CAA12950 for ; Mon, 2 Apr 2001 02:01: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.9.3/8.9.1) with ESMTP id VAA22540 for ; Sun, 1 Apr 2001 21:30:10 -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 f324VSk25441 for ; Sun, 1 Apr 2001 21:31:29 -0700 (PDT) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f324VMi01500 for ; Sun, 1 Apr 2001 21:31:22 -0700 (PDT) Received: from petersburg (adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id VAA25899; Sun, 1 Apr 2001 21:05:44 -0700 X-Authentication-Warning: mail.webfountain.com: Host adsl-63-197-78-195.dsl.snfc21.pacbell.net [63.197.78.195] claimed to be petersburg Reply-To: From: "Michael Luby" To: "Bill Nickless" , , , , Cc: "Michael Luby" Subject: RE: IPv4 multicast best current practice I-D Date: Sun, 1 Apr 2001 21:07:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.2.1.0.20010401220745.02a31988@pop.mcs.anl.gov> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit In the PIM Sparse Mode section: Within a PIM Sparse Mode domain, the standard PIM Sparse Mode mechanisms are used to build shared forwarding trees and source specific trees from IPv4 multicast sources to interested receivers. IPv4 multicast sources are registered with the PIM Rendezvous Point (RP). Interested IPv4 multicast receivers make their group interest known through the Internet Group Management Protocol, and the associated PIM Designated Router (DR) sends PIM Join messages towards the RP to build the appropriate forwarding trees. In the ASM model, PIM Sparse Mode Rendezvous Points have to co- operate in order to discover active sources and set up forwarding trees. MSDP is used to spread the knowledge of active sources within a multicast group. PIM-SM source-specific joins are used to set up forwarding from sources towards the interested receivers. No inter-PIM-domain shared forwarding tree is created. The last part of this first paragraph is specific to ASM, yet this paragraph is written as if though it applies to IPv4 multicast in general. There is no RP for SSM, there is no need for MSDP, etc. The second paragraph is good, as it specifies what happens with ASM using MSDP and the RPs, etc. However, it seems logical that there should be a third paragraph for SSM that parallels this second paragraph for ASM, that says specifically there is no need for MSDP and RPs are not used and the forwarding tree is set up directly from the source to the receivers using PIM-SM (or PIM-SSM) source-specific joins. In the MSDP section, it should be specifically noted at the top that the bulk of this section only applies to ASM, and specifically SSM does not need (and should not use) MSDP. Most of this section is ASM specific, and it should be specifically called out which parts apply to ASM and which parts apply to SSM. -----Original Message----- From: owner-wg-multicast@internet2.edu [mailto:owner-wg-multicast@internet2.edu]On Behalf Of Bill Nickless Sent: Sunday, April 01, 2001 8:16 PM To: msdp@network-services.uoregon.edu; wg-multicast@internet2.edu; mboned@network-services.uoregon.edu Subject: IPv4 multicast best current practice I-D -----BEGIN PGP SIGNED MESSAGE----- I have posted http://www-fp.mcs.anl.gov/~nickless/draft-nickless-ipv4-mcast-bcp-00.txt to the internet-drafts@ietf.org and to the IETF mboned mailing list. Please read it over and comment. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQCVAwUBOsfu2awgm7ipJDXBAQH6xgP9FOBW07KbnHRIXQODPkOjm80XHeKBIpnJ z+QeObthJsgaeqgPiZUTJJRYrfneQcfYb8WGiKrhRkepoLK5jDZf2GNg8GBDAo7G HoIHMvazttzUJC+onCyvGr8VZhgx6TgDQbp18/sjWOxtZtorWnAFFeE0AC5vQovA Ddv+/au40pw= =FOYB -----END PGP SIGNATURE----- From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Mon Apr 2 03:25:58 2001 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01855 for ; Mon, 2 Apr 2001 03:25:58 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA19897 for ; Sun, 1 Apr 2001 23:16:50 -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 f326GRp06037 for ; Sun, 1 Apr 2001 23:16:27 -0700 (PDT) Received: from accord-soft.com ([164.164.69.252]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f326FYb10585 for ; Sun, 1 Apr 2001 23:15:35 -0700 (PDT) Received: from accord-soft.com (Lokesh [192.168.1.27]) by accord-soft.com (8.9.3/8.9.3) with ESMTP id LAA08730 for ; Mon, 2 Apr 2001 11:42:22 +0530 Message-ID: <3AC8193A.81415B61@accord-soft.com> Date: Mon, 02 Apr 2001 11:46:26 +0530 From: loki X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ssm-interest@external.cisco.com Subject: How to unsubsribe from this list Content-Type: multipart/alternative; boundary="------------A359223456CBD36844DC139F" --------------A359223456CBD36844DC139F Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sorry for disturbing. Can anyone tell me how to unsubscribe from this list? i.e link from where i can unsubscribe. --------------A359223456CBD36844DC139F Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit Sorry for disturbing.

Can anyone tell me how to unsubscribe from this list?
i.e link from where i can unsubscribe.
 
  --------------A359223456CBD36844DC139F-- From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Mon Apr 2 12:57:21 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 MAA20517 for ; Mon, 2 Apr 2001 12:57:20 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA25779 for ; Mon, 2 Apr 2001 08:26:25 -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 f32FRf923105 for ; Mon, 2 Apr 2001 08:27:41 -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 f32FNpi10491 for ; Mon, 2 Apr 2001 08:23:52 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 840628; Mon, 02 Apr 2001 10:42:27 -0400 Message-ID: <3AC89049.FD08241F@21rst-century.com> Date: Mon, 02 Apr 2001 10:44:24 -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: luby@digitalfountain.com CC: Bill Nickless , msdp@network-services.uoregon.edu, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, ssm-interest@external.cisco.com Subject: Re: IPv4 multicast best current practice I-D References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Luby wrote: > In the PIM Sparse Mode section: > > Within a PIM Sparse Mode domain, the standard PIM Sparse Mode > mechanisms are used to build shared forwarding trees and source > specific trees from IPv4 multicast sources to interested receivers. > IPv4 multicast sources are registered with the PIM Rendezvous Point > (RP). Interested IPv4 multicast receivers make their group interest > known through the Internet Group Management Protocol, and the > associated PIM Designated Router (DR) sends PIM Join messages > towards the RP to build the appropriate forwarding trees. > > In the ASM model, PIM Sparse Mode Rendezvous Points have to co- > operate in order to discover active sources and set up forwarding > trees. MSDP is used to spread the knowledge of active sources > within a multicast group. PIM-SM source-specific joins are used to > set up forwarding from sources towards the interested receivers. No > inter-PIM-domain shared forwarding tree is created. > > The last part of this first paragraph is specific to ASM, yet this paragraph > is written as if though it applies to IPv4 multicast in general. There is > no RP for SSM, there is no need for MSDP, etc. The second paragraph is > good, as it specifies what happens with ASM using MSDP and the RPs, etc. > However, it seems logical that there should be a third paragraph for SSM > that parallels this second paragraph for ASM, that says specifically there > is no need for MSDP and RPs are not used and the forwarding tree is set up > directly from the source to the receivers using PIM-SM (or PIM-SSM) > source-specific joins. > > In the MSDP section, it should be specifically noted at the top that the > bulk of this section only applies to ASM, and specifically SSM does not need > (and should not use) MSDP. Most of this section is ASM specific, and it > should be specifically called out which parts apply to ASM and which parts > apply to SSM. > > -----Original Message----- > From: owner-wg-multicast@internet2.edu > [mailto:owner-wg-multicast@internet2.edu]On Behalf Of Bill Nickless > Sent: Sunday, April 01, 2001 8:16 PM > To: msdp@network-services.uoregon.edu; wg-multicast@internet2.edu; > mboned@network-services.uoregon.edu > Subject: IPv4 multicast best current practice I-D > > -----BEGIN PGP SIGNED MESSAGE----- > > I have posted > > http://www-fp.mcs.anl.gov/~nickless/draft-nickless-ipv4-mcast-bcp-00.txt > > to the internet-drafts@ietf.org and to the IETF mboned mailing > list. Please read it over and comment. > > === > Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 > PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov > Mike; I will have comments on the draft soon; but these are my comments on your comments. From the PIM v2 spec draft-ietf-pim-sm-v2-new-01.txt -------------------- o A router MUST NOT forward packets based on (*,G) or (S,G,rpt) state. The (*,G) and (S,G,rpt) -related state summarization macros are NULL for any SSM address, for the purposes of packet forwarding. o A router acting as an RP MUST NOT forward any Register-encapsulated packet that has an SSM destination address. The last two rules are present to deal with "legacy" routers unaware of SSM that may be sending (*,G) and (S,G,rpt) Join/Prunes, or Register messages for SSM destination addresses. Additionally: o A router MAY be configured to advertise itself as a Candidate RP for an SSM address. If so, it SHOULD respond with a Register-Stop message to any Register message containing a packet destined for an SSM address. ----------------- I would say that for the foreseeable future, domains will be BOTH ASM and SSM. I would also say that these domains will thus have to deal both with RP's and with cross-domain traffic that potentially has ASM traffic in the ISM space. I would therefore recommend that the BCP explicitly include these details on what to do with RP's in the SSM space. I would also say that the BCP for SSM should be that inter-domain SSM is only done in the 232/8 address range, and that other SSM uses are restricted to the administratively scoped domain 239/8. Otherwise, SSM address discovery will rear its ugly head. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Mon Apr 2 17:58:19 2001 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02521 for ; Mon, 2 Apr 2001 17:58:18 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20857 for ; Mon, 2 Apr 2001 13:44:25 -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 f32Ki4b28633 for ; Mon, 2 Apr 2001 13:44:04 -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 f32Khvi13618 for ; Mon, 2 Apr 2001 13:43:58 -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 PAA27874 for ; Mon, 2 Apr 2001 15:28:55 -0500 (CDT) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA298B; Mon, 2 Apr 2001 16:28:18 -0400 Message-ID: <3AC8E38E.AD302175@alcatel.com> Date: Mon, 02 Apr 2001 16:39:42 -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: L.Wood@eim.surrey.ac.uk CC: Jon Crowcroft , ssm-interest@external.cisco.com, pim@catarina.usc.edu, ns-users mailing list Subject: Re: has anyone done PIM SM/SSM v2 in NS2? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Lloyd, Do you mean that NS2 available today supports some variation of PIM-SM? If so, which one? Also, are there any plans of supporting SSM in the near future? Thanks, Nagesh Lloyd Wood wrote: > [widening to include ns-users.] > > On Fri, 30 Mar 2001, Jon Crowcroft wrote: > > > Date: Fri, 30 Mar 2001 15:21:16 +0100 > > From: Jon Crowcroft > > To: ssm-interest@external.cisco.com, pim@catarina.usc.edu > > Subject: has anyone done PIM SM/SSM v2 in NS2? > > > > > > we're interested to know if anyone has pim sm/ssm as of latest specs > > in ns2 (or is working on it!).... > > Updating: > http://www.isi.edu/cgi-bin/nsnam/cvsweb/ns-2/tcl/pim/Attic/ > > to better match PIM-SM (as was, never mind now) and changes in ns > multicast internals strikes me as a large task... > > L. > > PGP From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 5 08:02:25 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 IAA28726 for ; Thu, 5 Apr 2001 08:02:24 -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.9.3/8.9.1) with ESMTP id DAA18863 for ; Thu, 5 Apr 2001 03:58: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 f35AwDV06517 for ; Thu, 5 Apr 2001 03:58:13 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f35AsNi23590 for ; Thu, 5 Apr 2001 03:54:24 -0700 (PDT) Message-Id: <200104051054.f35AsNi23590@proxy1.cisco.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:19 -0100 From: "Rita de Groot" To: Subject: huidziekte Sender: "Rita de Groot" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:59:50 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Apr 5 13:00:09 2001 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08060 for ; Thu, 5 Apr 2001 13:00:08 -0400 (EDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23911 for ; Thu, 5 Apr 2001 08:56:33 -0700 (PDT) Received: (from dmm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA15954; Thu, 5 Apr 2001 08:55:33 -0700 (PDT) From: David Meyer Message-Id: <200104051555.IAA15954@cisco.com> Subject: Re: Why MSDP? To: aboudani@irisa.fr (Ali Boudani) Date: Thu, 5 Apr 2001 08:55:32 -0700 (PDT) Cc: fenner@research.att.com (Bill Fenner), nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu In-Reply-To: <3ACC8F04.12F658E1@irisa.fr> from "Ali Boudani" at Apr 05, 2001 05:28:04 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not sure about the history of this thread, but here's some of the history. First, we looked at putting SAs into BGP. I wanted to do this as a first thought since the MBGP/MSDP split effectively splits the control plane. However, this turned out to be a less than optimal solution for several reasons, not the least of which included: (i). State The reason MSDP is periodic and not incremental (and originally non-caching) is that we were tryin to avoid explosion of (S,G) state. I guess we're not so worried about that (c.f. SSM). In addition, we had to somehow (attempt to) solve the bursty source problem. (ii). BGP Stability I don't really want to argue that the dynamic nature of SA advertisements is going to help the stability of BGP (that is, of the global routing system). Neither do you, I would guess. (iii). Deployment Because of (i). and (ii). above, SAs in BGP would have been impossible to deploy (who would want to deploy a version of BGP that carried SAs? MBGP with SAFI \in {1,2} was hard enough). There were a few other things, but these were the main concerns. BTW, what we were doing was attempting to find a way to free providers from having to co-locate their RPs on a dense-mode exchange point (i.e., get (S,G) state from outside their domain onto their RPs so their customers could join those groups, w/o sharing RPs). That was the (lost in the mist of history) design goal. Dave According to Ali Boudani: > > > One reason: the timescales for change of active source indications are > > much different than BGP was designed to carry. BGP wants to carry > > data that doesn't change very often, e.g. see route dampening. Sources > > can come and go at an arbitrary rate, so the rate of change of the > > information is potentially much higher. > > can you specifie more, > why should the timescales for change active source indications are much > different.??? > > From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 5 13:02:25 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 NAA08131 for ; Thu, 5 Apr 2001 13:02:25 -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.9.3/8.9.1) with ESMTP id IAA02649 for ; Thu, 5 Apr 2001 08:45:22 -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 f35Fj8h01266 for ; Thu, 5 Apr 2001 08:45:08 -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 f35FfGi17425 for ; Thu, 5 Apr 2001 08:41:16 -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 RAA16530; Thu, 5 Apr 2001 17:27:59 +0200 (MET DST) Message-ID: <3ACC8F04.12F658E1@irisa.fr> Date: Thu, 05 Apr 2001 17:28:04 +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: Bill Fenner CC: nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu Subject: Re: Why MSDP? References: <200103222325.RAA13581@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > One reason: the timescales for change of active source indications are > much different than BGP was designed to carry. BGP wants to carry > data that doesn't change very often, e.g. see route dampening. Sources > can come and go at an arbitrary rate, so the rate of change of the > information is potentially much higher. can you specifie more, why should the timescales for change active source indications are much different.??? From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 5 14:20:50 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 OAA10493 for ; Thu, 5 Apr 2001 14:20: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-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00143 for ; Thu, 5 Apr 2001 09:51:00 -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 f35GqI820095 for ; Thu, 5 Apr 2001 09:52:18 -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 f35GqDi06211 for ; Thu, 5 Apr 2001 09:52:13 -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 SAA23681; Thu, 5 Apr 2001 18:38:39 +0200 (MET DST) Message-ID: <3ACC9F94.9B73D3AC@irisa.fr> Date: Thu, 05 Apr 2001 18:38:44 +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: David Meyer CC: Bill Fenner , nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu Subject: Re: Why MSDP? References: <200104051555.IAA15954@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think I didnt understand well the SA message. In unicast (using BGP), a source can send messages without disturbing the BGP , so why isnt the case in MBGP?? and if we imagine that we are using PIM-SM shared tree, then it is the same as unicast ?? (in some way). what am I missing here? thanx > Not sure about the history of this thread, but here's some > of the history. > > First, we looked at putting SAs into BGP. I wanted to > do this as a first thought since the MBGP/MSDP split > effectively splits the control plane. However, this > turned out to be a less than optimal solution for several > reasons, not the least of which included: > > (i). State > > The reason MSDP is periodic and not incremental > (and originally non-caching) is that we were tryin > to avoid explosion of (S,G) state. I guess we're > not so worried about that (c.f. SSM). In addition, > we had to somehow (attempt to) solve the bursty > source problem. > > (ii). BGP Stability > > I don't really want to argue that the dynamic nature > of SA advertisements is going to help the stability > of BGP (that is, of the global routing system). Neither > do you, I would guess. > > (iii). Deployment > > Because of (i). and (ii). above, SAs in BGP would have been > impossible to deploy (who would want to deploy a > version of BGP that carried SAs? MBGP with SAFI \in {1,2} > was hard enough). > > > There were a few other things, but these were the main concerns. > BTW, what we were doing was attempting to find a way to free > providers from having to co-locate their RPs on a dense-mode > exchange point (i.e., get (S,G) state from outside their domain onto > their RPs so their customers could join those groups, w/o sharing > RPs). That was the (lost in the mist of history) design goal. > > Dave > > > According to Ali Boudani: > > > > > One reason: the timescales for change of active source indications are > > > much different than BGP was designed to carry. BGP wants to carry > > > data that doesn't change very often, e.g. see route dampening. Sources > > > can come and go at an arbitrary rate, so the rate of change of the > > > information is potentially much higher. > > > > can you specifie more, > > why should the timescales for change active source indications are much > > different.??? > > > > From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 5 14:47:59 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 OAA10992 for ; Thu, 5 Apr 2001 14:47:58 -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.9.3/8.9.1) with ESMTP id KAA18447 for ; Thu, 5 Apr 2001 10:25:50 -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 f35HQme24817 for ; Thu, 5 Apr 2001 10:26:48 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f35HMF804864 for ; Thu, 5 Apr 2001 10:22:16 -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 TAA26851; Thu, 5 Apr 2001 19:09:37 +0200 (MET DST) Message-ID: <3ACCA6D6.17122283@irisa.fr> Date: Thu, 05 Apr 2001 19:09:42 +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: David Meyer CC: Bill Fenner , nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu Subject: Re: Why MSDP? References: <200104051555.IAA15954@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I think I understand but just correct me if I am wrong. the multicast topology advertised by MBGP is not the Trees but it is just advertising the network reachability of the connected multicast routers. that mean instead of advertising all the routes in a domain , we just advertise the routes between multicast routers and subnetworks. MBGP is not advertising the trees in the domains and that is why we should send another kind messages when a source appers. because this source will construct a new multicast tree in the domain using PIM-SM or other protocol. Of course, MBGP like BGP cant support a lot of changes in the topology in a domain and that is why , multicast trees (reachability) should not transported via MBGP. we should found something else (and that is why we are using MSDP) Is that true? (I hope I am right :-) ) thanx Ali From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Apr 5 15:12:50 2001 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11507 for ; Thu, 5 Apr 2001 15:12:50 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA15704 for ; Thu, 5 Apr 2001 10:47: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 f35Hkxd05248 for ; Thu, 5 Apr 2001 10:46:59 -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 f35Hh8i09501 for ; Thu, 5 Apr 2001 10:43:08 -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 MAA06569 for ; Thu, 5 Apr 2001 12:28:04 -0500 (CDT) Received: from alcatel.com ([198.205.41.19]) by nsamail01.us.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6B9F; Thu, 5 Apr 2001 13:27:28 -0400 Message-ID: <3ACCADB7.14210809@alcatel.com> Date: Thu, 05 Apr 2001 13:39:03 -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: David Meyer CC: Ali Boudani , Bill Fenner , ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu Subject: Re: Why MSDP? References: <200104051555.IAA15954@cisco.com> Content-Type: multipart/alternative; boundary="------------B7643E2C07603C3C96B96AD4" --------------B7643E2C07603C3C96B96AD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Meyer wrote: > Not sure about the history of this thread, but here's some > of the history. > I think you are addressing the core of this topic, which is, why we can't use MBGP instead of MSDP. > > First, we looked at putting SAs into BGP. I wanted to > do this as a first thought since the MBGP/MSDP split > effectively splits the control plane. However, this > turned out to be a less than optimal solution for several > reasons, not the least of which included: > > (i). State > > The reason MSDP is periodic and not incremental > (and originally non-caching) is that we were tryin > to avoid explosion of (S,G) state. I guess we're > not so worried about that (c.f. SSM). In addition, > we had to somehow (attempt to) solve the bursty > source problem. Yes, indeed SSM seems to side-step this problem very well. About the bursty sources: it seems to me that we add a lot of overhead to MSDP to solve this problem, and yet it is not clear if it is completely reliable. > > (ii). BGP Stability > > I don't really want to argue that the dynamic nature > of SA advertisements is going to help the stability > of BGP (that is, of the global routing system). Neither > do you, I would guess. > Is there info available to compare the time-scales of these two traffic types ( i.e SA-advt vs Unicast Route advt)? If so, that will be enlightening, and I'd urge anyone to post it. If I want to analyze this, I'd have to consider in a given time, in a given network, the number of routes, the rate at which these are changing. What are the assumptions about: 1. Rate of unicast route change ( per route) 2. Number of unicast routes in the network 3. Rate of an average SA advt ( per S,G) 4. Number of sources in the network. My suspicion is that #4 is far less compared to #2, and also that #1 is far slower compared to #3. leading to an intereting question on where the trade-off lies. So, unless we are talking about really short sessions and much larger number of sources than is typical, it is not clear to me that this would threaten BGP's stability. And what about timescales for other types of MBGP traffic? ( VPNs, for example) > > (iii). Deployment > > Because of (i). and (ii). above, SAs in BGP would have been > impossible to deploy (who would want to deploy a > version of BGP that carried SAs? MBGP with SAFI \in {1,2} > was hard enough). > I have a question: If some provider is starting to deploy interdomain Multicast from scratch ( anyone out there?), I'd think that it is far more attractive to deploy MBGP based SA-advt since 1. MBGP is stable, widely deployed, and very well understood 2. MBGP can provide policy framework missing in MSDP ( and it is also well understood) 3. No learning curve or additional time required to deploy one more protocol like MSDP 4. MSDP implementations are more buggy compared to MBGP 5. MSDP is supposed to be only interim. Any thoughts from the deployment side on this topic? Thanks, Nagesh > > > There were a few other things, but these were the main concerns. > BTW, what we were doing was attempting to find a way to free > providers from having to co-locate their RPs on a dense-mode > exchange point (i.e., get (S,G) state from outside their domain onto > their RPs so their customers could join those groups, w/o sharing > RPs). That was the (lost in the mist of history) design goal. > > Dave > > > According to Ali Boudani: > > > > > One reason: the timescales for change of active source indications are > > > much different than BGP was designed to carry. BGP wants to carry > > > data that doesn't change very often, e.g. see route dampening. Sources > > > can come and go at an arbitrary rate, so the rate of change of the > > > information is potentially much higher. > > > > can you specifie more, > > why should the timescales for change active source indications are much > > different.??? > > > > --------------B7643E2C07603C3C96B96AD4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
David Meyer wrote:

        Not sure about the history of this thread, but here's some
        of the history.
 
I  think you are addressing the core of this topic, which is, why we can't use MBGP instead of MSDP.
 
        First, we looked at putting SAs into BGP. I wanted to
        do this as a first thought since the MBGP/MSDP split
        effectively splits the control plane. However, this
        turned out to be a less than optimal solution for several
        reasons, not the least of which included:

        (i).    State

                The reason MSDP is periodic and not incremental
                (and originally non-caching) is that we were tryin
                to avoid explosion of (S,G) state. I guess we're
                not so worried about that (c.f. SSM). In addition,
                we had to somehow (attempt to) solve the bursty
                source problem.

Yes, indeed SSM seems to side-step this problem very well.
About the bursty sources: it seems to me that we add a lot of overhead to MSDP to solve this problem, and yet it is not clear if it is completely reliable.
 
        (ii).   BGP Stability

                I don't really want to argue that the dynamic nature
                of SA advertisements is going to help the stability
                of BGP (that is, of the global routing system). Neither
                do you, I would guess.
 

Is there info available to compare the time-scales of these two traffic types ( i.e SA-advt vs Unicast Route advt)? If so, that will be enlightening, and I'd urge anyone to post it.

If I want to analyze this, I'd have to consider in a given time, in a given network, the number of routes, the
rate at which these are changing. What are the assumptions about:
   1. Rate of unicast route change ( per route)
   2. Number of unicast routes in the network
   3. Rate of an average SA advt ( per S,G)
   4. Number of sources in the network.

My suspicion is that #4 is far less compared to #2, and also that #1 is far slower compared to #3. leading to an intereting question on where the trade-off lies.

So, unless we are talking about really short sessions and  much larger  number of sources than is typical, it is not clear to me that this would threaten BGP's stability.

And what about timescales for other types of MBGP traffic? ( VPNs, for example) 

 
        (iii).  Deployment

                Because of (i). and (ii). above, SAs in BGP would have been
                impossible to deploy (who would want to deploy a
                version of BGP that carried SAs? MBGP with SAFI \in {1,2}
                was hard enough).
 

I have a question: If some provider is starting to deploy interdomain Multicast from scratch ( anyone out there?), I'd think that it is far more attractive to deploy MBGP based SA-advt since
1. MBGP is stable, widely deployed, and very well understood
2. MBGP can provide policy framework missing in MSDP ( and it is also well understood)
3. No learning curve or additional time required to deploy one more protocol like MSDP
4. MSDP implementations are more buggy compared to MBGP
5. MSDP is supposed to be only interim.

Any thoughts from the deployment side on this topic?

Thanks,
Nagesh

 

        There were a few other things, but these were the main concerns.
        BTW, what we were doing was attempting to find a way to free
        providers from having to co-locate their RPs on a dense-mode
        exchange point (i.e., get (S,G) state from outside their domain onto
        their RPs so their customers could join those groups, w/o sharing
        RPs). That was the (lost in the mist of history) design goal.

        Dave
 

According to Ali Boudani:
>
> > One reason: the timescales for change of active source indications are
> > much different than BGP was designed to carry.  BGP wants to carry
> > data that doesn't change very often, e.g. see route dampening.  Sources
> > can come and go at an arbitrary rate, so the rate of change of the
> > information is potentially much higher.
>
> can you specifie more,
> why should the timescales for change active source indications are much
> different.???
>
>

--------------B7643E2C07603C3C96B96AD4-- From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Thu Apr 5 16:04:57 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 QAA13264 for ; Thu, 5 Apr 2001 16:04:56 -0400 (EDT) Received: from cisco.com (router.cisco.com [171.69.182.20]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA10623 for ; Thu, 5 Apr 2001 14:36:14 -0400 (EDT) Received: from localhost (selina@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA21687; Thu, 5 Apr 2001 14:36:57 -0400 (EDT) Message-Id: <200104051836.OAA21687@cisco.com> To: Ali Boudani cc: David Meyer , Bill Fenner , nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu Subject: Re: Why MSDP? In-reply-to: Message from of Thu Apr 5,2001 19:9 +0200 <3ACCA6D6.17122283@irisa.fr> Date: Thu, 05 Apr 2001 14:36:57 -0400 From: Selina Priestley I am just learning about Multicast, so folks correct me if I am wrong: I *believe* that MBGP carries the source networks that will be sending multicast traffic (there is no tree because BGP is basically fancy distance vector). These networks are announced in MBGP whenever the sources associated network is up, whether the source is sending traffic or not. This is used for reachability info only - how do I forward away from this source? or send joins/prunes toward the source? MSDP is used to send information about specific sources, *when they are actually sending traffic*. This is used to start building trees in the first place (assuming you have local receivers). Then you use the MBGP info to send your join to the source. Networks are up for days, weeks, maybe even months. Sources are sending traffic for hours tops. This may be what you're saying below, but I can't be sure. :) Selina >Hello, >I think I understand but just correct me if I am wrong. > >the multicast topology advertised by MBGP is not the Trees but it is just >advertising the network reachability of the connected multicast routers. that >mean instead of advertising all the routes in a domain , we just advertise the >routes between multicast routers and subnetworks. >MBGP is not advertising the trees in the domains and that is why we should sen >d >another kind messages when a source appers. because this source will construct > a >new multicast tree in the domain using PIM-SM or other protocol. >Of course, MBGP like BGP cant support a lot of changes in the topology in a >domain and that is why , multicast trees (reachability) should not transported >via MBGP. >we should found something else (and that is why we are using MSDP) > >Is that true? (I hope I am right :-) ) > >thanx >Ali > > From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Apr 5 17:41:17 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 RAA15239 for ; Thu, 5 Apr 2001 17:41:16 -0400 (EDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01301 for ; Thu, 5 Apr 2001 13:27:33 -0700 (PDT) Received: from glock (dhcp-161-44-19-51.cisco.com [161.44.19.51]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA12357; Thu, 5 Apr 2001 13:27:08 -0700 (PDT) Message-ID: <019901c0be0e$c9dbaad0$33132ca1@glock> From: "Stephen Sprunk" To: "Ali Boudani" , "David Meyer" Cc: "Bill Fenner" , , , , , , References: <200104051555.IAA15954@cisco.com> <3ACCA6D6.17122283@irisa.fr> Subject: Re: Why MSDP? Date: Thu, 5 Apr 2001 15:25:25 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Thus spake "Ali Boudani" > Hello, > I think I understand but just correct me if I am wrong. > > the multicast topology advertised by MBGP is not the Trees but it is just > advertising the network reachability of the connected multicast routers. > that mean instead of advertising all the routes in a domain , we just > advertise the routes between multicast routers and subnetworks. You're missing what MBGP does. For mcast forwarding, all routers need an RPF table. Normally, the RPF table is identical to the unicast (BGP) routing table; however, in some cases we want RPF and unicast to be different. For that, we have MBGP. > Of course, MBGP like BGP cant support a lot of changes in the topology > in a domain and that is why , multicast trees (reachability) should not > transported via MBGP. > we should found something else (and that is why we are using MSDP) Remember that the PIM-SM shared tree is limited to a single domain. To find sources outside your domain, you need a global shared tree; that's the purpose of MSDP. Think of the split between PIM and MSDP as similar to the split between ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and between routing domains. 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-1.cisco.com Thu Apr 5 17:41:42 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 RAA15258 for ; Thu, 5 Apr 2001 17:41:41 -0400 (EDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01125 for ; Thu, 5 Apr 2001 13:27:18 -0700 (PDT) Received: from glock (dhcp-161-44-19-51.cisco.com [161.44.19.51]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with SMTP id NAA12468; Thu, 5 Apr 2001 13:27:09 -0700 (PDT) Message-ID: <019a01c0be0e$ca6218e0$33132ca1@glock> From: "Stephen Sprunk" To: "Ali Boudani" , "Bill Fenner" Cc: , , , References: <200103222325.RAA13581@windsor.research.att.com> <3ACC8F04.12F658E1@irisa.fr> Subject: Re: Why MSDP? Date: Thu, 5 Apr 2001 15:27:01 -0500 Organization: Cisco Systems, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Thus spake "Ali Boudani" > > One reason: the timescales for change of active source indications > > are much different than BGP was designed to carry. BGP wants to > > carry data that doesn't change very often, e.g. see route dampening. > > Sources can come and go at an arbitrary rate, so the rate of change > > of the information is potentially much higher. > > can you specifie more, why should the timescales for change active > source indications are much different.??? BGP route advertisements are measured in days or months; MSDP source advertisements are measured in seconds. Also, the traffic patterns for the two are completely different. BGP only needs updates when networks (dis)connect to each other or when there is a critical link failure -- things that are fairly rare and relatively long-lived. MSDP needs an SA for every new mcast flow originated, and they can be as small as a single packet and rarely last more than a few hours. 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-1.cisco.com Thu Apr 5 18:42:12 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 SAA16039 for ; Thu, 5 Apr 2001 18:42:11 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA16577 for ; Thu, 5 Apr 2001 14:21:41 -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 f35LLdk08320 for ; Thu, 5 Apr 2001 14:21:39 -0700 (PDT) Received: from dino-pc.procket.com (flowpoint.procket.com [205.253.146.41]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f35LH4803963 for ; Thu, 5 Apr 2001 14:17:04 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id OAA02323; Thu, 5 Apr 2001 14:14:53 -0700 Date: Thu, 5 Apr 2001 14:14:53 -0700 Message-Id: <200104052114.OAA02323@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: ssprunk@cisco.com CC: aboudani@irisa.fr, dmm@cisco.com, fenner@research.att.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu In-reply-to: <019901c0be0e$c9dbaad0$33132ca1@glock> (ssprunk@cisco.com) Subject: Re: Why MSDP? References: <200104051555.IAA15954@cisco.com> <3ACCA6D6.17122283@irisa.fr> <019901c0be0e$c9dbaad0$33132ca1@glock> >> Think of the split between PIM and MSDP as similar to the split between >> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and >> between routing domains. I wouldn't go that far. Dino From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 5 20:38:59 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 UAA17019 for ; Thu, 5 Apr 2001 20:38:59 -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.9.3/8.9.1) with ESMTP id QAA06916 for ; Thu, 5 Apr 2001 16:30:11 -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 f35NVS809182 for ; Thu, 5 Apr 2001 16:31:28 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f35NRrw09900 for ; Thu, 5 Apr 2001 16:27:53 -0700 (PDT) Received: from tingle.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id SAA29780; Thu, 5 Apr 2001 18:22:02 -0500 Message-Id: <5.0.2.1.0.20010405181746.02a3bd98@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 18:19:26 -0500 To: Dino Farinacci From: Bill Nickless Subject: Re: Why MSDP? Cc: ssprunk@cisco.com, aboudani@irisa.fr, dmm@cisco.com, fenner@research.att.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu In-Reply-To: <200104052114.OAA02323@dino-pc.procket.com> References: <019901c0be0e$c9dbaad0$33132ca1@glock> <200104051555.IAA15954@cisco.com> <3ACCA6D6.17122283@irisa.fr> <019901c0be0e$c9dbaad0$33132ca1@glock> Mime-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- At 02:14 PM 4/5/2001 -0700, Dino Farinacci wrote: > >> Think of the split between PIM and MSDP as similar to the split between > >> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and > >> between routing domains. > > I wouldn't go that far. > >Dino Making sure I understand you here: MSDP is PIM-specific? === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQCVAwUBOsz9fqwgm7ipJDXBAQFBhwQAhl0FlwZhhXnvhQtGWVfBWlKIU+ZpAXDF 3LsV3euohtrJPH1WZf78bF550WxgiHoxHxvWFsSZ25qczNqw/m63LcO81yN4r0qq 3nLx03TdWVKzGlF61FqDYdjDsbe9wDk/XjFu9nyW3+57xVfxe193z0e0bp97k51l pOb9NDqmefg= =fwar -----END PGP SIGNATURE----- From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 5 21:43:24 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 VAA18646 for ; Thu, 5 Apr 2001 21:43:24 -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.9.3/8.9.1) with ESMTP id RAA13073 for ; Thu, 5 Apr 2001 17:36:17 -0700 (PDT) From: morehits@webmktplace.com 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 f360aFM09791 for ; Thu, 5 Apr 2001 17:36:15 -0700 (PDT) Received: from mail.webmktplace.com (webmktplace.com [207.0.63.9]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f360Vfw20312 for ; Thu, 5 Apr 2001 17:31:41 -0700 (PDT) Received: from web-script(nobody).webmktplace.com (207.0.63.9) by mail.webmktplace.com (8.9.3/8.9.3) with SMTP id f35NqUx24825 for ; Thu, 5 Apr 2001 19:52:31 -0400 To: ssm-interest@external.cisco.com Subject: ADV:NEED MORE WEBSITE TRAFFIC? Date: Thu, 5 Apr 2001 16:45:41 Message-Id: <681.125090.103110@unknown> Reply-To: morehits@webmktplace.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" **************************************************** To be removed from further mailings please respond with Remove in the subject line **************************************************** Dear Friend, Discover a new revolutionary way of promoting your website and generating insane amounts of traffic in as little as 48 hours. This brand new program takes one of the worlds oldest methods of promoting a business and applies it to the Internet. Now you can have more traffic, sell more products and generate more income in less time than it takes to even get your presence online. This new program is one of the strongest and most effective ways to generate targeted traffic to your site. If your one of those websites that has all the tools necessary to make money, but just doesn't have the traffic, we can help. If you have an interest in learning more about generate a large amount of traffic to your website in a short period of time please respond to this email with: YOUR NAME, PHONE# AND BEST TIME TO CALL TO: mailto:morehits@webmktplace.com A representative will return your call within 12 hours P.S. BE SURE TO ASK ABOUT OUR FREE REVOLUTIONARY PAY-PER-CLICK AFFILIATE PROGRAM. GS,INC 7657 Winnetka Ave Canoga Park Ca 91306 From owner-extdom.ssm-interest@rtp-msg-core-1.cisco.com Fri Apr 6 04:09:26 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 EAA06207 for ; Fri, 6 Apr 2001 04:09:25 -0400 (EDT) Received: from cisco.com (london.cisco.com [144.254.96.137]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA10495 for ; Fri, 6 Apr 2001 03:19:16 -0400 (EDT) Received: from ssimlo-w2k.cisco.com (ssimlo-isdn-home.cisco.com [10.49.135.226]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA06892; Fri, 6 Apr 2001 09:16:09 +0100 (BST) Message-Id: <4.3.2.7.2.20010406081027.027c3ef8@london.cisco.com> X-Sender: ssimlo@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Apr 2001 08:11:38 +0100 To: Bill Nickless , Dino Farinacci From: Steve Simlo Subject: Re: Why MSDP? Cc: ssprunk@cisco.com, aboudani@irisa.fr, dmm@cisco.com, fenner@research.att.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu In-Reply-To: <5.0.2.1.0.20010405181746.02a3bd98@pop.mcs.anl.gov> References: <200104052114.OAA02323@dino-pc.procket.com> <019901c0be0e$c9dbaad0$33132ca1@glock> <200104051555.IAA15954@cisco.com> <3ACCA6D6.17122283@irisa.fr> <019901c0be0e$c9dbaad0$33132ca1@glock> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 18:19 05/04/2001 -0500, Bill Nickless wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >At 02:14 PM 4/5/2001 -0700, Dino Farinacci wrote: > > >> Think of the split between PIM and MSDP as similar to the split between > > >> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and > > >> between routing domains. > > > > I wouldn't go that far. > > > >Dino > >Making sure I understand you here: MSDP is PIM-specific? Correct - MSDP is PIM SM specific....from: http://search.ietf.org/internet-drafts/draft-ietf-msdp-spec-08.txt snip The Multicast Source Discovery Protocol, MSDP, describes a mechanism to connect multiple PIM-SM domains together. Each PIM-SM domain uses its own independent RP(s) and does not have to depend on RPs in other domains. snip >=== >Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 >PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov > >-----BEGIN PGP SIGNATURE----- >Version: PGPfreeware 6.5.8 for non-commercial use > >iQCVAwUBOsz9fqwgm7ipJDXBAQFBhwQAhl0FlwZhhXnvhQtGWVfBWlKIU+ZpAXDF >3LsV3euohtrJPH1WZf78bF550WxgiHoxHxvWFsSZ25qczNqw/m63LcO81yN4r0qq >3nLx03TdWVKzGlF61FqDYdjDsbe9wDk/XjFu9nyW3+57xVfxe193z0e0bp97k51l >pOb9NDqmefg= >=fwar >-----END PGP SIGNATURE----- Steve Simlo Consulting Engineer Cisco Systems Ltd 3 The Square Stockley Park Uxbridge Middlesex UB11 1BN United Kingdom Direct Line: +44 20-8756 8435 Fax: +44-20-8756 8099 GSM: +44 7802-608 318 Home Office Tel: +44 20-8767 5886 Email: ssimlo@cisco.com Internal URL: http://wwwin-emea/FieldInfo/Consult/General/team/PersInfo/ssimlo.htm From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Apr 6 08:05:00 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 IAA07887 for ; Fri, 6 Apr 2001 08:05:00 -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.9.3/8.9.1) with ESMTP id EAA06552 for ; Fri, 6 Apr 2001 04:13:18 -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 f36BDEo08200 for ; Fri, 6 Apr 2001 04:13:14 -0700 (PDT) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f36BDOw14855 for ; Fri, 6 Apr 2001 04:13:24 -0700 (PDT) Received: from neserve0.corp.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQkjom15500; Fri, 6 Apr 2001 11:11:51 GMT Received: by neserve0.corp.us.uu.net id QQkjom09833; Fri, 6 Apr 2001 07:11:44 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Why MSDP? In-Reply-To: <4.3.2.7.2.20010406081027.027c3ef8@london.cisco.com> from Steve Simlo at "Apr 6, 2001 08:11:38 am" To: Steve Simlo Date: Fri, 6 Apr 2001 07:11:44 -0400 (EDT) CC: Bill Nickless , Dino Farinacci , ssprunk@cisco.com, aboudani@irisa.fr, dmm@cisco.com, fenner@research.att.com, nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit msdp could in theory be used to cross a pim-sm domain and connect two dvmrp domains. The fact that no sane vendor has implemented this functionality is beyond the scope of the definition of msdp. _J In the new year, Steve Simlo wrote: > At 18:19 05/04/2001 -0500, Bill Nickless wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > > > >At 02:14 PM 4/5/2001 -0700, Dino Farinacci wrote: > > > >> Think of the split between PIM and MSDP as similar to the split between > > > >> ISIS/OSPF/EIGRP/RIP and BGP -- we use different protocols within and > > > >> between routing domains. > > > > > > I wouldn't go that far. > > > > > >Dino > > > >Making sure I understand you here: MSDP is PIM-specific? > > Correct - MSDP is PIM SM specific....from: > > http://search.ietf.org/internet-drafts/draft-ietf-msdp-spec-08.txt > > snip > The Multicast Source Discovery Protocol, MSDP, describes a mechanism > to connect multiple PIM-SM domains together. Each PIM-SM domain uses > its own independent RP(s) and does not have to depend on RPs in other > domains. > snip > > > >=== > >Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 > >PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov > > > >-----BEGIN PGP SIGNATURE----- > >Version: PGPfreeware 6.5.8 for non-commercial use > > > >iQCVAwUBOsz9fqwgm7ipJDXBAQFBhwQAhl0FlwZhhXnvhQtGWVfBWlKIU+ZpAXDF > >3LsV3euohtrJPH1WZf78bF550WxgiHoxHxvWFsSZ25qczNqw/m63LcO81yN4r0qq > >3nLx03TdWVKzGlF61FqDYdjDsbe9wDk/XjFu9nyW3+57xVfxe193z0e0bp97k51l > >pOb9NDqmefg= > >=fwar > >-----END PGP SIGNATURE----- > > > Steve Simlo > Consulting Engineer > Cisco Systems Ltd > 3 The Square > Stockley Park > Uxbridge > Middlesex UB11 1BN > United Kingdom > > Direct Line: +44 20-8756 8435 > Fax: +44-20-8756 8099 > GSM: +44 7802-608 318 > Home Office Tel: +44 20-8767 5886 > > Email: ssimlo@cisco.com > Internal > URL: http://wwwin-emea/FieldInfo/Consult/General/team/PersInfo/ssimlo.htm > > > From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Apr 6 14:15: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 OAA16302 for ; Fri, 6 Apr 2001 14:15: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.9.3/8.9.1) with ESMTP id JAA13916 for ; Fri, 6 Apr 2001 09:22: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 f36GM7D12337 for ; Fri, 6 Apr 2001 09:22:08 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f36GISo29458 for ; Fri, 6 Apr 2001 09:18:28 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 842445; Fri, 06 Apr 2001 11:57:13 -0400 Message-ID: <3ACDE7F3.F2B54FC0@21rst-century.com> Date: Fri, 06 Apr 2001 11:59:45 -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: Selina Priestley CC: Ali Boudani , David Meyer , Bill Fenner , nagesh.chintada@alcatel.com, ssm-interest@external.cisco.com, pim@catarina.usc.edu, msdp@network-services.uoregon.edu, rcoltun@redback.com, ahuja@umich.edu Subject: Re: Why MSDP? References: <200104051836.OAA21687@cisco.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Let me give this a try. MBGP conveys information about the AS hop path that multicast traffic should follow. It says that, for example, for us (here at AS 16517) to reach 171.70.89.102 = dhcp-171-70-89-102.cisco.com multicasttech-2>show ip mbgp 171.70.89.102 BGP routing table entry for 171.68.0.0/14, version 899674 Paths: (2 available, best #2, table NULL) Flag: 0x208 Advertised to non peer-group peers: 192.168.1.2 145 24 1239 109 204.147.129.89 from 204.147.129.89 (204.147.128.136) Origin IGP, localpref 100, valid, external Community: 9503719 1239 109 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin IGP, metric 59, localpref 100, valid, external, best So, for us to get multicast traffic from this IP address, we send the join to AS 1239 (Sprint). You need MBGP as multicast traffic may need to follow a different route than unicast traffic. This is the case here : multicasttech-2>show ip bgp 171.70.89.102 BGP routing table entry for 171.68.0.0/14, version 5801427 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.1.2 701 109 157.130.46.53 from 157.130.46.53 (137.39.4.99) Origin IGP, localpref 100, valid, external, best 1239 1239 1239 109 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin IGP, metric 59, localpref 100, valid, external multicasttech-2> For unicast, our preferred route involves AS 701 (UUNET). Now, this is ROUTING. Routing does not convey information about traffic - BGP does not tell you if you have an email waiting. MBGP likewise does not tell you about sources. MSDP involves SOURCE DISCOVERY. We have sources here in AS 16517. We also have an RP. Each of our sources informs our RP of its existence. Our RP floods this info to our neighboring RP's, including the ones in Sprint, and they tell the ones in Cisco.com. When 171.70.89.102 wants to join one of our groups, which it did on Tuesday, it sends an IGMP message which triggers a PIM-SM join TO THE CISCO.COM RP. This RP knows about us, and so it sends a join to our source directly. The biggest advantage to this method is that you rely only on your RP for work. Since you presumably pay for your RP, this is not a problem. MSDP uses the MBGP routing info to only select SA messages that come from the right direction. (We, for example, would only accept CISCO.com SA messages that came through Sprint.) These Reverse Path Forwarding (RPF) checks for MSDP will likely be relaxed to make the system more robust - this was discussed a lot at the recent IETF. SSM shoves the source discovery out of the protocol entirely. You find out sources by other means (e-mail, webpage,...), and join the group and source directly. MSDP is not needed. I hate to say it, but this discussion would be more appropriate on the IPMULTICAST mailing list. Selina Priestley wrote: > I am just learning about Multicast, so folks correct me if I am wrong: > > I *believe* that MBGP carries the source networks that will be sending > multicast traffic (there is no tree because BGP is basically fancy > distance vector). These networks are announced in MBGP whenever the > sources associated network is up, whether the source is sending traffic > or not. This is used for reachability info only - how do I forward away > from this source? or send joins/prunes toward the source? > > MSDP is used to send information about specific sources, *when they > are actually sending traffic*. This is used to start building trees > in the first place (assuming you have local receivers). Then you use > the MBGP info to send your join to the source. > > Networks are up for days, weeks, maybe even months. Sources are sending > traffic for hours tops. > Not correct, or at least, not always true. Our sources have been up since October, 2000, and have had continuous multicast state going out since early November, except for a few hours of downtime due to computer problems. U Oregon and Broadcast.com, at least, have similar permanent groups. > > This may be what you're saying below, but I can't be sure. :) > > Selina > > >Hello, > >I think I understand but just correct me if I am wrong. > > > >the multicast topology advertised by MBGP is not the Trees but it is just > >advertising the network reachability of the connected multicast routers. that > >mean instead of advertising all the routes in a domain , we just advertise the > >routes between multicast routers and subnetworks. > >MBGP is not advertising the trees in the domains and that is why we should sen > >d > >another kind messages when a source appers. because this source will construct > > a > >new multicast tree in the domain using PIM-SM or other protocol. > >Of course, MBGP like BGP cant support a lot of changes in the topology in a > >domain and that is why , multicast trees (reachability) should not transported > >via MBGP. > >we should found something else (and that is why we are using MSDP) > > > >Is that true? (I hope I am right :-) ) > > > >thanx > >Ali > > > > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@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-2.cisco.com Mon Apr 16 15:35: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 PAA12281 for ; Mon, 16 Apr 2001 15:35: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.9.3/8.9.1) with ESMTP id KAA23596 for ; Mon, 16 Apr 2001 10:31:31 -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 f3GHV9a04982 for ; Mon, 16 Apr 2001 10:31:09 -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 f3GHVGZ10597 for ; Mon, 16 Apr 2001 10:31:16 -0700 (PDT) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Mon, 16 Apr 2001 10:27:57 -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 G5FQDT8P; Mon, 16 Apr 2001 10:27:51 -0700 From: Supratik Bhattacharyya To: ssm-interest@external.cisco.com Message-ID: <3ADB2BC0.86318DE2@sprintlabs.com> Date: Mon, 16 Apr 2001 10:28:32 -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: Meeting minutes - 50th IETF. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks are due to Tom Pusateri for agreeing to be the scribe (under severe coercion :-) ) --Supratik ---------------------------------------------------------------------- SSM working group minutes March 2001 IETF Minneapolis, MN Updates on existing ssm drafts holbrook-ssm-arch 02 Hugh Holbrook gave update Addressed ipv6 Added examples and address range Ready for wg last call for proposed standard bhattach-pim-ssm Supratik gave update Added IPv6 and security discussion Remaining: conformance with the architecture Headed for informational Need comments holbrook-idmr-igmpv-v3-ssm-01 Hugh Holbrook gave update New changes IGMP module should have configuration option for SSM ranges Default to IANA range Must allow for manual config IGMPv3 hosts MUST not transition to exclude mode when it runs out of resources. Now in base igmpv3 spec. This doc will move to new MAGMA working group should it be approved. He-mixed-igmp-proxy He gave update Current igmp proxying draft only addresses behavior for same version proxying With mixed versions, there are some differences : v3 to v2 - v2 on upstream, v3 on downstream v3 joins translated to v2 joins forwarding is still done based on v3 info v2 to v3 - proxy should drop v2 joins in ssm range Hugh pointed out that faking v3 when you have v2 upstream routers is a configuration bug. Dave Thaler gave an example of where proxy must look at source address and not just transparently send upstream to router when source is not toward router. Hal Sandick would like to see transition section updated before last call. draft-kim-ssm-hierarchical-scheme-00 Myung-ki Shin talked about their draft SSM ignores deployment issues in inter-domain Hierarchical considerations should be considered Automatic tunneling between border gateway and source not on multicast network Receiver requirements no changes required Border gateway router requirements sends unicast registration to source Source requirements source receives registration message and tunnels ssm data to all border gateway routers Dave Meyer Suggested that SSM doesn't have a scaling problem. Concerned that this draft solves a problem we don't have consensus that this is an incremental deployment solution that should be discussed in MBONED. DNS for SSM Hugh summarized discussion on mailing list Jeff Schoch : mcast.example.com IN A 10.10.10.42 radio.mcast.example.com IN A 232.1.1.1 Dino : radio.example.com IN AA 10.1.1.1.232.1.1.1 Toerless : just use SDP draft-schoch-dns-ssm : Jeff Schoch gave a talk on his proposal : Little change to existing infrastructure, keep it simple Proposal: group.source.domain-name Joel objected to this method : doesn't give you the info you really need. SDP does have all the info you need, not just the IP addresses. Dave Thaler agreed with Joel Hugh repeated that on the mailing list it was mentioned that this might be useful for debugging. Dave Meyer did not like the idea of putting semantic context in the DNS. Off topic, Dave would like us to use ASM (Any source multicast) instead of ISM (Internet standard multicast) Ross Finlayson said use SIM (source independent multicast) Hugh polled the working group on AA records. Dave Meyer still objected. Joel said while people may want a replacement for SDR, we don't really need one. Multicast is no different than unicast in this sense. Hugh said others thought it might be useful for mtrace Marshall didn't think it was ever useful to have names to map to group and source. Jeremy Hall said that people with access to sources aren't the same people with access to DNS. No conclusion reached, the discussion is to be taken to the mailing list. Charter Bashing Charter item have been fulfilled. There are no new action items We expect this is the last meeting. From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Tue Apr 17 16:38:39 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16308 for ; Tue, 17 Apr 2001 16:38:38 -0400 (EDT) Received: from holbrook-laptop.cisco.com (dhcp-171-69-41-28.cisco.com [171.69.41.28]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA15372; Tue, 17 Apr 2001 12:10:56 -0700 (PDT) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id CD21EC3A71; Tue, 17 Apr 2001 12:11:04 -0700 (PDT) From: Hugh Holbrook To: ssm-interest@external.cisco.com Cc: holbrook@cisco.com, Supratik Bhattacharyya In-reply-to: <3ADB2AB7.35D119A7@sprintlabs.com> Subject: [CORRECTION] 50th IETF Source Specific Multicast WG SLIDES Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20010417191104.CD21EC3A71@holbrook-laptop.cisco.com> Date: Tue, 17 Apr 2001 12:11:04 -0700 (PDT) Slides from the SSM working group meeting at the 50th IETF in Minneapolis are available at: http://dsg.stanford.edu/~holbrook/ietf/mpls/ssm-slides/ (html) http://dsg.stanford.edu/~holbrook/ietf/mpls/ssm-slides.tgz (tarball) Jeff's slides: http://dsg.stanford.edu/~holbrook/ietf/mpls/schoch-slides.ppt Haixiang's slides: http://dsg.stanford.edu/~holbrook/ietf/mpls/he-slides.ppt Thanks, -Hugh and Supratik (SSM working group chairs) From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 19 09:29:16 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 JAA10763 for ; Thu, 19 Apr 2001 09:29:16 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id FAA20708 for ; Thu, 19 Apr 2001 05:11:12 -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 f3JCCXD21778 for ; Thu, 19 Apr 2001 05:12:33 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3JCBS519583 for ; Thu, 19 Apr 2001 05:11:28 -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 NAA27390 for ; Thu, 19 Apr 2001 13:57:30 +0200 (MET DST) Message-ID: <3ADED2B1.D226E5ED@irisa.fr> Date: Thu, 19 Apr 2001 13:57:37 +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: Address allocation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I didnt understand the issue aof address allocation in ssm.? we have a source S and a receiver say R want to recieve informations from S. So in that case R should inform its DR by using IGMPv3. How R knows that he is a member of a group G and how is G is allocated? is the address g is allocated by the application ?? I just want to know the complete process because it is not clear in the drafts. thanx From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 19 10:30:57 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11660 for ; Thu, 19 Apr 2001 10:30: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.9.3/8.9.1) with ESMTP id GAA10881 for ; Thu, 19 Apr 2001 06:10:38 -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 f3JDAWd29817 for ; Thu, 19 Apr 2001 06:10:32 -0700 (PDT) Received: from sippie.star2.net ([65.89.75.10]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3JDAmG22291 for ; Thu, 19 Apr 2001 06:10:49 -0700 (PDT) Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Thu, 19 Apr 2001 09:06:49 -0400 Received: from 21rst-century.com (1Cust240.tnt4.lorton.va.da.uu.net [63.24.102.240]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 19 Apr 2001 09:19:29 -0400 Message-ID: <3ADEE3D0.FFB3D963@21rst-century.com> Date: Thu, 19 Apr 2001 09:10:40 -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 MIME-Version: 1.0 To: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: Address allocation References: <3ADED2B1.D226E5ED@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Ali; Ali Boudani wrote: > > I didnt understand the issue aof address allocation in ssm.? > we have a source S and a receiver say R want to recieve informations > from S. > So in that case R should inform its DR by using IGMPv3. > How R knows that he is a member of a group G and how is G is allocated? R knows he is a member of the group because he joined it ? If you are asking "how does R know that a group exists to be joined ?", this is done "out of band" - that is, you will know about SSM groups because you have been informed about them in some other fashion, such as by clicking on a button on a web page, or in an e-mail, etc., etc. The address G is allocated by the source. There are basically no restrictions on G, except that it has to be kept in the 232/8 address range (for multicasts to the general Internet) and, if you are sourcing more than one group from the same IP address, S, you have to give them unique group addresses, G. Also, from http://www.ietf.org/internet-drafts/draft-holbrook-ssm-arch-02.txt The network service identified by (S,G), for SSM address G and source host address S, is referred to as a "channel." So the use of "Group" is considered obsolete ! Again, from the above draft : The following table summarizes the terminology: Service Model: Any-Source Source-Specific Network Abstraction: group channel Identifier: G S,G Receiver Operations: join, leave subscribe, unsubscribe (Personally, I regard unnecessary changes in widely used terminology to be unwise, but the rough consensus seems to have gone otherwise.) > is the address g is allocated by the application ?? > > I just want to know the complete process because it is not clear in the > drafts. > thanx Regards Marshall 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 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 Thu Apr 19 11:31:07 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12773 for ; Thu, 19 Apr 2001 11:31:07 -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.9.3/8.9.1) with ESMTP id GAA02807 for ; Thu, 19 Apr 2001 06:55: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 f3JDt4u22444 for ; Thu, 19 Apr 2001 06:55:04 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3JDrt500326 for ; Thu, 19 Apr 2001 06:53:55 -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 PAA08473; Thu, 19 Apr 2001 15:41:40 +0200 (MET DST) Message-ID: <3ADEEB1C.937D0E3F@irisa.fr> Date: Thu, 19 Apr 2001 15:41:48 +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: tme@21rst-century.com CC: ssm-interest@external.cisco.com Subject: Re: Address allocation References: <3ADED2B1.D226E5ED@irisa.fr> <3ADEE3D0.FFB3D963@21rst-century.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, If all sources use the same G , there is no meaning of multicast group. because S1 ....Sn can use the same address G and in that case all the multicast world is using the same address G. So we can maybe just assign or allocate a single multicast address to all the multicast recievers in the internet and use the S just to differciate between them. Isnt true?? Ali Marshall Eubanks wrote: > Hello Ali; > > Ali Boudani wrote: > > > > I didnt understand the issue aof address allocation in ssm.? > > we have a source S and a receiver say R want to recieve informations > > from S. > > So in that case R should inform its DR by using IGMPv3. > > How R knows that he is a member of a group G and how is G is allocated? > > R knows he is a member of the group because he joined it ? If you > are asking "how does R know that a group exists to be joined ?", > this is done "out of band" - that is, you will know about SSM groups > because you have been informed about them in some other fashion, such > as by clicking on a button on a web page, or in an e-mail, etc., etc. > > The address G is allocated by the source. There are basically no > restrictions on G, except that it has to be kept in the 232/8 > address range (for multicasts to the general Internet) and, > if you are sourcing more than one group from the same IP address, S, > you have to give them unique group addresses, G. > > Also, from > http://www.ietf.org/internet-drafts/draft-holbrook-ssm-arch-02.txt > > The network service > identified by (S,G), for SSM address G and source host address S, is > referred to as a "channel." > > So the use of "Group" is considered obsolete ! > > Again, from the above draft : > > The following table summarizes the terminology: > > Service Model: Any-Source Source-Specific > Network Abstraction: group channel > Identifier: G S,G > Receiver Operations: join, leave subscribe, unsubscribe > > (Personally, I regard unnecessary changes in widely used terminology to be > unwise, but the rough consensus seems to have gone otherwise.) > > > is the address g is allocated by the application ?? > > > > I just want to know the complete process because it is not clear in the > > drafts. > > thanx > > Regards > Marshall 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 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 Thu Apr 19 11:31:10 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12783 for ; Thu, 19 Apr 2001 11:31:09 -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.9.3/8.9.1) with ESMTP id GAA00557 for ; Thu, 19 Apr 2001 06:50: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 f3JDob402610 for ; Thu, 19 Apr 2001 06:50:37 -0700 (PDT) Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3JDnW528200 for ; Thu, 19 Apr 2001 06:49:32 -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 PAA08015; Thu, 19 Apr 2001 15:37:17 +0200 (MET DST) Message-ID: <3ADEEA14.FF202EA7@irisa.fr> Date: Thu, 19 Apr 2001 15:37:24 +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: tme@21rst-century.com CC: ssm-interest@external.cisco.com Subject: Re: Address allocation References: <3ADED2B1.D226E5ED@irisa.fr> <3ADEE3D0.FFB3D963@21rst-century.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok, then what is the meaning of S,G ?? the S, G is not useful also and we should use only S. I should be interrested just about S and I dont care about G .. The channel cant mean S,G because S cant generate more than one G , isnt right?? Thanx From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Apr 19 11:55:52 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 LAA13286 for ; Thu, 19 Apr 2001 11:55:50 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA07164 for ; Thu, 19 Apr 2001 07:33:03 -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 f3JEWeM29898 for ; Thu, 19 Apr 2001 07:32:40 -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 f3JESkT29196 for ; Thu, 19 Apr 2001 07:28:47 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 850899; Thu, 19 Apr 2001 10:10:33 -0400 Message-ID: <3ADEF2E8.DEBE4F17@21rst-century.com> Date: Thu, 19 Apr 2001 10:15:05 -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: Ali Boudani CC: ssm-interest@external.cisco.com Subject: Re: Address allocation References: <3ADED2B1.D226E5ED@irisa.fr> <3ADEE3D0.FFB3D963@21rst-century.com> <3ADEEB1C.937D0E3F@irisa.fr> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ali Boudani wrote: > Hello, > If all sources use the same G , there is no meaning of multicast group. > because S1 ....Sn can use the same address G and in that case all the > multicast world is using the same address G. So we can maybe just assign or > allocate a single multicast address to all the multicast recievers in the > internet and use the S just to differciate between them. > Isnt true?? > Ali What you say is true in principle. This would cause problems in practice on Ethernet links, because of the mapping between group addresses and MAC addresses is not unique - see the discussion at the end of http://www.multicasttech.com/faq/multicast_faq.html Also, remember, for any given S, the sources must be unique. We (for example) source 3 to 6 G for each S. But SSM basically does remove any need to assign or allocate group addresses. Note that not all multicast applications will migrate to SSM. > > > Marshall Eubanks wrote: > > > Hello Ali; > > > > Ali Boudani wrote: > > > > > > I didnt understand the issue aof address allocation in ssm.? > > > we have a source S and a receiver say R want to recieve informations > > > from S. > > > So in that case R should inform its DR by using IGMPv3. > > > How R knows that he is a member of a group G and how is G is allocated? > > > > R knows he is a member of the group because he joined it ? If you > > are asking "how does R know that a group exists to be joined ?", > > this is done "out of band" - that is, you will know about SSM groups > > because you have been informed about them in some other fashion, such > > as by clicking on a button on a web page, or in an e-mail, etc., etc. > > > > The address G is allocated by the source. There are basically no > > restrictions on G, except that it has to be kept in the 232/8 > > address range (for multicasts to the general Internet) and, > > if you are sourcing more than one group from the same IP address, S, > > you have to give them unique group addresses, G. > > > > Also, from > > http://www.ietf.org/internet-drafts/draft-holbrook-ssm-arch-02.txt > > > > The network service > > identified by (S,G), for SSM address G and source host address S, is > > referred to as a "channel." > > > > So the use of "Group" is considered obsolete ! > > > > Again, from the above draft : > > > > The following table summarizes the terminology: > > > > Service Model: Any-Source Source-Specific > > Network Abstraction: group channel > > Identifier: G S,G > > Receiver Operations: join, leave subscribe, unsubscribe > > > > (Personally, I regard unnecessary changes in widely used terminology to be > > unwise, but the rough consensus seems to have gone otherwise.) > > > > > is the address g is allocated by the application ?? > > > > > > I just want to know the complete process because it is not clear in the > > > drafts. > > > thanx > > > > Regards > > Marshall 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 http://www.on-the-i.com > > > > Test your network for multicast : http://www.multicasttech.com/mt/ -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@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-1.cisco.com Thu Apr 19 12:53:03 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 MAA14313 for ; Thu, 19 Apr 2001 12:52:58 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06894 for ; Thu, 19 Apr 2001 08:24:16 -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 f3JFOB607349 for ; Thu, 19 Apr 2001 08:24:11 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3JFJM515998 for ; Thu, 19 Apr 2001 08:19:22 -0700 (PDT) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA06507; Thu, 19 Apr 2001 08:15:19 -0700 (PDT) Received: from localhost (shep@localhost) by maroon.jnpr.net (8.9.3/8.9.3) with ESMTP id IAA10678; Thu, 19 Apr 2001 08:15:19 -0700 (PDT) (envelope-from shep@juniper.net) X-Authentication-Warning: maroon.jnpr.net: shep owned process doing -bs Date: Thu, 19 Apr 2001 08:15:19 -0700 (PDT) From: Gregory Shepherd X-Sender: shep@maroon.jnpr.net To: Ali Boudani cc: tme@21rst-century.com, ssm-interest@external.cisco.com Subject: Re: Address allocation In-Reply-To: <3ADEEA14.FF202EA7@irisa.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ali, Yes, S CAN generate more than one G and does. Content houses would hit a scaling limit if each stream required a unique S. Greg On Thu, 19 Apr 2001, Ali Boudani wrote: > Ok, > then what is the meaning of S,G ?? > the S, G is not useful also and we should use only S. > I should be interrested just about S and I dont care about G .. > The channel cant mean S,G because S cant generate more than one G , isnt > right?? > Thanx > > From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Apr 19 13:51:48 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 NAA15261 for ; Thu, 19 Apr 2001 13:51:48 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22766 for ; Thu, 19 Apr 2001 09:27:50 -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 f3JGRiU13103 for ; Thu, 19 Apr 2001 09:27:45 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f3JGRcT17124 for ; Thu, 19 Apr 2001 09:27:39 -0700 (PDT) Received: from msablic ([62.172.151.5]) by alpo.casc.com (8.9.1a/8.9.1) with SMTP id MAA16040; Thu, 19 Apr 2001 12:13:07 -0400 (EDT) Message-ID: <00f501c0c8eb$9f244d00$0597ac3e@ukip> From: "Mladen Sablic" To: "Ali Boudani" , Cc: References: <3ADED2B1.D226E5ED@irisa.fr> <3ADEE3D0.FFB3D963@21rst-century.com> <3ADEEB1C.937D0E3F@irisa.fr> Subject: Re: Address allocation Date: Thu, 19 Apr 2001 17:13:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit > Hello, > If all sources use the same G , there is no meaning of multicast group. > because S1 ....Sn can use the same address G and in that case all the > multicast world is using the same address G. So we can maybe just assign or > allocate a single multicast address to all the multicast recievers in the > internet and use the S just to differciate between them. > Isnt true?? > Ali Ali, If you used only S to differentiate between SSM sources then ALL multicast packets from that source would go to ALL the receivers interested in S. By having channels (S,G) one can have (in SSM range) 2^24 independent multicast packet streams from one source each going to a independent set of receivers. Hence you can have receiver interested in (S,G1) & not in (S,G2) and each (S,G) is likely to have a chunk of bandwidth associated with it and bandwidth is likely to be a limited resource at the receiver end. By having (S,G) you control bandwidth at the expense of router memory which has to store state for each (S,G) passing through it. Mladen From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Apr 19 14:10:48 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 OAA15555 for ; Thu, 19 Apr 2001 14:10:48 -0400 (EDT) Received: from cisco.com (london.cisco.com [144.254.96.137]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA09151 for ; Thu, 19 Apr 2001 09:47:56 -0700 (PDT) Received: from ssimlo-w2k.cisco.com (ssimlo-isdn-home.cisco.com [10.49.158.250]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA06732; Thu, 19 Apr 2001 17:47:48 +0100 (BST) Message-Id: <4.3.2.7.2.20010419173308.029528a8@london.cisco.com> X-Sender: ssimlo@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Apr 2001 17:34:20 +0100 To: Ali Boudani , tme@21rst-century.com From: Steve Simlo Subject: Re: Address allocation Cc: ssm-interest@external.cisco.com In-Reply-To: <3ADEEA14.FF202EA7@irisa.fr> References: <3ADED2B1.D226E5ED@irisa.fr> <3ADEE3D0.FFB3D963@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed A Source can generate many IPmc discrete groups Gi and each will be a separate SSM Channel: (S,G1), (S,G2)....etc etc At 15:37 19/04/2001 +0200, Ali Boudani wrote: >Ok, >then what is the meaning of S,G ?? >the S, G is not useful also and we should use only S. >I should be interrested just about S and I dont care about G .. >The channel cant mean S,G because S cant generate more than one G , isnt >right?? >Thanx Steve Simlo Consulting Engineer Cisco Systems Ltd 3 The Square Stockley Park Uxbridge Middlesex UB11 1BN United Kingdom Direct Line: +44 20-8756 8435 Fax: +44-20-8756 8099 GSM: +44 7802-608 318 Home Office Tel: +44 20-8767 5886 Email: ssimlo@cisco.com Internal URL: http://wwwin-emea/FieldInfo/Consult/General/team/PersInfo/ssimlo.htm From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 19 18:07:17 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 SAA19068 for ; Thu, 19 Apr 2001 18:07:12 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14459 for ; Thu, 19 Apr 2001 13:44:24 -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 f3JKjjj08176 for ; Thu, 19 Apr 2001 13:45:45 -0700 (PDT) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by proxy2.cisco.com (8.11.2/8.11.2) with SMTP id f3JKid502527 for ; Thu, 19 Apr 2001 13:44:40 -0700 (PDT) Received: (qmail 18980 invoked from network); 19 Apr 2001 20:37:40 -0000 Received: from useraq80.uk.uudial.com (HELO vaionote) (62.188.136.140) by smtp-1.dial.pipex.com with SMTP; 19 Apr 2001 20:37:40 -0000 Message-ID: <00d801c0c910$874e76e0$729cbc3e@vaionote> Reply-To: "Tony Ballardie" From: "Tony Ballardie" To: Cc: Subject: SSM, RTCP, SAP Date: Thu, 19 Apr 2001 21:36:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit What's the current thinking about handling RTP apps with SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)? Similarly, what about (global) SAP? Given that SAP comes under the category of "bootstrap" (I guess), wouldn't it be an idea to RPF flood SAP (minus the prune), and not incur any state for that flood? Such a flood would result in SAP announcements flowing over redundant paths, but a) they're infrequent, b) all SDRs want them within the flood (mcast) scope, c) they're bootstrap so they fit within a flood model. So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells routers not to create fwd state for this packet?? I'm not suggesting doing the same for RTCP RRs, since they don't fall under bootstrap, and require sender/member-constrained distribution. thoughts? Tony From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Thu Apr 19 18:16:15 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 SAA19117 for ; Thu, 19 Apr 2001 18:16:14 -0400 (EDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA24586; Thu, 19 Apr 2001 13:59:27 -0700 (PDT) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA15453; Thu, 19 Apr 2001 13:59:27 -0700 (PDT) Message-Id: <200104192059.NAA15453@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: "Tony Ballardie" cc: ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu Subject: Re: SSM, RTCP, SAP In-Reply-To: Your message of "Thu, 19 Apr 2001 21:36:28 BST." <00d801c0c910$874e76e0$729cbc3e@vaionote> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Apr 2001 13:59:27 -0700 From: Lorenzo Vicisano For RTCP, the idea floating around was to unicast the RRs back to the source and having the source echoing them back in the multicast session (either the report themselves or some digested summary of them). I don't know if this was ever specified 'though. I don't know of anything similar for SAP, but I don't think we should re-invent an ad-hoc routing protocol just for this. We should either use the existing ASM multicast service, if present, or SSM + application modifications (e.g. a set of relays that accept unicast SAP messages and remulticast them. Relays will have all to listen to each other announcements .. ect.. there are scalability concerns but seems feasible). Lorenzo > What's the current thinking about handling RTP apps with > SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)? > > Similarly, what about (global) SAP? > > Given that SAP comes under the category of "bootstrap" (I guess), wouldn't > it be an idea to RPF flood SAP (minus the prune), and not incur any state > for that flood? Such a flood would result in SAP announcements flowing > over redundant paths, but a) they're infrequent, b) all SDRs want them > within the flood (mcast) scope, c) they're bootstrap so they fit within > a flood model. > > So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells > routers not to create fwd state for this packet?? > > I'm not suggesting doing the same for RTCP RRs, since they don't > fall under bootstrap, and require sender/member-constrained distribution. > > thoughts? > > Tony > From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 19 19:21:03 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19678 for ; Thu, 19 Apr 2001 19:21:03 -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.9.3/8.9.1) with ESMTP id PAA07487 for ; Thu, 19 Apr 2001 15:15:35 -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 f3JMFU501274 for ; Thu, 19 Apr 2001 15:15:30 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3JMFkG15526 for ; Thu, 19 Apr 2001 15:15:46 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0BD484CED9; Thu, 19 Apr 2001 18:10:27 -0400 (EDT) Received: from research.att.com ([135.197.2.51]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA26216; Thu, 19 Apr 2001 18:10:25 -0400 (EDT) Sender: julian@research.att.com Message-ID: <3ADF61DE.4A2484E6@research.att.com> Date: Thu, 19 Apr 2001 15:08:30 -0700 From: Julian Chesterfield Organization: AT&T Labs X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Ballardie Cc: Lorenzo Vicisano , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu Subject: Re: SSM, RTCP, SAP References: <200104192059.NAA15453@lorenzo-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I submitted a draft to the AVT group to specify a unicast mechanism for RTCP RRs back to the sender. Originally this was intended just for SSM, but discussions in Minneapolis indicated there is interest for a more generic unicast feedback. Currently, the intention is to specify the method indicated by Lorenzo, although a summarised reporting method in addition is being considered to cut down on some of the information for large scale groups. The original draft is 'draft-chesterfield-avt-rtcpssm-00.txt'. Comments from the meeting have yet to be included in a new release. Thanks, Julian Chesterfield > For RTCP, the idea floating around was to unicast the RRs back to > the source and having the source echoing them back in the multicast > session (either the report themselves or some digested summary of them). > I don't know if this was ever specified 'though. > > I don't know of anything similar for SAP, but I don't think we should > re-invent an ad-hoc routing protocol just for this. We should either > use the existing ASM multicast service, if present, or SSM + application > modifications (e.g. a set of relays that accept unicast SAP messages and > remulticast them. Relays will have all to listen to each other > announcements .. ect.. there are scalability concerns but seems feasible). > > Lorenzo > > > What's the current thinking about handling RTP apps with > > SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)? > > > > Similarly, what about (global) SAP? > > > > Given that SAP comes under the category of "bootstrap" (I guess), wouldn't > > it be an idea to RPF flood SAP (minus the prune), and not incur any state > > for that flood? Such a flood would result in SAP announcements flowing > > over redundant paths, but a) they're infrequent, b) all SDRs want them > > within the flood (mcast) scope, c) they're bootstrap so they fit within > > a flood model. > > > > So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells > > routers not to create fwd state for this packet?? > > > > I'm not suggesting doing the same for RTCP RRs, since they don't > > fall under bootstrap, and require sender/member-constrained distribution. > > > > thoughts? > > > > Tony > > From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 19 19:54:13 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19959 for ; Thu, 19 Apr 2001 19:54:12 -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.9.3/8.9.1) with ESMTP id PAA17757 for ; Thu, 19 Apr 2001 15:35:18 -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 f3JMZHn04347 for ; Thu, 19 Apr 2001 15:35:17 -0700 (PDT) Received: from sippie.star2.net ([65.89.75.10]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3JMVjG21715 for ; Thu, 19 Apr 2001 15:31:45 -0700 (PDT) Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Thu, 19 Apr 2001 18:27:44 -0400 Received: from 21rst-century.com (1Cust143.tnt2.lorton.va.da.uu.net [63.23.103.143]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Thu, 19 Apr 2001 18:40:38 -0400 Message-ID: <3ADF6745.EFB1C853@21rst-century.com> Date: Thu, 19 Apr 2001 18:31:35 -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 MIME-Version: 1.0 To: Lorenzo Vicisano CC: Tony Ballardie , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield Subject: Re: SSM, RTCP, SAP References: <200104192059.NAA15453@lorenzo-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Lorenzo; Julian's draft covers this : draft-chesterfield-avt-rtcpssm-00.txt - and I think it has merit if you want to run many to many type services using SSM. I will append at the bottom what I wrote to the rem-conf list about my thoughts about SSM RTCP for very large groups. I apologize for the redundancy - this is really a AVT issue. Lorenzo Vicisano wrote: > > For RTCP, the idea floating around was to unicast the RRs back to > the source and having the source echoing them back in the multicast > session (either the report themselves or some digested summary of them). > I don't know if this was ever specified 'though. > > I don't know of anything similar for SAP, but I don't think we should > re-invent an ad-hoc routing protocol just for this. We should either > use the existing ASM multicast service, if present, or SSM + application > modifications (e.g. a set of relays that accept unicast SAP messages and > remulticast them. Relays will have all to listen to each other > announcements .. ect.. there are scalability concerns but seems feasible). > IMHO this should not be a new protocol - it could easily be handled at the application layer. Running these relay's sounds like a commercial matter to me. I would NOT add any router type support for this. Marshall > Lorenzo > > > What's the current thinking about handling RTP apps with > > SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)? > > > > Similarly, what about (global) SAP? > > > > Given that SAP comes under the category of "bootstrap" (I guess), wouldn't > > it be an idea to RPF flood SAP (minus the prune), and not incur any state > > for that flood? Such a flood would result in SAP announcements flowing > > over redundant paths, but a) they're infrequent, b) all SDRs want them > > within the flood (mcast) scope, c) they're bootstrap so they fit within > > a flood model. > > > > So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells > > routers not to create fwd state for this packet?? > > > > I'm not suggesting doing the same for RTCP RRs, since they don't > > fall under bootstrap, and require sender/member-constrained distribution. > > > > thoughts? > > > > Tony > > --------- Subject: Re: RTT estimation for multicast Date: Mon, 16 Apr 2001 12:27:07 -0400 Let's get specific. We are multicasting 3 x 38 samples (packets) per second at our high data rate. For now we are using standard RTCP RR's. For licensing and advertising purposes it is essential that any receiver report interval be kept to about 100 seconds or less. (You might push that by a factor of 2, maybe, but this will really start to impact on the business utility of these reports. 100 seconds seems a good upper bound on this.) Our receiver reports include reports on at most 3 separate substreams, so they are in length IP (4 x 32 bits) + UDP (2 x 32 bits) + RR header (2 x 32 bits) + 3 x (6 x 32 bits) = 26 x 32 bits = 832 bits or 104 bytes. If we assume a minimum reporting rate of 0.01 Hz (i.e., one per 100 seconds) then Audience Size | Minimum Bit Rate Returned 1000 8 kbps 10,000 80 kbps 100,000 800 kbps 1,000,000 8 mbps Now, the receiver report RTCP packet basically only includes low order information about packet loss and jitter. (And jitter is frequently trashed anyway.) If we were sending packets to Mars over a deep space link, this would be sufficient to tell us everything we might want to know about packet losses. We're not, and recently certain non-random packet loss patterns (see http://www.multicasttech.com/rr/u_oregon.12_apr.gif for an example ) have convinced me that more information needs to be supplied. As we discussed briefly when you came over to our offices, one way of doing this would be to send a bit pattern for every packet that should have been received during the RR interval. Suppose, for example, that you are sending 38 packets per second, and the RR interval is 100 seconds. Then the RR will cover 3800 packets (and will completely obscure the pattern shown in u_oregon.12_apr.gif). You could then send 3800 bits (or a little fewer, as packets that should have arrived after the last packet that did arrive will of necessity be missed), in the form 11110111110111111111011111000000000001 etc., where 1 means the packet was received, 0 means it wasn't (this represents one second of traffic, btw.) If you send this naively, as such a bit pattern, then the RR packet will be ~ 832 bits + (3 x 3800 bits) = 12,232 bits or 1529 bytes. Now the minimum returned bit rate becomes Audience Size | Minimum Bit Rate Returned 1000 120 kbps 10,000 1.2 mbps 100,000 12 mbps 1,000,000 122 mbps This is a real hit, and suggests that more thought should be given to this area - maybe the loss bit patterns could be compressed. either losslessly or lossily, say by applying a Walsh transform and only sending a certain number of coefficients in order of size, or by sending the location of the largest continuous block of dropped packet, by using runs of zeros and ones or by some other means. (A different means would be to have the source inform the sender in the stream that the RR report rate should be changed.) In any case, for an audience size of 100,000, the RTCP RR bit rate will be _at least_ order 1 megabit per second. Now, for a broadcaster receiving SSM receiver reports, that's OK. Anyone with that size audience can afford that much bandwidth. If we then set up a SSM group sending out 1 mbps of receiver reports, who would want to receive it ? Who would want to get that much bandwidth ? My guess is, no actual receivers, and very few monitoring groups. My assumption is that both from the broadcasters end and the monitoring groups end, some aggregation (compression) would be desired. The one that came to our minds was to average loss on a per AS basis, as receivers tend to be (so far) highly clustered in terms of ASNs. I think that you will find strong resistance on the part of broadcasters to sharing all information (including IP addresses) for all receivers at all time to everyone. This information is simply too valuable to assume that this will fly. (Seen any RR from Real Networks lately ?) I do not think that these kind of aggregated RR information (and the current RTCP RR's represent one particular kind of aggregation) will serve to diagnose ALL network problems. That is just not realistic. The goal should be to set up sufficient information sharing to serve as an early warning of most problems, hopefully able to diagnose at least some, and to get this established as a BCP. I think that it will be difficult enough to keep multicasting flowing smoothly that there is a chance of establishing this as a principle. Otherwise I can guarantee you that such information will be treated as proprietary and not revealed at all. Regards Marshall 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 http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Thu Apr 19 20:12:56 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 UAA20111 for ; Thu, 19 Apr 2001 20:12:55 -0400 (EDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12287; Thu, 19 Apr 2001 15:48:58 -0700 (PDT) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA15699; Thu, 19 Apr 2001 15:48:31 -0700 (PDT) Message-Id: <200104192248.PAA15699@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: tme@21rst-century.com cc: Tony Ballardie , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield Subject: Re: SSM, RTCP, SAP In-Reply-To: Your message of "Thu, 19 Apr 2001 18:31:35 EDT." <3ADF6745.EFB1C853@21rst-century.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Apr 2001 15:48:31 -0700 From: Lorenzo Vicisano Marshall, > > I don't know of anything similar for SAP, but I don't think we should > > re-invent an ad-hoc routing protocol just for this. We should either > > use the existing ASM multicast service, if present, or SSM + application > > modifications (e.g. a set of relays that accept unicast SAP messages and > > remulticast them. Relays will have all to listen to each other > > announcements .. ect.. there are scalability concerns but seems feasible). > > > > IMHO this should not be a new protocol - it could easily be handled at the ap >plication layer. > Running these relay's sounds like a commercial matter to me. I would NOT add >any router > type support for this. I had in mind an application-level solution too, no router support: the router support is ASM, where available. Lorenzo From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 19 21:36:09 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 VAA21624 for ; Thu, 19 Apr 2001 21:36:08 -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.9.3/8.9.1) with ESMTP id QAA12693 for ; Thu, 19 Apr 2001 16:59:04 -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 f3K00P717394 for ; Thu, 19 Apr 2001 17:00:25 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3JNuuG24730 for ; Thu, 19 Apr 2001 16:56:56 -0700 (PDT) Received: from TWINKLE.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id SAA55114; Thu, 19 Apr 2001 18:51:23 -0500 Message-Id: <5.1.0.14.0.20010419184746.02cdb990@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Apr 2001 18:49:17 -0500 To: "Tony Ballardie" From: Bill Nickless Subject: Re: SSM, RTCP, SAP Cc: , In-Reply-To: <00d801c0c910$874e76e0$729cbc3e@vaionote> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:36 PM 4/19/2001 +0100, Tony Ballardie wrote: >Similarly, what about (global) SAP? SAP was developed before the web. I believe the web makes SAP obsolete, so we shouldn't worry about supporting it as a special case. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Thu Apr 19 21:50:26 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 VAA21775 for ; Thu, 19 Apr 2001 21:50:25 -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.9.3/8.9.1) with ESMTP id RAA24526 for ; Thu, 19 Apr 2001 17:34:47 -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 f3K0aBR25654 for ; Thu, 19 Apr 2001 17:36:12 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3K0VI505515 for ; Thu, 19 Apr 2001 17:31:19 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.11.1/8.11.1) with ESMTP id f3K0MX161178; Thu, 19 Apr 2001 17:22:33 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Bill Nickless cc: Tony Ballardie , ssm-interest , mboned Subject: Re: SSM, RTCP, SAP In-reply-to: Your message of "Thu, 19 Apr 2001 18:49:17 CDT." <5.1.0.14.0.20010419184746.02cdb990@pop.mcs.anl.gov> Date: Thu, 19 Apr 2001 17:22:33 -0700 Message-ID: <61176.987726153@aardvark.aciri.org> Sender: mjh@aciri.org >At 09:36 PM 4/19/2001 +0100, Tony Ballardie wrote: >>Similarly, what about (global) SAP? > >SAP was developed before the web. I believe the web makes SAP obsolete, so >we shouldn't worry about supporting it as a special case. I don't think SAP is completely obsolete, but I also don't think it's very useful for global groups. SAP is best used for admin-scoped multicast groups, where you want the people who can receive the session to be the only people who receive the announcement. The web can't easily satisfy this requirement. Admin-scoping doesn't apply for SSM, and I don't think SAP is relevant for SSM either. For SSM groups, using RTSP/SDP or HTTP/SDP makes much more sense. - Mark From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Thu Apr 19 22:04:48 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21899 for ; Thu, 19 Apr 2001 22:04:47 -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.9.3/8.9.1) with ESMTP id RAA21798 for ; Thu, 19 Apr 2001 17:49: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 f3K0nPE03742 for ; Thu, 19 Apr 2001 17:49:25 -0700 (PDT) Received: from kinkajou.arc.nasa.gov (kinkajou.arc.nasa.gov [128.102.132.150]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3K0ncG11168 for ; Thu, 19 Apr 2001 17:49:38 -0700 (PDT) Received: from localhost (lamaster@localhost) by kinkajou.arc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id RAA21248; Thu, 19 Apr 2001 17:33:45 -0700 (PDT) X-Authentication-Warning: kinkajou.arc.nasa.gov: lamaster owned process doing -bs Date: Thu, 19 Apr 2001 17:33:45 -0700 (PDT) From: Hugh LaMaster X-Sender: lamaster@kinkajou.arc.nasa.gov To: ssm-interest@external.cisco.com, Mboned List Subject: Re: SSM, RTCP, SAP In-Reply-To: <200104192059.NAA15453@lorenzo-u10.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Apr 2001, Lorenzo Vicisano wrote: > I don't know of anything similar for SAP, but I don't think we should > re-invent an ad-hoc routing protocol just for this. We should either > use the existing ASM multicast service, if present, or SSM + application > modifications (e.g. a set of relays that accept unicast SAP messages and > remulticast them. Relays will have all to listen to each other > announcements .. ect.. there are scalability concerns but seems feasible). I see no reason not to use ASM-based SAP for announcements, but, the canonical announcement mechanism for SSM would be the web, would it not? -- Hugh LaMaster, M/S 233-21, Email: lamaster@nas.nasa.gov NASA Ames Research Center Or: lamaster@nren.nasa.gov Moffett Field, CA 94035-1000 Or: lamaster@kinkajou.arc.nasa.gov Phone: 650/604-1056 Disc: Unofficial, personal *opinion*. From owner-extdom.ssm-interest@sj-msg-core-2.cisco.com Fri Apr 20 00:24:16 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 AAA24091 for ; Fri, 20 Apr 2001 00:24:16 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id TAA03924 for ; Thu, 19 Apr 2001 19:54:23 -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 f3K2s0F05609 for ; Thu, 19 Apr 2001 19:54:00 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f3K2o7T14896 for ; Thu, 19 Apr 2001 19:50:07 -0700 (PDT) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA23099; Thu, 19 Apr 2001 19:45:00 -0700 (PDT) Received: from localhost (shep@localhost) by maroon.jnpr.net (8.9.3/8.9.3) with ESMTP id TAA29737; Thu, 19 Apr 2001 19:44:59 -0700 (PDT) (envelope-from shep@juniper.net) X-Authentication-Warning: maroon.jnpr.net: shep owned process doing -bs Date: Thu, 19 Apr 2001 19:44:59 -0700 (PDT) From: Gregory Shepherd X-Sender: shep@maroon.jnpr.net To: Mark Handley cc: Bill Nickless , Tony Ballardie , ssm-interest , mboned Subject: Re: SSM, RTCP, SAP In-Reply-To: <61176.987726153@aardvark.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Apr 2001, Mark Handley wrote: > > >At 09:36 PM 4/19/2001 +0100, Tony Ballardie wrote: > >>Similarly, what about (global) SAP? > > > >SAP was developed before the web. I believe the web makes SAP obsolete, so > >we shouldn't worry about supporting it as a special case. > > I don't think SAP is completely obsolete, but I also don't think it's > very useful for global groups. SAP is best used for admin-scoped > multicast groups, where you want the people who can receive the > session to be the only people who receive the announcement. The web > can't easily satisfy this requirement. http is not only used for globally available content. An enterprise's intranet could just as easily advertise internal sessions as it does internal static content. > Admin-scoping doesn't apply for SSM, and I don't think SAP is relevant > for SSM either. For SSM groups, using RTSP/SDP or HTTP/SDP makes much > more sense. True, there is no assigned SSM scoped range, but if/when IGMPv3 is ubiquitous on the enterprise desktop, then coorporate 'talking head' sessions could be best served by the mechanisms of SSM BUT in the admin scoped range. This would only require the network administer to extend the SSM defined range for the enterprise to include all or a portion of the admin scoped range. Both JunOS and IOS provide for the default SSM range (232/8) and any config'd extensions to that range. No SAP required. Greg > - Mark > From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Fri Apr 20 04:56: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 EAA09082 for ; Fri, 20 Apr 2001 04:56:29 -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.9.3/8.9.1) with ESMTP id AAA19794 for ; Fri, 20 Apr 2001 00:51:06 -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 f3K7qRE01798 for ; Fri, 20 Apr 2001 00:52:27 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f3K7qNT12458 for ; Fri, 20 Apr 2001 00:52:23 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 08:47:11 +0100 To: Lorenzo Vicisano cc: tme@21rst-century.com, Tony Ballardie , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield , J.Crowcroft@cs.ucl.ac.uk Subject: Re: SSM, RTCP, SAP In-reply-to: Your message of "Thu, 19 Apr 2001 15:48:31 PDT." <200104192248.PAA15699@lorenzo-u10.cisco.com> Date: Fri, 20 Apr 2001 08:47:10 +0100 Message-ID: <17454.987752830@cs.ucl.ac.uk> From: Jon Crowcroft what about a GRA solution? In message <200104192248.PAA15699@lorenzo-u10.cisco.com>, Lorenzo Vicisano ty ped: >>Marshall, >> >>> > I don't know of anything similar for SAP, but I don't think we should >>> > re-invent an ad-hoc routing protocol just for this. We should either >>> > use the existing ASM multicast service, if present, or SSM + application >>> > modifications (e.g. a set of relays that accept unicast SAP messages and >>> > remulticast them. Relays will have all to listen to each other >>> > announcements .. ect.. there are scalability concerns but seems feasible). >>> > >>> >>> IMHO this should not be a new protocol - it could easily be handled at the ap >>>plication layer. >>> Running these relay's sounds like a commercial matter to me. I would NOT add >>>any router >>> type support for this. >> >>I had in mind an application-level solution too, no router support: >>the router support is ASM, where available. >> >> Lorenzo >> cheers jon From owner-extdom.ssm-interest@sj-msg-core-4.cisco.com Fri Apr 20 07:01:51 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10180 for ; Fri, 20 Apr 2001 07:01:51 -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.9.3/8.9.1) with ESMTP id DAA12282 for ; Fri, 20 Apr 2001 03:00:00 -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 f3K9xxq22473 for ; Fri, 20 Apr 2001 02:59:59 -0700 (PDT) Received: from sippie.star2.net ([65.89.75.10]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3K9uRG09357 for ; Fri, 20 Apr 2001 02:56:28 -0700 (PDT) Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Fri, 20 Apr 2001 05:52:26 -0400 Received: from 21rst-century.com (1Cust93.tnt1.lorton.va.da.uu.net [63.23.102.93]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Fri, 20 Apr 2001 06:05:23 -0400 Message-ID: <3AE007C3.CE356D66@21rst-century.com> Date: Fri, 20 Apr 2001 05:56:18 -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 MIME-Version: 1.0 To: Jon Crowcroft CC: Lorenzo Vicisano , Tony Ballardie , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield Subject: Re: SSM, RTCP, SAP References: <17454.987752830@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Jon; What did you have in mind ? Marshall Jon Crowcroft wrote: > > what about a GRA solution? > > In message <200104192248.PAA15699@lorenzo-u10.cisco.com>, Lorenzo Vicisano ty > ped: > > >>Marshall, > >> > >>> > I don't know of anything similar for SAP, but I don't think we should > >>> > re-invent an ad-hoc routing protocol just for this. We should either > >>> > use the existing ASM multicast service, if present, or SSM + application > >>> > modifications (e.g. a set of relays that accept unicast SAP messages and > >>> > remulticast them. Relays will have all to listen to each other > >>> > announcements .. ect.. there are scalability concerns but seems feasible). > >>> > > >>> > >>> IMHO this should not be a new protocol - it could easily be handled at the ap > >>>plication layer. > >>> Running these relay's sounds like a commercial matter to me. I would NOT add > >>>any router > >>> type support for this. > >> > >>I had in mind an application-level solution too, no router support: > >>the router support is ASM, where available. > >> > >> Lorenzo > >> > > cheers > > jon -- 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 http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Fri Apr 20 07:12:52 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 HAA10243 for ; Fri, 20 Apr 2001 07:12:51 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id DAA25349 for ; Fri, 20 Apr 2001 03:12:12 -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 f3KAC7111843 for ; Fri, 20 Apr 2001 03:12:07 -0700 (PDT) Received: from sippie.star2.net ([65.89.75.10]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3KACOG13238 for ; Fri, 20 Apr 2001 03:12:24 -0700 (PDT) Received: from web-2.star2.net (web-2.star2.net [207.192.119.10]) by sippie.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id for ; Fri, 20 Apr 2001 06:08:22 -0400 Received: from 21rst-century.com (1Cust93.tnt1.lorton.va.da.uu.net [63.23.102.93]) by web-2.star2.net (Vircom SMTPRS 4.5.185) with ESMTP id ; Fri, 20 Apr 2001 06:21:20 -0400 Message-ID: <3AE00B81.E32AECD3@21rst-century.com> Date: Fri, 20 Apr 2001 06:12:16 -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 MIME-Version: 1.0 To: Jon Crowcroft CC: ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield Subject: Re: SSM, RTCP, SAP References: <18035.987760946@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Jon; Jon Crowcroft wrote: > > well, depends what GRA support is there, but one possibility for > RTCP reports from receivers on an SSM tree is to design a new RTCP > report (with GRA router alert) that is self describing w.r.t > summarising responses routers (like PGM nack aggregation) reporting > a summarised loss bitmap, a highest and lowest loss rate, and so > forth... > I could see where that might make a lot of sense in a TRACK type RMT. Interesting. Marshall > In message <3AE007C3.CE356D66@21rst-century.com>, Marshall Eubanks typed: > > >>Dear Jon; > >> > >> What did you have in mind ? > >> > >> Marshall > >> > >>Jon Crowcroft wrote: > >>> > >>> what about a GRA solution? > >>> > >>> In message <200104192248.PAA15699@lorenzo-u10.cisco.com>, Lorenzo Vicisano ty > >>> ped: > >>> > >>> >>Marshall, > >>> >> > >>> >>> > I don't know of anything similar for SAP, but I don't think we should > >>> >>> > re-invent an ad-hoc routing protocol just for this. We should either > >>> >>> > use the existing ASM multicast service, if present, or SSM + application > >>> >>> > modifications (e.g. a set of relays that accept unicast SAP messages and > >>> >>> > remulticast them. Relays will have all to listen to each other > >>> >>> > announcements .. ect.. there are scalability concerns but seems feasible). > >>> >>> > > >>> >>> > >>> >>> IMHO this should not be a new protocol - it could easily be handled at the ap > >>> >>>plication layer. > >>> >>> Running these relay's sounds like a commercial matter to me. I would NOT add > >>> >>>any router > >>> >>> type support for this. > >>> >> > >>> >>I had in mind an application-level solution too, no router support: > >>> >>the router support is ASM, where available. > >>> >> > >>> >> Lorenzo > >>> >> > >>> > >>> cheers > >>> > >>> jon > >> > >>-- > >> 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.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 Fri Apr 20 07:19:25 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10302 for ; Fri, 20 Apr 2001 07:19:25 -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.9.3/8.9.1) with ESMTP id DAA15513 for ; Fri, 20 Apr 2001 03:07:50 -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 f3KA7nv26616 for ; Fri, 20 Apr 2001 03:07:49 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f3KA7eT28841 for ; Fri, 20 Apr 2001 03:07:40 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 20 Apr 2001 11:02:27 +0100 To: tme@21rst-century.com cc: ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu, Julian Chesterfield Subject: Re: SSM, RTCP, SAP In-reply-to: Your message of "Fri, 20 Apr 2001 05:56:18 EDT." <3AE007C3.CE356D66@21rst-century.com> Date: Fri, 20 Apr 2001 11:02:26 +0100 Message-ID: <18035.987760946@cs.ucl.ac.uk> From: Jon Crowcroft well, depends what GRA support is there, but one possibility for RTCP reports from receivers on an SSM tree is to design a new RTCP report (with GRA router alert) that is self describing w.r.t summarising responses routers (like PGM nack aggregation) reporting a summarised loss bitmap, a highest and lowest loss rate, and so forth... In message <3AE007C3.CE356D66@21rst-century.com>, Marshall Eubanks typed: >>Dear Jon; >> >> What did you have in mind ? >> >> Marshall >> >>Jon Crowcroft wrote: >>> >>> what about a GRA solution? >>> >>> In message <200104192248.PAA15699@lorenzo-u10.cisco.com>, Lorenzo Vicisano ty >>> ped: >>> >>> >>Marshall, >>> >> >>> >>> > I don't know of anything similar for SAP, but I don't think we should >>> >>> > re-invent an ad-hoc routing protocol just for this. We should either >>> >>> > use the existing ASM multicast service, if present, or SSM + application >>> >>> > modifications (e.g. a set of relays that accept unicast SAP messages and >>> >>> > remulticast them. Relays will have all to listen to each other >>> >>> > announcements .. ect.. there are scalability concerns but seems feasible). >>> >>> > >>> >>> >>> >>> IMHO this should not be a new protocol - it could easily be handled at the ap >>> >>>plication layer. >>> >>> Running these relay's sounds like a commercial matter to me. I would NOT add >>> >>>any router >>> >>> type support for this. >>> >> >>> >>I had in mind an application-level solution too, no router support: >>> >>the router support is ASM, where available. >>> >> >>> >> Lorenzo >>> >> >>> >>> cheers >>> >>> jon >> >>-- >> >> 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 http://www.on-the-i.com >> >> Test your network for multicast : http://www.multicasttech.com/mt/ cheers jon From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Sat Apr 21 00:24:09 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 AAA24279 for ; Sat, 21 Apr 2001 00:24:08 -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.9.3/8.9.1) with ESMTP id TAA02680 for ; Fri, 20 Apr 2001 19: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 f3L2hVV13323 for ; Fri, 20 Apr 2001 19:43:31 -0700 (PDT) Received: from purple.east.isi.edu (purple.east.isi.edu [38.245.76.9]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f3L2cYr17746 for ; Fri, 20 Apr 2001 19:38:35 -0700 (PDT) Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id RAA01936; Thu, 19 Apr 2001 17:07:35 -0400 Message-Id: <200104192107.RAA01936@purple.east.isi.edu> To: Lorenzo Vicisano cc: Tony Ballardie , ssm-interest@external.cisco.com, mboned@network-services.uoregon.edu Subject: Re: SSM, RTCP, SAP In-Reply-To: Message from Lorenzo Vicisano of "Thu, 19 Apr 2001 13:59:27 PDT." <200104192059.NAA15453@lorenzo-u10.cisco.com> Date: Thu, 19 Apr 2001 17:07:35 -0400 From: Colin Perkins --> Lorenzo Vicisano writes: >For RTCP, the idea floating around was to unicast the RRs back to >the source and having the source echoing them back in the multicast >session (either the report themselves or some digested summary of them). >I don't know if this was ever specified 'though. There was some discussion of this in AVT at the last IETF - see draft-chesterfield-avt-rtcpssm-00.txt Colin >I don't know of anything similar for SAP, but I don't think we should >re-invent an ad-hoc routing protocol just for this. We should either >use the existing ASM multicast service, if present, or SSM + application >modifications (e.g. a set of relays that accept unicast SAP messages and >remulticast them. Relays will have all to listen to each other >announcements .. ect.. there are scalability concerns but seems feasible). > > Lorenzo > >> What's the current thinking about handling RTP apps with >> SSM; RTP apps are intrinsically multi-sender (==> Receiver Reports)? >> >> Similarly, what about (global) SAP? >> >> Given that SAP comes under the category of "bootstrap" (I guess), wouldn't >> it be an idea to RPF flood SAP (minus the prune), and not incur any state >> for that flood? Such a flood would result in SAP announcements flowing >> over redundant paths, but a) they're infrequent, b) all SDRs want them >> within the flood (mcast) scope, c) they're bootstrap so they fit within >> a flood model. >> >> So, how to prevent (s,g) state for SAPs? Define a ToS bit pattern that tells >> routers not to create fwd state for this packet?? >> >> I'm not suggesting doing the same for RTCP RRs, since they don't >> fall under bootstrap, and require sender/member-constrained distribution. >> >> thoughts? >> >> Tony >> > > From owner-extdom.ssm-interest@sj-msg-core-1.cisco.com Tue Apr 24 02:19:17 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 CAA04074 for ; Tue, 24 Apr 2001 02:19:17 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3O5AYu25908 for ; Mon, 23 Apr 2001 22:10:34 -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 f3O5ATL05383 for ; Mon, 23 Apr 2001 22:10:29 -0700 (PDT) Received: from smt.com.hk ([202.77.25.62]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f3O4vdF11042 for ; Mon, 23 Apr 2001 21:57:41 -0700 (PDT) Received: from adam.kaist.ac.kr [212.134.16.13] by smt.com.hk (SMTPD32-6.06 EVAL) id A2ED220136; Tue, 24 Apr 2001 12:37:01 +0800 Message-ID: <00006d7e7ab0$00005f48$00006bb4@adam.kaist.ac.kr> To: From: fastpicks@cirrostratus.netaccess.co.nz Subject: OUR NEXT STOCK PICK: MLMS $.08 Date: Mon, 23 Apr 2001 17:37:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-1.cisco.com id f3O5Bfu25924 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04074 OUR NEXT STOCK PICK IS OTCBB: MLMS Price: $ .08 Target Price: $.65 - $.75 Float: 1.1mil We consider MLMS a STRONG BUY! Tier II Expected to Create Over $29 Million in Revenues SAN DIEGO--(Business Wire)--April 23, 2001--MLM World News Today, Inc. announced that the company has signed a Letter of Intent with a team of top network marketing professionals to promote the company's "Business Too Box'' world-wide. "We have known these individuals for many years. Their reputation and proven successes have built a huge following in our industry. We are extremely excited that they see the value in our ''Business Tool Box, "and that they are confident in forecasting sales in excess of 100,000 units during the first 6 to 12 months,'' stated James C. Frans, president/CEO of MLM World News Today, Inc. for details go to: http://quote.yahoo.com/q?s=mlms.ob&d=v1 DISCLAIMER: pennypicks 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 pennypicks. All information concerning the companies is received directly from company press releases. pennypicks 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. pennypicks 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. pennypicks is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such pennypicks is not offering investment advice or promoting any investment strategies. pennypicksis not offering securities for sale or solicitation of any offer to buy or sell securities. 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”. pennypicks holds sixty thousand shares of this company profile. pennypicks, its affiliates, associates, relatives and anyone associated with pennypicks 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. We reserve the right to sell shares at anytime, even during the time periodin which we are profiling a company. pennypicks 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 outanna020@excite.com From owner-extdom.ssm-interest@sj-msg-core-3.cisco.com Tue Apr 24 23:57: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 XAA23255 for ; Tue, 24 Apr 2001 23:57:28 -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.9.3/8.9.1) with ESMTP id TAA09474 for ; Tue, 24 Apr 2001 19:21:45 -0700 (PDT) From: allpicks@router.coepb.br Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3P2NA120732 for ; Tue, 24 Apr 2001 19:23:10 -0700 (PDT) Received: from m011.kyowa.ne.jp ([203.136.224.26]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f3P2NN905717 for ; Tue, 24 Apr 2001 19:23:24 -0700 (PDT) Received: from lisa.netzero.com_[212.134.16.12] (tnt-10-12.easynet.co.uk [212.134.16.12]) by m011.kyowa.ne.jp (8.8.5+ExpressMail-1.14/3.5Wpl1) with SMTP id LAA00213; Wed, 25 Apr 2001 11:05:10 +0900 (JST) Received: from router.coepb.br by lisa.netzero.com with ESMTP; Tue, 24 Apr 2001 15:00:28 -0500 Message-ID: <0000152164a8$000058a8$000041b0@router.coepb.br> To: Subject: MAJOR STOCK PLAY: MLMS (otc) $.18 Date: Tue, 24 Apr 2001 15:00:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-3.cisco.com id TAA09475 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23255 Target Price: $.65 - $.75 Float: 1.1mil We consider MLMS a STRONG BUY Tier II Expected to Create Over $29 Million in Revenues SAN DIEGO--(Business Wire)---MLM World News Today, Inc. announced that the company has signed a Letter of Intent with a team of top network marketing professionals to promote the company's "Business Too Box'' world-wide. "We have known these individuals for many years. Their reputation and proven successes have built a huge following in our industry. We are extremely excited that they see the value in our ''Business Tool Box, "and that they are confident in forecasting sales in excess of 100,000 units during the first 6 to 12 months,'' stated James C. Frans, president/CEO of MLM World News Today, Inc. for details go to: http://quote.yahoo.com/q?s=mlms.ob&d=v1 DISCLAIMER: pennypicks 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 pennypicks. All information concerning the companies is received directly from company press releases. pennypicks 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. pennypicks 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. pennypicks is not an Investment Advisor, Financial Planning Service or a Stock Brokerage Firm and in accordance with such pennypicks is not offering investment advice or promoting any investment strategies. pennypicksis not offering securities for sale or solicitation of any offer to buy or sell securities. 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”. pennypicks holds sixty thousand shares of this company profile. pennypicks, its affiliates, associates, relatives and anyone associated with pennypicks 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. We reserve the right to sell shares at anytime, even during the time periodin which we are profiling a company. pennypicks 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 outanna020@excite.com OUR PICK IS MLMS Tier II Expected to Create Over $29 Million in Revenues OTCBB: MLMS Price: $ .08