The Internet's Multicast
Backbone (MBone) is the small subset of Internet
routers and hosts that are interconnected and capable of forwarding IP multicast
Note that I said “small subset,” which is to say that IP
multicast traffic does not flow to every point in the Internet (yet). Newcomers
to IP multicasting often mistakenly think that if they are connected to the
Internet they can receive IP multicast traffic. They believe that by just
turning on IP multicast routing on their Internet gateway router or by adding
some special application to their PC, they can receive MBone multimedia sessions
via their dialup Internet service provider. Unfortunately, this is not the
case, as you will learn in the following sections.
The next few sections describe various MBone session examples, a history
of the MBone, and the MBone architecture of today and tomorrow.
One of the most popular sessions on the MBone is the audio/video
multicast of NASA's shuttle missions. Other interesting and sometimes
rather bizarre multimedia content is often broadcast over the MBone. For example,
individuals have set up pet-cams to broadcast video of their pets. On one
occasion, an engineer set up a cat-cam at home and kept the workstation at
his office tuned in to this video multicast so he could monitor the cat's
recovery from its recent surgery.
On another occasion, someone broadcast the live CNN feed of the
O. J. Simpson verdict. This multimedia multicast had over 350 members tuned
in at one point. Other media events have been multicast over the MBone. In
1994, a Rolling Stones concert was multicast over the MBone from the DEC Systems
Research Center. The interesting thing was that about a half-hour before the
concert began, the rock group Severe Tire Damage (several members of which
were Internet engineers) began transmitting audio and video of their band
performing live music. The band timed their show so that they finished as
the Rolling Stones concert was beginning, thereby “opening” for
the Rolling Stones via the MBone.
Besides the popular NASA shuttle missions and the occasional rock concert,
sessions from various conventions and seminars are frequently multicast over
the MBone. During a period when I was unable to travel (while I was recovering
from minor knee surgery), I tuned in to the Internet Engineering Task Force
(IETF) audio and video multicast from my home by way of my Cisco 1600 router
and ISDN line that connects me to Cisco's corporate network. This allowed
me to keep up with some of the key IETF sessions (which just happened to have
to do with IP multicasting) that I was interested in attending.
These sorts of events have been largely responsible for the growing
demand for MBone connectivity by more and more Internet users. Although some
of the examples that I have given are more for fun than anything else (would
you believe that at one time someone was multicasting video of several different
lava lamps), commercial and private multicasting over the MBone is rapidly
becoming part of the new Internet experience.
In the early 1990s, several members
of the research community complained to the Defense Advanced Research
Projects Agency (DARPA)the governing body of the Internet at that timethat
the Internet had become a production network and was therefore no longer available
for research and experimentation with new network technologies. As a result,
the U.S. government
formed the DARPA Testbed Network (DARTNet) to give the researchers a playground
network on which they could test and evaluate new tools and technologies without affecting the production Internet.
DARTNet was initially composed of T1 lines connecting various
sites including Xerox PARC, Lawrence Berkley Labs, SRI, ISI, BBN, MIT, and
the University of Delaware. These sites used Sun SPARCstations running routed
as the unicast routing daemon as well as mrouted as the
DVMRP multicast routing daemon. Therefore, DARTNet had native IP multicast
support between all sites. Weekly audio conferences between researchers located
at the various DARTNet sites around the United States were soon normal practice.
In early 1992, the IETF made plans to hold their next meeting in March
in San Diego, California. Unfortunately, one of the D