• Back to all articles

Introduction to Multicasting

Multicasting is the ability to transmit a single stream to multiple subscribers at the same time. Unlike conventional streaming, it does not need one stream per recipient. Instead, there is one stream on any one segment of the network on which there is a subscriber. It is the task of the routers to track subscriptions and to create copies only on an as-needed basis. Unlike broadcasting, segments on which there are no subscribers do not receive the stream.

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.

How do I set up my machine for multicasting?

First, configure the kernel to support multicasting. Under Linux, you do this by going into the networking options and enabling multicasting. Rebuild the kernel, install, and reboot. For most BSDs, multicasting is enabled by default.

The next step is to configure the routing table. Under Linux distributions with iputils2, you need to type the command:

ip route add 224.0.0.0/4 dev eth0

For older Linuxes or other Unix-like operating systems, you'd use:

route add -net 224.0.0.0 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 224.0.0.1

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.

If I just want to use multicasting, rather than route it, where can I get software?

http://www-mice.cs.ucl.ac.uk/multimedia/software/

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.

I've got the software, but there's nothing in the session directory. What gives?

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

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.

Conventional Networks

Group Management

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.

Internet Group Management Protocol version 3

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.

Extensible Authentication Protocol

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.

Multicast Listener Discovery version 2

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.

Source-Specific Multicasting

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.

Protocol Independent Multicast version 2

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.

Sparse Mode

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

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.

Bi-Directional Mode

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

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.

Mobile Networking, Mobile Networks and Ad-Hoc Networks

Mobile networking

is a system in which computers are free to move, but the infrastructure is static.

Mobile networks

are networks in which local-area connections are permanent, but routers and the infrastructure between them are mobile.

Ad-Hoc networks

are networks in which all members are mobile.

Multicasting is NOT defined for mobile networking OR mobile networks. It has been defined, however, for ad-hoc networking.

Multicast Ad-Hoc On-Demand Distance Vector Routing

MAODVR is the ad-hoc version of DVMRP. It is very simple, but at the cost of being limited and memory-hungry.

Additional Capabilities

Reliable Multicasting

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.

Bandwidth Reservation

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.

Further Reading

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.

• http://www.ietf.org/html.charters/magma-charter.html
• http://www.ietf.org/html.charters/pim-charter.html
• http://www.ietf.org/html.charters/ssm-charter.html
• http://www.ietf.org/html.charters/msec-charter.html
• http://www.ietf.org/html.charters/rmt-charter.html

A tree of a portion of the multicast network can be found at:

• http://www.abilene.iu.edu/images/ab-mcast.pdf