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

From: Toerless Eckert <[email-masked]>
Date: Thu, 5 Jan 2006 02:38:30 -0800

Fei,

I'm not quite clear what your question is. Check out the
SSM architecture draft. In traditional "ASM" (Any Source Multicast),
a host "joins to a group", which is basically what you could do in
IGMPv1 and IGPv2. In IGMPv3, that would be an EXCLUDE({}, G) membership.
In SSM, the host "subscribes to a channel" (S,G), which is only
possible with IGMPV3 via an INCLUDE({S},G) membership. If you talk
about such INCLUDE({S},G) memberships, then this is always SSM, and
if you have two channels, then they could use the same group, eg:
(S1,G) = TV-program-1 and (S2,G) = TV-program-2, or they could
use different groups, eg: (S1,G1) = TV-program-1 and (S2,G2) = TV-program-2.

There is no architecture reason win SM hy two TV-programs should have
different groups, but thee are some short-term deployment reasons:
  a) When users migrate from ASM to SSM, some transition methods
     (like SSM Mapping) still require for different programs to use
      different groups.
  b) When using an L2 switched access network with IGMP snooping,
     man current IGMP snoopingswitches can suport IGMPv3 snooping, but
     can not separate in the forwarding plane forwarding for (S1,G)
     and (S2,G) because their L2 forwarding isonly based on MAC(G).

Whether or not a single IGMPv3 packet would ever contain the wo
type6 message elements is a question of the host-stack implementation.
I would bet that any implementation, eg: in a Set-Top-Box would most
likely send two separate packets, one for the TV-program-1 "unsubscribe"
(BLOCK_OLD_SOURCE) and another packet for the "subscribe" of the
new TV-program (ALLOW_NEW_SOURCE). The reason is that the TV-application
wil likely use the MSF-PI towards the (STB's) OS, and that has two different
calls for these actions, and the most common OS implementation of
IGMPv3 wil not try to batch multiple API cals for such triggerent
membership changes. But it would of course be a nice optimization
to put both requests into the same packet.

Does this answer your questions ?

Cheers
    Toerless

On Thu, Jan 05, 2006 at 02:16:27PM +0800, fei wang wrote:
> 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

-- 
Thanks
   Toerless Eckert

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 5 Jan 2006 11:35:08 -0500

Hello;

>      and (S2,G) because their L2 forwarding isonly based on MAC(G).

I would add that

- PIM snooping switches also may only look at G, not {S,G}. (Others
may only look at S.) So, these would have the same problem with
sources sharing the same channel numbers.

- SSM groups with the same channel will of course map into the same
Ethernet MAC address, and thus, if you are on a LAN that floods
multicast, or a snooping switch that can't distinguish between them,
this may  cause problems as the device NIC card will pass both streams
up the stack. This will be even worse if they use the same ports.

So, I would recommend that SSM channels try and pick unique groups.
There are a lot to chose from.

> > multicast Group could NOT be owned by two Sources (TV station in IPTV).

Sources do not "own" groups. In ASM, more than one source can send (of
course, this may be desired), in SSM each channel is associated with a
particular source address.

> > realistic applications (besides IPTV)?

There is nothing in SSM to prevent one source from sourcing many
channels, just as there is nothing in ASM to prevent one source to
send to many groups. Both are quite routine.

Regards
Marshall