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 RTP Live: Info Bocoran RTP Slot Online Pragmatic Play Gacor Terlengkap ) 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 NLANR -- National Laboratory for Applied Network Research 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.