From owner-idmr@cs.ucl.ac.uk Wed Aug 1 08:23:41 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29263 for ; Wed, 1 Aug 2001 08:23:40 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 1 Aug 2001 12:42:38 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Aug 2001 12:42:32 +0100 Received: from 47.129.242.157 by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 1 Aug 2001 12:42:30 +0100 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f71Bg4928117 for ; Wed, 1 Aug 2001 07:42:05 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Wed, 1 Aug 2001 07:42:18 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QAADLHKX; Wed, 1 Aug 2001 07:42:17 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5M6P5; Wed, 1 Aug 2001 07:42:16 -0400 Message-ID: <3B67EB0E.344DEF52@americasm06.nt.com> Date: Wed, 01 Aug 2001 07:42:06 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Brian Haberman Reply-To: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MAGMA Mailing List , idmr@cs.ucl.ac.uk Subject: Updated MAGMA agenda Content-Type: multipart/mixed; boundary="------------0CBFC64005554840C4788E47" X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. --------------0CBFC64005554840C4788E47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Here is the updated MAGMA agenda for London. Feel free to point out any errors. Thanks, Brian & Bill --- --------------0CBFC64005554840C4788E47 Content-Type: text/plain; charset=us-ascii; name="agenda-073101.txt" Content-Disposition: inline; filename="agenda-073101.txt" Content-Transfer-Encoding: 7bit Multicast and Anycast Group Membership (magma) Monday, August 06 at 0900-1130 Agenda: Agenda Bashing Chairs 5 minutes Document Status Chairs 15 minutes IDMR Status Fenner 5 minutes IGMP Proxying Fenner/He 15 minutes - draft-ieft-idmr-igmp-proxy-01.txt IGMP Snooping Christensen 15 minutes - draft-ietf-idmr-snoop-01.txt Multicast Source Filter API Fenner 10 minutes MIB Discussion Fenner 15 minutes IGMPv3 Interactions Martin 10 minutes - draft-ietf-idmr-igmpv3-and-routing-01.txt MSNIP for IGMP Proxying He 15 minutes - draft-he-msnip-igmp-proxy-ext-00.txt Author Recruiting Chairs 10 minutes MAGMA Future Chairs 5 minutes --------------0CBFC64005554840C4788E47-- From owner-idmr@cs.ucl.ac.uk Wed Aug 1 18:35:40 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08066 for ; Wed, 1 Aug 2001 18:35:39 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 1 Aug 2001 22:43:50 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Aug 2001 22:43:45 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 1 Aug 2001 22:43:43 +0100 Received: from bwilliam-t20.cisco.com (sj-vpdn-client-93.cisco.com [171.70.193.94]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA16188; Wed, 1 Aug 2001 14:41:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 16:37:59 -0500 To: John Zwiebel , Bryan Mclaughlin , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk From: Beau Williamson Subject: Re: draft-ietf-pim-dm-new-v2-04.txt In-Reply-To: <3B66F847.4BC0D18F@Procket.com> References: <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk John, Once again I think you and I are on the same wavelength. I'd like to see MSNIP evolve into something more like the RTS/CTS mechanism that you describe with sufficient specifications as to how the first hop device (maybe a router or maybe a layer-3 aware switch) should handle this. In addition, I'd like to see "receiver" admission control added if at all possible. I'm not convinced that this would require a extension to IGMP or a new protocol and may actual fall into vendor specific features. In any case, the worries over DoS Attacks due to random sourcing and random joining (especially if SSM takes off) are real and are quickly becoming a barrier to multicast deployment. Maybe this can be discussed at the MAGMA WG in London. Unfortunately, I won't be there so I'm hoping you or someone else will carry the flag. (At least initially.) Beau At 01:26 PM 7/31/2001, John Zwiebel wrote: >Bryan Mclaughlin wrote: >> >> This issue is addressed by Multicast Source Notification of Interest >> Protocol (MSNIP) for SM protocols, isn't it ? What would need to be added >> to make it work for DM? >> > >MSNIP does not do admission control. It "kind of" does it, but >there's nothing that prevents a source from dumping mpackets on to the >LAN. >And MSNIP does not specifically address what a router should do if >it sees packets from a source that hasn't registered via MSNIP. >(one could make the leap that in such a case the router could just >bit bucket the data stream) > >The host (source) is still "in charge" and the network has to muddle >through the best it can. If a host is sending and there is no MSNIP >available, there's nothing to stop it. > >The RTS/CTS process I'd like to see would make the network more >"superior" to the host and is quite a bit more complicated than what >MSNIP is trying to provide. > >I guess this sentence from the MSNIP draft makes my point: > > Hosts that wish to be managed by MSNIP periodically transmit an > Interest Solicitation message. This message is multicast with a >group > destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is > transmitted every [Interest Solicitation Interval] seconds. > > -- MSNIP is IGMPv3 only > -- Hosts can arbitrarily decide to not be managed by MSNIP > -- MSNIP does not describe how to signal the "network" that the > source is about to send. > >This shouldn't be taken as a condemnation of MSNIP. Its quite >possible my imagination just isn't strong enough to grasp the >capabilities. And what I think is needed may be way too complicated >and contrary to the "spirit of the internet". From owner-idmr@cs.ucl.ac.uk Thu Aug 2 09:15:22 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26011 for ; Thu, 2 Aug 2001 09:15:20 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 2 Aug 2001 12:32:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 2 Aug 2001 12:32:05 +0100 Received: from 47.129.242.157 by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 2 Aug 2001 12:31:58 +0100 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f72BVV917491 for ; Thu, 2 Aug 2001 07:31:31 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 2 Aug 2001 07:31:38 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QDV65B6D; Thu, 2 Aug 2001 07:31:39 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5M7D5; Thu, 2 Aug 2001 07:31:35 -0400 Message-ID: <3B693A0F.DBA2FED0@americasm06.nt.com> Date: Thu, 02 Aug 2001 07:31:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Brian Haberman Reply-To: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Zwiebel CC: Beau Williamson , Bryan Mclaughlin , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk Subject: Re: [Magma] Re: MSNIP References: <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit John & Beau, Dave Thaler has requested some time in London to discuss MSNIP. Specifically, what it does and does not do (especially in a zeroconf environment). We can evolve that to a meta discussion on MSNIP and hopefully get some more interest in it than what we have had in the past. Regards, Brian John Zwiebel wrote: > > Beau Williamson wrote: > > > > John, > > > > Once again I think you and I are on the same wavelength. I'd like to see MSNIP evolve into something more like the RTS/CTS mechanism that you describe with sufficient specifications as to how the first hop device (maybe a router or maybe a layer-3 aware switch) should handle this. > > > > FWIW: if we view the future to be SSM then MSNIP will be more than > good enough. The setup of a SSM multicast session will migrate out > of the network so that the requirement to not drop packets will become > an application problem. (And, 2cents, MSNIP at that point could be > viewed as superfluous from a network perspective. Who cares if the > source LAN alone is swamped. This shouldn't be taken to mean that > I believe MSNIP is not a good idea, its just an idea that I wouldn't > care about.) > > Folks who want to continue pushing SM/DM are the ones who'll need the > greater admission control capability. If we had just "KISSed" it in > the beginning... > > z > _______________________________________________ > Magma mailing list > Magma@innovationslab.net > http://www.innovationslab.net/mailman/listinfo/magma From owner-idmr@cs.ucl.ac.uk Thu Aug 2 12:28:24 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05242 for ; Thu, 2 Aug 2001 12:28:23 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 2 Aug 2001 15:41:01 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 2 Aug 2001 15:40:56 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 2 Aug 2001 15:40:56 +0100 Received: from bwilliam-t20.cisco.com (sj-vpdn-client-100.cisco.com [171.70.193.101]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA03609; Thu, 2 Aug 2001 07:38:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20010802093012.00b85b08@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 09:34:53 -0500 To: Brian Haberman , John Zwiebel From: Beau Williamson Subject: Re: [Magma] Re: MSNIP Cc: Bryan Mclaughlin , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk In-Reply-To: <3B693A0F.DBA2FED0@americasm06.nt.com> References: <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Brian, Unfortunately, I wont be in London so I'll have to let someone else carry the torch at that meeting. I don't agree that MSNIP is "good enough" and would like to see us extend IGMP to include the RTS/CTS mechanism that John Z. mentioned. That would permit the first hope devices (switches?) to snoop only a single protocol for both senders and receivers. We could make it such that sender admission control was something that could be enabled (or not) on a switch/router/first-hop device and that would permit one to still use the old "send in the blind" model defined in RFC 1112 (the "Multicast Dead Sea Scrolls"). Hopefully, the MAGMA session will be multicast and I can at least listen in on what is going on. Beau At 06:31 AM 8/2/2001, Brian Haberman wrote: >John & Beau, > Dave Thaler has requested some time in London to discuss MSNIP. >Specifically, what it does and does not do (especially in a zeroconf >environment). We can evolve that to a meta discussion on MSNIP and >hopefully get some more interest in it than what we have had in the >past. > >Regards, >Brian > > >John Zwiebel wrote: >> >> Beau Williamson wrote: >> > >> > John, >> > >> > Once again I think you and I are on the same wavelength. I'd like to see MSNIP evolve into something more like the RTS/CTS mechanism that you describe with sufficient specifications as to how the first hop device (maybe a router or maybe a layer-3 aware switch) should handle this. >> > >> >> FWIW: if we view the future to be SSM then MSNIP will be more than >> good enough. The setup of a SSM multicast session will migrate out >> of the network so that the requirement to not drop packets will become >> an application problem. (And, 2cents, MSNIP at that point could be >> viewed as superfluous from a network perspective. Who cares if the >> source LAN alone is swamped. This shouldn't be taken to mean that >> I believe MSNIP is not a good idea, its just an idea that I wouldn't >> care about.) >> >> Folks who want to continue pushing SM/DM are the ones who'll need the >> greater admission control capability. If we had just "KISSed" it in >> the beginning... >> >> z >> _______________________________________________ >> Magma mailing list >> Magma@innovationslab.net >> http://www.innovationslab.net/mailman/listinfo/magma From owner-idmr@cs.ucl.ac.uk Thu Aug 2 14:33:19 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11847 for ; Thu, 2 Aug 2001 14:33:18 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 2 Aug 2001 18:22:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 2 Aug 2001 18:22:06 +0100 Received: from london.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 2 Aug 2001 18:22:07 +0100 Received: from BRMCLAUG-W2K1.cisco.com (dhcp-man-did-vlan10-64-103-110-177.cisco.com [64.103.110.177]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26784; Thu, 2 Aug 2001 18:16:49 +0100 (BST) Message-Id: <4.3.2.7.2.20010802175836.01e99428@london.cisco.com> X-Sender: brmclaug@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Aug 2001 18:16:46 +0100 To: Beau Williamson From: Bryan Mclaughlin Subject: Re: [Magma] Re: MSNIP Cc: Brian Haberman , John Zwiebel , Bryan Mclaughlin , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk In-Reply-To: <4.3.2.7.2.20010802093012.00b85b08@mail1.cisco.com> References: <3B693A0F.DBA2FED0@americasm06.nt.com> <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Beau, My question is what does RTS/CTS stand for? Ready to send/ clear to send or reason to send/ content to send? I do not feel comfortable with a router having the power to 'enforce' quiescence on a host or am I just being a coward ;) Perhaps the ability to enable or not enable this feature would mitigate my concerns. I agree that augmenting an existing deployed protocol, such as IGMP, with source communication abilities is a good idea. Bryan At 09:34 02/08/2001 -0500, Beau Williamson wrote: >Brian, > >Unfortunately, I wont be in London so I'll have to let someone else carry >the torch at that meeting. > >I don't agree that MSNIP is "good enough" and would like to see us extend >IGMP to include the RTS/CTS mechanism that John Z. mentioned. That would >permit the first hope devices (switches?) to snoop only a single protocol >for both senders and receivers. We could make it such that sender >admission control was something that could be enabled (or not) on a >switch/router/first-hop device and that would permit one to still use the >old "send in the blind" model defined in RFC 1112 (the "Multicast Dead Sea >Scrolls"). > >Hopefully, the MAGMA session will be multicast and I can at least listen >in on what is going on. > >Beau >At 06:31 AM 8/2/2001, Brian Haberman wrote: > >John & Beau, > > Dave Thaler has requested some time in London to discuss MSNIP. > >Specifically, what it does and does not do (especially in a zeroconf > >environment). We can evolve that to a meta discussion on MSNIP and > >hopefully get some more interest in it than what we have had in the > >past. > > > >Regards, > >Brian > > > > > >John Zwiebel wrote: > >> > >> Beau Williamson wrote: > >> > > >> > John, > >> > > >> > Once again I think you and I are on the same wavelength. I'd like > to see MSNIP evolve into something more like the RTS/CTS mechanism that > you describe with sufficient specifications as to how the first hop > device (maybe a router or maybe a layer-3 aware switch) should handle this. > >> > > >> > >> FWIW: if we view the future to be SSM then MSNIP will be more than > >> good enough. The setup of a SSM multicast session will migrate out > >> of the network so that the requirement to not drop packets will become > >> an application problem. (And, 2cents, MSNIP at that point could be > >> viewed as superfluous from a network perspective. Who cares if the > >> source LAN alone is swamped. This shouldn't be taken to mean that > >> I believe MSNIP is not a good idea, its just an idea that I wouldn't > >> care about.) > >> > >> Folks who want to continue pushing SM/DM are the ones who'll need the > >> greater admission control capability. If we had just "KISSed" it in > >> the beginning... > >> > >> z > >> _______________________________________________ > >> Magma mailing list > >> Magma@innovationslab.net > >> http://www.innovationslab.net/mailman/listinfo/magma From owner-idmr@cs.ucl.ac.uk Fri Aug 3 07:07:47 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13042 for ; Fri, 3 Aug 2001 07:07:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 11:22:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 03:20:16 +0100 Received: from postoffice.sarnoff.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 3 Aug 2001 03:20:15 +0100 Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYTJ00.ACY for ; Thu, 2 Aug 2001 21:58:31 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXT00.NBH; Fri, 27 Jul 2001 19:51:29 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id MAA06953; Wed, 25 Jul 2001 12:50:56 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA00375 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 12:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25634 for ; Wed, 25 Jul 2001 06:35:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07814; Wed, 25 Jul 2001 06:35:13 -0400 (EDT) Message-Id: <200107251035.GAA07814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-proxy-01.txt,.ps Date: Wed, 25 Jul 2001 06:35:13 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : IGMP-based Multicast Forwarding ('IGMP Proxying') Author(s) : W. Fenner et al. Filename : draft-ietf-idmr-igmp-proxy-01.txt,.ps Pages : 7 Date : 24-Jul-01 In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient to learn group membership information and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon IGMP membership information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-proxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-proxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Fri Aug 3 07:07:53 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13054 for ; Fri, 3 Aug 2001 07:07:52 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 11:26:09 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 09:57:28 +0100 Received: from postoffice.sarnoff.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 3 Aug 2001 09:56:46 +0100 Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF8U00.DQH for ; Fri, 3 Aug 2001 03:53:18 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXT00.NBH; Fri, 27 Jul 2001 19:51:29 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id MAA06953; Wed, 25 Jul 2001 12:50:56 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA00375 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 12:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25634 for ; Wed, 25 Jul 2001 06:35:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07814; Wed, 25 Jul 2001 06:35:13 -0400 (EDT) Message-Id: <200107251035.GAA07814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-proxy-01.txt,.ps Date: Wed, 25 Jul 2001 06:35:13 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : IGMP-based Multicast Forwarding ('IGMP Proxying') Author(s) : W. Fenner et al. Filename : draft-ietf-idmr-igmp-proxy-01.txt,.ps Pages : 7 Date : 24-Jul-01 In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient to learn group membership information and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon IGMP membership information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-proxy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-proxy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Fri Aug 3 08:22:10 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14298 for ; Fri, 3 Aug 2001 08:22:10 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 12:24:48 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 12:24:41 +0100 Received: from london.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 3 Aug 2001 12:24:41 +0100 Received: from BRMCLAUG-W2K1.cisco.com (dhcp-man-did-vlan10-64-103-110-177.cisco.com [64.103.110.177]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA00291; Fri, 3 Aug 2001 12:19:44 +0100 (BST) Message-Id: <4.3.2.7.2.20010803121721.03826428@london.cisco.com> X-Sender: brmclaug@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 12:19:42 +0100 To: john.zwiebel@Procket.com From: Bryan Mclaughlin Subject: Re: [Magma] Re: MSNIP Cc: Bryan Mclaughlin , Beau Williamson , Brian Haberman , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk In-Reply-To: <3B69A6E2.27171F0A@procket.com> References: <3B693A0F.DBA2FED0@americasm06.nt.com> <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> <4.3.2.7.2.20010802175836.01e99428@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk John The RTS CTS questions was facetious. RTS CTS is part of v24/rs232 control where the DTE rts's and the DCE CTS's i.e the DCE has control over when a DTE can start TXing. My point being that in IP environment we do not(IMHO) want the DCE/router to have that amount of control. It(the router) can/should however inform the DTE/Host that there is a "reason" to send and dependent upon the network admin/application support we can use a MSNIP type protocol to enable the DCE/router convey this "reason to send" to the host. This 'rts' would be sent after the host/DTE also has used its the ability to indicate it has "Content to send" to DCE/router who has subsequently been able to determine if there are interested receivers in the Multicast network. As you point out this could introduce a delay in the initialization of the session, which is why I belive the ability to use this on a per application as well as per network scenario is important. Bryan At 12:15 02/08/2001 -0700, John Zwiebel wrote: >Bryan Mclaughlin wrote: > > > > Beau, > > > > My question is what does RTS/CTS stand for? > > Request to Send > Clear to Send > >Modem cable stuff -- right? > > > > > I do not feel comfortable with a router having the power to 'enforce' > > quiescence on a host or am I just being a coward ;) Perhaps the ability to > > enable or not enable this feature would mitigate my concerns. > >Don't configure it in your network. :-) > > >Multicast doesn't have a nice handshake like TCP to start a session. >Customers (some customers anyway) insist that multicast not lose any >data. Expecting the network to be able to immediately set up a (S,G) >route as soon as a source starts dumping data on to the LAN is never >going to work. > >There are many, many, many alternatives. And, IMHO, some of the >best would be to let the application handle the problem. But that >may result in chaos if we ever get a multicast implementation that >depends on many different vendors. (implementation isn't the right >word, but then neither is session, or protocol or capability. Perhaps >I mean service.) > >Video/audio doesn't care about the few lost packets at the beginning >of a session. Downloading data files (MFTP like) does. > >I'm not necessarily in favor of the IETF doing anything about this -- >including MSNIP. Its a question that the Apps guys have to ask because >the solution depends on what they want to do. > >What I do want to do is make sure that no one goes around thinking that >if we follow Fenner's (et. al.) new spec to the letter that data won't >be lost at session start up any longer. I want to bring expectations >down to a realistic level. I want to start "KISSing" multicast so >certain ISPs will stop complaining about how badly it destabilizes >their network. (Perhaps I should say, "can stop", after all they >are just pointing out an unpleasent truth). > >Now, again, this shouldn't be taken to mean that I think the new PIM >spec is useless or flawed or anything at all like that. I'm constantly >amazed by how complete it is. It's just too bad its so hard to >grasp. > >2cents. I'll try to refrain from expressing any more political >view points in this area now. :-) From owner-idmr@cs.ucl.ac.uk Fri Aug 3 12:23:17 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19827 for ; Fri, 3 Aug 2001 12:23:16 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 16:13:22 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 15:58:36 +0100 Received: from prue.eim.surrey.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Fri, 3 Aug 2001 15:58:36 +0100 Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15SgPF-0005X3-00; Fri, 03 Aug 2001 15:58:29 +0100 Date: Fri, 3 Aug 2001 15:58:26 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: fenner@research.att.com, haixiang@nortelnetworks.com cc: idmr@cs.ucl.ac.uk, udlr@sophia.inria.fr Subject: IGMP proxying Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15SgPF-0005X3-00*FzlsSRgfInI* http://duncanthrax.net/exiscan/ Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Bill and HH, A comment on: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-proxy-01.txt IGMP-based Multicast Forwarding ("IGMP Proxying") Fenner, He et al. It strikes me from a brief read of this draft that your use of 'upstream/downstream interface' terminology restricts the draft to topologies sans unidirectional links, since in a unidirectional case the definition of the direction of the root of the tree becomes a little munged. In particular, section 4.2 of your draft won't hold for unidirectional-link topologies, where the upstream receive interface and upstream send interface are actually on separate interfaces. Have you considered topologies with one-way links? The IETF UDLR WG is heading for rechartering to document multicast solutions for one-way links (see http://www-sop.inria.fr/rodeo/udlr/archive/msg00525.html ), so there seems to be some overlap here. thanks, L. see you in the MAGMA and UDLR sessions on Monday. PGP From owner-idmr@cs.ucl.ac.uk Fri Aug 3 13:44:18 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22699 for ; Fri, 3 Aug 2001 13:44:18 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 17:34:41 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 17:34:37 +0100 Received: from mail1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 3 Aug 2001 17:34:36 +0100 Received: from bwilliam-t20.cisco.com (sj-vpdn-client-30.cisco.com [171.70.193.31]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA29989; Fri, 3 Aug 2001 09:31:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20010803112642.00b61878@mail1.cisco.com> X-Sender: bwilliam@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 11:28:26 -0500 To: Bryan Mclaughlin From: Beau Williamson Subject: Re: [Magma] Re: MSNIP Cc: Brian Haberman , John Zwiebel , Bryan Mclaughlin , pim@catarina.usc.edu, MAGMA Mailing List , idmr@cs.ucl.ac.uk In-Reply-To: <4.3.2.7.2.20010802175836.01e99428@london.cisco.com> References: <4.3.2.7.2.20010802093012.00b85b08@mail1.cisco.com> <3B693A0F.DBA2FED0@americasm06.nt.com> <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk At 12:16 PM 8/2/2001, Bryan Mclaughlin wrote: >Beau, > >My question is what does RTS/CTS stand for? Request-to-Send / Clear-to-Send >Ready to send/ clear to send or reason to send/ content to send? > >I do not feel comfortable with a router having the power to 'enforce' quiescence on a host or am I just being a coward ;) Perhaps the ability to enable or not enable this feature would mitigate my concerns. Yes, I think at least initially we have to have a way to enable/disable this function. At least until the new sender model is implemented in the host stacks. >I agree that augmenting an existing deployed protocol, such as IGMP, with source communication abilities is a good idea. > >Bryan > > > >At 09:34 02/08/2001 -0500, Beau Williamson wrote: >>Brian, >> >>Unfortunately, I wont be in London so I'll have to let someone else carry the torch at that meeting. >> >>I don't agree that MSNIP is "good enough" and would like to see us extend IGMP to include the RTS/CTS mechanism that John Z. mentioned. That would permit the first hope devices (switches?) to snoop only a single protocol for both senders and receivers. We could make it such that sender admission control was something that could be enabled (or not) on a switch/router/first-hop device and that would permit one to still use the old "send in the blind" model defined in RFC 1112 (the "Multicast Dead Sea Scrolls"). >> >>Hopefully, the MAGMA session will be multicast and I can at least listen in on what is going on. >> >>Beau >>At 06:31 AM 8/2/2001, Brian Haberman wrote: >>>John & Beau, >>> Dave Thaler has requested some time in London to discuss MSNIP. >>>Specifically, what it does and does not do (especially in a zeroconf >>>environment). We can evolve that to a meta discussion on MSNIP and >>>hopefully get some more interest in it than what we have had in the >>>past. >>> >>>Regards, >>>Brian >>> >>> >>>John Zwiebel wrote: >>>> >>>> Beau Williamson wrote: >>>> > >>>> > John, >>>> > >>>> > Once again I think you and I are on the same wavelength. I'd like to see MSNIP evolve into something more like the RTS/CTS mechanism that you describe with sufficient specifications as to how the first hop device (maybe a router or maybe a layer-3 aware switch) should handle this. >>>> > >>>> >>>> FWIW: if we view the future to be SSM then MSNIP will be more than >>>> good enough. The setup of a SSM multicast session will migrate out >>>> of the network so that the requirement to not drop packets will become >>>> an application problem. (And, 2cents, MSNIP at that point could be >>>> viewed as superfluous from a network perspective. Who cares if the >>>> source LAN alone is swamped. This shouldn't be taken to mean that >>>> I believe MSNIP is not a good idea, its just an idea that I wouldn't >>>> care about.) >>>> >>>> Folks who want to continue pushing SM/DM are the ones who'll need the >>>> greater admission control capability. If we had just "KISSed" it in >>>> the beginning... >>>> >>>> z >>>> _______________________________________________ >>>> Magma mailing list >>>> Magma@innovationslab.net >>>> http://www.innovationslab.net/mailman/listinfo/magma > From owner-idmr@cs.ucl.ac.uk Fri Aug 3 18:31:16 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00161 for ; Fri, 3 Aug 2001 18:31:15 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 3 Aug 2001 22:53:44 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Aug 2001 22:53:38 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 3 Aug 2001 22:53:37 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 9CB6C4CE90; Fri, 3 Aug 2001 17:53:36 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA22548; Fri, 3 Aug 2001 17:53:35 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA23392; Fri, 3 Aug 2001 14:53:34 -0700 (PDT) Message-Id: <200108032153.OAA23392@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: john.zwiebel@procket.com Subject: Re: [Magma] Re: MSNIP Cc: brmclaug@cisco.com, bwilliam@cisco.com, haberman@nortelnetworks.com, pim@catarina.usc.edu, magma@innovationslab.net, idmr@cs.ucl.ac.uk References: <3B693A0F.DBA2FED0@americasm06.nt.com> <3B587D6F.B707EFC1@Procket.com> <3B586018.B6ADDC06@nexthop.com> <4.3.2.7.2.20010731172225.01e673f0@london.cisco.com> <4.3.2.7.2.20010801163241.05435120@mail1.cisco.com> <3B6886AE.B3D5486F@Procket.com> <4.3.2.7.2.20010802175836.01e99428@london.cisco.com> <3B69A6E2.27171F0A@procket.com> Date: Fri, 3 Aug 2001 14:53:34 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >Multicast doesn't have a nice handshake like TCP to start a session. Neither does IP. >Customers (some customers anyway) insist that multicast not lose any >data. Expecting the network to be able to immediately set up a (S,G) >route as soon as a source starts dumping data on to the LAN is never >going to work. As you say, the right answer here is to a) Set their expectations properly. b) Design a protocol that meets their expectations. The answer to "b" probably should not require any IP-level changes. Bill From owner-idmr@cs.ucl.ac.uk Fri Aug 3 22:13:09 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03367 for ; Fri, 3 Aug 2001 22:13:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 4 Aug 2001 02:28:50 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 4 Aug 2001 02:28:44 +0100 Received: from 47.129.242.157 by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 4 Aug 2001 02:28:45 +0100 Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f741SI914570 for ; Fri, 3 Aug 2001 21:28:18 -0400 (EDT) Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Fri, 3 Aug 2001 20:28:56 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 18:28:33 -0700 Message-ID: <5D630265EF50D311ABB60008C7917DB6045940CC@zsc4c004.us.nortel.com> From: Sundeep Singatwaria To: "'Bill Fenner'" , "'john.zwiebel@procket.com'" Cc: "'brmclaug@cisco.com'" , "'bwilliam@cisco.com'" , Brian Haberman , "'pim@catarina.usc.edu'" , "'magma@innovationslab.net'" , "'idmr@cs.ucl.ac.uk'" Subject: RE: [Magma] Re: MSNIP Date: Fri, 3 Aug 2001 18:28:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11C84.C63F9100" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11C84.C63F9100 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Bill Fenner [mailto:fenner@research.att.com] Sent: Friday, August 03, 2001 2:54 PM To: john.zwiebel@procket.com Cc: brmclaug@cisco.com; bwilliam@cisco.com; Haberman, Brian [NCWIN:6T50:EXCH]; pim@catarina.usc.edu; magma@innovationslab.net; idmr@cs.ucl.ac.uk Subject: Re: [Magma] Re: MSNIP >Multicast doesn't have a nice handshake like TCP to start a session. Neither does IP. >Customers (some customers anyway) insist that multicast not lose any >data. Expecting the network to be able to immediately set up a (S,G) >route as soon as a source starts dumping data on to the LAN is never >going to work. As you say, the right answer here is to a) Set their expectations properly. b) Design a protocol that meets their expectations. The answer to "b" probably should not require any IP-level changes. > Isn't PGM supposed to be doing this ? Bill ------_=_NextPart_001_01C11C84.C63F9100 Content-Type: text/html; charset="iso-8859-1" RE: [Magma] Re: MSNIP

-----Original Message-----
From: Bill Fenner [mailto:fenner@research.att.com]
Sent: Friday, August 03, 2001 2:54 PM
To: john.zwiebel@procket.com
Cc: brmclaug@cisco.com; bwilliam@cisco.com; Haberman, Brian
[NCWIN:6T50:EXCH]; pim@catarina.usc.edu; magma@innovationslab.net;
idmr@cs.ucl.ac.uk
Subject: Re: [Magma] Re: MSNIP



>Multicast doesn't have a nice handshake like TCP to start a session.

Neither does IP.

>Customers (some customers anyway) insist that multicast not lose any
>data.  Expecting the network to be able to immediately set up a (S,G)
>route as soon as a source starts dumping data on to the LAN is never
>going to work.

As you say, the right answer here is to
a) Set their expectations properly.
b) Design a protocol that meets their expectations.

The answer to "b" probably should not require any IP-level changes.

> Isn't PGM supposed to be doing this ?

  Bill

------_=_NextPart_001_01C11C84.C63F9100-- From owner-idmr@cs.ucl.ac.uk Mon Aug 13 08:10:08 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16106 for ; Mon, 13 Aug 2001 08:10:08 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 13 Aug 2001 12:06:59 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Aug 2001 12:06:53 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 13 Aug 2001 12:06:48 +0100 Received: from vernille.loria.fr (IDENT:lahmadi@vernille.loria.fr [152.81.11.123]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id NAA18577 for ; Mon, 13 Aug 2001 13:06:45 +0200 (MET DST) From: Abdelkader Lahmadi Organization: LORIA To: idmr@cs.ucl.ac.uk Subject: upstream/downstream interface Date: Mon, 13 Aug 2001 13:01:46 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01081313064500.03499@vernille.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, in the specification of the igmp proxy does an interface can be at the same time an upstream interface and downstream interface? for example if on the upstream interface there are also members of a group. --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Mon Aug 13 09:41:28 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19962 for ; Mon, 13 Aug 2001 09:41:27 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 13 Aug 2001 13:52:45 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Aug 2001 13:52:39 +0100 Received: from malmo.trab.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 13 Aug 2001 13:52:39 +0100 Received: from trab2822 (dhcp-rsm-146142.ram.malmo.trab.se [131.115.146.142]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id f7DCojP17531; Mon, 13 Aug 2001 14:50:45 +0200 (MEST) From: =?iso-8859-1?Q?Samuel_Sundstr=F6m?= To: Abdelkader Lahmadi , idmr Subject: RE: upstream/downstream interface Date: Mon, 13 Aug 2001 14:50:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <01081313064500.03499@vernille.loria.fr> Importance: Normal Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hi, in the specification of the igmp proxy does an interface can be at the same time an upstream interface and downstream interface? for example if on the upstream interface there are also members of a group. According to my understanding of the protocol, an interface of a proxy is either upstream or downstream for a certain group. On the upstream if (towards the multicast-tree), the proxy employs the host porton of IGMP and on the downstream ifs it employs the router portion of IGMP. What might confuse is the case when a member on a downstream interface is also a sender, maybe that's what you're asking here; Then the proxy shall forward traffic from that source (received on that particular downstream interface) out on the other downstream interfaces as well as the upstream interface [thus making the upstream interface look like a downstream, maybe]. By definition, upstream is towards the tree and, hopefully, there are some members of the group there as well. /samuel -- Samuel Sundstrom [Samuel.L.Sundstrom@telia.se] IP core networks Telia Research Aurorum 6 SE-97775 Lulea, Sweden From owner-idmr@cs.ucl.ac.uk Mon Aug 13 11:00:14 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21553 for ; Mon, 13 Aug 2001 11:00:14 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 13 Aug 2001 14:53:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Aug 2001 14:53:35 +0100 Received: from h157s242a129n47.user.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 13 Aug 2001 14:53:35 +0100 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7DDrDp25264 for ; Mon, 13 Aug 2001 09:53:13 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Mon, 13 Aug 2001 09:53:02 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q5XKF6WY; Mon, 13 Aug 2001 09:52:52 -0400 Received: from nortelnetworks.com (dhcp137-137.engeast.baynetworks.com [192.32.137.137]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLTQ6X97; Mon, 13 Aug 2001 09:52:58 -0400 Message-ID: <3B77DB6E.FBFE4E9@nortelnetworks.com> Date: Mon, 13 Aug 2001 09:51:42 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Haixiang He X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Abdelkader Lahmadi CC: idmr@cs.ucl.ac.uk Subject: Re: upstream/downstream interface References: <01081313064500.03499@vernille.loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit In IGMP Proxy, we assume that there is no multicast protocol running. And the multicast distribution tree is statically configured where the root is the Proxy. Then we define the interface that connect the Proxy to the multicast cloud as the upstream interface and there is only ONE upstream interface. All other interfaces of the Proxy are considered as downstream interface(s). These are the terms we defined to describe the protocol. haixiang Abdelkader Lahmadi wrote: > hi, > > in the specification of the igmp proxy does an interface can be at the same > time an upstream interface and downstream interface? > for example if on the upstream interface there are also members of a group. > > --------------------------------------------- > Lahmadi Abdelkader > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : lahmadi@loria.fr > --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Mon Aug 13 11:54:00 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22771 for ; Mon, 13 Aug 2001 11:53:59 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 13 Aug 2001 16:07:37 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Aug 2001 15:59:34 +0100 Received: from prue.eim.surrey.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Mon, 13 Aug 2001 15:59:34 +0100 Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15WJBb-0003FN-00; Mon, 13 Aug 2001 15:59:23 +0100 Date: Mon, 13 Aug 2001 15:59:20 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Haixiang He cc: Abdelkader Lahmadi , idmr@cs.ucl.ac.uk Subject: Re: upstream/downstream interface In-Reply-To: <3B77DB6E.FBFE4E9@nortelnetworks.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15WJBb-0003FN-00*Q6D0afgYitY* http://duncanthrax.net/exiscan/ Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Mon, 13 Aug 2001, Haixiang He wrote: > In IGMP Proxy, we assume that there is no multicast protocol running. And the > multicast distribution tree is statically configured where the root is the > Proxy. Then we define the interface that connect the Proxy to the multicast > cloud as the upstream interface and there is only ONE upstream interface. Just so I'm clear on this: you're not considering a proxy that receives from the multicast cloud via one (unidirectional, receive-only) interface, and sends traffic to the multicast cloud via a separate (unidirectional, send-only) interface? > All other interfaces of the Proxy are considered as downstream > interface(s). These are the terms we defined to describe the > protocol. According to this, one of the unidirectional interfaces I describe above would need to be considered as a downstream interface - although both are enabling upstream connectivity. I find that an odd contradiction. cheers, L. PGP From owner-idmr@cs.ucl.ac.uk Tue Aug 14 07:58:30 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27942 for ; Tue, 14 Aug 2001 07:58:29 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 14 Aug 2001 12:18:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 14 Aug 2001 12:18:37 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 14 Aug 2001 12:18:38 +0100 Received: from joudreville.loria.fr (IDENT:lahmadi@joudreville.loria.fr [152.81.11.89]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id NAA29982; Tue, 14 Aug 2001 13:18:36 +0200 (MET DST) From: Abdelkader Lahmadi Organization: LORIA To: Jung Cyndi-ACJ099 Subject: RE: upstream/downstream interface Date: Tue, 14 Aug 2001 12:59:33 +0200 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: In-Reply-To: Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01081413211100.26967@joudreville.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 13 Aug 2001, you wrote: > A receiver on the upstream interface require no effort of the igmp > proxy they should receive the multicast data before it arrives at the igmp proxy. > > Cyndi > i guess that an igmp proxy is realtive to a static multicast tree, where the upstream interface is in the direction of the root of the tree (or the sender), is correct ? --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Thu Aug 16 16:23:33 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21955 for ; Thu, 16 Aug 2001 16:23:33 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 16 Aug 2001 20:44:23 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Aug 2001 20:44:17 +0100 Received: from emerson.torrentnet.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 16 Aug 2001 20:44:17 +0100 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7GJiGG10130; Thu, 16 Aug 2001 15:44:16 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7GJiGb92632; Thu, 16 Aug 2001 15:44:16 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7GJiGQ03829; Thu, 16 Aug 2001 15:44:16 -0400 (EDT) Date: Thu, 16 Aug 2001 15:44:16 -0400 (EDT) From: Todd Hayton To: idmr cc: fenner Subject: IGMPv3 QRV and QQI values Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hello, In IGMPv3 draft it is stated that the QRV and QQI values contain the [Robustness Value] and [Query Interval] used by the current querier. It also states that non-queriers should adopt these values as their own. Once a non-querier adopts these values as its own, when is it going to use these values (since it's not actually sending out queries)? It looked as if there were two possible uses: 1) The non-querier uses the received QRV and QQI values to calculate a new Other Querier Present Interval: QRV * QQI + [0.5 * Query Response Interval] And I'm assuming the scenario for this is that because of network latency, we increase the [Robustness Variable] and [Query Response Interval] on the current querier, and so we want non-queriers to wait longer as well before deciding that the current querier has expired. 2) If we adopt these values as our own, and the current querier does in fact expire, should we use the adopted values (for things such as General Queries, retransmissions, etc), or should we revert back to the default values? Regards, Todd Hayton From owner-idmr@cs.ucl.ac.uk Mon Aug 20 20:01:30 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07843 for ; Mon, 20 Aug 2001 20:01:29 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 21 Aug 2001 00:10:20 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Aug 2001 00:10:15 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 21 Aug 2001 00:10:16 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 956A54CE51; Mon, 20 Aug 2001 19:10:15 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA15656; Mon, 20 Aug 2001 19:10:14 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA23809; Mon, 20 Aug 2001 16:10:14 -0700 (PDT) Message-Id: <200108202310.QAA23809@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: thayton@torrentnet.com Subject: Re: IGMPv3 QRV and QQI values Cc: idmr@cs.ucl.ac.uk Date: Mon, 20 Aug 2001 16:10:14 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >Once a non-querier adopts these values as its own, when is it going to use >these values (since it's not actually sending out queries)? It will use them in derived values, e.g. Group Membership Interval, Other Querier Present Interval, Last Member Query Interval, Last Member Query Count, Older Host Present Interval. When a router becomes a Querier, it sends its own configured values as the QRV and QQI values. Bill From owner-idmr@cs.ucl.ac.uk Tue Aug 21 11:24:03 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20122 for ; Tue, 21 Aug 2001 11:23:57 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 21 Aug 2001 15:32:25 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Aug 2001 15:32:19 +0100 Received: from malmo.trab.se by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 21 Aug 2001 15:32:20 +0100 Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f7LEUWP24421; Tue, 21 Aug 2001 16:30:32 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Aug 2001 16:32:18 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D045FE013@trab-hermes.haninge.trab.se> From: Thomas Eriksson To: idmr@cs.ucl.ac.uk Cc: Ida Burlin , =?ISO-8859-1?Q?Kristofer_W=E5re?= =?ISO-8859-1?Q?ll?= , Niklas Borg , =?ISO-8859-1?Q?Samuel_Sundstr=F6m?= Subject: Auxiliary data field Date: Tue, 21 Aug 2001 16:32:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi, I have been pondering over the auxiliary data field, found in the group record of the IGMPv3 membership report message. A pointer to previous discussions on the issue why the working group decided to add the field would be appreciated. A summary of them would be even more appreciated. Thomas =============================================== Thomas Eriksson Office: +46 8 713 8120 Telia Research AB Fax: +46 8 713 8199 SE-123 86 Farsta Mobile: +46 70 566 1088 Sweden =============================================== From owner-idmr@cs.ucl.ac.uk Wed Aug 29 00:18:19 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28897 for ; Wed, 29 Aug 2001 00:18:19 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 29 Aug 2001 04:29:04 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 29 Aug 2001 04:28:58 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 29 Aug 2001 04:29:01 +0100 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 30B2A1E15D; Tue, 28 Aug 2001 23:28:54 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA07826; Tue, 28 Aug 2001 23:28:52 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id UAA00455; Tue, 28 Aug 2001 20:28:52 -0700 (PDT) Message-Id: <200108290328.UAA00455@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: thomas.a.eriksson@telia.se Subject: Re: Auxiliary data field Cc: idmr@cs.ucl.ac.uk, ida.k.burlin@telia.se, kristofer.j.warell@telia.se, niklas.g.borg@telia.se, samuel.l.sundstrom@telia.se Date: Tue, 28 Aug 2001 20:28:51 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk It's an extension mechanism. In previous IGMP versions, each message contained a fixed-length report about a single group, so any extensions could unambiguously be appended to the packet. Since IGMPv3 has variable-length reports, potentially with multiple groups, in order to keep the same extension ability we added the auxilliary data field. I don't know if anyone has any concrete ideas for what to use the field for; one thing that's been suggested several times is to provide authentication information. Bill From owner-idmr@cs.ucl.ac.uk Fri Aug 31 05:09:02 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26980 for ; Fri, 31 Aug 2001 05:09:02 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 31 Aug 2001 09:25:35 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 31 Aug 2001 09:25:29 +0100 Received: from 203.197.141.34 by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 31 Aug 2001 09:25:30 +0100 Received: from cdc2vwall.wipro.com (cdc2vwall.wipro.com [10.145.0.23]) by raksha.wipro.com (8.11.3/8.11.3) with SMTP id f7V8PqI07130 for ; Fri, 31 Aug 2001 13:55:53 +0530 (IST) Received: from Vinod ([10.145.2.225]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GIXBG700.8AQ for ; Fri, 31 Aug 2001 13:56:31 +0530 Message-ID: <01c901c131f7$0d576900$e102910a@wipro.com> From: Vinodkumar Parasmal To: IDMR Subject: IGMPv3 Router Implementation Date: Fri, 31 Aug 2001 13:59:28 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I wanted to know if there is any implementation of IGMPv3 Router available ? Thanks in advance Vinod --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit --------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ----------------------------------------------------------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary-- From owner-idmr@cs.ucl.ac.uk Fri Aug 31 06:26:10 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27498 for ; Fri, 31 Aug 2001 06:26:09 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 31 Aug 2001 10:46:18 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 31 Aug 2001 10:46:12 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 31 Aug 2001 10:46:14 +0100 Received: from dargneuilles.loria.fr (IDENT:lahmadi@dargneuilles.loria.fr [152.81.11.183]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id LAA25481; Fri, 31 Aug 2001 11:45:55 +0200 (MET DST) From: Abdelkader Lahmadi Organization: LORIA To: Vinodkumar Parasmal Subject: IGMPv3 router Date: Fri, 31 Aug 2001 11:41:51 +0200 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01083111455400.08079@dargneuilles.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hi, i have an implementation of IGMPv3 router. i had implement it according to the last draft of IGMPv3. soon, i will put the code on a web page. perhaps this week end. the implementatio is a demon that send IGMPv3 query and maintain an IGMP table. regards, --------------------------------------------- Lahmadi Abdelkader LORIA - UHP NANCY I CAMPUS SCIENTIFIQUE B.P.239 54506 VANDOEUVRE-LES-NANCY CEDEX E-mail : lahmadi@loria.fr --------------------------------------------- From owner-idmr@cs.ucl.ac.uk Fri Aug 31 06:26:13 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27511 for ; Fri, 31 Aug 2001 06:26:12 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 31 Aug 2001 11:12:29 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 31 Aug 2001 11:12:22 +0100 Received: from london.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 31 Aug 2001 11:12:13 +0100 Received: from BRMCLAUG-W2K1.cisco.com (brmclaug-isdn-home.cisco.com [10.49.128.246]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA25059; Fri, 31 Aug 2001 11:11:55 +0100 (BST) Message-Id: <4.3.2.7.2.20010831110502.01e610d0@london.cisco.com> X-Sender: brmclaug@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Aug 2001 11:11:40 +0100 To: Vinodkumar Parasmal From: Bryan Mclaughlin Subject: Re: IGMPv3 Router Implementation Cc: IDMR In-Reply-To: <01c901c131f7$0d576900$e102910a@wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Vinod, If you are asking do any routers support IGMPv3 then yes. If you are asking about available code for you to utilise then none that I know of, only host stacks. http://videolab.uoregon.edu/projects.html#SSM Bryan At 13:59 31/08/2001 +0530, Vinodkumar Parasmal wrote: >Hi, >I wanted to know if there is any implementation of IGMPv3 Router >available ? > >Thanks in advance >Vinod > > Bryan Mclaughlin Technical Marketing Engineer Telephone :+44 (0)20 8756 8811 IOS Technology Division Email :brmclaug@cisco.com Cisco Systems Mobile :+44 (0)7710 164487