Subject: IGMPv3 Proxying

From: Srivatsan S <[email-masked]>
Date: Thu, 07 Mar 2002 18:37:27 +0530

Hi,

    An IGMP proxy behaves as a router on the downstream i/fs and host on
the upstream i/fs. Similarly for an IGMPv3 proxy, a router has to
perform as both router and host on downstream and upstream i/fs
respectively. I am specifically looking at this particular context
(IGMPv3 Proxying). 

    Consider a case where a group has been registered and mode is
EXCLUDE. At present, one source is registered under EXCLUDE mode which
should be completely blocked (source_timer = 0). Now, the router
receives a request for the source to be unblocked on the same interface
(i.e., a conflict occurs). Now, a source_timer is started for this
source. How should this change be communicated on the upstream i/f side
to the neighbouring Mcast Router. According to the state table under the
Section 5.1 in the draft for igmpv3, following has been mentioned.

  Old State         New State         State-Change Record Sent
  ---------         ---------         ------------------------
  EXCLUDE (A)       EXCLUDE (B)       ALLOW (A-B), BLOCK (B-A)

  In the particular case I mentioned, A-B and B-A = 0 and hence no
report is sent. But in effect, mcast data packets from the source should
be forwarded to the proxy. I think on the upstream side, in addition to
the change in the number of hosts, the state of the source should also
be taken care of. Am I missing something here ?

Thanks In Advance,
Srivatsan

-- 
Srivatsan S
Email: [email-masked]
Phone: 91-80-8520261 Extn 6506
Bangalore, India.

---

From: Haixiang He <[email-masked]>
Date: Thu, 07 Mar 2002 11:49:58 -0500

Hi,

You ask a very good question. Since IGMP proxying work is moved to MAGMA so
I also CC this to MAGMA mailing list.

I think we can understand this way. IGMP proxying is proxying IGMP requests
not relaying IGMP requests. So some information may be lost during the
proxying. But the bottom line is that the multicast traffic forwarding
should not be affected.

In IGMPv3 specification section 3, we can see that the INCLUDE information
is not communicated to the routers if the interface mode is EXCLUDE. Similar
in IGMP proxying, some information is not communicated.

If an interface is in EXCLUDE mode and the source S' source_timer>0, S is
actually in INCLUDE mode. The rationale to keep this source record is
described in IGMPv3 specification A.3. So in your example, the old state is
EXCLUDE( {S}) and the new state is EXCLUDE( {}). ALLOW({S}-{})= ALLOW({S}).
So the traffic from S will be forwarded to the proxy.

I do think that we should clarify this in the draft since IGMPv3 draft does
not deal this issue.

Regards,

Haixiang

---

From: Wilbert de Graaf <[email-masked]>
Date: Thu, 7 Mar 2002 08:40:40 -0800

Srivatsan,

> to the neighbouring Mcast Router.

Probably ALLOW(that source)

> According to the state table under the

>   In the particular case I mentioned, A-B and B-A = 0 and hence no

I don't think A-B = 0. If that source was labelled 's', and substitute A =
s, than B = s - s = 0, than A - B= {s} - 0 = {s} -> ALLOW {s}