Subject: [pim] When will the IGMPv3 type 6 Group record be sent by IPTV end users?

From: "fei wang" <[email-masked]>
Date: Thu, 5 Jan 2006 14:16:27 +0800

Let's suppose an IPTV deployment scenario.

There have two TV station TVs1 and TVs2 which may correspond to two
multicast Sources in PIM. And multiple channels associated with each TV
station which may correspond to multicast Group in PIM.

And normally the user do a channel zapping, which may result in the
type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE( TVs2,
G2) sending. I am wondering, for one Group when will the end user device
(STB or PC) send such Source-List-Change records? Since the same
multicast Group could NOT be owned by two Sources (TV station in IPTV). 

Since the IGMPV3 RFC define the detail Query and Response behavior for
the Source-List-Change record towards one Group, any scenario will
fulfill the rule? And rather, the IGMPv3 is designed to maintain the
one-multiple (one group vs. multiple sources) relationship, however for
the IPVT, in many cases, it use one Source (TV station) vs. Multiple
Group (channel) model. Any one can explain the difference from the
realistic applications (besides IPTV)? 

Regards,

Fei

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Mon, 9 Jan 2006 11:57:21 -0800

I think the the question you were asking was, "How practical is it to  
implement type 5 and 6
messages?"

FWIW:  My short answer: its not.

Switching Channels could be accomplished with just type 1 (include)  
and type 2 (exclude) messages.

IMHO: type 5 and 6 messages are used when you are receiving from a  
large number of sources
simultaneously and want to add to or remove from those sources  
without affecting the others.  But
again, an "include (S,G)" and and "exclude (S,G)" could accomplish  
this same thing depending on
how the router processed the request.

You see, putting a "I want to received from all sources except this  
one" message into
PIM is problematic.  It would result in a message that contained a  
(*,G) join with an (S,G,rp-bit) prune.
I'm not saying it can't be done (or shouldn't be done), just that it  
isn't clear at this point
that it is worth doing.

One of the reasons for this is that the internet is (I hope)  
transitioning away from sparse-mode.
Bi-dir does not have the capability of forwarding all sources except  
one.
SSM does not have the capability of forwarding all sources on a  
shared path.

My point is not that this can't be done, but rather to question  
whether or not it should be.
If you accept my premise that it should not be, then IGMPv3 type 5  
and type 6 messages
are not very useful.  And type 3 and type 4 messages become redundant.

I have to emphasize that this is an opinion on the practicality of  
implementing all of IGMPv3 and not
on whether or not it works.  If a -real- application can be defined  
that would require the
additional capability, then, of course, my response would change.

I refer you to the history of PIM and the development of dense mode.

On Jan 4, 2006, at 10:16 PM, fei wang wrote:

> Let’s suppose an IPTV deployment scenario.
>
>
>
> multicast Sources in PIM. And multiple channels associated with  
> each TV station which may correspond to multicast Group in PIM.
>
>
>
> type6 BLOCK_OLD_SOURCES( TVs1, G1 ) and type5 ALLOW_NEW_SOURCE 
> ( TVs2, G2) sending. I am wondering, for one Group when will the  
> end user device (STB or PC) send such Source-List-Change records?  
> Since the same multicast Group could NOT be owned by two Sources  
> (TV station in IPTV).
>
>
>
> Since the IGMPV3 RFC define the detail Query and Response behavior  
> for the Source-List-Change record towards one Group, any scenario  
> will fulfill the rule? And rather, the IGMPv3 is designed to  
> maintain the one-multiple (one group vs. multiple sources)  
> relationship, however for the IPVT, in many cases, it use one  
> Source (TV station) vs. Multiple Group (channel) model. Any one can  
> explain the difference from the realistic applications (besides IPTV)?
>
>
>
> Regards,
>
>
>
> Fei
>