[AG-TECH] IGMPv3, Source Specific Multicast, fully supported in Windows XP

[Jay Beavers]

> SSM gets around this problem by making the receivers identify the
source to the network before the source goes active.

Using the RTP protocol in a stateless server multicast model you
discover the current sources that you want to listen to by receiving
those sources RTCP SDES packets over the multicast channel.  After
receiving this "Sender Description" packet, you can then decide whether
you want to receive that sender's streamed RTP traffic.

I've recently been wondering if for AG-like scenarios we need to use two
IP addresses, one for "shared" traffic like RTCP SDES notifications and
another for "filtered" traffic like SSM filtered RTP streams (see my
message to the IETF AVT alias on this if you're interested).

Has any thought gone into SSM and its implication to protocol design in
AG-like scenarios?  Is this dual multicast group approach something
people have played with in the past?  Is this similar to SDP on a
dedicated multicast channel (haven't played with that myself)?  Or is it
assumed that session announcements and such are moving to a unicast
based distribution/join process like the SIP folks seem to be fond of?

-----Original Message-----
From: Bill Nickless [mailto:nickless at mcs.anl.gov] 
Sent: Friday, August 16, 2002 9:16 AM
To: eschbach at labs.mot.com
Cc: Jay Beavers; ag-tech at accessgrid.org
Subject: Re: [AG-TECH] IGMPv3, Source Specific Multicast, fully
supported in Windows XP

At 10:49 AM 8/16/2002 -0500, Jeffrey Eschbach wrote:
>I don't think IGMPv3 actually is involved on the
>source side... the router just needs to know that it should not forward
>traffic in the SSM range unless it has received a join.  (For ASM
range,
>traffic would go to the RP and then receive a "register stop" to keep
>the traffic from leaving the network.)

Close.  You're right on with the SSM mechanism.  But in the ASM case,
the 
traffic goes to the RP and then a subset gets converted into MSDP Source

Active messages and are flooded.  When a remote PIM domain notices the 
active source and sends source-specific joins, the traffic leaves the
local 
PIM domain and gets sent towards the receiver.

In my opinion, this is one of the fundamental flaws of the current
Internet 
multicast architecture.  The architectural assumption is that the
Internet 
is analogous to an old-fashioned 10Base5 Ethernet segment--nothing needs
to 
be done before putting a packet on the wire.

Since RFC 1112 laid down that architecture, the Internet community has 
learned that the best known way to route multicast traffic is via 
source-rooted distribution trees.  So there's a race condition--the 
source-rooted distribution tree can't be created until the network knows

there's a source.  But if the network only discovers a source when it
puts 
a packet on the wire, it's too late to create those source-rooted 
distribution trees.

SSM gets around this problem by making the receivers identify the source
to 
the network before the source goes active.

MSDP gets around this problem by flooding the knowledge of active 
receivers, and the first packet of the source's traffic, independent of
the 
source-rooted distribution trees.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252
7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7
nickless at mcs.anl.gov