From owner-idmr@cs.ucl.ac.uk Wed May 2 04:00:32 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03367 for ; Wed, 2 May 2001 04:00:32 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 26 Apr 2001 22:40:56 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Apr 2001 22:40:50 +0100 Received: from newgate.mitel.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Thu, 26 Apr 2001 22:41:11 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA05654; Thu, 26 Apr 2001 17:34:14 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A3A.00767C56 ; Thu, 26 Apr 2001 17:34:10 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk cc: brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Message-ID: <85256A3A.00767A61.00@kanmta01.software.mitel.com> Date: Thu, 26 Apr 2001 14:34:04 -0700 Subject: Suppress router-side processing flag in IGMPv3 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, My understaning of the "suppress router-side processing flag (S-flag) is that it is used to synchronize timer updates between the querier and the rest of the routers in the subnet. The querier will set the S-flag in a query to 1 if itself will not update the corresponding timer after sending the query. When the other router receives a query with S-flag set to 1, they will not update the corresponding timer either. Otherwise, they will lower the timer to LMQI. My question is -- when a router sends or receives a query with the S-flag not set and the corresponding timer is smaller than LMQI, should it set the timer to LMQI?? Thanks, -- James C. Huang From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:42 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03437 for ; Wed, 2 May 2001 04:08:41 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 02:23:58 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 02:23:53 +0100 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 02:24:13 +0100 Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA09664; Thu, 26 Apr 2001 18:24:38 -0700 (PDT) Received: from localhost (kouvelas@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA13822; Thu, 26 Apr 2001 18:24:12 -0700 (PDT) Message-Id: <200104270124.SAA13822@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: kouvelas owned process doing -bs To: James_Huang@Mitel.COM cc: idmr@cs.ucl.ac.uk, Isidor Kouvelas Subject: Re: Another IGMPv3 question In-reply-to: Your message of "Thu, 26 Apr 2001 17:54:56 PDT." <85256A3B.00050819.00@kanmta01.software.mitel.com> Date: Thu, 26 Apr 2001 18:24:12 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The periodic query / report mechanism of IGMP will make sure that the INCLUDE hosts get a chance to report before the exclude timer expires hence the X set will contain the list of sources to use when switching to include mode. thanks I James_Huang@Mitel.COM writes: > > >From: James Huang@MITEL on 04/26/2001 05:54 PM PDT >Hi Isidor: > > I found the the following quote from an email you sent back in Aug/2000. > >"When the last host in EXCLUDE mode leaves the group, the router sends a group >specific query. This causes the EXCLUDE group timer on the router to be lowere >d. >At this point all hosts in INCLUDE mode respond and update the list X. As ther >e >are no hosts left in EXCLUDE mode, no EXCLUDE reports are received to update t >he >group timer. Hence the timer expires with all the sources in INCLUDE mode list >ed >in X. At this point list X is used as the list of source to forward in INCLUDE >mode." > > I believe what you described there is about the action to take when >receiving a TO_IN(A) report when in the EXCLUDE(X,Y) state. My question is >whether the router should also send a qroup-specific query when the group time >r >expires and the router is about to switch from the EXCLUDE mode to the INCLUDE >mode. When I read section 6.5 "Switching Router Filter-Modes", I can not find >any description about sending a group specific query when the group timer >expires. Without sending a group-sepcific query before switching the filter >mode of the group, you may end up not forwarding traffics from some sources >which have interested receivers in the subnet. This may happen, for example, >when the last EXCLUDE mode host crashes. Of course, the router only have to se >nd >the group-specific query if it has not sent such query recently. Otherwise, t >he >router will keep on sending group-specific queries. > > >Thanks, >-- James Huang > > From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:44 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03447 for ; Wed, 2 May 2001 04:08:43 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 02:29:14 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 02:29:05 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 02:29:25 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id VAA17665; Thu, 26 Apr 2001 21:29:21 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A3B.00082C86 ; Thu, 26 Apr 2001 21:29:16 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: Isidor Kouvelas , idmr@cs.ucl.ac.uk Message-ID: <85256A3B.00082BE2.00@kanmta01.software.mitel.com> Date: Thu, 26 Apr 2001 18:29:13 -0700 Subject: Re: Another IGMPv3 question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk From: James Huang@MITEL on 04/26/2001 06:29 PM PDT I understand now. It works because GMI is larger than (Query Interval + Query Response Interval). Thanks, James Huang Isidor Kouvelas on 04/26/2001 06:24:12 PM To: James Huang/USA/Mitel@Mitel cc: idmr@cs.ucl.ac.uk, Isidor Kouvelas Subject: Re: Another IGMPv3 question The periodic query / report mechanism of IGMP will make sure that the INCLUDE hosts get a chance to report before the exclude timer expires hence the X set will contain the list of sources to use when switching to include mode. thanks I James_Huang@Mitel.COM writes: > > >From: James Huang@MITEL on 04/26/2001 05:54 PM PDT >Hi Isidor: > > I found the the following quote from an email you sent back in Aug/2000. > >"When the last host in EXCLUDE mode leaves the group, the router sends a group >specific query. This causes the EXCLUDE group timer on the router to be lowere >d. >At this point all hosts in INCLUDE mode respond and update the list X. As ther >e >are no hosts left in EXCLUDE mode, no EXCLUDE reports are received to update t >he >group timer. Hence the timer expires with all the sources in INCLUDE mode list >ed >in X. At this point list X is used as the list of source to forward in INCLUDE >mode." > > I believe what you described there is about the action to take when >receiving a TO_IN(A) report when in the EXCLUDE(X,Y) state. My question is >whether the router should also send a qroup-specific query when the group time >r >expires and the router is about to switch from the EXCLUDE mode to the INCLUDE >mode. When I read section 6.5 "Switching Router Filter-Modes", I can not find >any description about sending a group specific query when the group timer >expires. Without sending a group-sepcific query before switching the filter >mode of the group, you may end up not forwarding traffics from some sources >which have interested receivers in the subnet. This may happen, for example, >when the last EXCLUDE mode host crashes. Of course, the router only have to se >nd >the group-specific query if it has not sent such query recently. Otherwise, t >he >router will keep on sending group-specific queries. > > >Thanks, >-- James Huang > > From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:46 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03457 for ; Wed, 2 May 2001 04:08:45 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 04:13:34 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 04:13:25 +0100 Received: from mailsrv.psl.com.sg by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 04:13:37 +0100 Received: from netpornote3 ([172.16.18.71]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with SMTP id f3R3A1U21413; Fri, 27 Apr 2001 11:10:01 +0800 (SGT) Reply-To: chenghong From: Cheng Hong To: James_Huang , idmr Subject: RE: Another IGMPv3 question Date: Fri, 27 Apr 2001 11:17:09 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <85256A3B.00050819.00@kanmta01.software.mitel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit I think the draft is not updated properly. Anyway, here is the reply I got for a related questions:: """"""""""""""""""""""""""""""""""""""""" >> >> If someone wanted A-B before the EXCLUDE statements group timer >> ran out, they would send a notice about it. This would stuff >> A-B in the X entry, so it would be there when you go to INCLUDE. >> > >Also in the table of page 32, it says that when the router is in >EXCLUDE(X,Y) state, if it received the IS_IN(A) report, the state would go >to EXCLUDE(X, Y-A). The X is not touched at all. I just checked: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-07.txt Actually it says this: EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A,Y-A) (A)=GMI Is there some other page you're refering to? > >So, consider a sequence like this: > INCLUDE(A) received IS_EX(B) --> EXCLUDE(A*B, B-A) received IS_IN(A) -- >> >EXCLUDE(A*B, B-A) received IS_EX(B) --> EXCLUDE(B-(B-A), (B-A)*B) = >EXCLUDE(B*A, B-A) >Seems it would never reach the EXCLUDE(A, B-A) which could lead to >INCLUDE(A) when the group timer expires. > """""""""""""""""""""""""""""""""""""""""""""" > -----Original Message----- > From: owner-idmr@cs.ucl.ac.uk [mailto:owner-idmr@cs.ucl.ac.uk]On Behalf > Of James_Huang@Mitel.COM > Sent: Friday, April 27, 2001 8:55 AM > To: idmr@cs.ucl.ac.uk; Isidor Kouvelas > Subject: Re: Another IGMPv3 question > > > > > From: James Huang@MITEL on 04/26/2001 05:54 PM PDT > Hi Isidor: > > I found the the following quote from an email you sent back > in Aug/2000. > > "When the last host in EXCLUDE mode leaves the group, the router > sends a group > specific query. This causes the EXCLUDE group timer on the router > to be lowered. > At this point all hosts in INCLUDE mode respond and update the > list X. As there > are no hosts left in EXCLUDE mode, no EXCLUDE reports are > received to update the > group timer. Hence the timer expires with all the sources in > INCLUDE mode listed > in X. At this point list X is used as the list of source to > forward in INCLUDE > mode." > > I believe what you described there is about the action to take when > receiving a TO_IN(A) report when in the EXCLUDE(X,Y) state. My question is > whether the router should also send a qroup-specific query when > the group timer > expires and the router is about to switch from the EXCLUDE mode > to the INCLUDE > mode. When I read section 6.5 "Switching Router Filter-Modes", I > can not find > any description about sending a group specific query when the group timer > expires. Without sending a group-sepcific query before switching > the filter > mode of the group, you may end up not forwarding traffics from > some sources > which have interested receivers in the subnet. This may happen, > for example, > when the last EXCLUDE mode host crashes. Of course, the router > only have to send > the group-specific query if it has not sent such query recently. > Otherwise, the > router will keep on sending group-specific queries. > > > Thanks, > -- James Huang > > > From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03467 for ; Wed, 2 May 2001 04:08:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 14:36:35 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 14:36:29 +0100 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 14:36:49 +0100 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id PAA20879 for ; Fri, 27 Apr 2001 15:36:43 +0200 (MET DST) Message-ID: <3AE975EC.8EF4E438@irisa.fr> Date: Fri, 27 Apr 2001 15:36:44 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello, In the draft : IPv4 multicast best current practice Your are saying : Inter-domain IP multicast forwarding trees are all source-specific. how is that ??? and is that is true?? Thanx From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:50 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03477 for ; Wed, 2 May 2001 04:08:49 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 17:05:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 17:05:37 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 17:05:57 +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 3D26D4DBE5; Fri, 27 Apr 2001 12:05:56 -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 MAA28755; Fri, 27 Apr 2001 12:05:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA03292; Fri, 27 Apr 2001 09:05:55 -0700 (PDT) Message-Id: <200104271605.JAA03292@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: arthurr@optibase.com Subject: Re: RFC 1112/2236 Cc: idmr@cs.ucl.ac.uk Date: Fri, 27 Apr 2001 09:05:54 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk RFC 988 was obsoleted by RFC1112, so you can ignore anything that RFC 988 says that 1112 doesn't (like the CreateGroup() stuff) -- senders just send, receivers just join. Bill From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:52 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03487 for ; Wed, 2 May 2001 04:08:51 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 17:49:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 16:25:23 +0100 Received: from sol.extremenetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 16:25:38 +0100 Received: by SOL with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 08:19:33 -0700 Message-ID: From: Les Stuart To: idmr@cs.ucl.ac.uk Subject: remove Date: Fri, 27 Apr 2001 08:21:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Please remove me from this list -----Original Message----- From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] Sent: Thursday, April 26, 2001 5:55 PM To: idmr@cs.ucl.ac.uk; Isidor Kouvelas Subject: Re: Another IGMPv3 question From: James Huang@MITEL on 04/26/2001 05:54 PM PDT Hi Isidor: I found the the following quote from an email you sent back in Aug/2000. "When the last host in EXCLUDE mode leaves the group, the router sends a group specific query. This causes the EXCLUDE group timer on the router to be lowered. At this point all hosts in INCLUDE mode respond and update the list X. As there are no hosts left in EXCLUDE mode, no EXCLUDE reports are received to update the group timer. Hence the timer expires with all the sources in INCLUDE mode listed in X. At this point list X is used as the list of source to forward in INCLUDE mode." I believe what you described there is about the action to take when receiving a TO_IN(A) report when in the EXCLUDE(X,Y) state. My question is whether the router should also send a qroup-specific query when the group timer expires and the router is about to switch from the EXCLUDE mode to the INCLUDE mode. When I read section 6.5 "Switching Router Filter-Modes", I can not find any description about sending a group specific query when the group timer expires. Without sending a group-sepcific query before switching the filter mode of the group, you may end up not forwarding traffics from some sources which have interested receivers in the subnet. This may happen, for example, when the last EXCLUDE mode host crashes. Of course, the router only have to send the group-specific query if it has not sent such query recently. Otherwise, the router will keep on sending group-specific queries. Thanks, -- James Huang From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:54 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03497 for ; Wed, 2 May 2001 04:08:53 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 21:35:29 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 21:35:23 +0100 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 21:35:32 +0100 Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3RKZOZ02337; Fri, 27 Apr 2001 13:35:24 -0700 (PDT) Received: from localhost (kouvelas@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA17333; Fri, 27 Apr 2001 13:35:19 -0700 (PDT) Message-Id: <200104272035.NAA17333@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: kouvelas owned process doing -bs To: James_Huang@Mitel.COM cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Subject: Re: Suppress router-side processing flag in IGMPv3 In-reply-to: Your message of "Thu, 26 Apr 2001 14:34:04 PDT." <85256A3A.00767A61.00@kanmta01.software.mitel.com> Date: Fri, 27 Apr 2001 13:35:19 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk James_Huang@Mitel.COM writes: >Hi all, > > My understaning of the "suppress router-side processing flag (S-flag) is >that it is used to synchronize timer updates between the querier and the rest >of >the routers in the subnet. The querier will set the S-flag in a query to 1 if >itself will not update the corresponding timer after sending the query. When t >he >other router receives a query with S-flag set to 1, they will not update the >corresponding timer either. Otherwise, they will lower the timer to LMQI. > > My question is -- when a router sends or receives a query with the S-flag >not set and the corresponding timer is smaller than LMQI, should it set the >timer to LMQI?? No. When SRSP is set on a query, the corresponding timer value should not be changed. thanks I From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:56 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03507 for ; Wed, 2 May 2001 04:08:55 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 22:21:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 22:21:06 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 22:21:20 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA15063; Fri, 27 Apr 2001 17:20:39 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A3B.00753D5D ; Fri, 27 Apr 2001 17:20:34 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: Isidor Kouvelas cc: idmr@cs.ucl.ac.uk Message-ID: <85256A3B.00753CB2.00@kanmta01.software.mitel.com> Date: Fri, 27 Apr 2001 14:20:32 -0700 Subject: Re: Suppress router-side processing flag in IGMPv3 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk From: James Huang@MITEL on 04/27/2001 02:20 PM PDT Hi Isidor: My question is about the case where the SRSP flag is NOT set in the query and the corresponding timer is smaller than LMQI. In this case, should the querier and other receiving routers change the timer to LMQI? My guess is NO. But can you confirm? If my quess is correct, I think it will be a good idea to change sentences in the table of section 6.6.1 from "... lowered to LMQI" to "lowered to MIN(current timer value, LMQI)". Thanks, -- James Huang Isidor Kouvelas on 04/27/2001 01:35:19 PM To: James Huang/USA/Mitel@Mitel cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com Subject: Re: Suppress router-side processing flag in IGMPv3 James_Huang@Mitel.COM writes: >Hi all, > > My understaning of the "suppress router-side processing flag (S-flag) is >that it is used to synchronize timer updates between the querier and the rest >of >the routers in the subnet. The querier will set the S-flag in a query to 1 if >itself will not update the corresponding timer after sending the query. When t >he >other router receives a query with S-flag set to 1, they will not update the >corresponding timer either. Otherwise, they will lower the timer to LMQI. > > My question is -- when a router sends or receives a query with the S-flag >not set and the corresponding timer is smaller than LMQI, should it set the >timer to LMQI?? No. When SRSP is set on a query, the corresponding timer value should not be changed. thanks I From owner-idmr@cs.ucl.ac.uk Wed May 2 04:08:58 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03517 for ; Wed, 2 May 2001 04:08:57 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 28 Apr 2001 00:18:18 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 28 Apr 2001 00:18:12 +0100 Received: from sj-msg-core-2.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 28 Apr 2001 00:18:34 +0100 Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24220; Fri, 27 Apr 2001 16:19:00 -0700 (PDT) Received: from localhost (kouvelas@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA17563; Fri, 27 Apr 2001 16:18:32 -0700 (PDT) Message-Id: <200104272318.QAA17563@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: kouvelas owned process doing -bs To: James_Huang@Mitel.COM cc: Isidor Kouvelas , idmr@cs.ucl.ac.uk Subject: Re: Suppress router-side processing flag in IGMPv3 In-reply-to: Your message of "Fri, 27 Apr 2001 14:20:32 PDT." <85256A3B.00753CB2.00@kanmta01.software.mitel.com> Date: Fri, 27 Apr 2001 16:18:32 -0700 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk You are right. When the timer is lower than LMQI it is not increased to LMQI. The receipt of the query should only have the effect of lowering the timer if it has a higher value. thanks I James_Huang@Mitel.COM writes: > > >From: James Huang@MITEL on 04/27/2001 02:20 PM PDT >Hi Isidor: > > My question is about the case where the SRSP flag is NOT set in the query >and the corresponding timer is smaller than LMQI. In this case, should the >querier and other receiving routers change the timer to LMQI? My guess is NO. >But can you confirm? If my quess is correct, I think it will be a good idea to >change sentences in the table of section 6.6.1 from "... lowered to LMQI" to >"lowered to MIN(current timer value, LMQI)". > > >Thanks, >-- James Huang > > > > > >Isidor Kouvelas on 04/27/2001 01:35:19 PM > >To: James Huang/USA/Mitel@Mitel >cc: idmr@cs.ucl.ac.uk, brad.cain@mirror-image.com, fenner@research.att.com, > deering@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com > >Subject: Re: Suppress router-side processing flag in IGMPv3 > > > > >James_Huang@Mitel.COM writes: >>Hi all, >> >> My understaning of the "suppress router-side processing flag (S-flag) is >>that it is used to synchronize timer updates between the querier and the rest >>of >>the routers in the subnet. The querier will set the S-flag in a query to 1 if >>itself will not update the corresponding timer after sending the query. When >t >>he >>other router receives a query with S-flag set to 1, they will not update the >>corresponding timer either. Otherwise, they will lower the timer to LMQI. >> >> My question is -- when a router sends or receives a query with the S-fla >g >>not set and the corresponding timer is smaller than LMQI, should it set the >>timer to LMQI?? > >No. When SRSP is set on a query, the corresponding timer value should >not be changed. > >thanks >I > > > > > From owner-idmr@cs.ucl.ac.uk Wed May 2 04:09:00 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03527 for ; Wed, 2 May 2001 04:08:59 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sun, 29 Apr 2001 04:11:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sun, 29 Apr 2001 04:11:04 +0100 Received: from presque.djinesys.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Sun, 29 Apr 2001 04:11:26 +0100 Received: from nexthop.com ([141.211.130.160]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f3T3BMa57079 for ; Sat, 28 Apr 2001 23:11:22 -0400 (EDT) (envelope-from ctbrown@nexthop.com) Message-Id: <200104290311.f3T3BMa57079@presque.djinesys.com> From: Christopher Thomas Brown Subject: Re: Suppress router-side processing flag in IGMPv3 To: idmr@cs.ucl.ac.uk In-Reply-To: Your message of "Fri, 27 Apr 2001 16:18:32 PDT." <200104272318.QAA17563@lorenzo-u10.cisco.com> Date: Sat, 28 Apr 2001 23:11:21 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Fri, 27 Apr 2001 16:18:32 PDT Isidor Kouvelas wrote: > >You are right. When the timer is lower than LMQI it is not increased >to LMQI. The receipt of the query should only have the effect of lowering >the timer if it has a higher value. > >>From: James Huang@MITEL on 04/27/2001 02:20 PM PDT >>Hi Isidor: >> >> My question is about the case where the SRSP flag is NOT set in the quer >y >>and the corresponding timer is smaller than LMQI. In this case, should the >>querier and other receiving routers change the timer to LMQI? My guess is NO >. >>But can you confirm? If my quess is correct, I think it will be a good idea t >o >>change sentences in the table of section 6.6.1 from "... lowered to LMQI" to >>"lowered to MIN(current timer value, LMQI)". >> >> >>Thanks, >>-- James Huang I don't like the use of "lowered to MIN(current timer value, LMQI)" though. If current timer value is lower than LMQI it is not really being lowered at all it is left as is. Perhaps "set to MIN(current timer value, LMQI)"? ctbrown From owner-idmr@cs.ucl.ac.uk Wed May 2 04:11:27 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03566 for ; Wed, 2 May 2001 04:11:26 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 27 Apr 2001 01:55:15 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 01:55:08 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 27 Apr 2001 01:55:29 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id UAA16088; Thu, 26 Apr 2001 20:55:11 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A3B.0005094A ; Thu, 26 Apr 2001 20:55:00 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: idmr@cs.ucl.ac.uk, Isidor Kouvelas Message-ID: <85256A3B.00050819.00@kanmta01.software.mitel.com> Date: Thu, 26 Apr 2001 17:54:56 -0700 Subject: Re: Another IGMPv3 question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk From: James Huang@MITEL on 04/26/2001 05:54 PM PDT Hi Isidor: I found the the following quote from an email you sent back in Aug/2000. "When the last host in EXCLUDE mode leaves the group, the router sends a group specific query. This causes the EXCLUDE group timer on the router to be lowered. At this point all hosts in INCLUDE mode respond and update the list X. As there are no hosts left in EXCLUDE mode, no EXCLUDE reports are received to update the group timer. Hence the timer expires with all the sources in INCLUDE mode listed in X. At this point list X is used as the list of source to forward in INCLUDE mode." I believe what you described there is about the action to take when receiving a TO_IN(A) report when in the EXCLUDE(X,Y) state. My question is whether the router should also send a qroup-specific query when the group timer expires and the router is about to switch from the EXCLUDE mode to the INCLUDE mode. When I read section 6.5 "Switching Router Filter-Modes", I can not find any description about sending a group specific query when the group timer expires. Without sending a group-sepcific query before switching the filter mode of the group, you may end up not forwarding traffics from some sources which have interested receivers in the subnet. This may happen, for example, when the last EXCLUDE mode host crashes. Of course, the router only have to send the group-specific query if it has not sent such query recently. Otherwise, the router will keep on sending group-specific queries. Thanks, -- James Huang From owner-idmr@cs.ucl.ac.uk Fri May 4 00:58:29 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21334 for ; Fri, 4 May 2001 00:58:28 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 May 2001 03:25:42 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 May 2001 03:25:36 +0100 Received: from newgate.mitel.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 May 2001 03:26:00 +0100 Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id WAA00797; Thu, 3 May 2001 22:25:49 -0400 (EDT) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256A42.000D5772 ; Thu, 3 May 2001 22:25:43 -0400 X-Lotus-FromDomain: MITEL From: James_Huang@Mitel.COM To: Isidor Kouvelas cc: idmr@cs.ucl.ac.uk Message-ID: <85256A42.000D5724.00@kanmta01.software.mitel.com> Date: Thu, 3 May 2001 19:25:50 -0700 Subject: IGMPv3 interoperability question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, I have a question about IGMP interoperability in the following scenario. An IGMPv3 querier, an IGMPv1 host, an IGMPv2 host, and an IGMPv3 host are in the same IP subnet. Suppose these three hosts all join the same group G. So the IGMPv3 querier will have Group Compatibility Mode = IGMPv1 for group G and will ignore IGMPv2 leave message for G. How about Group Record for G in IGMPv3 reports? Will the querier simply ignore the Group Record or will it convert the record into an equivalent IGMPv1 report? If the answer is the latter, is it O.K. to treat any Group Record for G in IGMPv3 report as a join for G? How about another scenario where the Group Compatability Mode for group G = IGMPv2? In this case, how will the querier handle Group Record for G in IGMPv3 reports? Thanks, -- James Huang From owner-idmr@cs.ucl.ac.uk Fri May 4 08:20:28 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10432 for ; Fri, 4 May 2001 08:20:27 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 4 May 2001 09:51:27 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 4 May 2001 09:51:21 +0100 Received: from sky.irisa.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 4 May 2001 09:51:32 +0100 Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA02405 for ; Fri, 4 May 2001 10:51:31 +0200 (MET DST) Message-ID: <3AF26D95.84A23108@irisa.fr> Date: Fri, 04 May 2001 10:51:33 +0200 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk Subject: something about Groups Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit hello, a host send an IGMP message to announce that he want to be a member of an group G. 1-Is G here mean that the host want to recieve special data from a specific source (like in SSM) or not?? 2-what is the meaning of G if it is not having trafic from a source. 3-how does the host choose that he is a member in G and G1 for example if it does not know about data it want to recieve from a source?? 4- how G is setup , static or dynamic by the application?? Thanx From owner-idmr@cs.ucl.ac.uk Tue May 8 20:54:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10680 for ; Tue, 8 May 2001 20:54:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 9 May 2001 00:16:47 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 9 May 2001 00:16:43 +0100 Received: from sol.extremenetworks.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 9 May 2001 00:17:07 +0100 Received: by SOL with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 16:10:49 -0700 Message-ID: <2F5F27915881D411B43F00508BD8935F4D9FB8@sc-sol-04.extremenetworks.com> From: Mike Yip To: "IDMR Mailing List (E-mail)" Subject: Looking for IGMPv3 implementation on LINUX/UNIX Date: Tue, 8 May 2001 16:13:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi there, Can anyone point me to any existing implementation of the IGMPv3 draft? One with source code for LINUX/UNIX will, of course, be great. -- Mike From owner-idmr@cs.ucl.ac.uk Wed May 9 06:42:43 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03309 for ; Wed, 9 May 2001 06:42:43 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 9 May 2001 10:35:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 9 May 2001 10:35:18 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 9 May 2001 10:35:32 +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 LAA05824; Wed, 9 May 2001 11:35:29 +0200 (MET DST) From: Abdelkader Lahmadi To: Mike Yip Subject: Re: Looking for IGMPv3 implementation on LINUX/UNIX Date: Tue, 8 May 2001 12:47:19 +0200 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <2F5F27915881D411B43F00508BD8935F4D9FB8@sc-sol-04.extremenetworks.com> In-Reply-To: <2F5F27915881D411B43F00508BD8935F4D9FB8@sc-sol-04.extremenetworks.com> Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01050812473501.27270@joudreville.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, 09 May 2001, you wrote: > Hi there, > > Can anyone point me to any existing implementation of the IGMPv3 draft? One > with source code for LINUX/UNIX will, of course, be great. > > -- Mike -- Sprint labs have an implementation of IGMv3 hote side, it's a patch for the linux kernel: http://www.sprintlabs.com/Department/IP-Interworking/multicast/linux-igmpv3 or there are an implentation for FreeBSD written by Wilbert de graaf: http://home.hetnet.nl/~wilbertdg/igmpv3.html --------------------------------------------- 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 Wed May 9 06:43:57 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03320 for ; Wed, 9 May 2001 06:43:57 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 9 May 2001 10:35:24 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 9 May 2001 10:35:17 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 9 May 2001 10:35:30 +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 LAA05821; Wed, 9 May 2001 11:35:28 +0200 (MET DST) From: Abdelkader Lahmadi To: Mike Yip Subject: Re: Looking for IGMPv3 implementation on LINUX/UNIX Date: Tue, 8 May 2001 12:37:56 +0200 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <2F5F27915881D411B43F00508BD8935F4D9FB8@sc-sol-04.extremenetworks.com> In-Reply-To: <2F5F27915881D411B43F00508BD8935F4D9FB8@sc-sol-04.extremenetworks.com> Cc: idmr@cs.ucl.ac.uk MIME-Version: 1.0 Message-Id: <01050812434300.27270@joudreville.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, 09 May 2001, you wrote: > Hi there, > > Can anyone point me to any existing implementation of the IGMPv3 draft? One > with source code for LINUX/UNIX will, of course, be great. > > -- Mike -- Sprint labs have an implementation of IGMv3 hote side, it's a patch for the linux kernel: http://www.sprintlabs.com/Department/IP-Interworking/multicast/linux-igmpv3 or there are an implentation for FreeBSD written by Wilbert de graaf: http://home.hetnet.nl/~wilbertdg/igmpv3.html --------------------------------------------- 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 Tue May 15 20:36:29 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 UAA10277 for ; Tue, 15 May 2001 20:36:28 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 15 May 2001 23:50:12 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 15 May 2001 23:50:06 +0100 Received: from mail-blue.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 15 May 2001 23:50:33 +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 71DB24DC5B; Tue, 15 May 2001 18:50:31 -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 SAA03242; Tue, 15 May 2001 18:50:30 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA06911; Tue, 15 May 2001 15:50:29 -0700 (PDT) Message-Id: <200105152250.PAA06911@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ahuja@merit.edu, rcoltun@redback.com Subject: Advancement of IGMPv3 to Proposed Standard Cc: idmr@cs.ucl.ac.uk, ietf-secretariat@ietf.org Date: Tue, 15 May 2001 15:50:29 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Dear Abha and Rob, The IDMR Working Group would like to advance the IGMP Version 3 spec, draft-ietf-idmr-igmp-v3-07.{ps,txt} to Proposed Standard. draft-ietf-idmr-igmp-v3-05.{ps,txt} went through an IDMR working group last call in November-December 2000; -06 and -07 were published in response to feedback received during this last call. I'm sorry this advancement request is so delayed. Thanks, Bill From owner-idmr@cs.ucl.ac.uk Tue May 15 23:32:26 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 XAA14746 for ; Tue, 15 May 2001 23:32:25 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 16 May 2001 03:28:41 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 16 May 2001 03:28:34 +0100 Received: from mail.producegate.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 16 May 2001 03:29:00 +0100 Received: from localhost (sh.producegate.net [211.123.211.167]) by producegate.net (8.11.3/8.11.0) with ESMTP id f4G2Sso18503 for ; Wed, 16 May 2001 11:28:54 +0900 (JST) To: idmr@cs.ucl.ac.uk Subject: igmpv3 questions and comments X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010516112854R.asaeda@producegate.net> Date: Wed, 16 May 2001 11:28:54 +0900 From: Hitoshi Asaeda X-Dispatcher: imput version 20000228(IM140) Lines: 124 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi. I have several comments and questions for IGMPv3 spec. [1] As a host side, timer controled by IPMulticastListen() invokation is independent from interface timer or group timer? Or, this timer should be overwrapped by Query timer (i.e. interface timer or *the same group's* group timer)? For example, IPMulticastListen() is invoked and the node is about to send State-Change Report even the report is the first one or resent one which is controled by Robustness Variable. After that, the node receives General Query or Group-Specific Query for the same group. What should the node do? Cancel State-Change Report? Or each report, State-Change Report and Current-State Report, should be sent? Or it depends on each timer? e.g. Let's see following time chart with Robustness Variable=3. 1 2 3 4 5 6 | | | | | | V V V V V V ----------------------------------------> time 1. IPMulticastListen() was invoked. 2. First timer for State-Change Report was expired. (Then, State-Change Report was sent.) 3. General Query or Group-Specific Query for *the* gorup was received. 4. Second timer for State-Change Report was expired. (State-Change Report should be sent?) <--- * 5. Interface timer or *the* group timer was expired. (Current-State Report should be sent?) <--- * 6. Third timer for State-Change Report was expired. (State-Change Report should be sent?) <--- * There is no description about above three * notations. I think following may be the correct story; When an interface timer for pending responce of General Query or Group-Sepcific Query for the same multicast address is sooner than the scheduled timer of State-Change Report invoked by IPMulticastListen, pending State-Change Report(s) scheduled by Robustness Variable is (are) canceled at that time. If I am correct, above 6's notation won't be occured. What's correct? [2] 3.2 in an I-D says; 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} ) At this situation, when the application using socket s3 wants to stop itself (i.e., close socket s3), the node must send LEAVE message from interface i. So, at this situation, the application tries to call (m, EXCLUDE, {d,e,f}). However, according to an I-D, the interface state is finally cleared (i.e., (m, EXCLUDE, {}) calculated with (m, EXCLUDE, {b,c}) and (m, EXCLUDE, {d,e,f}) ), and after that, this node sends only ALLOW({b,c}) based on the rule of section 5.1 in an I-D, and the the kernel doesn't send BLOCK({d,e,f}) to mention the LEAVE. And another example. When the interface i has (m, EXCLUDE, {b,c}) state like above and some application calls (m, INCLUDE, {a}), the interface state will not be changed. So, at this time, JOIN message will also not be transfered? Am I talking wrong stories? [3] Also using above 3.2's sample. In this case, an include list of the interface SHOULD be cleared? I mean, after keeping above state, if this node calls (m, INCLUDE,{b,c,g}), this node has which filter, (m, INCLUDE, {g}) or (m, INCLUDE, {d,e,f,g})? There is also no description about this state in an I-D. [4] 5.2 in an I-D says; 2. If the received Query is a General Query, the interface timer is used to schedule a response to the General Query after the selected delay. Any previously pending response to a General Query is canceled. So, any previously pending response to a General Query is canceled, *even if* an interface timer set by previous General Query is sooner than the selected delay? [5] How about local group handling? IPMulitcastListen() can specify LOCAL group address? I may say "yes" because some application, not a user application but e.g., a routing daemon, may want to restrict neighbor nodes. Of course, it would be able to make a filter not to receive routing message without using IPMulticastListen(), with using upper layer filtering implementation, though. (Actually, IGMPv2's implementation on *BSD kernl doesn't set Report timer for LOCAL group, because it's done by each application (including a routing daemon). This is because there was no mechanism to set some filtering policy by *protocol* (i.e. IGMPv1/v2), I think.) And, local group addresses except ALL-HOSTS and ALL-ROUTERS will be queried by specific queries (Group- and Group-and-Source-Specific Query)? And these should be reported by any query (General, Group-, and Group-and-Source-Specific Query)? Also, local group addresses should be reported within a report message for General query? I cannot find these specification in an I-D. Thanks. -- Hitoshi Asaeda From owner-idmr@cs.ucl.ac.uk Wed May 16 12:32: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 MAA13520 for ; Wed, 16 May 2001 12:32:21 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 16 May 2001 11:11:46 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 16 May 2001 05:18:51 +0100 Received: from red.juniper.net by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 16 May 2001 05:19:03 +0100 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA17795; Tue, 15 May 2001 21:18:57 -0700 (PDT) Message-Id: <200105160418.VAA17795@red.juniper.net> To: Bill Fenner cc: ahuja@merit.edu, rcoltun@redback.com, idmr@cs.ucl.ac.uk, ietf-secretariat@ietf.org, pusateri@juniper.net Subject: Re: Advancement of DVMRPv3 Spec, Applicability Statement to Proposed Standard In-Reply-To: Message from Bill Fenner of "Tue, 15 May 2001 15:53:24 PDT." <200105152253.PAA06940@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84342.989986737.1@juniper.net> Date: Tue, 15 May 2001 21:18:57 -0700 From: Tom Pusateri Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk In message <200105152253.PAA06940@windsor.research.att.com> you write: > > >Dear Abha and Rob, > > The IDMR Working Group would like to advance the DVMRP Version 3 >spec, draft-ietf-idmr-dvmrp-v3-10.{ps,txt} and its associated applicability >statement, draft-ietf-idmr-dvmrp-v3-as-00.{ps,txt} to Proposed Standard. >These documents went through an IDMR working group last call in >November, 2000 with no feedback received. > > The MIB passed the same last call but requires a small update that has >not happened yet. I expect to forward the MIB to you for advancement >as soon as the draft is republished with the change. > > I'm sorry this advancement request is so delayed. I believe the >documents are expired now; if Steve doesn't have a stashed copy I'm >sure we can get copies from the author. > >Thanks, > Bill The drafts can be obtained from the following location since they've timed out: ftp://ftp.juniper.net/pub/users/pusateri/draft-ietf-idmr-dvmrp-v3-10.txt ftp://ftp.juniper.net/pub/users/pusateri/draft-ietf-idmr-dvmrp-v3-10.ps ftp://ftp.juniper.net/pub/users/pusateri/draft-ietf-idmr-dvmrp-v3-as-00.txt ftp://ftp.juniper.net/pub/users/pusateri/draft-ietf-idmr-dvmrp-v3-as-00.ps Thanks, Tom From owner-idmr@cs.ucl.ac.uk Sat May 19 19:28: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 TAA16714 for ; Sat, 19 May 2001 19:28:16 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Sat, 19 May 2001 17:49:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Sat, 19 May 2001 16:00:34 +0100 Received: from TCE-E-7-182-12.bta.net.cn by bells.cs.ucl.ac.uk with Internet SMTP id ; Sat, 19 May 2001 16:01:01 +0100 Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm63b06ec4d; Sat, 19 May 2001 15:00:43 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jm23b05adaa; Fri, 18 May 2001 19:43:17 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA12007 for ietf-123-outbound.02@ietf.org; Fri, 18 May 2001 15:35:00 -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 PAA11972 for ; Fri, 18 May 2001 15:29:49 -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 PAA13157; Fri, 18 May 2001 15:29:47 -0400 (EDT) Message-Id: <200105181929.PAA13157@ietf.org> To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: The IESG SUBJECT: Last Call: Distance Vector Multicast Routing Protocol to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 18 May 2001 15:29:47 -0400 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The IESG has received a request from the Inter-Domain Multicast Routing Working Group to consider publication of the following as Proposed Standards: o Distance Vector Multicast Routing Protocol o Distance Vector Multicast Routing Protocol Applicability Statement The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 31, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-10.txt http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-as-00.txt From owner-idmr@cs.ucl.ac.uk Mon May 21 05:47:36 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04399 for ; Mon, 21 May 2001 05:47:36 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 21 May 2001 09:39:10 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 21 May 2001 09:39:03 +0100 Received: from juicer38.bigpond.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 21 May 2001 09:39:29 +0100 Received: from derek ([139.134.4.50]) by mailin7.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GDOGAP00.CRA for ; Mon, 21 May 2001 18:44:49 +1000 Received: from CPE-144-132-131-53.nsw.bigpond.net.au ([144.132.131.53]) by mail8.bigpond.com (Claudes-Remorseful-MailRouter V2.9c 17/11665442); 21 May 2001 18:39:04 Message-ID: <002f01c0e1c1$4f5a7580$0901010a@derek> From: Ronnie Sahlberg To: idmr Subject: Packet Analyzer for IGMP Date: Mon, 21 May 2001 16:43:13 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Hope this is not too offtopic, but I hope you might find this useful. The free (GPL) graphical analyzer Ethereal, (www.ethereal.com) now has full support for IGMP v3 (and V2 V1 V0). Source code can be downloaded from the webpage CVS. (official version 0.8.18 does not support V3, you need CVS, or next release) I think of implementing DVMRP V1,V3 and CBQ V2 in the near future. If anyone on this list could provide me with a capture of dummy packets for these protocols for testing I would be grateful. Best Regards Ronnie Sahlberg From owner-idmr@cs.ucl.ac.uk Mon May 28 10:49:20 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05079 for ; Mon, 28 May 2001 10:49:19 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 28 May 2001 14:24:43 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 28 May 2001 14:24:36 +0100 Received: from 202.54.64.6 by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 28 May 2001 14:25:05 +0100 Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LZ7MG4F3; Mon, 28 May 2001 19:07:12 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LVHSL23N; Mon, 28 May 2001 18:52:40 +0530 From: Vijayanand C To: idmr Cc: fenner Subject: Multicast recv IF Date: Mon, 28 May 2001 19:00:40 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I am using BSD sockets to send and receive multicast datagrams for a protocol(LDP). I have a few doubts on this. 1)Is it possible to have a different socket for each interface, though they bind to the same Group address in the bind.(While setting the IP_ADD_MEMBERSHIP option, the interface address is mentioned) 2)If we have a common socket for all interfaces bound to the same Group Address, how can we find out the interface on which the datagram arrived. Thanks in advance. Regards, Vijay From owner-idmr@cs.ucl.ac.uk Mon May 28 17:24:46 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07384 for ; Mon, 28 May 2001 17:24:46 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 28 May 2001 20:38:24 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 28 May 2001 20:38:18 +0100 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 28 May 2001 20:38:47 +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 B7D8F1E9C6; Mon, 28 May 2001 15:38:40 -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 PAA00314; Mon, 28 May 2001 15:38:40 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id MAA05682; Mon, 28 May 2001 12:38:39 -0700 (PDT) Message-Id: <200105281938.MAA05682@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vijayc@hclt.com Subject: Re: Multicast recv IF Cc: idmr@cs.ucl.ac.uk Date: Mon, 28 May 2001 12:38:38 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk There is no relationship between the join operations done on a socket and the data that will be received on a socket. The only way I'm aware of to determine the incoming interface for a packet is the IP_RECVIF socket option. I don't know how widely implemented it is. Bill From owner-idmr@cs.ucl.ac.uk Tue May 29 00:41:48 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11792 for ; Tue, 29 May 2001 00:41:47 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 29 May 2001 04:19:32 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 29 May 2001 04:19:25 +0100 Received: from wiproecmx1.wipro.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 29 May 2001 04:19:53 +0100 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id f4TDdlv22397 for ; Tue, 29 May 2001 08:39:49 -0500 (GMT) Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GE2UIS00.S9I for ; Tue, 29 May 2001 08:48:28 +0530 Received: from wipro.com ([192.168.91.138]) by helium.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GE2UG700.LRO; Tue, 29 May 2001 08:46:55 +0530 Message-ID: <3B13166D.60C3A572@wipro.com> Date: Tue, 29 May 2001 08:54:29 +0530 From: Radhakrishna Singuru Organization: Wipro, Global R&D X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijayanand C CC: idmr , fenner Subject: Re: Multicast recv IF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Yes, for sending packets on a particular interface, you can use the setsockopt call with IP_MULTICAST_IF option. For receive, you need to determine the interface based on the source address. thanks radha Vijayanand C wrote: > Hello All, > > I am using BSD sockets to send and receive multicast datagrams for a > protocol(LDP). I have a few doubts on this. > > 1)Is it possible to have a different socket for each interface, though they > bind to the same Group address in the bind.(While setting the > IP_ADD_MEMBERSHIP option, the interface address is mentioned) > 2)If we have a common socket for all interfaces bound to the same Group > Address, how can we find out the interface on which the datagram arrived. > > Thanks in advance. > > Regards, > Vijay From owner-idmr@cs.ucl.ac.uk Tue May 29 02:17:34 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23442 for ; Tue, 29 May 2001 02:17:33 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Tue, 29 May 2001 06:22:49 +0100 Received: from haig.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Tue, 29 May 2001 06:22:43 +0100 Received: from 202.54.64.6 by haig.cs.ucl.ac.uk with Internet SMTP id ; Tue, 29 May 2001 06:23:10 +0100 Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LZ7MGYQN; Tue, 29 May 2001 11:05:10 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LVHSLJJZ; Tue, 29 May 2001 10:50:35 +0530 From: Vijayanand C To: Radhakrishna Singuru Cc: idmr Subject: RE: Multicast recv IF Date: Tue, 29 May 2001 10:58:28 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3B13166D.60C3A572@wipro.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 7bit Hello radha, Sending is not a problem. But receiving is. > For receive, you need to determine the >interface based on the source address. Finding the incoming interface based on source IP address will not be always correct, unless the routes are always symmetrical(This need not be true with all links and interfaces).So this method may not yield the correct solution. Regards, Vijay Vijayanand C wrote: > Hello All, > > I am using BSD sockets to send and receive multicast datagrams for a > protocol(LDP). I have a few doubts on this. > > 1)Is it possible to have a different socket for each interface, though they > bind to the same Group address in the bind.(While setting the > IP_ADD_MEMBERSHIP option, the interface address is mentioned) > 2)If we have a common socket for all interfaces bound to the same Group > Address, how can we find out the interface on which the datagram arrived. > > Thanks in advance. > > Regards, > Vijay From owner-idmr@cs.ucl.ac.uk Tue May 29 21:02:20 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13424 for ; Tue, 29 May 2001 21:02:20 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 30 May 2001 00:54:36 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 30 May 2001 00:54:30 +0100 Received: from shuttle.wide.toshiba.co.jp by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 30 May 2001 00:54:58 +0100 Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id IAA15776; Wed, 30 May 2001 08:52:46 +0900 (JST) Date: Wed, 30 May 2001 00:04:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vijayanand C Cc: idmr , fenner Subject: Re: Multicast recv IF In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk >>>>> On Mon, 28 May 2001 19:00:40 +0530, >>>>> Vijayanand C said: > 1)Is it possible to have a different socket for each interface, though they > bind to the same Group address in the bind.(While setting the > IP_ADD_MEMBERSHIP option, the interface address is mentioned) Yes, it is. But you should specify the SO_REUSEPORT socket option for all the sockets in order to prevent the kernel from rejecting the duplicated bind. Also, since all the sockets will accept all packets to the address regardless of the receiving interface, you should filter irrelevant packets at the application level. > 2)If we have a common socket for all interfaces bound to the same Group > Address, how can we find out the interface on which the datagram arrived. As far as I know, there is no mechanism to tell the receiving interface in BSD variants in this scenario. (Just FYI, for IPv6 sockets, you can use the IPV6_(RECV)PKTINFO socket option for this purpose.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-idmr@cs.ucl.ac.uk Thu May 31 07:01:54 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20017 for ; Thu, 31 May 2001 07:01:53 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 31 May 2001 10:51:52 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 10:51:46 +0100 Received: from lorraine.loria.fr by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 May 2001 10:52:14 +0100 Received: from euvezin.loria.fr (euvezin.loria.fr [152.81.11.90]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with SMTP id LAA05946; Thu, 31 May 2001 11:52:14 +0200 (MET DST) From: Abdelkader Lahmadi To: idmr@cs.ucl.ac.uk Subject: (INCLUDE , NO SOURCE ELEMENTS) Date: Thu, 31 May 2001 11:39:24 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: fenner@research.att.com MIME-Version: 1.0 Message-Id: <01053111521300.01862@euvezin.loria.fr> Content-Transfer-Encoding: 8bit Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Content-Transfer-Encoding: 8bit hello, in the igmpv3 spec, if the hote send only one igmpv3 report to the router , so the router will create a record for the group requested by the hote and the state of this group will: (INCLUDE,timer = 0,NO SOURCE Elements) in this case the router will kept this state and can`t delete the group record. and really there`nt a member for this group. my question is when the router will delete the group record ? 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 Thu May 31 23:01:53 2001 Received: from pan2.cs.ucl.ac.uk ([128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14297 for ; Thu, 31 May 2001 23:01:53 -0400 (EDT) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Thu, 31 May 2001 21:15:13 +0100 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 21:02:24 +0100 Received: from mailhost.iprg.nokia.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 May 2001 21:02:54 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA28292; Thu, 31 May 2001 13:02:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4VK2pF10350; Thu, 31 May 2001 13:02:51 -0700 X-mProtect: Thu, 31 May 2001 13:02:51 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdZUBFhL; Thu, 31 May 2001 13:02:48 PDT Message-ID: <3B16A368.6449D603@iprg.nokia.com> Date: Thu, 31 May 2001 13:02:48 -0700 From: Theo Pagtzis Reply-To: tpagtzis@IPRG.nokia.com Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk, fenner@research.att.com Subject: multicast and load balancing Content-Type: text/plain; charset=us-ascii Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi all, I have been pondering on this one and I am trying to see if the rule can be relaxed. However I need first to know what is the reason for having this rule. IGMPvX and MLD mention that the router has to be a Querier in the particular interface so that multicast packets can be forwarded. When one has two multicast enabled routers and would like to load balance traffic between the two routers it seems to me that there is problem with load balancing since only the interface in any of the 2 IGMP-enable routers, with the lowest IPv6 addr will win the Querier election. So in that case the second router cannot load balance multicast forwarding on that link. Does that make any sense? Why should one enforce that only if the router is the querier of the interface can it forward packets on that interface since any router with a lower IP addr on that link would take its Querier status away.. Thanks Theo UCL/ Mobile Systems