Re: Question about proxy implemenation in RFC 4605
"Alvaro Fernandez" <[email protected]> Wed, 3 Nov 2010 08:58:27 +0100
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0162526829== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7B2C.E5AEA35B" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7B2C.E5AEA35B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kunal =20 Not exactly. If a group expires in an interface just need to update in = the proxy the state of only this group. No need to wait until all the = doenstrem interfaces (behaving like routers) update their state.=20 =20 Also, for example removing an include source list of a multicast group = is not computing intensive (easy with a listed link, but depending on = the type of cache used in the microprocesor a table could be faster than = a linked list) =20 At the end you must apply the rules of RFC 3376, 3.2 and they are not = computing intensive. =20 ALvaro ________________________________ De: Kunal Shah [mailto:[email protected]] Enviado el: mi=E9 03/11/2010 0:25 Para: Alvaro Fernandez Asunto: RE: [magma] Question about proxy implemenation in RFC 4605 Hi Alvaro, =20 Ok I think I understand what you are saying. So now if the new PROXY = state is recomputed when a group expires on an interface, is int this = very CPU intensive because the new state would be generated after = considering the state of all the interfaces?? =20 Kunal ________________________________ From: Alvaro Fernandez [mailto:[email protected]]=20 Sent: Tuesday, November 02, 2010 9:40 AM To: Kunal Shah Cc: [email protected] Subject: RE: [magma] Question about proxy implemenation in RFC 4605 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:[email protected]] Enviado el: lun 01/11/2010 23:49 Para: Alvaro Fernandez CC: [email protected] 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:[email protected]] Sent: Monday, November 01, 2010 2:19 PM To: Kunal Shah Cc: [email protected] 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=FAltiple host and this is not your question. The proxy should apply same rules explained inRFC3376 in the funci=F3n = 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 =C1lvaro -----Mensaje original----- De: Kunal Shah [mailto:[email protected]] Enviado el: lun 01/11/2010 19:30 Para: Alvaro Fernandez CC: [email protected] 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:[email protected]] Sent: Saturday, October 30, 2010 10:36 AM To: Kunal Shah Cc: [email protected] 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 =C1lvaro -----Mensaje original----- De: [email protected] en nombre de Kunal Shah Enviado el: s=E1b 30/10/2010 2:46 Para: [email protected] 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 ------_=_NextPart_001_01CB7B2C.E5AEA35B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML dir=3Dltr><HEAD><TITLE>RE: [magma] Question about proxy = implemenation in RFC 4605</TITLE>=0A= <META content=3D"text/html; charset=3Dunicode" http-equiv=3DContent-Type>=0A= <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18828"></HEAD>=0A= <BODY>=0A= <DIV dir=3Dltr id=3DidOWAReplyText76889>=0A= <DIV dir=3Dltr><FONT color=3D#000000 size=3D2 = face=3DArial>Kunal</FONT></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT> </DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial>Not exactly. If a group = expires in an interface just need to update in the proxy the state of = only this group. No need to wait until all the doenstrem interfaces = (behaving like routers) update their state. </FONT></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT> </DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial>Also, for example removing an = include source list of a multicast group is not computing = intensive (easy with a listed link, but depending on the type of = cache used in the microprocesor a table could be faster than a linked = list)</FONT></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT> </DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial>At the end you must apply the = rules of RFC 3376, 3.2 and they are not computing intensive.</FONT></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT> </DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial>ALvaro</FONT></DIV></DIV>=0A= <DIV dir=3Dltr><FONT size=3D2 face=3DArial></FONT><BR>=0A= <HR tabIndex=3D-1>=0A= <FONT size=3D2 face=3DTahoma><B>De:</B> Kunal Shah = [mailto:[email protected]]<BR><B>Enviado el:</B> mi=E9 03/11/2010 = 0:25<BR><B>Para:</B> Alvaro Fernandez<BR><B>Asunto:</B> RE: [magma] = Question about proxy implemenation in RFC 4605<BR></FONT><BR></DIV>=0A= <DIV>=0A= <DIV dir=3Dltr align=3Dleft><SPAN class=3D080192223-02112010><FONT = color=3D#0000ff size=3D2 face=3DArial>Hi Alvaro,</FONT></SPAN></DIV>=0A= <DIV dir=3Dltr align=3Dleft><SPAN class=3D080192223-02112010><FONT = color=3D#0000ff size=3D2 face=3DArial></FONT></SPAN> </DIV>=0A= <DIV dir=3Dltr align=3Dleft><SPAN class=3D080192223-02112010><FONT = color=3D#0000ff size=3D2 face=3DArial>Ok I think I understand what you = are saying. So now if the new PROXY state is recomputed when a = group expires on an interface, is int this very CPU intensive because = the new state would be generated after considering the state of all the = interfaces??</FONT></SPAN></DIV>=0A= <DIV dir=3Dltr align=3Dleft><SPAN class=3D080192223-02112010><FONT = color=3D#0000ff size=3D2 face=3DArial></FONT></SPAN> </DIV>=0A= <DIV dir=3Dltr align=3Dleft><SPAN class=3D080192223-02112010><FONT = color=3D#0000ff size=3D2 face=3DArial>Kunal</FONT></SPAN></DIV><BR>=0A= <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft>=0A= <HR tabIndex=3D-1>=0A= <FONT size=3D2 face=3DTahoma><B>From:</B> Alvaro Fernandez = [mailto:[email protected]] <BR><B>Sent:</B> Tuesday, November 02, = 2010 9:40 AM<BR><B>To:</B> Kunal Shah<BR><B>Cc:</B> = [email protected]<BR><B>Subject:</B> RE: [magma] Question about proxy = implemenation in RFC 4605<BR></FONT><BR></DIV>=0A= <DIV></DIV>=0A= <P><FONT size=3D2>Hi Kunal<BR><BR>Just something else.<BR><BR>From your = last e-mail: " i.e the state that would exist if all the = interfaces represented individual hosts on a single LAN"<BR><BR>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.<BR><BR>Regards<BR><BR>Alvaro<BR><BR><BR>-----Mensaje = original-----<BR>De: Kunal Shah [<A = href=3D"mailto:[email protected]">mailto:[email protected]</A= >]<BR>Enviado el: lun 01/11/2010 23:49<BR>Para: Alvaro Fernandez<BR>CC: = [email protected]<BR>Asunto: RE: [magma] Question about proxy implemenation = in RFC 4605<BR><BR>Hi Alvaro,<BR><BR>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.<BR><BR>Or I have not = understood the RFC 4605 = correctly...<BR><BR>Kunal<BR><BR>________________________________<BR>From= : Alvaro Fernandez [<A = href=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>= Sent: Monday, November 01, 2010 2:19 PM<BR>To: Kunal Shah<BR>Cc: = [email protected]<BR>Subject: RE: [magma] Question about proxy = implemenation in RFC 4605<BR><BR><BR>Hi Kunai,<BR><BR>I thing my = previous Mail was wrong. I was thinking in once interface with = m=FAltiple host and this is not your question.<BR><BR>The proxy should = apply same rules explained inRFC3376 in the funci=F3n = IPMulticastListen when there are different sockets using the same = multicast group.<BR><BR>I think there is no need for queries, just apply = these rules.<BR><BR>Hope this will = help<BR><BR>=C1lvaro<BR><BR>-----Mensaje original-----<BR>De: Kunal Shah = [<A = href=3D"mailto:[email protected]">mailto:[email protected]</A= >]<BR>Enviado el: lun 01/11/2010 19:30<BR>Para: Alvaro Fernandez<BR>CC: = [email protected]<BR>Asunto: RE: [magma] Question about proxy implemenation = in RFC 4605<BR><BR>Hi Alvaro,<BR><BR>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??<BR><BR>Kunal<BR><BR>________________________________<BR>From= : Alvaro Fernandez [<A = href=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>= Sent: Saturday, October 30, 2010 10:36 AM<BR>To: Kunal Shah<BR>Cc: = [email protected]<BR>Subject: RE: [magma] Question about proxy = implemenation in RFC 4605<BR><BR><BR>Hi Kunal<BR><BR>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<BR><BR>=C1lvaro<BR><BR><BR>-----Mensaje original-----<BR>De: = [email protected] en nombre de Kunal Shah<BR>Enviado el: s=E1b = 30/10/2010 2:46<BR>Para: [email protected]<BR>Asunto: [magma] Question = about proxy implemenation in RFC 4605<BR><BR>Hi all,<BR><BR>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:<BR><BR>Interface 1 has host reporting Include = S1 -> I(S1)<BR>Interface 2 has host reporting Exclude S2 -> = E(0,S2)<BR>Interface 3 has host reporting Exclude nothing -> = E(0,0)<BR><BR>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.<BR>Is there a better way to recompute the new membership = record??<BR><BR><BR>Thanks<BR>Kunal<BR><BR><BR><BR><BR><BR></FONT></P></D= IV></BODY></HTML> ------_=_NextPart_001_01CB7B2C.E5AEA35B-- --===============0162526829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list [email protected] https://www.ietf.org/mailman/listinfo/magma --===============0162526829==--