This FAQ documents local information about the MBONE at UCLA, including what efforts are currently in progress on campus, and what you need to know to participate in the MBONE at UCLA. This document complements rather than duplicates the many important general MBONE documents already available on the net: thus it is imperative that you read both. Pointers to these external resources are supplied here.
The MBONE is still primarily a research effort, and thus its stability and quality of service, while generally very good, cannot be guaranteed. Indeed the global MBONE is still very fragile, depending almost entirely on the goodwill, knowledge and cooperation of all participants to function smoothly. A single individual can significantly degrade large parts of the worldwide MBONE through a careless or ignorant act. With the exploding population on the MBONE--and the Internet in general--more care is necessary than ever before to ensure its continued existence.
As a research effort, there is no off-the-shelf software you can obtain to join the MBONE; and documentation on software, hardware, multicasting, and so on is not consistent nor available in one place. By participating, you are expected to have significant technical skills and self-sufficiency, as well as the time and resources to spend on acquiring working knowledge of this area so as to minimize blunders that can affect others. The most important principle is to read everything you can! This document will help you get started.
(There are many overviews of the MBONE available, most of them being relatively technical. You might start with one written by Jean Bunn of Geneva University. Many more pointers are given below.)
It is true that direct participation on the MBONE is currently possible only if you have one of the several varieties of Unix systems that multicasting software is available for. This includes PCs which run Linux or FreeBSD. Apple's replacement for MacTCP, which is due out in 1995, will contain support for multicasting; some PC Winsock packages already do. It would not be unreasonable to expect tool development when the basic multicast support is stable.
Recent enhancements to the MBONE videoconferencing tools and the CU-SeeMe (Cornell University SeeMe) tool which runs on Macintoshes and PCs allows limited interoperation between the two worlds. It is expected that this interoperability will increase over time.
If you have no MBONE connection on your LAN, you may still be able to participate in selected MBONE events in a limited fashion. Although we have been able to demonstrate interoperability between CU-SeeMe and MBONE, it is not yet clear how this may translate into a real service. For the moment, you should send a note to mbone-admin@cns.ucla.edu.
Minimally, you will need a multicast-capable Unix system (including, but not limited to, Sun, IBM, DEC, SGI, and FreeBSD systems). Because certain MBONE tools are released only as binaries, not all tools are available for all platforms.
If your Campus Backbone connection is through a Cisco router, you will not need to run your own multicast router. Otherwise, you will need a Unix system capable of running mrouted on your network.
An MBONE `feed' can take up to 500kb/sec. Although it can be constrained to deny higher rates, you should think about the impact of this high-volume traffic on your LAN.
Currently, if you are on a token-ring network, multicast packets are sent as broadcasts, potentially degrading the response of your systems. A solution that avoids the performance degradation is to tunnel to an IBM RS/6000 using token ring functional addresses. In this case, only RS/6000s will understand this traffic (e.g. no Suns on token ring can take advantage of this).
To participate fully in MBONE videoconferencing, you will also need a microphone, sound card/speaker, and video camera/video board. We have successfully used the following:
IBM Video Capture Adapter RS/6000s AIX 3.2.5 Sun VideoPix board SunOS 4.1.3 SunVideo board Solaris 2.3, 2.4
Working knowledge of IP networks is necessary, and you should be comfortable with Unix networking administration.
There are many sources of information. Many of them overlap, and the greatest hazard is that much of it is out of date. Nevertheless, you should peruse as much as you can. To get started, here are some things you should look at:
You should certainly join the local MBONE list for UCLA,
uclambone@grizzly.ucla.edu, by sending a message to listserv@grizzly.ucla.edu, whose body is a command such as `subscribe
uclambone your name'. Discussion of the MBONE at UCLA occurs
here, as well as announcements of local programming.
There are two world-wide lists that are relevant: MBONE and rem-conf. Among other things, the latter is used to announce a broadcast event. See the details on joining these lists.
A nice summary page of what software is available and where to get it has been created by EIT.
Dan Mosedale of Stanford has created a Quick and Dirty Guide to Getting Connected to the MBONE that is well worth looking at.
Read the UCLA MBONE Policy document.
Send a request to mbone-admin@cns.ucla.edu, giving as much detail as you can. If you are not part of the CSC or LSC organization of your department or school, please contact them first.
Because the MBONE is a fragile and scarce resource, and further, has resource implications for your network, a connection to it should not be taken lightly.
There is ongoing debate about what is appropriate on the Internet. The same issues apply with respect to broadcast material on the MBONE...except that the MBONE is a very scarce resource, which cannot afford a lot of bandwidth, whether it is appropriate or not. Broadcast only as widely as necessary to reach the audience you need to reach.
A note about copyright and other such legal matters. With the MBONE tools and a standard VCR or CD player, it is easy to broadcast copyrighted video and audio around the planet. Refrain from doing this. It's illegal.
The standard method of reserving a slot for a broadcast is to use the LBL session directory tool, sd. There is now also an experimental WWW-based form for reserving slots, called the MBONE Global Agenda. Use of these tools helps to avoid scheduling conflicts, but ultimately conflict resolution will occur on the MBONE lists: please been gracious in negotiating conflicts, especially when doing so for a global event.
Global events are expected to be announced on the rem-conf@es.net list. (Please announce this on the UCLA list--see below--as well, so that we can all be aware of when the `critical times' are.) Typically you will have put up a WWW page that gives all the details of your event, and it is the URL to this page that will be used in your rem-conf announcement, as well as in the description of the event scheduled under sd.
(An interesting alternative to using sd to see the broadcast schedule is Bill Fenner's SD Sessions interface through a WWW browser.)
Local events (i.e. events that are to be broadcast only within UCLA) may be scheduled using sd, with a threshold of 63 or less. If it is a campus-wide broadcast, you can announce it to the uclambone@grizzly.ucla.edu list with a pointer to the URL or your WWW page describing the event.
The scope of a broadcast event on the MBONE is determined by the threshold value indicated when the event is scheduled in sd. See the UCLA MBONE Policy document for specific threshold values that can be used to limit propagation to a department, or to within the campus.
Broadcast bandwidth within a LAN is of course limited by the LAN itself, and use of this bandwidth is determined by local policy.
If you are broadcasting outside of your LAN, and particularly if you are broadcasting outside of UCLA, the standard rate limits on nv and vat use should apply, including the number of simultaneous video and audio streams you are generating.
To point a camera at a fixed location does not require a lot of effort. However, you quickly find that this is generally insufficient (and furthermore, is boring for viewers). Audio is even trickier to get right, especially if it is a conference situation rather than a lecture. Finally, maximizing the effectiveness of a `remote' presentation involves a lot of preparation; agreeing on the protocol that will be used to handle interaction between remote participants, for example, is harder than you might think.
As time goes on, a wide body of experience is being gained in MBONE broadcasting. Carl Malamud of the Internet Multicasting Service, for example, is leading the effort to define a production-quality service. Others who have put together event broadcasts have written about their experiences. In particular, you might want to read a report on the effort to multicast the 2nd International WWW Conference held in Chicago, October 1994, and the excellent ` countdown list' used to produce the MICE seminar series.
Send a note to mbone-admin@cns.ucla.edu.
Watch this space!
Send a request to mbone-admin@cns.ucla.edu.
logo designed by
Tom Sketchley.
