North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: SSM vs MSDP (was: IP Multicasting)

  • From: Jared Mauch
  • Date: Wed Jan 03 04:30:15 2001

On Tue, Jan 02, 2001 at 03:54:01PM -0600, Bill Nickless wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 

	Cisco has igmpv3 support in their routers and switches in the
latest service provider releases.  I think it's also in 12.1(5)T.  Juniper
has supported ssm, etc.. for awhile.  This takes care of most of the core
of peoples networks.

> 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 

	I've been hearing that igmpv3 will not be in Windows for at
least another year.

> IGMPv3 yet?  What about ACE?  (See above for IP Multicast Beacon tool; it's 
> pure Java.)

	There are a number of hacks to get around lack of igmpv3 support
in endstations.  I'm aware that there are patches for most of the 
free unices to make them support igmpv3 which is encouraging.  Windows
and other operating systems have applications that generate joins
that trigger ssm join to the multicast group.  Someone else more
knowledgeable than myself should speak up on how this all works and
what they are doing.  U of O is doing a lot of work with SSM last I
checked.

> 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.

	This is very useful because you can check the number of "SA's"
that are in the "multicast world".

> 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.

	As am I.  I'd like to see more providers deploying multicast
even if it's not used or supported for their customers.  At my previous
job we deployed multicast within the network and eventually received
customer requests for multicast which meant that we could deliver the
services to the customer that they requested.  It turned out later that
they didn't know quite what they wanted when they requested it but
the customer not knowing exactly what they want with streaming media
is very typical i'm sure.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email protected]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
END OF LINE  | Manager of IP networks built within my own home