Multicasting is an unreliable protocol, using UDP as its basis. It is possible to add reliability to it, as described later, but this is a wrapper on top of an inherently unreliable mechanism.
The next step is to configure the routing table. Under Linux distributions with iputils2, you need to type the command:
ip route add 188.8.131.52/4 dev eth0
For older Linuxes or other Unix-like operating systems, you'd use:
route add -net 184.108.40.206 netmask 240.0.0.0 gateway default dev eth0
(This assumes your ethernet device is eth0 and your default router is enabled to support multicasting.)
To test this configuration, type:
ping -c 2 220.127.116.11
You should receive two replies from every multicast-enabled machine on the LAN, including the router. If you do not, check to see that the router has multicasting enabled and/or that there are, indeed, other machines with multicasting enabled for you to detect.
There are three pieces of software you absolutely need for videoconferencing (the most popular use for multicasting): VIC, RAT, and SDR. VIC and RAT handle the video and audio parts of the video conference. SDR is a session manager, allowing you to pick the multicast session you wish to see.
Hopefully, your ISP will give. Not all ISPs support multicasting, although they have all the hardware they need and it costs nothing to turn it on. Pester your ISP. If that doesn't work, you should be able to get a tunnel established with an existing MBone provider. The MBone newsgroup (alt.mbone) should provide some insights on that.
Multicast routing involves two components, the subscribers and the routers. In general, you can't be both. The capabilities of a subscriber are limited to the capabilities of the least able subscriber to a given stream. Thus, if a subscriber is using IGMPv1, all machines are limited to the abilities of IGMPv1. It is not entirely clear what happens when the most limited subscribers unsubscribe themselves (if the stream acquires greater capabilities, for example).
The consequence of this is that backwards-compatibility is absolute, at the cost of having some very complex networking processes going on to track what is possible at a given time and also at the cost of having a consistent environment. Capabilities can certainly be removed without notice, for example.
This is the heart of multicasting. Each router keeps track of subscribers to a given stream and forwards the relevant information to the next router out for that stream. In this way, a virtual network tree is built and maintained for each stream that is being transmitted.
More than one person can transmit over that tree. It is not a single-source VPN. Rather, any number of machines can contribute to the stream, provided they are subscribers.
IGMP version 3 adds some extra capabilities, namely authentication and source-based multicasting. Authentication allows you to demand that transmitting machines prove that they are who they say they are, preventing spoofing. As multicasting has been used in surgery and other realtime remote operations, it is clear that eliminating forged streams is very important.
Source-based multicasting complements this. It allows you to stipulate that certain addresses are either permitted or not permitted. Any other streams on that multicast tree are simply ignored.
This is the mechanism by which authentication takes place. As the name suggests, it is an extensible protocol. It operates as part of IGMPv3, and is itself an extension to this protocol. For obvious reasons, the EAP extension, along with the authentication mechanism used, must be supported by all subscribing machines in order to work properly. If the mechanisms aren't supported, authentication fails.
Because it is an IGMPv3 feature, if there are subscribers using IGMPv1 or v2 on the network, authentication will not work, as this feature will be disabled by the multicast routers.
MLDv2 is IGMPv3 for IPv6. :) It describes the same mechanisms, and has the same limitations. Namely, if MLDv1 users are using a stream, MLDv2 features will be disabled.
This is the mechanism by which multicast sources can be specified, and then either rejected or accepted. In essence, this provides a very primitive firewall system for multicast networks.
Multicasting operates on a tree system, but different router systems make different assumptions about the nature of that tree. Normally, it is assumed that subscribers will form dense clumps at the ends of trees in which branches are sparse. As a result, most endpoints use a dense multicast protocol such as DVMRP or Dense Mode PIM.
DVMRP is just the RIP routing protocol, modified to support multicasting. It works, but it isn't particularly efficient if you have only a very limited multicast userbase. It is also difficult to get it to interoperate with other multicast routing protocols. PIM was designed to provide different assumptions under different conditions, but be interoperable with other PIM routers.
In Sparse Mode, the assumption is that there are very few subscribers, connecting to only a very few streams. This is normally how the Internet backbone would operate, for example. As such, it is highly efficient to track individual users and individual streams, rather than aggregate into pools.
Dense Mode makes the opposite assumption, that you have a large cluster of users. Tracking individual members would be prohibitive. Instead, an aggregate is used as far as possible. This gets horribly messy when source-based multicasting is used, because you can't pool connections if different people are receiving different data.
Here, we forget about the tree topology altogether. There can be a great many users connected to a few streams, a few users connected to a great many streams, or any other combination of users and streams. It works in a similar way to dense mode, except that either/both sides can have the high density of connections.
Anycasting is a curious twist on multicasting. A request is multicast to subscribing services. The "nearest" service that can handle that request then replies, using a direct unicast connection. The idea of anycasting is that it should be possible to perform certain queries without having to know anything about the layout of the network, or where the servers are. In practice, there are few (if any) services which are capable of using the anycast approach.
Multicasting is NOT defined for mobile networking OR mobile networks. It has been defined, however, for ad-hoc networking.
MAODVR is the ad-hoc version of DVMRP. It is very simple, but at the cost of being limited and memory-hungry.
Reliable Multicasting is a layer you can wrap on top of conventional multicasting. This supports ACK/NAK, giving the illusion of multicast TCP. You can quite easily run such protocols as FTP and HTTP over multicasting this way.
There are a number of methods of reserving bandwidth. Of these, RSVP is probably the most widely implemented. This allows users to pre-allocate a certain amount of bandwidth on the network. They are guaranteed this much bandwidth between themselves and any endpoints to which they transmit or from which they are receiving.
RSVP is very expensive on the network, requiring a lot of state information to be transmitted. As such, it is not particularly popular over the Internet as a whole. It is most effective when used on an Intranet.
The following IETF working groups have numerous RFCs and drafts that relate to multicasting. It is strongly recommended that you read these if you are interested in low-level information.
A tree of a portion of the multicast network can be found at: