SSM vs MSDP (was: IP Multicasting)

Tue Jan 2 21:54:01 UTC 2001

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

Jared Mauch writes:

>The advent of SSM (single source multicast) makes such one-to-many much 
>easier than in the past.

I would be interested in learning more details about how this is the case, 
operationally, today.  My perspective argues against Jared's statement as I 
understand it.

For the past 18 months or so I've been involved in making IP multicast work 
for the Access Grid project (see http://www.mcs.anl.gov/accessgrid ) which 
is admittedly a many-to-many application.  Since the Access Grid project 
started we have been able to use it to run several multi-day meetings with 
roughly a dozen sites, plus literally hundreds of meetings with 2-5 
sites.  We have seen the larger meetings consume 20 megabits/second of 
multicast bandwidth, sustained for 10+ hours over 2-3 days.

Few sites could afford the N^2 bandwidth requirement of unicast, so Access 
Grid is fundamentally dependant on IP multicast to work properly.  I've had 
lots of fun debugging IP multicast deployment over the past 1.5 
years.  This has been at sites ranging from national laboratories to 
universities to Native American tribal colleges, in cooperation with the 
folks at networks like vBNS+, Abilene, and ESNet and their various connectors.

SSM introduces new things to debug, and I think makes IP multicast 
deployment harder to actually deploy than the existing M-BGP/PIM-SM/MSDP 
model.  Please note the date on this message--these comments are likely to 
be obsolete in the future.  But for now, here are three major reasons why:

No SSM Support in IP Multicast Beacon Tool
==========================================
We developed a Java-based tool to monitor IP multicast reachability.  This 
tool is intended to be deployed on end stations.  Each end station reports 
reachability to a central server, which makes the information available on 
a web page (see http://beaconserver.accessgrid.org:9999 for the 
reachability matrix, and http://dast.nlanr.net/projects/beacon for the code 
itself.)  Obviously this tool could be updated to support SSM, but it's not 
there yet.

SSM Requires IGMPv3 Or Other Proprietary Hacks At The End Station
=================================================================
Implementing SSM is trivial at the service provider.  Once you have M-BGP 
and PIM Sparse Mode working you are pretty much done, since your customers 
will have the burden of sending you PIM-SM joins.  It's even easier, 
because you don't have to worry about MSDP.

But at the customer things are much harder.  First, the customer has to 
provide SSM/IGMPv3 support at the edge network devices, and that support is 
by no means widespread.  Second, the customer has to install and debug the 
IGMPv3 support in the end stations, which is just now becoming 
available.  Compare IGMPv3 availability with IGMPv2 for Windows 95.  And 
finally the middleware and applications need to be appropriately coded to 
handle the SSM/IGMPv3 model.  Are the major Java distributions supporting 
IGMPv3 yet?  What about ACE?  (See above for IP Multicast Beacon tool; it's 
pure Java.)

MSDP As A Useful Debugging Tool
===============================
Yes, MSDP is another protocol you have to configure and maintain as a 
service provider.  But I have found it to be useful debugging tool for 
confirming proper operation of M-BGP and PIM-SM in certain cases.

  - Customer site without PIM-SM configured properly on a sender.  If the
    customer isn't generating an MSDP SA, then we can quickly point the
    finger at the customer, and give the customer a specific thing to get
    working (the MSDP advertisements, a.k.a. the A flag on new-model
    Cisco code.)

  - Customer site not properly doing route path forward calculation, due
    (possibly) to misconfiguration of M-BGP.  This shows up as MSDP SAs not
    being properly accepted in the customer.  That explains why a customer
    might not be sending PIM-SM joins towards the service provider.

In both of these cases, trying to debug without MSDP, but with SSM, would 
require considerably more debugging effort.  One would need to go deeper 
into the customer network and/or turn on PIM-SM debugging at the customer edge.

Summary
=======
If your objective is to reduce the amount of work your engineering staff 
has to do to support IP Multicast, I can guarantee that telling your 
customers to use M-BGP/PIM-SM/SSM instead of M-BGP/PIM-SM/MSDP will help a 
lot--but (in my opinion) for the wrong reason: it will delay the actual 
availability of IP Multicast service to the end user.

Telling your customers to use M-BGP/PIM-SM/SSM *IN ADDITION TO* 
M-BGP/PIM-SM/MSDP will indeed help reduce the amount of global MSDP state 
carried in routers over the long term, and that's arguably a very good 
thing.  I look forward to ubiquitous support of IGMPv3 in lots of vendors 
products--whether they be layer 2, layer 3, software, or whatever.
===
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>

iQCVAwUBOlJN+awgm7ipJDXBAQEQpQQAh2JkINd3K0ZTc3gM+xl2U1luyTufDDqq
Kk5AMEIfAi57kXGTmMSnSOfVolTMiz/BLHROKq0BR4q+pZuIWHuaWdUcek4vkPBM
FubhTpAUqFVvS4XKgwQkJFOEHw70hK0h2r7kmTilmNSI8MaPYzm6A992e/dM8apP
BojosYEvoRs=
=prQv
-----END PGP SIGNATURE-----