Re: Question about proxy implemenation in RFC 4605
"Alvaro Fernandez" <[email protected]> Tue, 2 Nov 2010 09:38:01 +0100
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0510976379==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CB7A69.6C391703"
This is a multi-part message in MIME format.
------_=_NextPart_001_01CB7A69.6C391703
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_01CB7A69.6C391703
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 http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2900.5969" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText26515 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>=0A=
<DIV id=3DidOWAReplyText90503 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Hi =
Kunan,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>RFC 4605 refers to RFC 3376 =
for this:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr>From RFC 4605. (4.1)</DIV>=0A=
<DIV dir=3Dltr>The membership database is a set of membership records of =
the form:</DIV>=0A=
<DIV dir=3Dltr> (multicast-address, filter-mode, =
source-list)</DIV>=0A=
<DIV dir=3Dltr> 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. <STRONG><U>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]</U></STRONG> and in Section 4.2 of the =
MLDv2<BR> specification [MLDv2])</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>Section 3.2 of RFC 3376</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>3.2. Interface State</DIV>=0A=
<DIV dir=3Dltr> 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:</DIV>=0A=
<DIV dir=3Dltr> =
(multicast-address, filter-mode, source-list)</DIV>=0A=
<DIV dir=3Dltr> 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:</DIV>=0A=
<DIV dir=3Dltr> =
IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )</DIV>=0A=
<DIV dir=3Dltr> 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:</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>Cain, et. =
al. &nbs=
p; Standards =
Track &n=
bsp; [Page 5]<BR><BR>RFC =
3376 &nb=
sp; &nbs=
p; =
IGMPv3 &=
nbsp; October 2002</DIV>=0A=
<DIV dir=3Dltr><BR> =
IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )</DIV>=0A=
<DIV dir=3Dltr> 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}.</DIV>=0A=
<DIV dir=3Dltr> 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.</DIV>=0A=
<DIV dir=3Dltr> 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.</DIV>=0A=
<DIV dir=3Dltr> 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,</DIV>=0A=
<DIV dir=3Dltr> 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:</DIV>=0A=
<DIV dir=3Dltr> 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} )</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>Cain, et. =
al. &nbs=
p; Standards =
Track &n=
bsp; [Page 6]<BR><BR>RFC =
3376 &nb=
sp; &nbs=
p; =
IGMPv3 &=
nbsp; October 2002</DIV>=0A=
<DIV dir=3Dltr><BR> then the corresponding =
interface record on interface i is:</DIV>=0A=
<DIV =
dir=3Dltr> &nb=
sp; &nbs=
p; ( m, EXCLUDE, {b, c} )</DIV>=0A=
<DIV dir=3Dltr> If a fourth socket is added, =
such as:</DIV>=0A=
<DIV dir=3Dltr> from socket =
s4: ( i, m, EXCLUDE, {} )</DIV>=0A=
<DIV dir=3Dltr> then the interface record =
becomes:</DIV>=0A=
<DIV =
dir=3Dltr> &nb=
sp; &nbs=
p; ( m, EXCLUDE, {} )</DIV>=0A=
<DIV dir=3Dltr> 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:</DIV>=0A=
<DIV dir=3Dltr> 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} )</DIV>=0A=
<DIV dir=3Dltr> then the corresponding interface =
record on interface i is:</DIV>=0A=
<DIV =
dir=3Dltr> &nb=
sp; &nbs=
p; ( m, INCLUDE, {a, b, c, d, e, f} )</DIV>=0A=
<DIV dir=3Dltr> 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.</DIV>=0A=
<DIV dir=3Dltr> 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.</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>--------------</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>So I think just applying these rules there is no need for =
querys</DIV>=0A=
<DIV dir=3Dltr> </DIV></DIV>=0A=
<DIV dir=3Dltr>Don't hesitate to contact me for a follow up</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>Alvaro<BR></DIV></FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>De:</B> Kunal Shah =
[mailto:[email protected]]<BR><B>Enviado el:</B> lun 01/11/2010 =
23:49<BR><B>Para:</B> Alvaro Fernandez<BR><B>CC:</B> =
[email protected]<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=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2>Hi Alvaro,</FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2>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. =
</FONT></SPAN><SPAN class=3D534413422-01112010><FONT face=3DArial =
color=3D#0000ff size=3D2>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. </FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2>Or I have not understood the RFC =
4605 correctly...</FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2>Kunal</FONT></SPAN></DIV>=0A=
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT =
face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV>=0A=
<DIV dir=3Dltr align=3Dleft>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2><B>From:</B> =
Alvaro Fernandez [mailto:[email protected]] <BR><B>Sent:</B> Monday, =
November 01, 2010 2:19 PM<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 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></FONT></P></DIV><=
/BODY></HTML>
------_=_NextPart_001_01CB7A69.6C391703--
--===============0510976379==
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
--===============0510976379==--