[AG-TECH] IGMPv3, Source Specific Multicast, fully supported in Windows XP
jbeavers at microsoft.com
Fri Aug 16 11:30:02 CDT 2002
> 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?
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
>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,
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
PIM domain and gets sent towards the receiver.
In my opinion, this is one of the fundamental flaws of the current
multicast architecture. The architectural assumption is that the
is analogous to an old-fashioned 10Base5 Ethernet segment--nothing needs
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
a packet on the wire, it's too late to create those source-rooted
SSM gets around this problem by making the receivers identify the source
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
source-rooted distribution trees.
Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7
nickless at mcs.anl.gov
More information about the ag-tech