Re: Question about proxy implemenation in RFC 4605
"Alvaro Fernandez" <[email protected]> Tue, 2 Nov 2010 19:42:06 +0100
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2145692492== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7ABD.B352F25B" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7ABD.B352F25B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Mensaje original----- De: Alvaro Fernandez Enviado el: mar 02/11/2010 9:38 Para: Kunal Shah CC: [email protected] Asunto: RE: [magma] Question about proxy implemenation in RFC 4605 =20 Hi Kunan, =20 RFC 4605 refers to RFC 3376 for this: =20 From RFC 4605. (4.1) The membership database is a set of membership records of the form: (multicast-address, filter-mode, source-list) Each record is the result of the merge of all subscriptions for that record's multicast-address on downstream interfaces. If some subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, these subscriptions are converted to IGMPv3/MLDv2 subscriptions. The IGMPv3/MLDv2 and the converted subscriptions are first preprocessed to remove the timers in the subscriptions and, if the filter mode is EXCLUDE, to remove every source whose source timer > 0. Then the preprocessed subscriptions are merged using the merging rules for multiple memberships on a single interface (specified in Section 3.2 of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2 specification [MLDv2]) =20 =20 Section 3.2 of RFC 3376 =20 =20 3.2. Interface State In addition to the per-socket multicast reception state, a system must also maintain or compute multicast reception state for each of its interfaces. That state conceptually consists of a set of records of the form: (multicast-address, filter-mode, source-list) At most one record per multicast-address exists for a given interface. This per-interface state is derived from the per-socket state, but may differ from the per-socket state when different sockets have differing filter modes and/or source lists for the same multicast address and interface. For example, suppose one application or process invokes the following operation on socket s1: IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} ) requesting reception on interface i of packets sent to multicast address m, *only* if they come from source a, b, or c. Suppose another application or process invokes the following operation on socket s2: =20 Cain, et. al. Standards Track [Page 5] RFC 3376 IGMPv3 October 2002 IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} ) requesting reception on the same interface i of packets sent to the same multicast address m, *only* if they come from sources b, c, or d. In order to satisfy the reception requirements of both sockets, it is necessary for interface i to receive packets sent to m from any one of the sources a, b, c, or d. Thus, in this example, the reception state of interface i for multicast address m has filter mode INCLUDE and source list {a, b, c, d}. After a multicast packet has been accepted from an interface by the IP layer, its subsequent delivery to the application or process listening on a particular socket depends on the multicast reception state of that socket [and possibly also on other conditions, such as what transport-layer port the socket is bound to]. So, in the above example, if a packet arrives on interface i, destined to multicast address m, with source address a, it will be delivered on socket s1 but not on socket s2. Note that IGMP Queries and Reports are not subject to source filtering and must always be processed by hosts and routers. Filtering of packets based upon a socket's multicast reception state is a new feature of this service interface. The previous service interface [RFC1112] described no filtering based upon multicast join state; rather, a join on a socket simply caused the host to join a group on the given interface, and packets destined for that group could be delivered to all sockets whether they had joined or not. The general rules for deriving the per-interface state from the per-socket state are as follows: For each distinct (interface, multicast-address) pair that appears in any socket state, a per- interface record is created for that multicast address on that interface. Considering all socket records containing the same (interface, multicast-address) pair, o if *any* such record has a filter mode of EXCLUDE, then the filter mode of the interface record is EXCLUDE, and the source list of the interface record is the intersection of the source lists of all socket records in EXCLUDE mode, minus those source addresses that appear in any socket record in INCLUDE mode. For example, if the socket records for multicast address m on interface i are: from socket s1: ( i, m, EXCLUDE, {a, b, c, d} ) from socket s2: ( i, m, EXCLUDE, {b, c, d, e} ) from socket s3: ( i, m, INCLUDE, {d, e, f} ) =20 =20 Cain, et. al. Standards Track [Page 6] RFC 3376 IGMPv3 October 2002 then the corresponding interface record on interface i is: ( m, EXCLUDE, {b, c} ) If a fourth socket is added, such as: from socket s4: ( i, m, EXCLUDE, {} ) then the interface record becomes: ( m, EXCLUDE, {} ) o if *all* such records have a filter mode of INCLUDE, then the filter mode of the interface record is INCLUDE, and the source list of the interface record is the union of the source lists of all the socket records. For example, if the socket records for multicast address m on interface i are: from socket s1: ( i, m, INCLUDE, {a, b, c} ) from socket s2: ( i, m, INCLUDE, {b, c, d} ) from socket s3: ( i, m, INCLUDE, {e, f} ) then the corresponding interface record on interface i is: ( m, INCLUDE, {a, b, c, d, e, f} ) An implementation MUST NOT use an EXCLUDE interface record to represent a group when all sockets for this group are in INCLUDE state. If system resource limits are reached when an interface state source list is calculated, an error MUST be returned to the application which requested the operation. The above rules for deriving the interface state are (re-)evaluated whenever an IPMulticastListen invocation modifies the socket state by adding, deleting, or modifying a per-socket state record. Note that a change of socket state does not necessarily result in a change of interface state. =20 -------------- =20 So I think just applying these rules there is no need for querys =20 Don't hesitate to contact me for a follow up =20 Alvaro ________________________________ 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, =20 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.=20 =20 Or I have not understood the RFC 4605 correctly... =20 Kunal =20 ________________________________ From: Alvaro Fernandez [mailto:[email protected]]=20 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_01CB7ABD.B352F25B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>RE: [magma] Question about proxy implemenation in RFC = 4605</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <BR> <BR> <BR> <P><FONT SIZE=3D2>-----Mensaje original-----<BR> De: Alvaro Fernandez<BR> Enviado el: mar 02/11/2010 9:38<BR> Para: Kunal Shah<BR> CC: [email protected]<BR> Asunto: RE: [magma] Question about proxy implemenation in RFC 4605<BR> <BR> Hi Kunan,<BR> <BR> RFC 4605 refers to RFC 3376 for this:<BR> <BR> From RFC 4605. (4.1)<BR> The membership database is a set of membership records of the form:<BR> (multicast-address, filter-mode, source-list)<BR> Each record is the result of the merge of all subscriptions = for that<BR> record's multicast-address on downstream interfaces. = If some<BR> subscriptions are IGMPv1 or IGMPv2/MLDv1 subscriptions, = these<BR> subscriptions are converted to IGMPv3/MLDv2 = subscriptions. The<BR> IGMPv3/MLDv2 and the converted subscriptions are first = preprocessed<BR> to remove the timers in the subscriptions and, if the = filter mode is<BR> EXCLUDE, to remove every source whose source timer > = 0. Then the<BR> preprocessed subscriptions are merged using the merging = rules for<BR> multiple memberships on a single interface (specified in = Section 3.2<BR> of the IGMPv3 specification [RFC3376] and in Section 4.2 of = the MLDv2<BR> specification [MLDv2])<BR> <BR> <BR> Section 3.2 of RFC 3376<BR> <BR> <BR> 3.2. Interface State<BR> In addition to the per-socket multicast = reception state, a system<BR> must also maintain or compute multicast = reception state for each of<BR> its interfaces. That state conceptually = consists of a set of<BR> records of the form:<BR> (multicast-address, = filter-mode, source-list)<BR> At most one record per multicast-address exists = for a given<BR> interface. This per-interface state is = derived from the per-socket<BR> state, but may differ from the per-socket state = when different<BR> sockets have differing filter modes and/or = source lists for the<BR> same multicast address and interface. For = example, suppose one<BR> application or process invokes the following = operation on socket<BR> s1:<BR> IPMulticastListen ( s1, i, m, = INCLUDE, {a, b, c} )<BR> requesting reception on interface i of packets = sent to multicast<BR> address m, *only* if they come from source a, = b, or c. Suppose<BR> another application or process invokes the = following operation on<BR> socket s2:<BR> <BR> Cain, et. = al. &nbs= p; Standards = Track &n= bsp; [Page 5]<BR> <BR> RFC = 3376 &nb= sp; &nbs= p; = IGMPv3 &= nbsp; October 2002<BR> <BR> IPMulticastListen ( s2, i, m, = INCLUDE, {b, c, d} )<BR> requesting reception on the same interface i of = packets sent to the<BR> same multicast address m, *only* if they come = from sources b, c, or<BR> d. In order to satisfy the reception = requirements of both sockets,<BR> it is necessary for interface i to receive = packets sent to m from<BR> any one of the sources a, b, c, or d. = Thus, in this example, the<BR> reception state of interface i for multicast = address m has filter<BR> mode INCLUDE and source list {a, b, c, d}.<BR> After a multicast packet has been accepted from = an interface by the<BR> IP layer, its subsequent delivery to the = application or process<BR> listening on a particular socket depends on the = multicast reception<BR> state of that socket [and possibly also on = other conditions, such<BR> as what transport-layer port the socket is = bound to]. So, in the<BR> above example, if a packet arrives on interface = i, destined to<BR> multicast address m, with source address a, it = will be delivered on<BR> socket s1 but not on socket s2. Note that = IGMP Queries and Reports<BR> are not subject to source filtering and must = always be processed by<BR> hosts and routers.<BR> Filtering of packets based upon a socket's = multicast reception<BR> state is a new feature of this service = interface. The previous<BR> service interface [RFC1112] described no = filtering based upon<BR> multicast join state; rather, a join on a = socket simply caused the<BR> host to join a group on the given interface, = and packets destined<BR> for that group could be delivered to all = sockets whether they had<BR> joined or not.<BR> The general rules for deriving the = per-interface state from the<BR> per-socket state are as follows: For each = distinct (interface,<BR> multicast-address) pair that appears in any = socket state, a per-<BR> interface record is created for that multicast = address on that<BR> interface. Considering all socket records = containing the same<BR> (interface, multicast-address) pair,<BR> o if *any* such record has a filter mode of EXCLUDE, then = the filter<BR> mode of the interface record is EXCLUDE, and = the source list of the<BR> interface record is the intersection of the = source lists of all<BR> socket records in EXCLUDE mode, minus those = source addresses that<BR> appear in any socket record in INCLUDE = mode. For example, if the<BR> socket records for multicast address m on = interface i are:<BR> from socket s1: ( i, m, = EXCLUDE, {a, b, c, d} )<BR> from socket s2: ( i, m, = EXCLUDE, {b, c, d, e} )<BR> from socket s3: ( i, m, = INCLUDE, {d, e, f} )<BR> <BR> <BR> Cain, et. = al. &nbs= p; Standards = Track &n= bsp; [Page 6]<BR> <BR> RFC = 3376 &nb= sp; &nbs= p; = IGMPv3 &= nbsp; October 2002<BR> <BR> then the corresponding interface record on = interface i is:<BR> &= nbsp; = ( m, EXCLUDE, {b, c} )<BR> If a fourth socket is added, such as:<BR> from socket s4: ( i, m, = EXCLUDE, {} )<BR> then the interface record becomes:<BR> &= nbsp; = ( m, EXCLUDE, {} )<BR> o if *all* such records have a filter mode of INCLUDE, then = the<BR> filter mode of the interface record is INCLUDE, = and the source list<BR> of the interface record is the union of the = source lists of all the<BR> socket records. For example, if the = socket records for multicast<BR> address m on interface i are:<BR> from socket s1: ( i, m, = INCLUDE, {a, b, c} )<BR> from socket s2: ( i, m, = INCLUDE, {b, c, d} )<BR> from socket s3: ( i, m, = INCLUDE, {e, f} )<BR> then the corresponding interface record on = interface i is:<BR> &= nbsp; = ( m, INCLUDE, {a, b, c, d, e, f} )<BR> An implementation MUST NOT use an EXCLUDE = interface record to<BR> represent a group when all sockets for this = group are in INCLUDE<BR> state. If system resource limits are = reached when an interface<BR> state source list is calculated, an error MUST = be returned to the<BR> application which requested the operation.<BR> The above rules for deriving the interface state are = (re-)evaluated<BR> whenever an IPMulticastListen invocation modifies the = socket state by<BR> adding, deleting, or modifying a per-socket state = record. Note that<BR> a change of socket state does not necessarily result = in a change of<BR> interface state.<BR> <BR> --------------<BR> <BR> So I think just applying these rules there is no need for querys<BR> <BR> Don't hesitate to contact me for a follow up<BR> <BR> Alvaro<BR> <BR> <BR> ________________________________<BR> <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> <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> <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> <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> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CB7ABD.B352F25B-- --===============2145692492== 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 --===============2145692492==--