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 the Naval Postgraduate School heard that the Jason Project, an underwater exploration and educational program supported by Woods Hole Oceanographic Institution in Massachusetts, was showing live video over the Internet from an underwater robot in waters off Baja, Mexico. We worked furiously to figure out how to receive that video signal, laboring diligently to gather the right equipment, contact the appropriate network managers, and obtain hardware permissions from local bureaucrats. After several days of effort, we learned that a satellite antenna uplink cable on the Jason support ship had become flooded with seawater a few hours before we became operational.

Despite this disappointment, we remained enthusiastic because, during our efforts, we discovered how to use the Internet's most unique network, MBone. Short for Multicast Backbone [1] , MBone is a virtual network that has been in existence since early 1992. It was named by Steve Casner [1] of the University of Southern California Information Sciences Institute and originated from an effort to multicast audio and video from meetings of the Internet Engineering Task Force. Today, hundreds of researchers use MBone to develop protocols and applications for group communication. Multicast provides one-to-many and many-to-many network delivery services for applications such as videoconferencing and audio where several hosts need to communicate simultaneously.

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

Multicast networks

Multicasting has existed for several years on local area networks such as Ethernet and Fiber Distributed Data Interface. However, with Internet Protocol multicast addressing at the network layer, group communication can be established across the Internet. IP multicast addressing [2] is an Internet standard (Request For Comment 1112) developed by Steve Deering [3] of the Xerox Palo Alto Research Center and is supported by numerous workstation vendors, including Sun, Silicon Graphics, Digital Equipment Corporation, and Hewlett-Packard. Categorized officially as an IP Class D address, an IP multicast address is mapped to the underlying hardware multicast services of a LAN. Two things 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 same physical media as the Internet. It uses a network of routers (mrouters) that can support multicast. These mrouters are either upgraded commercial routers, or dedicated workstations running with modified kernels in parallel with standard routers.

MBone is augmented by "tunneling," a scheme to forward multicast packets among the islands of MBone subnets through Internet IP routers that (typically) do not support IP multicast. This is done by encapsulating the multicast packets inside regular IP packets. As installed commercial hardware is upgraded to support multicast traffic, this mixed system of specially dedicated mrouters and tunnels will no longer be necessary. We expect that most commercial routers will support multicast in the near future, eliminating the inefficiencies and management headaches of duplicate routers and tunnels.

Bandwidth constraints

The key to understanding the constraints of MBone is thinking about bandwidth. The reason a multicast stream is bandwidth-efficient is that one packet can touch all workstations on a network. Thus, a 128-kilobit per second video stream (typically 1-4 frames per second) uses the same bandwidth whether it is received by one workstation or 20. That is good. However, that same multicast packet is ordinarily prevented from crossing network boundaries such as routers. The reasons for this current restriction are religious and obvious from a networking standpoint. If a multicast stream that can touch every workstation could jump from network to network without controls, the entire Internet would quickly become saturated by such streams. That would be disastrous! Therefore, controls are necessary.

MBone can control multicast packet distribution across the Internet in two 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 making sure you don't overload your local or regional bandwidth capacity. MBone protocol developers are experimenting with automatically pruning and grafting subtrees, but for the most part MBone uses thresholds to truncate broadcasts to the leaf routers. The truncation is based on the setting for the time-to-live (ttl) field in a packet that is decremented each time the packet passes though an mrouter. A ttl value of 16 would limit multicast to a campus, as opposed to values of 127 or 255, which might send a multicast stream to every subnet on the MBone (currently about 13 countries). A ttl field is sometimes decremented by large values under a global thresholding scheme provided to limit multicasts to sites and regions if desired.

These issues can have a major impact on network performance. For example, a default video stream consumes about 128 Kbps of bandwidth, or nearly 10 percent of a T1 line (a common site-to-site link on the Internet). Several simultaneous high-bandwidth sessions might easily saturate network links and routers. This problem is compounded by the fact that general-purpose workstation routers that MBone typically uses are normally not as fast or robust as the dedicated hardware routers used in most of the Internet.

Networking details

When a host on an MBone-equipped subnet establishes or joins a common shared session, it announces that event via the Internet Group Management Protocol. The mrouter on the subnet forwards that announcement to the other mrouters in the network. Groups are disbanded when everyone leaves, freeing up the IP multicast address for reuse. The routers occasionally poll hosts on the subnets to determine if any are still group members. If there is no reply by a host, the router stops advertising that host's group membership to the other multicast routers. MBone routing protocols are still immature and their ongoing design is a central part of this network experiment. Most MBone routers use the Distance Vector Multicast Routing Protocol, which some network researchers commonly consider inadequate for rapidly changing network topologies because routing information propagates too slowly [4] . The Open Shortest Path Working Group [5] has proposed a Multicast extension to the Open Shortest Path link-state protocol that addresses this issue using an algorithm developed by Deering [5] . With both protocols, mrouters must dynamically compute a source tree for each participant in a multicast group.

MBone is small enough that this technique is not a problem. However, some researchers speculate that, for a larger network with frequently changing group memberships, these routing techniques will be computationally inefficient. Research efforts on these issues are ongoing, since every bottleneck conquered results in a new bottleneck revealed.

Topology and event scheduling

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

Scheduling MBone events is handled similarly. Special programs are announced in advance on an MBone event electronic mail list (for example, rem-conf@es.net for messages and rem-conf-request@es.net for subscription requests) (see Tables 1 and 2). Advance announcements usually prevent overloaded scheduling of Internet-wide events and alert potential participants.

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

Protocols

The magic of MBone is that teleconferencing can be done in the hostile world of the Internet where variable packet delivery delays and limited bandwidth play havoc with applications that require some real-time guarantees. Limited experiments demonstrated the feasibility of audio over 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 widespread opinion. 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 that the dog can talk at all!

The key network concepts that make MBone possible are IP multicast and real-time stream delivery via adaptive receivers. For example, in addition to the multicast protocols, many MBone applications are using the draft Real-Time Protocol on top of the User Datagram Protocol and Internet Protocol. RTP [6] , being developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force, provides timing and sequencing services, permitting the application to adapt and smooth out network-induced latencies and errors.

Related real-time delivery schemes are also being evaluated. The end result is that even with a time-critical application such as an audio tool, participants normally perceive conversations as if they are in real time. This is because there is actually a small buffering delay to synchronize and resequence the arriving voice packets. Protocol development continues. Although operation is usually acceptable in practice, many aspects of MBone are still considered experimental.

Data compression

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

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

Application tools

Besides basic networking technology, MBone researchers are developing new applications that typify many of the goals associated with the information superhighway. Session availability is dynamically announced using a tool called sd (session directory), which displays active multicast groups (see Figure 1). The sd tool also launches multicast applications and automatically selects unused addresses for any new groups. Steve McCanne and Van Jacobson of the University of California Lawrence 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 MBone applications, provided by software packages called nv (net video), vat (visual audio tool), and wb (whiteboard). The principal authors of these tools are Ron Frederick of Xerox Palo Alto Research Center for nv, and McCanne and Jacobson for vat and wb. Each program is available in executable form without charge from various anonymous File-Transfer Protocol sites on the Internet. Working versions are available for Sun, Silicon Graphics, DEC, and Hewlett-Packard architectures, with ports in progress for Macintosh. No DOS, OS-2, Amiga, or Windows versions are available, although ported tools can be found for 386 boxes running the (free) 386BSD Unix. Pointers to all public application tools are included in the Frequently Asked Questions (FAQ) document [1] . Mirror FTP sites are available overseas.

Additional tools are also available or under development. Winston Dang of the University of Hawaii has created imm (Image Multicaster Client), a low-bandwidth image server. It typically provides live images of Earth from various geostationary satellites at half-hour intervals in either visible or infrared spectra. Henning Schulzrinne of AT&T/Bell Laboratories developed nevot, a network voice terminal providing multiple party conferences with a choice of transport protocols. Eve Schooler of the Information Sciences Institute is part of a team developing mmcc, a session orchestration tool and multimedia conference control 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 Distributed Interactive Simulation (DIS) application protocol [8] . Stephen Lau of SRI International is experimenting with using graphics workstation windows as image drivers. Kurt Lidl of UUnet Technologies, Falls Church, Virginia, is working on a network news distribution application that uses multicast to reduce overall Internet loading and expedite news delivery. (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 channel broadcast during space shuttle missions. It's exciting seeing an astronaut positioning another astronaut by the boots to repair a satellite -- live on your desktop from 150 miles above the surface of the planet.

Conferences on supercomputing, the Internet Engineering Task Force, scientific visualization, and many other topics have appeared -- often accompanied by directions on how to download PostScript copies of presented papers and slides from anonymous FTP sites. Radio Free VAT is a community radio station whose DJs sign up for air time via an automated server (vat-radio-request@elxr.jpl.nasa.gov). Xerox PARC occasionally broadcasts lectures by distinguished speakers. Internet Talk Radio (Carl Malamud, info@radio.com) has presented talks by US Vice President Al Gore, talk-show host Larry King, and others. Another new area is remote learning, which can use MBone to bring expertise over long distances and multiply training benefits. Finally, default MBone audio and video channels are provided so that new users can experiment and 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 and international effort. Feedback and suggestions are often relayed to the entire MBone electronic mail list. (As an example, the article you are reading was previewed by that group.)

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

Cost of admission

The cost of equipment is often relatively low, but to get on MBone, you need the willingness to study and learn how to use these new and fast- moving tools, you need bandwidth, and you need some hardware. NPS runs MBone 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 generally unsuitable for MBone video, although some users -- sometimes entire countries! -- on specially configured networks have managed to make the tools work at 56 and 64 Kbps.

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

You should read the Frequently Asked Questions a few times, ensure that software tools and multicast-compatible kernels are available for your target workstations, and subscribe to the mail list in advance to enable you to ask questions and receive answers. Table 1 shows the various worldwide MBone list subscription request addresses. After subscribing, review the FAQ.

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

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

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

Once connected, you should pass along any lessons learned to the tool authors or the MBone list. When the opportunity presents itself, show your overall network site administrator something spectacular on MBone (such as a live space walk) and make sure your site is budgeting funds to 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 you can make. After that, everyone always wants to go straight to the speed of light."

Caveats aplenty

Problems still exist and a lot of work is in progress. The audio interface takes coaching and practice. Leaving your microphone on by mistake can disrupt a session since typically only one person can be understood at a time. You will need a video capture board in your workstation to transmit video, but no special hardware is needed to receive video. One-to-four frames per second video seems pretty slow (standard video is 30 frames per second), but in practice it is surprisingly effective when combined with phone-quality voice. There is one big danger: One user blasting a high-bandwidth video signal (greater than 128 Kbps) can cause severe and widespread network problems. Controls on access to tools are rudimentary and security is minimal; for example, a local user might figure out how to listen through your workstation mike (unless you unplug it). Audio broadcast preparations are often overlooked but can be just as involved as video broadcast preparations. Network monitoring tools are not yet convenient to use. There is no guaranteed delivery: Lost packets stay lost. Internet bandwidth 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 were willing to point out the symptoms of our error, it was not possible for the rest of the network to cut off the offending workstation cleanly. More situations will undoubtedly occur as MBone developers and users learn more. Unpleasant surprises usually trigger a flurry of discussion and a corresponding improvement in the tools.

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

It is not every day that someone says to you, "Here is a multimedia television station that you can use to broadcast from your desktop to the world." These are powerful concepts and powerful tools that extend our ability to communicate and collaborate tremendously. They have already 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 Postgraduate School 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 University provides the NPS backbone with real-time audio, video, and other MBone data feeds.

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

Five people who would not have been able to afford to travel to Boulder remotely "attended" the three-day training course at the NPS Computer Center's Visualization Laboratory. For the session, students -- including myself -- enjoyed two-way audio and video between the classroom at NCAR and the lab at NPS, and could ask questions of the NCAR instructor over the network. Advance preparation, good audio, and a camera operator in the NCAR classroom gave us a real feeling of presence in Boulder. "It was just like being there," one of my classmates 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 line between NPS and Stanford. During the course, there was only one 30-minute period of broken-up audio. We later determined that this interruption was caused by congestion on NCAR's Ethernet LAN. For much of 1993, the NPS Visualization Lab loaned a Sun Sparcstation 10 to the Monterey Bay Aquarium Research Institute for testing and incorporation into the live audio/video link to the research vessel Point Lobos and the remotely operated vehicle Ventana that explore the Monterey submarine canyon each day (see Figure 2). Local researchers in oceanography, virtual reality, and autonomous underwater vehicles continue to take advantage of the collaboration opportunities that this technology makes possible.

It might not be too long before MBone enables us to videoconference with a classroom or a colleague half way around the world -- directly from our 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 the Woods Hole Oceanographic Institution for underwater science and exploration. The Jason Foundation for Education uses this system as part of an annual Jason Project expedition.

During 1993, more than 600,000 K-12 students were involved in the project via live satellite transmissions. While prime broadcast hours of the expedition focused on the project's educational mission, an intense science program was conducted on a concurrent round-the-clock basis. The EDS Corporation and the University of Texas at Dallas provided a 56-Kbps data circuit for the project. Running on a Sun Workstation, MorningStar PPP software established the Internet connection with research vessel Laney Chouest from which the vehicles were deployed. This Internet connection made a transparent link with the multicast IP-based MBone. Although the lab experimented with multicast videoconferencing tools such as nv and vat, our primary interest in using the MBone was to transmit experimental data and to support shore-based models that depicted the positions and movement of the Laney Chouest and the two Jason/Medea vehicles. This technology was used by several investigators collaborating on Jason science projects at different locations throughout the US.

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

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

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

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

Table 1.          Electronic mail addresses for requesting addition to
                  the MBone mail lists.
 
                  Electronic Mail Address
Mail 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 Address
Mail List         for Posting Messages          Purpose
 
MBone             mbone@isi.edu                 Network configuration
                                                and tool development

rem-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 directed toward the development of software architectures supporting large-scale distributed virtual environments. During Operations Desert Shield and Desert 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 warfare analytical 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 IEEE Computer 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 doctoral research 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 annual unmanned 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-mail addresses are macedonia@cs.nps.navy.mil and brutzman@nps.navy.mil

FTP availability

This article is available electronically via anonymous FTP to taurus.cs.nps.navy.mil in subdirectory pub/mbmg as mbone.ps; in Uniform Resource Locator (URL) format used above, this anonymous FTP request corresponds to ftp://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