MBONE: Multicasting Tomorrow's Internet

Multicast

Another prerequisite to profit from the MBONE is the ability to handle multicast traffic appropriately. The traffic that runs over most of the Internet is unicast traffic. Unicast means that for a single source, there is one single destination. Multicast traffic is traffic with one single source but multiple destinations.

Most UNIX platforms require patches to enable multicast. Proper multicast is native to Solaris 2.x for Sun workstations. SGI workstations also come with multicast. Patches are required for the other UNIX flavors, such as SunOS 4.x, AIX 3.x, and so on. See Appendix C for instructions on how to get these patches.

PCs can talk multicast with only certain versions of networking software.

Macs can handle multicast with a recent version of Mac-TCP. Unfortunately, there aren't any native MBONE tools for the Mac yet, but we will see later how to get around this limitation.

This level of multicast handling is called host multicast.

Another level of multicast handling, multicast routing, is required to get MBONE traffic. Routing means to switch from one network to another until the final destination is reached. It's easy to send multicast traffic onto the local network, and if the multicast traffic is used on the local network only, then there is no problem. If multicast traffic has to be sent to other locations on the Internet, then you must work around a current limitation of the Internet. On the Internet (or rather, most of it), only unicast traffic is routed. To send multicast traffic to other networks, you must fool the Internet routers into thinking that you are sending them unicast traffic.

The most common method of fooling the Internet routers is to use a small program called mrouted. mrouted grabs the multicast traffic from the local network and disguises it as unicast traffic before sending it to the Internet. The multicast packets are put in unicast packets, which is called encapsulating. At the other end, another mrouted program takes this "multicast traffic in disguise" and turns it back into real multicast traffic. This becomes a virtual multicast-in-disguise link between your mrouted program and the destination's mrouted program. These virtual links are called tunnels. To receive MBONE traffic, you have to set up a tunnel between you and your network provider or any other site willing to give you an MBONE feed.

Not all platforms can run mrouted. The capability to route multicast traffic (via tunnels or not) requires special talents that are native in very few platforms. The operating system FreeBSD is one example. Solaris 2.x and SunOS 4.x can run mrouted, but they require that their kernel be patched to do it. See Appendix C for a list of platforms suitable for running Mrouted.

Ideally, your mrouted machine should be a separate machine so that other applications running on the machine does not influence the quality of the routing. However, I have done it the other way, too. At one time, I provided an MBONE feed for five sites on a Sun SPARC IPX running Solaris 2.3. This machine was also my backup machine. The poor IPX was nearly overloaded, but it worked.

Not only UNIX platforms can route multicast traffic. With special software, Proteon and Cisco routers can route multicast traffic, too. If you think this is the way you want to go, you should contact your vendor to find out more about it. However, you should know that the updates for Proteon and Cisco router software do not arrive nearly as fast as the UNIX mrouted updates hit the Internet. This means that if you go for a Proteon router, for example, it may become outdated and incompatible with the rest of the MBONE for a period of time. Because the router may become outdated, I recommend going with a UNIX multicast routing machine. CPU cycles are much cheaper on a UNIX machine than on a router, anyway.

Table of Contents | Previous Section | Next Section