Introduction to Multicasting
 by Jonathan Day, in Tutorials - Sat, May 15th 2004 00:00 PDT

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?

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

Author's bio:

Jonathan Day is a freelance computer programmer with ten years professional experience. He has helped with the porting of the PIM multicast router "PIMd" to Linux, wrote the brief introduction to multicasting found in the Linux Advanced Routing & Traffic Control (LARTC) guide, and maintains an active interest in current multicast technology. He maintained the first registered IPv6 node in the UK at the University of Manchester and plays with obscure technology in his spare time.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: System :: Networking

 Comments

[»] Relation between EAP and IGMP
by Salekul - Mar 27th 2006 10:56:27

According to this article, "Extensible Authentication Protocol (EAP) 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."

I have not found any valid relation between IGMPv3 and EAP by reading the IGMPv3 standard (RFC 3376). If any of you have any clue about it please add your comment or send me an email.

Salekul

[reply] [top]

[»] Any other network services using Multicasting?
by EAN - May 15th 2004 22:54:40

Another service that uses multicast is NTP - apparently serving up time is very much a broadcast style of service. What other services make use of multicasting? Anything specific to Clusters or Grids? I would think that a heartbeat would also fit this style of network usage.

--
Wilderness is where you might get lost. Wander Well!

[reply] [top]

[»] Re: Any other network services using Multicasting?
by Nils O. Selåsdal - May 16th 2004 17:26:53


> Another service that uses multicast is

> NTP - apparently serving up time is very

> much a broadcast style of service.

NTP by default doesn't seem to use multicast.
An app which imho can do very cool things(if apps would support it) is www.openslp.org ..


[reply] [top]

---

[»] Re: Any other network services using Multicasting?
by imipak - May 17th 2004 13:14:24


> What
> other services make use of multicasting?
> Anything specific to Clusters or Grids?

The concept of Anycasting would be an obvious target for clusters/grids, because you don't know where things are running.

As far as actual apps are concerned, Squid can use multicasting to communicate between proxies, and mMosaic is a multicast version of the Mosaic web browser.

[reply] [top]

---

[»] Programming
by Nils O. Selåsdal - May 15th 2004 16:49:48

Got any pointers to multicast programming as well ?

[reply] [top]

[»] TV over IP
by derekb - May 15th 2004 04:52:45

A popular use of multicast is the distribution of television services.

Imagine the cable tv and satellite scenario - big pipe into the home providing tremendous bandwidth that allows every channel to be received by the home user at the same time.

Using multicast for television delivery instead puts the emphasis of the subscriber only tuning into what they want to see. If you turn to channel 2, you are actually tuning into, say 225.0.0.2 which is simply an mpeg-2 stream wrapped into a UDP header.

As you change channels, you are actually tuning out of the first channel in order to join the second. So in terms of multicast, you leave one group and then join another - so atleast IGMPv2 is required.

Companies like Nextstream and Tandberg have made high quality mpeg-2 encoders that compress very good quality content into, say, a 2.7 MBPS stream. Many subscribers who are on modern DSLAMs (the telephone company's device that terminates your ADSL connection) and who have a loop lengths (that is, distance of your copper pair to the DSLAM) that are reasonably short, have no problem tuning into such a video.

In addition to broadcast tv, since the service is based on IP, you can also offer complementary services such as video on demand.

Testing is going on in almost every telco in the world right now.

The prices have come down significantly over the last few years - ADSL modems are cheaper, telcos have shorter and shorter loop lengths are they modernize their plant, and good quality mpeg-2 video doesn't require 6 MBPS anymore.

At the telco network, video is pushed out to individual DSLAMs. By having video available right at the edge of the last mile, you don't have to waste time pruning back and rejoining multicast streams throughout the network. This means channel change times rival that of satellite and digital cable.

[reply] [top]

[»] Re: TV over IP
by fat-tony - Jul 7th 2004 18:46:42


> A popular use of multicast is the

> distribution of television services.

>

> ... Snip ...

My ISP is currently offering this. www.sasktel.com. The service is called Max. It's pretty cool.


[reply] [top]

---

[»] nice tutorial
by René van Bevern - May 15th 2004 04:42:31

Really nice. :) The BZFlag-Server is also able to use Multicasting. ;)

--
GPG: 0662 B928 E386 E2EF 0E8A E2EE C26D 3034 7C71 4C78

[reply] [top]