MBone Provides Audio and Video Across the Internet

Michael R. Macedonia and Donald P. Brutzman, Naval Postgraduate School

Researchers have produced the Multicast Backbone, which provides audio and video connectivity from outer space to under water -- and virtually everyplace in between. Anyone can use it.

The joy of science is in the discovery. In March 1993, our group at theNaval Postgraduate School heard that the Jason Project, an underwaterexploration and educational program supported by Woods HoleOceanographic Institution in Massachusetts, was showing live video overthe Internet from an underwater robot in waters off Baja, Mexico. Weworked furiously to figure out how to receive that video signal,laboring diligently to gather the right equipment, contact theappropriate network managers, and obtain hardware permissions from localbureaucrats. After several days of effort, we learned that a satelliteantenna uplink cable on the Jason support ship had become flooded withseawater a few hours before we became operational.

Despite this disappointment, we remained enthusiastic because, duringour efforts, we discovered how to use the Internet's most uniquenetwork, MBone. Short for Multicast Backbone [1], MBone is a virtualnetwork that has been in existence since early 1992. It was named bySteve Casner [1]of the University of Southern California InformationSciences Institute and originated from an effort to multicast audio andvideo from meetings of the Internet Engineering Task Force. Today,hundreds of researchers use MBone to develop protocols and applicationsfor group communication. Multicast provides one-to-many andmany-to-many network delivery services for applications such asvideoconferencing and audio where several hosts need to communicatesimultaneously.

This article describes the network concepts underlying MBone, theimportance of bandwidth considerations, various application tools, MBoneevents, interesting MBone uses (see the two sidebars), and providesguidance on how to connect your Internet site to the MBone.

Multicast networks

Multicasting has existed for several years on local area networks suchas Ethernet and Fiber Distributed Data Interface. However, withInternet Protocol multicast addressing at the network layer, groupcommunication can be established across the Internet. IP multicastaddressing [2]is an Internet standard (Request For Comment 1112)developed by Steve Deering [3]of the Xerox Palo Alto Research Centerand is supported by numerous workstation vendors, including Sun, SiliconGraphics, Digital Equipment Corporation, and Hewlett-Packard.Categorized officially as an IP Class D address, an IP multicast addressis mapped to the underlying hardware multicast services of a LAN. Twothings make multicasting feasible on a worldwide scale:

(1) installation of high bandwidth Internet backbone connections, and

(2) widespread availability of workstations with adequate processing power and built-in audio capability.

The reason MBone became a virtual network is that it shares the samephysical media as the Internet. It uses a network of routers (mrouters)that can support multicast. These mrouters are either upgradedcommercial routers, or dedicated workstations running with modifiedkernels in parallel with standard routers.

MBone is augmented by "tunneling," a scheme to forward multicast packetsamong the islands of MBone subnets through Internet IP routers that(typically) do not support IP multicast. This is done by encapsulatingthe multicast packets inside regular IP packets. As installedcommercial hardware is upgraded to support multicast traffic, this mixedsystem of specially dedicated mrouters and tunnels will no longer benecessary. We expect that most commercial routers will supportmulticast in the near future, eliminating the inefficiencies andmanagement headaches of duplicate routers and tunnels.

Bandwidth constraints

The key to understanding the constraints of MBone is thinking aboutbandwidth. The reason a multicast stream is bandwidth-efficient is thatone packet can touch all workstations on a network. Thus, a 128-kilobitper second video stream (typically 1-4 frames per second) uses the samebandwidth whether it is received by one workstation or 20. That isgood. However, that same multicast packet is ordinarily prevented fromcrossing network boundaries such as routers. The reasons for thiscurrent restriction are religious and obvious from a networkingstandpoint. If a multicast stream that can touch every workstationcould jump from network to network without controls, the entire Internetwould quickly become saturated by such streams. That would bedisastrous! Therefore, controls are necessary.

MBone can control multicast packet distribution across the Internet intwo ways:

(1) It can limit the lifetime of multicast packets, and

(2) It can use sophisticated pruning algorithms to adaptively restrict multicast transmission. This is being tested.

Responsible daily use of the MBone network consists merely of makingsure you don't overload your local or regional bandwidth capacity.MBone protocol developers are experimenting with automatically pruningand grafting subtrees, but for the most part MBone uses thresholds totruncate broadcasts to the leaf routers. The truncation is based on thesetting for the time-to-live (ttl) field in a packet that is decrementedeach time the packet passes though an mrouter. A ttl value of 16 wouldlimit multicast to a campus, as opposed to values of 127 or 255, whichmight send a multicast stream to every subnet on the MBone (currentlyabout 13 countries). A ttl field is sometimes decremented by largevalues under a global thresholding scheme provided to limit multicaststo sites and regions if desired.

These issues can have a major impact on network performance. Forexample, a default video stream consumes about 128 Kbps of bandwidth, ornearly 10 percent of a T1 line (a common site-to-site link on theInternet). Several simultaneous high-bandwidth sessions might easilysaturate network links and routers. This problem is compounded by thefact that general-purpose workstation routers that MBone typically usesare normally not as fast or robust as the dedicated hardware routersused in most of the Internet.

Networking details

When a host on an MBone-equipped subnet establishes or joins a commonshared session, it announces that event via the Internet GroupManagement Protocol. The mrouter on the subnet forwards thatannouncement to the other mrouters in the network. Groups are disbandedwhen everyone leaves, freeing up the IP multicast address for reuse.The routers occasionally poll hosts on the subnets to determine if anyare still group members. If there is no reply by a host, the routerstops advertising that host's group membership to the other multicastrouters. MBone routing protocols are still immature and their ongoingdesign is a central part of this network experiment. Most MBone routersuse the Distance Vector Multicast Routing Protocol, which some networkresearchers commonly consider inadequate for rapidly changing networktopologies because routing information propagates too slowly [4]. The Open Shortest Path Working Group [5]has proposed a Multicast extensionto the Open Shortest Path link-state protocol that addresses this issueusing an algorithm developed by Deering [5]. With both protocols,mrouters must dynamically compute a source tree for each participant ina multicast group.

MBone is small enough that this technique is not a problem. However,some researchers speculate that, for a larger network with frequentlychanging group memberships, these routing techniques will becomputationally inefficient. Research efforts on these issues areongoing, since every bottleneck conquered results in a new bottleneckrevealed.

Topology and event scheduling

The MBone community must manage the MBone topology and the scheduling ofmulticast sessions to minimize congestion. By the beginning of 1994,some 750 subnets were already connected worldwide. Topology changes fornew nodes are added by consensus: A new site announces itself to theMBone mail list, and the nearest potential providers decide who canestablish the most logical connection path to minimize regional Internetloading.

Scheduling MBone events is handled similarly. Special programs areannounced in advance on an MBone event electronic mail list (forexample, rem-conf@es.net for messages and rem-conf-request@es.net forsubscription requests) (see Tables 1 and 2). Advance announcementsusually prevent overloaded scheduling of Internet-wide events and alertpotential participants.

Cooperation is key. Many people are surprised to learn that no singleperson or entity is "in charge" of either local topology changes orevent scheduling.

Protocols

The magic of MBone is that teleconferencing can be done in the hostileworld of the Internet where variable packet delivery delays and limitedbandwidth play havoc with applications that require some real-timeguarantees. Limited experiments demonstrated the feasibility of audioover the ARPAnet as early as 1973. However, only a few years ago,transmitting video across the Internet was considered impossible.Development of effective multicast protocols disproved that widespreadopinion. In this respect, MBone is like the proverbial talking dog:It's not so much what the dog has to say that is amazing, it's more thatthe dog can talk at all!

The key network concepts that make MBone possible are IP multicast andreal-time stream delivery via adaptive receivers. For example, inaddition to the multicast protocols, many MBone applications are usingthe draft Real-Time Protocol on top of the User Datagram Protocol andInternet Protocol. RTP [6], being developed by the Audio-VideoTransport Working Group of the Internet Engineering Task Force, providestiming and sequencing services, permitting the application to adapt andsmooth out network-induced latencies and errors.

Related real-time delivery schemes are also being evaluated. The endresult is that even with a time-critical application such as an audiotool, participants normally perceive conversations as if they are inreal time. This is because there is actually a small buffering delay tosynchronize and resequence the arriving voice packets. Protocoldevelopment continues. Although operation is usually acceptable inpractice, many aspects of MBone are still considered experimental.

Data compression

Other aspects of this research include the related needs to compress avariety of media and optionally provide privacy through encryption.Several techniques to reduce bandwidth include Joint PhotographicExperts Group compression, wavelet-based encoding, and the ISO standardH.261 for video. Visually, this translates to "velocity compression;"rapidly changing screen blocks are updated much more frequently thanslowly changing blocks.

Encodings for audio include Pulse Coded Modulation and Group SpecialeMobile (the name of the standardization group for the European digitalcellular telephony standard). Besides concerns for real-time delivery,audio is a difficult media for both MBone and teleconferencing ingeneral. This is because of the need to balance signal levels for allparties, who may have different audio processing hardware (for example,different microphones and amplifiers). Audio also generates lots ofrelatively small packets, which are the bane of network routers.

Application tools

Besides basic networking technology, MBone researchers are developingnew applications that typify many of the goals associated with theinformation superhighway. Session availability is dynamically announcedusing a tool called sd (session directory), which displays activemulticast groups (see Figure 1). The sd tool also launches multicastapplications and automatically selects unused addresses for any newgroups. Steve McCanne and Van Jacobson of the University of CaliforniaLawrence Berkeley Laboratory developed sd.

Figure 1. MBone session at the Monterey Bay Aquarium Research Institute showing application tools nv (network video), vat (visual audio tool), wb (whiteboard), and sd (session directory).

Video, audio, and a shared drawing whiteboard are the principal MBoneapplications, provided by software packages called nv (net video), vat(visual audio tool), and wb (whiteboard). The principal authors ofthese tools are Ron Frederick of Xerox Palo Alto Research Center for nv,and McCanne and Jacobson for vat and wb. Each program is available inexecutable form without charge from various anonymous File-TransferProtocol sites on the Internet. Working versions are available for Sun,Silicon Graphics, DEC, and Hewlett-Packard architectures, with ports inprogress for Macintosh. No DOS, OS-2, Amiga, or Windows versions areavailable, although ported tools can be found for 386 boxes running the(free) 386BSD Unix. Pointers to all public application tools areincluded in the Frequently Asked Questions (FAQ) document [1]. Mirror FTP sites are available overseas.

Additional tools are also available or under development. Winston Dangof the University of Hawaii has created imm (Image Multicaster Client),a low-bandwidth image server. It typically provides live images ofEarth from various geostationary satellites at half-hour intervals ineither visible or infrared spectra. Henning Schulzrinne of AT&T/BellLaboratories developed nevot, a network voice terminal providingmultiple party conferences with a choice of transport protocols. EveSchooler of the Information Sciences Institute is part of a teamdeveloping mmcc, a session orchestration tool and multimedia conferencecontrol program. Mike Macedonia of the Naval Postgraduate School,coauthor of this article, has created a multicast version of NPSNET [7], a 3D distributed virtual environment that uses the IEEE DistributedInteractive Simulation (DIS) application protocol [8]. Stephen Lau ofSRI International is experimenting with using graphics workstationwindows as image drivers. Kurt Lidl of UUnet Technologies, FallsChurch, Virginia, is working on a network news distribution applicationthat uses multicast to reduce overall Internet loading and expedite newsdelivery. (Their goal is 120 ms total propagation coast to coast --which is amazing since light takes about 16 ms to make that trip.)

Events

Many of the most exciting events on the Internet appear on MBone first.Perhaps the most popular is NASA Select, the in-house cable channelbroadcast during space shuttle missions. It's exciting seeing anastronaut positioning another astronaut by the boots to repair asatellite -- live on your desktop from 150 miles above the surface ofthe planet.

Conferences on supercomputing, the Internet Engineering Task Force,scientific visualization, and many other topics have appeared -- oftenaccompanied by directions on how to download PostScript copies ofpresented papers and slides from anonymous FTP sites. Radio Free VAT isa community radio station whose DJs sign up for air time via anautomated server (vat-radio-request@elxr.jpl.nasa.gov). Xerox PARCoccasionally broadcasts lectures by distinguished speakers. InternetTalk Radio (Carl Malamud, info@radio.com) has presented talks by US VicePresident Al Gore, talk-show host Larry King, and others. Another newarea is remote learning, which can use MBone to bring expertise overlong distances and multiply training benefits. Finally, default MBoneaudio and video channels are provided so that new users can experimentand get advice from more experienced users.

Groupwork on groupware

The MBone community is active and open. Work on tools, protocols,standards, applications, and events is very much a cooperative andinternational effort. Feedback and suggestions are often relayed to theentire MBone electronic mail list. (As an example, the article you arereading was previewed by that group.)

Cooperation is essential due to the limited bandwidth of many networks-- in particular, transoceanic links. So far, no hierarchical schemehas been necessary for resolving potentially contentious issues such astopology changes or event scheduling. Interestingly, distributedproblem solving and decision making has worked on a human level just assuccessfully as on the network protocol level. We hope thisdecentralized approach will continue to be successful, even with therapid addition of new users.

Cost of admission

The cost of equipment is often relatively low, but to get on MBone, youneed the willingness to study and learn how to use these new and fast-moving tools, you need bandwidth, and you need some hardware. NPS runsMBone tools on workstations connected via Ethernet (10 Mbps).Off-campus links are via T1 lines (1.5 Mbps).

We found that bandwidth capacities lower than T1 are generallyunsuitable for MBone video, although some users -- sometimes entirecountries! -- on specially configured networks have managed to make thetools work at 56 and 64 Kbps.

Given adequate network bandwidth, you next need a designated MBonenetwork administrator. Working part-time, it typically takes one tothree weeks for a network-knowledgeable person to establish MBone at anew site. Setup is not for the faint of heart, but all the tools aredocumented, and help is available from the MBone list.

You should read the Frequently Asked Questions a few times, ensure thatsoftware tools and multicast-compatible kernels are available for yourtarget workstations, and subscribe to the mail list in advance to enableyou to ask questions and receive answers. Table 1 shows the variousworldwide MBone list subscription request addresses. After subscribing,review the FAQ.

These tools can also work in isolation between workstations on a singleLAN without an mrouter. We recommend that you test the applicationtools locally in advance (before going through the dedicated mroutereffort) to see if they are compatible with your system and match yourexpectations.

To receive multicast packets on your LAN, you will need to configure anmrouter. This can be either a single workstation on a LAN, or a hostdedicated as a parallel mrouter. A nondedicated single workstation canreceive and pass multicast to its LAN neighbors, but this arrangementcan place double MBone traffic on that LAN.

A more practical approach is to dedicate an old unused workstation as anmrouter and equip it with two Ethernet cards, which are needed so thismrouter can act independently and in parallel with your standard IProuter. (NPS uses both approaches.) After deciding on your mrouterconfiguration, obtain and load the application software tools. You arenow ready to put multicast on your LAN.

Once connected, you should pass along any lessons learned to the toolauthors or the MBone list. When the opportunity presents itself, showyour overall network site administrator something spectacular on MBone(such as a live space walk) and make sure your site is budgeting fundsto increase your network bandwidth.

Demands on network bandwidth are significant and getting more critical.You might consider Tengdin's First (and Only) Law of Telecommunications:"The jump from zero to whatever baud rate is the most important jump youcan make. After that, everyone always wants to go straight to the speedof light."

Caveats aplenty

Problems still exist and a lot of work is in progress. The audiointerface takes coaching and practice. Leaving your microphone on bymistake can disrupt a session since typically only one person can beunderstood at a time. You will need a video capture board in yourworkstation to transmit video, but no special hardware is needed toreceive video. One-to-four frames per second video seems pretty slow(standard video is 30 frames per second), but in practice it issurprisingly effective when combined with phone-quality voice. There isone big danger: One user blasting a high-bandwidth video signal (greaterthan 128 Kbps) can cause severe and widespread network problems.Controls on access to tools are rudimentary and security is minimal; forexample, a local user might figure out how to listen through yourworkstation mike (unless you unplug it). Audio broadcast preparationsare often overlooked but can be just as involved as video broadcastpreparations. Network monitoring tools are not yet convenient to use.There is no guaranteed delivery: Lost packets stay lost. Internetbandwidth is still inadequate for MBone in many countries.

On one occasion, an unusual topology change at NPS caused a feedback loop that overrode the NASA Select audio track. Although plenty of people werewilling to point out the symptoms of our error, it was not possible forthe rest of the network to cut off the offending workstation cleanly.More situations will undoubtedly occur as MBone developers and userslearn more. Unpleasant surprises usually trigger a flurry of discussionand a corresponding improvement in the tools.

Expect to spend some time if you want to be an MBone user. It istime-consuming because learning and fixing are involved and because itis lots of fun!

It is not every day that someone says to you, "Here is a multimediatelevision station that you can use to broadcast from your desktop tothe world." These are powerful concepts and powerful tools that extendour ability to communicate and collaborate tremendously. They havealready changed the way people work and interact on the net.

MBone and Distance Learning at the Naval Postgraduate School

Mike McCann, Naval Postgraduate School Visualization Laboratory

In March 1993, the W.R. Church Computer Center at the Naval PostgraduateSchool dedicated a Sun Sparcstation 2 to act as a Multicast Backbone(MBone) router for the campus and the Monterey Bay research community.This router and an IP-encapsulated tunnel from Stanford Universityprovides the NPS backbone with real-time audio, video, and other MBonedata feeds.

The MBone is an excellent tool for those doing research in networks andvideo teleconferencing technology. Although it is not generally thoughtof as "ready for prime time" (audio dropouts may be frequent and video,at best, is only 3 frames per second over the Internet), NPSsuccessfully used it to provide training in Cray Fortran optimizationfrom the National Center for Atmospheric Research in Boulder, Colorado.

Five people who would not have been able to afford to travel to Boulderremotely "attended" the three-day training course at the NPS ComputerCenter's Visualization Laboratory. For the session, students --including myself -- enjoyed two-way audio and video between theclassroom at NCAR and the lab at NPS, and could ask questions of theNCAR instructor over the network. Advance preparation, good audio, anda camera operator in the NCAR classroom gave us a real feeling ofpresence in Boulder. "It was just like being there," one of myclassmates said.

Paul Hyder of NCAR was instrumental in helping set up a direct "backup"tunnel between NPS and NCAR, where the slowest link is the T1 linebetween NPS and Stanford. During the course, there was only one30-minute period of broken-up audio. We later determined that thisinterruption was caused by congestion on NCAR's Ethernet LAN. For muchof 1993, the NPS Visualization Lab loaned a Sun Sparcstation 10 to theMonterey Bay Aquarium Research Institute for testing and incorporationinto the live audio/video link to the research vessel Point Lobos andthe remotely operated vehicle Ventana that explore the Montereysubmarine canyon each day (see Figure 2). Local researchers inoceanography, virtual reality, and autonomous underwater vehiclescontinue to take advantage of the collaboration opportunities that thistechnology makes possible.

It might not be too long before MBone enables us to videoconference witha classroom or a colleague half way around the world -- directly fromour desktop workstations.

Figure 2. The sd (session directory) of MBone events.

Remote science over the MBone during the Jason Project

Andy Maffei, Woods Hole Oceanographic Institution

Jason/Medea is a remotely operated, dual-vehicle system developed by theWoods Hole Oceanographic Institution for underwater science andexploration. The Jason Foundation for Education uses this system aspart of an annual Jason Project expedition.

During 1993, more than 600,000 K-12 students were involved in theproject via live satellite transmissions. While prime broadcast hoursof the expedition focused on the project's educational mission, anintense science program was conducted on a concurrent round-the-clockbasis. The EDS Corporation and the University of Texas at Dallasprovided a 56-Kbps data circuit for the project. Running on a SunWorkstation, MorningStar PPP software established the Internetconnection with research vessel Laney Chouest from which the vehicleswere deployed. This Internet connection made a transparent link withthe multicast IP-based MBone. Although the lab experimented withmulticast videoconferencing tools such as nv and vat, our primaryinterest in using the MBone was to transmit experimental data and tosupport shore-based models that depicted the positions and movement ofthe Laney Chouest and the two Jason/Medea vehicles. This technology wasused by several investigators collaborating on Jason science projects atdifferent locations throughout the US.

Both 2D and 3D models were developed at the Deep Submergence Laboratoryfor use on Sun and Silicon Graphics workstations. Software packages toaccess these models, along with real-time MBone data, were available toanyone on the MBone who wanted to try them out. As sonar surveysprogressed during the expedition, data was transmitted back to shore,and the detailed models were updated and then distributed over theInternet.

A workstation on board the Laney Chouest generated multicast packetscontaining navigation and attitude information for the three vehicles.These packets were distributed in real time over the MBone so usersrunning the modeling software could watch a graphic display of Jasonprowling real seafloor features as scientists investigated seamounts,thermal plumes, and the area's unique ecology. In addition to vehicleinformation, experimental data variables (such as temperatures) weremulticast on the MBone. Scientists and other interested users couldwrite programs to read these experimental values, watch the modelsevolve, and get immediate feedback on progress being made duringdifferent experiments.

From the accounts of participating researchers, MBone use enhanced thescience carried out during the cruise. However, since we spent a lot oftime supporting specific experiments, we were unable to spend much timehelping other interested MBone users get models up and running at theirown sites. This was the first time we used multicast IP during anexperiment, but we nevertheless learned a great deal. Such uniqueexperiments demonstrate the value of other science-based tools, inaddition to more generic videoconferencing applications.

For additional information, contact Andy Maffei at Woods Hole OceanographicInstitution, Deep Submergence Laboratory, Woods Hole, MA 02543.

Table 1.          Electronic mail addresses for requesting addition to                  the MBone mail lists.                   Electronic Mail AddressMail List         For Subscription Requests              Region mbone-eu:         mbone-eu-request@sics.se               Europe mbone-jp:         mbone-jp-request@wide.ad.jp            Japan mbone-korea       mbone-korea-request@mani.kaist.ac.kr   Korea mbone-na:         mbone-na-request@isi.edu               North America mbone-nz:         mbone-nz-request@waikato.ac.nz         New Zealand mbone-oz:         mbone-oz-request@internode.com.au      Australia mbone-sg:         mbone-sg-request@lincoln.technet.sg    Singapore mbone:            mbone-request@isi.edu                  Others  rem-conf:         rem-conf-request@es.net                Worldwide
Table 2.          Electronic mail addresses for putting messages on the                  mailing lists.                  Electronic Mail AddressMail List         for Posting Messages          Purpose MBone             mbone@isi.edu                 Network configuration                                                and tool developmentrem-conf          rem-conf@es.net               Conference announcements                                                and general discussion

References

1. Casner, " Frequently Asked Questions (FAQ) on the Multicast Backbone," May 6, 1993, ftp://venera.isi.edu/mbone/faq.txt

2. D.E. Comer, Internetworking with TCP/IP, Vol. 1, Prentice Hall, Englewood Cliffs, N.J., 1991.

3. S. Deering, "Host Extensions for IP Multicasting," Request For Comment 1112, Aug. 1989, ftp://nic.ddn.mil/rfc/rfc1112.txt

4. R. Perlman, Interconnections: Bridges and Routers, Addison-Wesley, New York, 1993, p. 258.

5. J. Moy, "Multicast Extensions to OSPF," Internet Engineering Task Force Draft, July 1993,ftp://nic.ddn.mil/internet-drafts/draft-ietf-mospf-multicast-04.txt

6. H. Schulzrinne and S. Casner, "RTP: A Transport Protocol for Real-Time Applications," Internet Engineering Task Force Draft, Oct. 20, 1993,ftp://nic.ddn.mil/internet-drafts/draft-ietf-avt-rtp-04.ps

7. D.R. Pratt, M.J. Zyda, et al., NPSNET Annual Lab Review, Dec. 1993, available at ftp://taurus.cs.nps.navy.mil/pub/npsnet/npsnet.annual.report.ps

8. IEEE Standard for Information Technology -- Protocols for Distributed Interactive Simulation Applications, Version 2.0, Univ. of Central Florida, Inst. for Simulation and Training, Orlando, Florida, May 28, 1993.

Acknowledgments

We thank the originators of the MBone tools and dozens of MBone users who provided essential contributions to this article.

Michael R. Macedonia is a US Army major and a PhD student in computer science at the Naval Postgraduate School. His research is directedtoward the development of software architectures supporting large-scale distributed virtual environments. During Operations Desert Shield andDesert Storm, he led a team that designed and established computer communications between the Joint Electronic Warfare Center modeling network and US forces in the Middle East to provide electronic warfareanalytical products for combat commanders.

Macedonia received a BS from the US Military Academy in 1979 and an MS from the University of Pittsburgh in 1989. He is a member of the IEEEComputer and Communications Societies.

Donald P. Brutzman is a lieutenant commander and submarine officer in the US Navy, and has served three submarine tours. His current doctoralresearch investigates the design and construction of an underwater virtual world that includes an operational autonomous underwater robot. His research interests also include 3D real-time computer graphics, virtual worlds, scientific visualization, underwater robotics, distributed simulation, machine learning, and high-performance network applications. He is editor of video proceedings for annualunmanned underwater vehicle conferences.

Brutzman received a BSEE from the US Naval Academy in 1978 and an MS in computer science from the Naval Postgraduate School in 1992. He is a member of IEEE, the IEEE Computer Society, ACM, and the American Association for Artificial Intelligence.

Readers can contact the authors at the Computer Science Department, Naval Postgraduate School, Monterey CA 93943-5000. Their e-mailaddresses are macedonia@cs.nps.navy.miland brutzman@nps.navy.mil

FTP availability

This article is available electronically via anonymous FTP totaurus.cs.nps.navy.mil in subdirectory pub/mbmg as mbone.ps; in Uniform Resource Locator (URL) format used above, this anonymous FTPrequest corresponds toftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.ps

PostScript, text, and hypertext versions of this article are available as ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.ps ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.txt ftp://taurus.cs.nps.navy.mil/pub/mbmg/mbone.html (this document)

This article was published in IEEE COMPUTER magazine, pp. 30-36, April 1994.

Jump to the Naval Postgraduate School Mosaic Home Page