The mbone was an experiment that used DVMRP and DVMRP tunnels, generally between unix machines running mrouted, to prove that multicasting over the internet would work. It was very successful.
However, DVMRP is a dense-mode protocol which means data from any source has to be flooded to the boundaries of the domain to create state. It doesn't scale for this to be the entire internet.
It was recognized that a sparse-mode protocol needed to be developed. But it wasn't (and IMHO still isn't) clear that a dense-mode protocol would not be useful. A group of folks began work on PIM. One of the goals was to not have to carry around network metrics (which is why its called "protocol independent multicasting"). PIM uses the unicast routing protocol to make its RPF (reverse path forwarding) decision. PIM also does both dense-mode and sparse-mode forwarding. Sparse-mode is forwarded only to receivers who specifically subscribe to the data. (ie, if no one asks for it it doesn't go anywhere).
However, PIM, like DVMRP, does not scale to the entire internet. The IETF is working on a protocol called BGMP which is suppose to establish a tree of domains or a routing heirarchy. It seems too complicated to me to be useful, but I just have to make the stuff work, I don't have to like it. ;-)
Because of this complexity, and because BGP was being enhanced to carry routes for address families other than just IPv4, MBGP was developed. At one time this stood for "Multicast BGP" but in reality, it was just the first address family that was introduced to BGP4+ (I could be wrong about it being first). Now MBGP is "Multiprotocol BGP".
MBGP allows a way of separating the internet into multicast domains, which in turn means the need for DVMRP tunnels (that made up the MBONE) no longer exists. Now, multicast data is delivered natively over the internet. Some times this is still referred to as the MBONE and that's fine, as long as it is clear that tunnels are no longer required.
John Meylor set up a AS (10666) to support this new paradigm. This AS consisted of routers in 3 locations that were connected via GRE tunnels. This AS ran in dense-mode. Enterprises and ISPs which wanted to send multicast natively could peer at these three "MIX"s (Multicast Internet Exchanges) by placing their RP on the MIX. This was necessary because there was no way to announce sources that were sending to a group in all domains. Obviously this meant flooding data from all source on the internet into AS10666, which of course, doesn't scale any better than the DVMRP tunnels (well maybe slightly better. That could be debated.)
So a protocol called MSDP (multicast source distribution protocol) was promulgated which provides a way of connecting PIM sparse-mode RP's in each sparse-mode domain together and allowing each RP to announce which sources were sending to which multicast group. These are called SA's or session announcements.
AS10666 was dismanteled. Now most multicast traffic is forwarded natively over the internet using a combintion of PIM/MBGP/MSDP. There are still many places that use DVMRP and some that use MOSPF. It depends on your specific network requirements and personel preference and sometimes vendor. I understand that there are 15 vendors offering PIM right now, but I'd be hard pressed to name them.
There are now 12+ MIXs throughout the world. If you go to www.nanog.org and look at the slides that were presented at the last meeting (this month), there is some additional information you'll be able to discover.
There have been alternate proposals for how to deliver multicast packets over the internet. This included CBT and SM (simple multicast) and EXPRESS. CBT wanted to used shared-trees so that all multicast traffic would be forwarded to a core router and then distributed down a common path rooted at that core. SM is more or less the same thing.
EXPRESS was looking at the idea that most multicast traffic would come from a single source -- like TV. And they wanted to build source-only trees.
PIM has always used a shared tree to initially deliver data to receivers. The RP (rendezvous point) is known to all routers within a domain so any router that finds out it has a directly connecte member can join the shared tree. One the RP delivers data down the share-tree the last-hop router can make the choice to join the source-only tree. So PIM supports both the shared-tree and the shortest-path tree.
Unfortunately, the shared-trees were unidirectional, meaning only from the RP to the receivers. The first-hop router would "register" or tunnel multicast packets to the RP for all the sources it served. This puts a huge load on the RP.
So now bi-directional PIM will soon be available. Now traffic can flow up and down the shared tree. So far this only works for intradomain multicast, but since the RP now becomes "virtual" in that for bi-dir pim the RP doesn't do anything and no longer has to be a physical box, the objection that the ISP's had to having to depend on an RP in some other ISP may disappear. I'm hoping that some smart guy will propose a way of arbitrarily assigning an address to be used as this virtual RP which can be placed anywhere. In this way, a web page could be set up that would allow hosts to tell their last hop router where the "RP" (remember it no longer exists) is located. This would meet the SM requirements that Radia Perlman and Tony Ballardie were championing. You can find more on the IETF web site in these documents.
draft-kouvelas-pim-bidir-new-00.txt draft-ietf-pim-bidir-00.txtTom Pusitari generated quite a bit of excitement when he brought up the idea of single source or source specific multicast via PIM at the Dec 99 IETF. This was taking the ideas promulgated in EXPRESS and combining them with IGMPv3 (which allows the host to identify to the router not only the multicast group it wants to listen to but also the host). Dave Cheriton and Hugh Holbrook had first suggested EXPRESS. Remember EXPRESS wants to work with source-trees, which PIM supports so, now there is going to be PIM-SSM which you can find out about in these IETF documents.
draft-bhaskar-pim-ss-00.txt draft-bhattach-diot-pimso-00.txt draft-sandick-pimsm-ssmrules-00.txtSo, PIM has become the "garbage man" for providing a way to forward multicast traffic. It allows you to do this on a per group basis, so you can do each type of forwarding all at the same time while configuring only one protocol. Of course, if something is a "jack of all trades" it may not be the best for a given forwarding model, so I expect that new protocols will come soon.
One of the ideas that needs to be looked at is the way sources are handled. The original idea was that any host anywhere could start sending multicast traffic at anytime and it was the network's responsibility to handle it. This made things easy for the host but very difficult for the network. Over many bottles of beer, the same conclusion always seems to be that some kind of CTS/RTS method of controlling which sources are allowed to send to which groups must be developed. The problem is getting that functionality into hosts will be difficult. It always "seems" that the network has to do all the work. :-)
I find it quite funny that broadcast.com is now also mbone.org. I don't know how they did that. But they are committed to multicast and have set up their own MIX to provide multicast content. The last "Victoria's Secret" webcast was multicast, and this time it "worked". There are many other content providers also working on multicast. It is anticipated that since SSM does not require anything other than the last-hop router to be upgraded, that multicast will start taking off.
The Netaid concert was multicast in Oct '99. Unfortunately, I don't think anyone knew about the concert, but if you did, and had multicast access to an ethernet, you could have watched two channels that provided full-screen "nearly as good as TV" video that was transmitted from the University of Oregon using IP/TV. UofO is also working on SSM.