From owner-idmr@cs.ucl.ac.uk Wed Mar 6 18:44:32 2002 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 SAA15658 for ; Wed, 6 Mar 2002 18:44:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 6 Mar 2002 23:13:05 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Mar 2002 18:46:47 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 6 Mar 2002 18:43:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26371; Wed, 6 Mar 2002 13:43:01 -0500 (EST) Message-Id: <200203061843.NAA26371@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-magma-igmpv3-and-routing-02.txt Date: Wed, 06 Mar 2002 13:43:00 -0500 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 : IGMPv3 and Multicast Routing Protocol Interaction Author(s) : B. Haberman, J. Martin Filename : draft-ietf-magma-igmpv3-and-routing-02.txt Pages : 5 Date : 05-Mar-02 The definition of IGMPv3 requires new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 messages necessitates that multicast routing protocols manage and utilize the information. This document will describe how IGMPv3 and multicast routing protocols interact. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-magma-igmpv3-and-routing-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-magma-igmpv3-and-routing-02.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-magma-igmpv3-and-routing-02.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: <20020305141932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-magma-igmpv3-and-routing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-magma-igmpv3-and-routing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305141932.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Thu Mar 7 08:51:11 2002 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 IAA24193 for ; Thu, 7 Mar 2002 08:51:11 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 7 Mar 2002 13:14:55 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Mar 2002 13:14:45 +0000 Received: from drawbridge.ascend.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 7 Mar 2002 13:10:59 +0000 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id FAA17871 for ; Thu, 7 Mar 2002 05:10:55 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 7 Mar 2002 13:10:55 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id FAA19725 for ; Thu, 7 Mar 2002 05:10:54 -0800 (PST) Received: from india.ascend.com (h135-254-196-198.outland.lucent.com [135.254.196.198]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id FAA15796 for ; Thu, 7 Mar 2002 05:10:53 -0800 (PST) Received: from ascend.com (tulalip.india.ascend.com [135.254.196.41]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id SAA03861 for ; Thu, 7 Mar 2002 18:37:21 +0530 (IST) Message-ID: <3C87660F.71206624@ascend.com> Date: Thu, 07 Mar 2002 18:37:27 +0530 From: Srivatsan S Reply-To: srivatsan@lucent.com X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: "'idmr@cs.ucl.ac.uk'" Subject: IGMPv3 Proxying Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, An IGMP proxy behaves as a router on the downstream i/fs and host on the upstream i/fs. Similarly for an IGMPv3 proxy, a router has to perform as both router and host on downstream and upstream i/fs respectively. I am specifically looking at this particular context (IGMPv3 Proxying). Consider a case where a group has been registered and mode is EXCLUDE. At present, one source is registered under EXCLUDE mode which should be completely blocked (source_timer = 0). Now, the router receives a request for the source to be unblocked on the same interface (i.e., a conflict occurs). Now, a source_timer is started for this source. How should this change be communicated on the upstream i/f side to the neighbouring Mcast Router. According to the state table under the Section 5.1 in the draft for igmpv3, following has been mentioned. Old State New State State-Change Record Sent --------- --------- ------------------------ EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) In the particular case I mentioned, A-B and B-A = 0 and hence no report is sent. But in effect, mcast data packets from the source should be forwarded to the proxy. I think on the upstream side, in addition to the change in the number of hosts, the state of the source should also be taken care of. Am I missing something here ? Thanks In Advance, Srivatsan -- Srivatsan S Email: srivatsan@lucent.com Phone: 91-80-8520261 Extn 6506 Bangalore, India. From owner-idmr@cs.ucl.ac.uk Thu Mar 7 12:28:03 2002 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 MAA08962 for ; Thu, 7 Mar 2002 12:28:02 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 7 Mar 2002 16:57:48 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Mar 2002 16:57:42 +0000 Received: from zcars0m9.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 7 Mar 2002 16:54:04 +0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27GrxT03485; Thu, 7 Mar 2002 11:53:59 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g27GruL12131; Thu, 7 Mar 2002 11:53:56 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FX1QYFVQ; Thu, 7 Mar 2002 11:53:55 -0500 Received: from nortelnetworks.com (dhcp225-230.engeast.baynetworks.com [192.32.225.230]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQMZ5V2F; Thu, 7 Mar 2002 11:53:54 -0500 Message-ID: <3C879A36.A9CEE83D@nortelnetworks.com> Date: Thu, 07 Mar 2002 11:49:58 -0500 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: srivatsan@lucent.com CC: "'idmr@cs.ucl.ac.uk'" , magma@innovationslab.net Subject: Re: IGMPv3 Proxying References: <3C87660F.71206624@ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, You ask a very good question. Since IGMP proxying work is moved to MAGMA so I also CC this to MAGMA mailing list. I think we can understand this way. IGMP proxying is proxying IGMP requests not relaying IGMP requests. So some information may be lost during the proxying. But the bottom line is that the multicast traffic forwarding should not be affected. In IGMPv3 specification section 3, we can see that the INCLUDE information is not communicated to the routers if the interface mode is EXCLUDE. Similar in IGMP proxying, some information is not communicated. If an interface is in EXCLUDE mode and the source S' source_timer>0, S is actually in INCLUDE mode. The rationale to keep this source record is described in IGMPv3 specification A.3. So in your example, the old state is EXCLUDE( {S}) and the new state is EXCLUDE( {}). ALLOW({S}-{})= ALLOW({S}). So the traffic from S will be forwarded to the proxy. I do think that we should clarify this in the draft since IGMPv3 draft does not deal this issue. Regards, Haixiang Srivatsan S wrote: > Hi, > > An IGMP proxy behaves as a router on the downstream i/fs and host on > the upstream i/fs. Similarly for an IGMPv3 proxy, a router has to > perform as both router and host on downstream and upstream i/fs > respectively. I am specifically looking at this particular context > (IGMPv3 Proxying). > > Consider a case where a group has been registered and mode is > EXCLUDE. At present, one source is registered under EXCLUDE mode which > should be completely blocked (source_timer = 0). Now, the router > receives a request for the source to be unblocked on the same interface > (i.e., a conflict occurs). Now, a source_timer is started for this > source. How should this change be communicated on the upstream i/f side > to the neighbouring Mcast Router. According to the state table under the > Section 5.1 in the draft for igmpv3, following has been mentioned. > > Old State New State State-Change Record Sent > --------- --------- ------------------------ > EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) > > In the particular case I mentioned, A-B and B-A = 0 and hence no > report is sent. But in effect, mcast data packets from the source should > be forwarded to the proxy. I think on the upstream side, in addition to > the change in the number of hosts, the state of the source should also > be taken care of. Am I missing something here ? > > Thanks In Advance, > Srivatsan > > -- > Srivatsan S > Email: srivatsan@lucent.com > Phone: 91-80-8520261 Extn 6506 > Bangalore, India. From owner-idmr@cs.ucl.ac.uk Fri Mar 8 02:21:47 2002 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 CAA23984 for ; Fri, 8 Mar 2002 02:21:46 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 8 Mar 2002 06:57:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Mar 2002 06:57:50 +0000 Received: from net090s.hetnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 8 Mar 2002 06:54:18 +0000 Received: from WDEGRAAFTO8100 ([63.202.179.214]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 8 Mar 2002 07:54:10 +0100 Message-ID: <000201c1c66e$1c348230$6501a8c0@inktomi.com> From: Wilbert de Graaf To: srivatsan Cc: idmr References: <3C87660F.71206624@ascend.com> Subject: Re: IGMPv3 Proxying Date: Thu, 7 Mar 2002 08:40:40 -0800 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Srivatsan, > Consider a case where a group has been registered and mode is > EXCLUDE. At present, one source is registered under EXCLUDE mode which > should be completely blocked (source_timer = 0). Now, the router > receives a request for the source to be unblocked on the same interface > (i.e., a conflict occurs). Now, a source_timer is started for this > source. How should this change be communicated on the upstream i/f side > to the neighbouring Mcast Router. Probably ALLOW(that source) > According to the state table under the > Section 5.1 in the draft for igmpv3, following has been mentioned. > > Old State New State State-Change Record Sent > --------- --------- ------------------------ > EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A) > In the particular case I mentioned, A-B and B-A = 0 and hence no I don't think A-B = 0. If that source was labelled 's', and substitute A = s, than B = s - s = 0, than A - B= {s} - 0 = {s} -> ALLOW {s} > report is sent. But in effect, mcast data packets from the source should > be forwarded to the proxy. I think on the upstream side, in addition to > the change in the number of hosts, the state of the source should also > be taken care of. Am I missing something here ? From owner-idmr@cs.ucl.ac.uk Sun Mar 10 18:57:38 2002 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 SAA16335 for ; Sun, 10 Mar 2002 18:57:38 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 10 Mar 2002 23:19:58 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Mar 2002 14:48:21 +0000 Received: from sundance.cse.ucsc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 10 Mar 2002 14:44:45 +0000 Received: from localhost (ajoy@localhost) by sundance.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id GAA12207; Sun, 10 Mar 2002 06:44:44 -0800 From: ajoy@cse.ucsc.edu X-Authentication-Warning: sundance.cse.ucsc.edu: ajoy owned process doing -bs Date: Sun, 10 Mar 2002 06:44:44 -0800 (PST) To: idmr@cs.ucl.ac.uk, ipmulticast Subject: Re: Request for help In-Reply-To: <00ae01c1bf0b$93774fe0$f788bc3e@vaionote> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi, I'm a grad student, trying to run some simulations to compare the performance of a protocol with that of CBT. However, i have so far been unable to get hold of a CBT implementation for ns. I was informed by Tony Ballardie that i could possobly get it from you. Please pass on any tips regarding the implementation of CBT in ns. Thank you very much -Ajoy On Tue, 26 Feb 2002, Tony Ballardie wrote: > > Ajoy, > > > I'm a CS graduate student, currently trying to run some simulations using > > ns-2 to compare the performance of a protocol with that of CBT. > > > > I have so far been unable to simulate CBT in ns. > > I'll be grateful if you could give some tips on running CBT simulations > > using ns-2, or if you could give me contacts of students who have already > > done this. > > I'm fairly sure CBT has been implemented in ns, but can't recall > by whom. I would suggest you send an e-mail request to > idmr@cs.ucl.ac.uk, and ipmulticast@lists.servicenetworks.com > > Hope you find it. > > Tony > > From owner-idmr@cs.ucl.ac.uk Tue Mar 12 09:31:13 2002 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 JAA23043 for ; Tue, 12 Mar 2002 09:31:12 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 12 Mar 2002 13:55:56 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Mar 2002 13:55:47 +0000 Received: from drawbridge.ascend.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 12 Mar 2002 13:51:54 +0000 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id FAA23757 for ; Tue, 12 Mar 2002 05:51:52 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 12 Mar 2002 13:51:52 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id FAA05035 for ; Tue, 12 Mar 2002 05:51:52 -0800 (PST) Received: from india.ascend.com (h135-254-196-198.outland.lucent.com [135.254.196.198]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id FAA11760 for ; Tue, 12 Mar 2002 05:51:50 -0800 (PST) Received: from ascend.com (tulalip.india.ascend.com [135.254.196.41]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id TAA09696 for ; Tue, 12 Mar 2002 19:19:06 +0530 (IST) Message-ID: <3C8E073A.AF2EFC5@ascend.com> Date: Tue, 12 Mar 2002 19:18:42 +0530 From: Srivatsan S Reply-To: srivatsan@lucent.com X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: "'idmr@cs.ucl.ac.uk'" Subject: IGMPv3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Quoting from the igmpv3 draft: From Section 3.2 regarding Interface State: o if *any* such record has a filter mode of EXCLUDE, then the filter mode of the interface record is EXCLUDE, and the source list of the interface record is the intersection of the source lists of all socket records in EXCLUDE mode, minus those source addresses that appear in any socket record in INCLUDE mode. For example, if the socket records for multicast address m on interface i are: from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) from socket s3: ( i, m, INCLUDE, {d, e, f} ) then the corresponding interface record on interface i is: ( m, EXCLUDE, {b, c} ) I think the above condition for sockets in EXCLUDE mode will hold good if and only if the sources for s1 and s2 are completely blocked. If source timer is running on any of the sources 'b' or 'c', I think this is not valid. The intersection of source lists of all socket records in EXCLUDE mode works only for all blocked sources. I think this point is not clear in the draft. Thanks, Srivatsan -- Srivatsan S Email: srivatsan@lucent.com Phone: 91-80-8520261 Extn 6506 Bangalore, India. From owner-idmr@cs.ucl.ac.uk Tue Mar 12 11:55:48 2002 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 LAA27267 for ; Tue, 12 Mar 2002 11:55:48 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 12 Mar 2002 16:09:27 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Mar 2002 16:09:20 +0000 Received: from zcars04e.nortelnetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 12 Mar 2002 16:05:36 +0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2CG5TZ21833; Tue, 12 Mar 2002 11:05:29 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWB0P40Q; Tue, 12 Mar 2002 11:05:28 -0500 Received: from nortelnetworks.com (dhcp225-230.engeast.baynetworks.com [192.32.225.230]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FQMZ56T1; Tue, 12 Mar 2002 11:05:29 -0500 Message-ID: <3C8E265C.7CA87228@nortelnetworks.com> Date: Tue, 12 Mar 2002 11:01:32 -0500 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: srivatsan@lucent.com CC: "'idmr@cs.ucl.ac.uk'" Subject: Re: IGMPv3 References: <3C8E073A.AF2EFC5@ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Srivatsan S wrote: > Hi, > > Quoting from the igmpv3 draft: > >From Section 3.2 regarding Interface State: > > o if *any* such record has a filter mode of EXCLUDE, then the filter > mode of the interface record is EXCLUDE, and the source list of the > interface record is the intersection of the source lists of all socket > records in EXCLUDE mode, minus those source addresses that appear in > any socket record in INCLUDE mode. For example, if the socket records > for multicast address m on interface i are: > > from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) > from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) > from socket s3: ( i, m, INCLUDE, {d, e, f} ) > > then the corresponding interface record on interface i is: > > ( m, EXCLUDE, {b, c} ) > > I think the above condition for sockets in EXCLUDE mode will > hold good if and only if the sources for s1 and s2 are completely > blocked. If source timer is running on any of the sources 'b' or > 'c', I think this is not valid. The intersection of source lists > of all socket records in EXCLUDE mode works only for all blocked > sources. I think this point is not clear in the draft. The "source record" and "source timer" are only used in the IGMPv3 router portion. From an IGMPv3 host socket point of view, there is no "source timer" that associates a source. Also "source timer" is not used in a host's interface record. In IGMP Proxying, the upstream IGMP host interface record is computed according to the downstream IGMP router interface records that contain the "source timer". As I described in my last email, we should clarify this issue in the IGMP Proxying draft. Haixiang > > > Thanks, > Srivatsan > > -- > Srivatsan S > Email: srivatsan@lucent.com > Phone: 91-80-8520261 Extn 6506 > Bangalore, India. From owner-idmr@cs.ucl.ac.uk Thu Mar 14 06:00:12 2002 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 GAA14700 for ; Thu, 14 Mar 2002 06:00:12 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 14 Mar 2002 10:28:17 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Mar 2002 10:28:11 +0000 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 14 Mar 2002 10:24:26 +0000 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 LAA20120 for ; Thu, 14 Mar 2002 11:24:21 +0100 (MET) From: Abdelkader Lahmadi Organization: LORIA To: "'idmr@cs.ucl.ac.uk'" Subject: igmp proxinig Date: Thu, 14 Mar 2002 11:23:02 +0100 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <02031411241600.07472@dargneuilles.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hello, on the draftt of the IGMP proxing i can't understant the "upstream loop", can someone calrify it ? thanks in advance -- --------------------------------------------- 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 Mar 14 07:14:57 2002 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 HAA15603 for ; Thu, 14 Mar 2002 07:14:57 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 14 Mar 2002 11:45:25 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Mar 2002 11:45:14 +0000 Received: from drawbridge.ascend.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 14 Mar 2002 11:41:28 +0000 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id DAA26175; Thu, 14 Mar 2002 03:41:26 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 14 Mar 2002 11:41:26 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id DAA22304; Thu, 14 Mar 2002 03:41:25 -0800 (PST) Received: from india.ascend.com (h135-254-196-198.outland.lucent.com [135.254.196.198]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id DAA25144; Thu, 14 Mar 2002 03:41:24 -0800 (PST) Received: from ascend.com (tulalip.india.ascend.com [135.254.196.41]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id RAA12933; Thu, 14 Mar 2002 17:08:42 +0530 (IST) Message-ID: <3C908BB1.C481D001@ascend.com> Date: Thu, 14 Mar 2002 17:08:25 +0530 From: Srivatsan S Reply-To: srivatsan@lucent.com X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Abdelkader Lahmadi CC: "'idmr@cs.ucl.ac.uk'" Subject: Re: igmp proxinig References: <02031411241600.07472@dargneuilles.loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The "upstream loop" indicates the mcast packets forwarded to LAN2 from LAN1 by 'A' is again forwarded back to LAN1 by 'B'. This leads to duplicity of packets on LAN1 (by McastRouter earlier and by 'B' again). This has to be resolved by an McastRouter on LAN1 which uses a mechanism called Reverse Path Forwarding (RPF) to find the best incoming interface for data packets destined for a group source combination. Hope this helps. Thanks, Srivatsan Abdelkader Lahmadi wrote: > > hello, > on the draftt of the IGMP proxing i can't understant the "upstream loop", can > someone calrify it ? > thanks in advance > -- > --------------------------------------------- > Lahmadi Abdelkader > LORIA - UHP NANCY I > CAMPUS SCIENTIFIQUE B.P.239 > 54506 VANDOEUVRE-LES-NANCY CEDEX > E-mail : lahmadi@loria.fr > --------------------------------------------- -- Srivatsan S Phone: 91-80-8520261 Extn 6506 Bangalore, India. From owner-idmr@cs.ucl.ac.uk Tue Mar 26 09:50:31 2002 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 JAA04819 for ; Tue, 26 Mar 2002 09:50:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 26 Mar 2002 13:34:31 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 26 Mar 2002 09:30:35 +0000 Received: from 61.73.62.148 by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 26 Mar 2002 09:26:19 +0000 Received: from localhost (localhost [[UNIX: localhost]]) by ysh.karam.co.kr (8.11.0/8.11.0) id g2Q9Q8S16449 for idmr@cs.ucl.ac.uk; Tue, 26 Mar 2002 18:26:08 +0900 Message-Id: <200203260926.g2Q9Q8S16449@ysh.karam.co.kr> Content-Type: text/plain; charset="euc-kr" From: ysh Reply-To: ysh@karam.co.kr Organization: karam To: idmr@cs.ucl.ac.uk Subject: [ Request joining MBone ] Date: Tue, 26 Mar 2002 18:26:08 +0900 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit Hi, my name is Yoon S.H. living in seoul, Korea. I'd like to join the MBone. But I have no idea how to join the Mbone. Can you tell me the way of joining the Mbone? What should I do to join the MBone? Can you help me? I'd like to use mrouted, because my router didn't support multicast. Please, give a piece of advice.... Thanks....