SSM in an AG context

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

John Greenfield asked me some questions in the Waterfall Glenn Access Grid 
Room this afternoon.  These questions were related to Source Specific 
Multicast and IGMP Version 3.  I realized that I typed enough that I wanted 
it in a permanent record: others may find this interesting too.  Comments 
welcome, as always.

What is SSM?
============
SSM -> Source Specific Multicast

Currently, a receiver joins a multicast group but has no ability to
specify a source. Multiple sources can exist and all data from them will be
received. SSM enables the selection of a particular source for multicast data.
This prevents traffic from other sources for the same group from being
forwarded to the host. SSM requires well-known sources and is most useful for
static applications.

The preceding paragraph was a quote from 
http://www.cisco.com/warp/public/cc/pd/iosw/iore/iomjre121/prodlit/1065_pp.htm
in case you want to read more about it.  Apparently SSM is available in 
Cisco IOS 12.1(3)T.

SSM requires IGMPv3 support in the edge routers and client hosts.  Current 
IGMPv2 allows the hosts to specify which groups they're interested in 
joining.   IGMPv3 extends this model to allow hosts to specify both the 
group AND the source.

I've been led to believe that IGMPv3 support is available as patches to 
modern Linux kernels.  SSM is a new feature in IOS 12.1(3)T which 
is  available now on the router platforms we care about.  I have not heard 
anything about IGMPv3 availability on the Wintel (95/98/me/2k) platforms.


Network implications
====================
The only missing piece for SSM deployment right now is the IGMPv3 support,
which lets a client specify both a sender and a group.  IGMPv2 (currently 
used) only lets a client express interest in a whole group.  Once the local 
client requests traffic from a source on a group, standard PIM-SM and M-BGP 
mechanisms are used to join the distribution tree.  Even the PIM-SM 
operation is simplified; the Rendezvous Point functionality goes away since 
all distribution trees are source specific.

MSDP is not required for SSM; it assumes the application (Access Grid in 
our case) knows about all active senders.  Again, the network no longer 
keeps track of all active senders in a given group.  Network Backbones like 
Abilene should require no additional work to implement SSM, since modern 
inter-domain routing is all source-specific anyway.

AG philosophical/planning implications
======================================
In an AG context, that means three additional requirements: IGMPv3 support 
on all AG node machines.  VV support to keep track of all senders in real 
time.  Client software (vic/rat/&c) extensions to allow VV to feed in the 
addresses of active sources.

The question of SSM revolves around how much we can depend on the
application to know about all participants.

My personal opinion is that SSM breaks the network support of our model of 
a virtual space.  Today a multicast group maps nicely into a virtual space
abstraction. SSM is more of a point-to-manypoint distribution model; you 
have to build more infrastructure in order to regain that virtual space.

On the other hand, building that infrastructure would be useful anyway, in
some cases, such as constrained-bandwidth nodes.  That way the 
constrained-bandwidth nodes could prioritize which streams are interesting.
===
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

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBOeTckqwgm7ipJDXBAQEr/gP+L0bfmGIwh3Y509eea/8efeORSyMH/gm8
ul3Ce0jwseeg8jC7DsfcuMsKYRJ4n5OnseNEoEfrvf8Gfj6DC4jjwQQ5Evw1CkqX
0Y2y66ObYiCIwiCAFxPlBLFtsd3RNwvbk+3mYR9YxJ6I4JEX/nondOqjaxcrMPCy
3mCSRolc3Ss=
=ZJ2a
-----END PGP SIGNATURE-----