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

["Alvaro Fernandez" <[e-mail]>]

Hi Kunal

Just something else.

>From your last e-mail:  " i.e the state that would exist if all the interfaces represented individual hosts on a single LAN"

I think this is not true. Host connected to a proxy are not the same that host connected to the same LAN. The difference is that each host is connected to the Proxy by a different downstream network interface and this makes the rules in the proxy easier that the state machine of the IGMPv3 router. 

Regards

Alvaro


-----Mensaje original-----
De: Kunal Shah [mailto:[e-mail]]
Enviado el: lun 01/11/2010 23:49
Para: Alvaro Fernandez
CC: [e-mail]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605
 
Hi Alvaro,

I dont think you have understood my question. The rules that you are suggesting from RFC 3376, are the rules used for aggregating the information on an interface with multiple sockets. What I am asking is what rules should be followed on a proxy device in order to aggregate the state of all the interfaces, after the state of one of the interfaces has changed. This is because, on a device doing proxy, the state that is created is an aggregate of the state of the interfaces; i.e the state that would exist if all the interfaces represented individual hosts on a single LAN. Now from RFC 3376, if a host goes away on an interface, there are certain rules that the router must follow regarding queries that need to be sent in order to arrive to the new state on that interface. My concern is, on a proxy device, if the same rules are followed, queries will need to be sent out on all the interfaces in order to make sure that the new state reflects the state of all the interfaces. This might not be efficient/scalable if the proxy device has interfaces in the order of hundreds.

Or I have not understood the RFC 4605 correctly...

Kunal

________________________________
From: Alvaro Fernandez [mailto:[e-mail]]
Sent: Monday, November 01, 2010 2:19 PM
To: Kunal Shah
Cc: [e-mail]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605


Hi Kunai,

I thing my previous Mail was wrong. I was thinking in once interface with múltiple host and this is not your question.

The proxy should apply same rules  explained inRFC3376 in the función IPMulticastListen when there are different sockets using the same multicast group.

I think there is no need for queries, just apply these rules.

Hope this will help

Álvaro

-----Mensaje original-----
De: Kunal Shah [mailto:[e-mail]]
Enviado el: lun 01/11/2010 19:30
Para: Alvaro Fernandez
CC: [e-mail]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605

Hi Alvaro,

For a router to determine that there are no interested hosts on the LAN, it does send out group specific or source-group specific queries. Does this mean, that the proxy device should send out source-group specific queries on other interfaces when deemed required?? How will this scale if there are a large number of interfaces??

Kunal

________________________________
From: Alvaro Fernandez [mailto:[e-mail]]
Sent: Saturday, October 30, 2010 10:36 AM
To: Kunal Shah
Cc: [e-mail]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605


Hi Kunal

I read it years ago but I think RFC 4605 explains that the downstream network interface should behave like a router, so the solution is in the state machine explained in RFC3376 for the IGMPv3 router

Álvaro


-----Mensaje original-----
De: [e-mail] en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: [e-mail]
Asunto: [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