Re: [magma] Question about proxy implemenation in RFC 4605

Bharat Joshi <bharat_joshi@infosys.com> Tue, 02 November 2010 03:24 UTC

Return-Path: <bharat_joshi@infosys.com>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997713A6867 for <magma@core3.amsl.com>; Mon, 1 Nov 2010 20:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tm9XX10SV35 for <magma@core3.amsl.com>; Mon, 1 Nov 2010 20:24:05 -0700 (PDT)
Received: from kecgate06.infosys.com (Kecgate06.infosys.com [122.98.14.33]) by core3.amsl.com (Postfix) with ESMTP id 4FDE728C0FF for <magma@ietf.org>; Mon, 1 Nov 2010 20:23:54 -0700 (PDT)
X-TM-IMSS-Message-ID: <609198c200009138@infosys.com>
Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 609198c200009138 ; Tue, 2 Nov 2010 08:55:10 +0530
Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Tue, 2 Nov 2010 08:53:53 +0530
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Kunal Shah <kunal.shah@ericsson.com>, "magma@ietf.org" <magma@ietf.org>
Date: Tue, 2 Nov 2010 08:53:53 +0530
Thread-Topic: Question about proxy implemenation in RFC 4605
Thread-Index: Act3y+dEzA46tWwmR6yuBZkXU/iNeACcKPvV
Message-ID: <31D55C4D55BEED48A4459EB64567589A107AE02427@BLRKECMBX02.ad.infosys.com>
References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AE@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AE@EUSAACMS0703.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [magma] Question about proxy implemenation in RFC 4605
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Nov 2010 03:24:06 -0000

Hi Kunal,

      When a box run IGMP proxy, it has router interfaces (interfaces that runs router part of IGMP) to collect membership information and host interface (interfaces that runs host part of IGMP) to report the membership to upstream router. Before reporting membership on host interface, it aggregates the membership collected from router interfaces. Now aggregating membership information in the box is done similar to how it is defined in RFC 3376 for hosts when multiple sockets are bound. So similar rules apply when any of these membership change (It will be similar to the case when one of the sockets are closed).

     In your case below, when join comes one by one, the next state is determined as explained in RFC 3376 ( as if a new socket is opened every time) and that is how you reach a particular state of EXC( G, NULL ). Similarly when one of the interface send a leave (on host interface side, this will be treated as if that socket is closed), it re-calculates the new state and use that.

     Let me know if this clears up things.

Thanks,
Bharat
________________________________________
From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com]
Sent: Saturday, October 30, 2010 6:16 AM
To: magma@ietf.org
Subject: [magma] Question about proxy implemenation in RFC 4605

Hi all,

According to RFC 4605, a router creates a membership database after merging the subscriptions on individual interfaces. Lets say that 3 IGMPv3 capable interfaces are as follows:

Interface 1 has host reporting Include S1 -> I(S1)
Interface 2 has host reporting Exclude S2 -> E(0,S2)
Interface 3 has host reporting Exclude nothing -> E(0,0)

For a device doing IGMPv3 proxy, the final membership record for group G is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, because of which the subscription on interface 3 would expire and there wont be any IGMPv3 state on interface 3.  How would the new membership record for PROXY be calculated?? The RFC does not suggest any way to do this. Would IGMP process have to go through each interface again and then recompute the new membership record?? This would be very inefficient especially if there are multiple interfaces.
Is there a better way to recompute the new membership record??


Thanks
Kunal



**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***