SSM vs MSDP (was: IP Multicasting)
-----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@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-----
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | Manager of IP networks built within my own home
Dear Bill; Bill Nickless wrote:
-----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.
This is, of course, the conventional wisdom of today. And I think that it has one strong thing going for it : It represents a break from the previous, one size fits all, view of multicasting. Group communication is tough. It is not made easier by pretending otherwise. SSM is tailored for one to many broadcasts. BUT, I agree with you in many ways. What does SSM buy you ? 1.) Freedom from MSDP. This is a mixed thing. Why is inter-domain multicast connectivity so flaky ? The conventional wisdom is that MSDP information is being lost. We shall see, but at least SSM gets around it. Loosing MSDP means you lose knowledge of sources potentially available, which is not really a good thing. 2.) SSM is perceived as being a means of having an exclusive "lock" on a broadcast, so that a random person cannot send to a SSM multicast group. (The flip slide is that it creates the possibly of certain type of DOS attacks.) This may be the biggest selling point to _broadcasters_. 3.) SSM is a break from the past. Didn't want to deploy multicasting ? Now you can deploy next years model ! (Do not denigrate these psychological factors. It HAS resulting in new interest in multicasting.) IMHO, the WORST thing about SSM is that, in their enthusiasm, people involved have tended to denigrate ISM (Internet Standard Multicast), even to the point of saying at IETF meetings that ISM will die. ISM will not die. I would argue that anyone who makes the effort to deploy SSM will want to deploy ISM.
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.
I use your beacon system, and think it is the most useful such tool out there, and have urged everyone interested to bring up a beacon (we're there as hendrix.multicasttech.com). I think that there will be a need for BOTH ISM and SSM beacon monitoring.
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.
Not quite - you have to implement internal route filters on the SSM address space on your core routers. If it had been me, I would have made SSM a true subset of PIM-SM, so that you could use the old, ISM, way to join groups, if it was available to you. But this was not the design path chosen.
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.)
True, but it's not too hard. Microsoft Whistler is supposed to have IGMPv3. There are Linux and BSD kernels with it now. U. Oregon is doing SSM broadcasting now. We expect to begin SSM broadcasts "Real Soon Now." For the time being, they will duplicate our existing ISM broadcasts.
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.
I agree - one reason why ISM monitors will remain useful. What is not clear is how MSDP could scale to 30,000 separate ASN's. One thing that seems clear to me is that BGMP is dead (but YMMV).
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.
I agree here - see above. You left out that SAP/SDR will not support SSM. There has been a big argument about this in the SSM IETF WG. The consensus is that source info will be communicated out of band (i.e., web pages). As usual, I take the minority viewpoint. I think that SSM will NEED something like SAP. Just think about doing a beacon project where beacons can join at will - how would you know in SSM ? I think that there sorts of consideration will lead to a re-inventing of the SAP wheel in some scalable fashion.
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@mcs.anl.gov
-- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com
-----BEGIN PGP SIGNED MESSAGE----- At 10:40 AM 1/3/2001 -0500, Marshall Eubanks wrote:
1.) Freedom from MSDP. This is a mixed thing. Why is inter-domain multicast connectivity so flaky ? The conventional wisdom is that MSDP information is being lost. We shall see, but at least SSM gets around it. Loosing MSDP means you lose knowledge of sources potentially available, which is not really a good thing.
Really? I hadn't heard that conventional wisdom. I obviously need to get out more (he says as he corresponds with his travel secretary about attending his first NANOG, #21.) My experience with deploying Access Grid has seen apparent MSDP lossage. But it almost always turns out not to be a bug in the MSDP stuff. Instead, most often, it turns out to be a bug in all but recent [ >= 12.0(10) ] Cisco PIM-SM implementations. And the bug isn't in the core router code or even the Rendezvous Point code--it's in the code that runs on the Designated Router for a given edge subnet. In a nutshell, occasionally the Designated Router for a subnet will stop sending PIM Register packets towards the Rendezvous Point. Thus, the Rendezvous Point doesn't have any PIM Registers to convert into MSDP SAs. This turns up on the Rendezvous Point (MSDP speaker) as a lack of an A flag, and on the Designated Router as the lack of an F flag. See Cisco Bug ID CSCdp68820 for all the details. Unfortunately, this only breaks MSDP--the existing PIM-SM state in the internetwork stays up as long as traffic flows. Thus, some remote sites don't get the traffic while other sites do. And new receiving sites don't get the traffic from the site with the broken router. And the fix is to have the sending site upgrade to IOS 12.0(10) or later on their router directly connected to the source. And while this sounds like a reasonable and easy thing to do, I'm working with at least two major universities that are still running 11.2(22) or thereabouts. We've had to set up GRE tunnels to bypass those routers. (oop, ack)
IMHO, the WORST thing about SSM is that, in their enthusiasm, people involved have tended to denigrate ISM (Internet Standard Multicast), even to the point of saying at IETF meetings that ISM will die. ISM will not die. I would argue that anyone who makes the effort to deploy SSM will want to deploy ISM.
Yes, I think your and my humble opinions mesh perfectly.
I use your beacon system, and think it is the most useful such tool out there, and have urged everyone interested to bring up a beacon (we're there as hendrix.multicasttech.com).
I think that there will be a need for BOTH ISM and SSM beacon monitoring.
Thank you for your kind words about the beacon. We have also found it very useful. When we start to bring up an Access Grid site the first thing we tell people to do is to start a beacon, even before they order the hardware. And yes I agree that we need both ISM and SSM monitoring of this form. Because IP multicast (ISM and SSM) requires per-flow state in lots of routers along the tree from sender to receivers, my experience points to a need for a long-term monitoring system. Long term monitoring of a test signal in a real-life environment is (in my opinion) one of the best ways to cover all the weird corner cases that crop up over time. === 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@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOlNz4Kwgm7ipJDXBAQGTSwP+I2DFYD4ku34s/VBznagXh4/dVJX9repi P8NVcUUzSnLe3fHdWD7jC9Ng8dDTDsbsY4X47LnyMKsntEoNU5JKf+I9OIqVq5Er C9+pfC8vQf6L/mz7gjlZlnp/qE+BAkJd8RRmnxt3ah6h+RfLdCWMMt+r2H0kI+0u 61cpP0O/XQ4= =ERYi -----END PGP SIGNATURE-----
At 10:40 03/01/01 -0500, Marshall Eubanks wrote:
You left out that SAP/SDR will not support SSM. There has been a big argument about this in the SSM IETF WG. The consensus is that source info will be communicated out of band (i.e., web pages). As usual, I take the minority viewpoint. I think that SSM will NEED something like SAP. Just think about doing a beacon project where beacons can join at will - how would you know in SSM ? I think that there sorts of consideration will lead to a re-inventing of the SAP wheel in some scalable fashion.
IPmc requires many debugging tools, builtin to the native router, to make it all work. Without sap/sdr capabilities, SSM will never take off. Having all the web pages out there are nice extras, but do not replace the needed builtin tools. -Hank
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@mcs.anl.gov
-- Regards Marshall Eubanks
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com
Hank Nussbacher wrote:
At 10:40 03/01/01 -0500, Marshall Eubanks wrote:
You left out that SAP/SDR will not support SSM. There has been a big argument about this in the SSM IETF WG. The consensus is that source info will be communicated out of band (i.e., web pages). As usual, I take the minority viewpoint. I think that SSM will NEED something like SAP. Just think about doing a beacon project where beacons can join at will - how would you know in SSM ? I think that there sorts of consideration will lead to a re-inventing of the SAP wheel in some scalable fashion.
IPmc requires many debugging tools, builtin to the native router, to make it all work. Without sap/sdr capabilities, SSM will never take off. Having all the web pages out there are nice extras, but do not replace the needed builtin tools.
-Hank
I'm not sure I agree with this. My case for a SDP like ability is basically a business / convenience one - i.e., it would be nice to have. I do not see why it would be really essential. Also, if you don't believe that ISM will die, then neither will SAP. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com
participants (4)
-
Bill Nickless -
Hank Nussbacher -
Jared Mauch -
Marshall Eubanks