Multicasting 401: How to Broadcast an IETF Without Losing Your Mind

David Boyes
Rice University
dboyes@rice.edu

January 31, 1994

Abstract

This document is intended to be a short introduction to multicasting an IETF meeting without driving yourself completely crazy (if you weren't already with all the other stuff that has to be done to make the meeting run smoothly). Some engineering notes for hardware and software configurations are discussed, and concrete recommendations for software configurations and setup wrap up the coverage.

Introduction

Broadcasting audio and video over the global Internet represents the deployment of several interesting technologies in concert with traditional audio and video production techniques.(1) The multicast network technology component is layered over the IP network backbone due to limitations in routing software -- multicast traffic is carried over a virtual backbone, colloquially referred to as the MBone(2). Multicasting provides one-to-many and many-to-many network delivery services supporting applications that need to communicate with several other hosts siultaneously. Multicasting has been supported for years on local network media such as Ethernet and FDDI, however with the assistance of the Mbone software and infrastructure, multicasting can be extended to include the global Internet.

IP multicasting as used by the IETF is defined by RFC1112(3) and is supported by several different hardware vendors, including Sun, SGI, DEC, and Hewlett-Packard. Two things make the Mbone possible on a world-wide scale: the installation of high bandwidth Internet backbone connections, and the widespread availability of workstations with adequate processing power and built-in audio hardware. The MBone is composed of a network of routers that can support multicast (mrouters). Most mrouters are either upgraded commercial routers or dedicated workstations with modified kernels in parallel with standard routers. To pass multicast packets through the bigger Internet, multicast packets are wrapped in the data portion of traditional IP packets. This process is known as tunneling. As commercial router vendors upgrade their software, tunneling and the extra level of routing information will no longer be necessary.

The MBone's primary limitation is bandwidth. The key to understanding this constraint is to consider the reason why multicast streams are efficient -- one packet can reach all workstations on a particular network segment. A single 128K/sec video stream consumes the same amount of bandwidth whether one workstation or twenty workstations are participating -- however, multicast packets are ordinarily prevented from crossing network or router boundaries due to propagation explosion. Two methods to reduce the impact of this side-effect are to limit the TTL of multicast packets and to employ pruning algorithms to limit propagation of packets for sessions with no participants downstream of a specific mrouter. The pruning code is still in limited distribution throughout the net, but is proving to be quite effective in avoiding problems with multicast propagation.

Sessions are announced using the Internet Group Management Protocol (IGMP); end-user workstations initiating a multicast session generate a session announcement packet which is forwarded by the mrouters to all participating MBone sites. Scheduling of sessions is (at the moment) a fairly manual process -- if a group requires the use of an MBone session, timing and bandwidth level are discussed on the rem-conf mailing lis.(4)

(1)Much of this section is provided courtesy of MAJ Michael R. Macedonia, USArmy and LCDR Donald P. Brutzman, USN, Naval Postgraduate School, Monterey, CA. It is an excerpt from a forthcoming article for IEEE Computer. The original paper is available for anonymous FTP from taurus.cs.nps.navy.mil as file pub/mbmg/mbone.hottopic.ps. The author offers greatest thanks to both authors for permitting this use. (2)Coined by Steve Casner, casner@isi.edu. (3)Deering, Steve. Internet Request for Comments, no. 1112. Xerox Palo Alto Research Center. (4)The mailing list address is rem-conf@es.net. Requests to be added to or deleted from the mailing list should be sent to rem-conf-request@es.net.

Multicast Applications

While the MBone software provides the basic data transport for the multicast network, there are several applications that actually make use of the multicast infrastructure to provide audio and video services. nv(5), vat, and sd(6) are three of the most popular multicast applications, and are most applicable to multicasting an IETF. nv provides slow-scan video images in color and B/W, and vat provides audio transmission capability. sd offers a method of announcing and scheduling multicast sessions using a simple point-and-click interface.

A wide range of other applications (including a shared ``white-board'' tool, a multi-channel voice terminal program, etc.) have been developed, but will not be covered here.

IETF Multicast Setup

During an IETF meeting, two multicast session ``tracks'' and the general plenary sessions are provided. The IETF Secretariat handles scheduling of sessions and rooms. A multicast operator is generally stationed at each site to ensure that the sound and video quality are acceptable and to direct the camera to the relevant information (overheads or speaker).

Engineering for Multicast

This section discusses practical engineering considerations for good multicasting.(7) The actual multicast clients are generally run on machines mounted on carts, to allow for flexibility in locating and moving the machines as they are needed.

(5)Developed by Ron Frederick of Xerox Palo Alto Research Center. (6)Developed by Steve McCanne and Van Jacobson at Lawrence Berkeley Laboratory, UC Berkeley. (7)Network engineering, hardware selection, and software recommendations are based on my experience, and do not reflect endoresments of any of the companies listed.

Network Engineering

High-quality multicast is an incredible bandwidth hog -- it can easily swamp a full T1. For good quality transmissions, the host site should plan on engineering a separate network segment for the multicast source machines. Thinnet coax (RG58U) or 10BaseT are acceptable as local connection media, however connectivity to the conference site should be at least T3 speed (FDDI is even better). If a single high-speed connection cannot be obtained for the conference site, separate T1 connections should be provided for the multicast network.

Routing protocols such as RIP, BGP or OSPF should be disabled for the multicast network, as they produce periodic spikes in response time that degrade audio and video quality. The separate multicast segment is a simple enough network that static routes are sufficient, and generally if there is a interface failure or other network problem on the multicast segment, something considerably more serious is wrong, and routing redundancy is the least of your problems...8-).

Plan on one network connection in each room designated as a multicast breakout room, and two connections in the plenary session room and the storage area for the multicast carts. The storage area is used during the evenings for time-delayed replays of the day's sessions.

Multicast Cart and Mrouter Hardware

The MRouter System

The machines used for the actual audio and video transmission and mrouter duties do not have to be the same brand or even in the same area. Currently, almost any workstation supported by the Mbone software can be used as a mrouter. Things to look for in a good mrouter:

Sufficient memory to avoid swapping/paging. Usually 32-48M is sufficient to avoid delays caused by paging.
Can be dedicated to the task. Two 128K/sec video and audio sessions will severely tax a machine running mrouted. Supporting interactive users and multicast routing affects routing performance sufficiently to noticeably reduce sound quality.
Can run sd. The IETF sessions need to be announced periodically to keep the mrouter pruning code from removing the entries. Running sd on the mrouter machine is a minimal load, and ensures that the sessions are kept refreshed and available for the duration of the conference.

The mrouter machine is usually located in the terminal room or in another out-of-the-way location. It has no special requirements for display or keyboard (a small B/W display and keyboard are sufficient).

Multicast Carts

The multicast carts are the machines that actually do the transmissions. Each cart should have:

A standalone workstation with audio hardware, a supported video capture board, and plenty of RAM. Most conferences use a Sun Sparcstation 2 with Sun's VideoPix slow-scan video card.(8) The workstation should have at least 32M of RAM to avoid swapping. A 525M internal disk is easily sufficient for all the necessary software on the workstation as well as the operating system and X software. Other IETFs have employed DECstations, and future meetings may wish to employ HPs or SGIs -- any platform capable of supporting vat and nv should be acceptable.
A VHS VCR capable of EP recording speed with line level video and audio inputs and outputs. Most medium-priced home-grade VCRs available today have these capabilities.
A small line mixer. A small line mixer allows mike and line level adjustments for best audio quality and a good feed to the house sound system. Settings for mike inputs and line outputs should be made before the conference starts, and then left at those settings.
A camera on a full-size tripod. Normal home-use video cameras work well. Try to avoid the hand-held CCD cameras; the full-size cameras are more stable and provide a slightly more detailed picture. If possible, use cameras that allow any automatic light level controls to be disabled.(9) B/W cameras are acceptable; auto-focus and zoom capability are pluses for inexperienced operators.

Two copies of this configuration should be mounted on carts to allow them to be moved between the plenary session room and the multicast session rooms.(10) Be aware that standard A/V carts will be top-heavy with a standard 17" monitor sitting on top -- move them carefully!

The cabling between the audio input and output jacks of the workstation, the VCR input/output, and the line mixer on the cart are detailed in the diagram in appendix A. CNRI owns a set of connectors and cables that can be used for this purpose, however you may wish to have the local host provide cables to keep things simple.

(8)Sparcstation 2's actually work somewhat better with vat and nv than SS10s or other types of Suns. Sparc LCs, LXs, and ELCs do not perform well in this application. (9)This feature is somewhat rare on cameras intended for home use. Most professional video cameras allow this feature to be switched off, but the cost for professional-grade cameras is considerably higher. (10) Moving the carts between the two rooms is actually an advantage; if you use T-200 video tapes in EP mode, a full 10 hour day can be recorded on a single videotape. If both carts are placed in the plenary room, both tapes can be started and stopped at the same time, and be roughly synchronized for later playback.

Multicast Software

The software supporting the multicast tools has a bad habit of undergoing rapid changes during IETF meetings; you should be prepared to build and rebuild the multicast kernel mods and/or tools several times during the course of a meeting if the authors come up with fixes or new versions. As time goes by, this need will decrease, but it's good to be prepared.

All the workstations supporting multicast should have multicast support compiled into the kernel according to the instructions provided with the multicast mods available from gregorio.stanford.edu in directory vmtp-ip. The multicast FAQ list is also available from the same source, and discusses installation on all the supported platforms.

Sources are not required to install multicast support, but you should know a little bit about how to build and install new kernels before attempting to install the multicast patches. If you intend to use a Sun for a mrouter, Solaris 2.x already includes multicast support, however the support included in Solaris 2.1 and 2.2 is buggy and requires a patch to work correctly. The code in Solaris 2.3 is correct. At this time, the multicast support for SunOS 4.1.3 is still slightly more efficient, so if possible, you should use 4.1.3 in preference to Solaris 2.x. Software Installations The mrouter machine needs only the mrouter software, a minimal X installation, and sd installed; the cart workstations should have a minimal X installation, vat, nv and sd installed. No other applications should be installed or running on the cart machines.

The MIT X distribution is slightly preferable to OpenWindows, as it is smaller and less resource intensive. Motif is useful, but not required.

The sd and vat distributions can be obtained from ftp.ee.lbl.gov. The nv distribution is available from parcftp.xerox.com in the file pub/net-research/nv.tar.Z. The sd and vat tar files include pre-built executables if you prefer not to build your own.

The mrouter machine should have no user accounts other than root and those necessary to maintain the machine remotely. The cart workstations should have two userids, historically named camera1 and camera2, named for each of the IETF transmission channels.

A system administrator should build and install the multicast kernel and set up a tunnel to the nearest MBone site, as discussed in the multicast FAQ. He/she should then add entries to the startup files in /etc to restart the mrouter software and reboot the mrouter machine. If mrouted starts correctly, then leave it running and start on the cart machines.

On one of the cart machines, log in as camera1 and ensure that the directories containing the X startup code and the multicast client software are included in the user's path. Create a .Xresources file with the following X resources:

   vat*geometry: 600x800
   vat*DefaultHost: 224.0.1.11     (224.0.1.14 for Channel 2)
   vat*DefaultPort: 4110           (4140 for Channel 2)
   vat*DefaultTTL: 191             (159 for Channel 2)
   vat*MikeGain: 65                (this value may need adjusting)
   vat*SpeakerGain: 180
   vat*JackGain: 54
   vat*SessionName: IETF Channel 1 (IETF Channel 2 for Channel 2)
   Nv*name: IETF Channel 1         (IETF Channel 2 for Channel 2)
   Nv*ttl: 127                     (95 for Channel 2)

in user camera1's home directory. Create a similar file in camera2's home directory using the values for channel 2 shown above. If your version of startx supports a list of applications to start when X is started, remove any unnecessary applications (clocks, mail checking tools, etc) and include command-line geometry and placement information to start up sd, vat and nv in convenient places. Once the setup on one machine is satisfactory, clone it on the other cart workstation with rcp or ftp.

Go back to the machine running mrouted, and start up sd. Create four sessions using the following information and multicast addresses. Use the addresses listed here instead of allowing SD to assign addresses for these sessions -- the addresses listed here are hard-coded into mrouted as exempt from the mrouted pruning algorithm to allow maximum propagation of the IETF sessions.

     Channel Name               Address     Port    ID     TTL
-------------------------------------------------------------------
  IETF Channel 1 Audio (PCM)    224.0.1.10  4100    0      255
  IETF Channel 1 Video          224.0.1.11  4110    0      191
  IETF Channel 2 Audio (PCM)    224.0.1.14  4114    0      159
  IETF Channel 2 Video          224.0.1.15  4444    0      95


Note: In the 3.5 and future kernals, the priority queueing scheme
      changed, so the ports that the IETF broadcasts uses must change as
      well. The new port allocations are:

        Channel Name              Address         Port    ID
-------------------------------------------------------------------
     IETF Channel 1 Whiteboard   224.0.1.10      41010    0
     IETF Channel 1 Audio (vat)  224.0.1.11      21010    0
     IETF Channel 1 Video (vic)  224.0.1.12      61010    0
     IETF Channel 2 Whiteboard   224.0.1.13      41020    0
     IETF Channel 2 Audio (vat)  224.0.1.14      21020    0
     IETF Channel 2 Video (vic)  224.0.1.15      61020    0

Leave sd running on the mrouter machine. This will ensure that the session information is constantly refreshed to anyone running SD.

At this point, you're ready to try it out. Obtain the help of the house sound manager and connect the cart machines to the house system. Get a good set of sound levels in the rooms and mark it on a piece of masking tape attached to the mixer. Test the video recording and playback, and you're ready to go.

Operation of the Multicast Carts

During the actual meeting, each cart should be manned by at least one volunteer. In general, the person monitoring the cart will need to do very little other than to ensure that the tape is started and the camera is directed toward the speaker or the overheads as appropriate. This section includes some operational concerns and a rough outline of a multicast day.

Normal Duties of Multicast Operations

The plenary sessions and the breakout rooms provide slightly different requirements in terms of operational assistance.

Plenary Sessions

The plenary sessions require both carts to be set up in the same area, although generally only one cart is broadcasting video (no point in sending the same bits twice). The personnel responsible for multicast duty should:

Disconnect the carts from the multicast net in the storage area or terminal room and shut down the workstations.
Remove the previous day's tape from the VCR and ensure that it is properly labeled.
Load a blank T-200 tape.
Move the carts to the plenary room.
Plug the carts into the multicast net in the plenary room.
Connect the line mixer on the carts to the house sound system.
Connect the cameras to the video inputs on the workstations.
Boot the workstations and start up camera1 and camera2 on their respoective workstations (Note: be sure the video sources are connected before booting the workstations. If you use Suns with the VideoPix boards, the kernel driver does not initialize correctly if nothing is connected to the video input.)

When the session is ready to start, ensure that the camera attached to the camera1 workstation is pointed at the overhead. Start transmission from nv on camera1 and audio transmission from both workstations. Start recording on both VCRs at the same time (to keep them in rough sync for later) and the session is off and running.

At the end of the plenary session, be prepared to move fast; there's not much time between the plenaries and the beginning of the first sessions. You'll need to:

Stop both VCRs at roughly the same time.
Stop transmission of audio and video.
Shut down the workstations (su to root and issue /etc/shutdown -h now).
Disconnect the audio and video cables from the line mixer and camera.
Disconnect the carts from the multicast net in the plenary room.
Move out. Remember that the carts are extremely top-heavy.

Breakout Sessions

Breakout sessions are simpler. Move the cart into the room and connect the network to the workstation, line mixer input/output to the house sound system, and video cable from the camera to the video input of the workstation. Boot the workstation. Check the schedule on the the cart and log in to the appropriate camera1 or camera2 userid (depending on which multicast room you're in). Use the buttons in vat and nv to change your name to the name of the session being broadcast. When the speaker is ready to start, start transmitting from vat and nv and start the VCR recording. Unless this is the last session of the day or the session immediatly preceding the lunch or dinner breaks, leave the VCR running.(11)

If this is the last session of the day, follow the instructions for shutting down the cart described in the plenary section, and return the cart to the terminal room or storage area. Plug the cart back in to the multicast net, and restart the workstation. Rewind the tape and start transmission from vat and nv. Start playback on the VCRs and go home.

Camera Motion

Move the cameras as little as possible unless video mixing hardware is available and connected. Camera motion tends to dizzying to viewers, and in general, is distracting. In sessions, focus on the overheads instead of the speaker whenever possible. The overheads generally represent the most important part of the session. It's generally not possible to distinguish well between the overheads and the speaker because the intense light from the overheads triggers the automatic light controls in most cameras and causes the speaker to be a black blob.

Delayed Broadcast of the Sessions

The easiest way to manage delayed replay of the day's sessions is to use T-200 videotapes. These tapes allow 10 hours of video and audio on each tape (at EP speeds) and avoid the problem of having to coordinate changes in tapes, however they are somewhat rare in some localities, so you may want to look for them well in advance of the meeting.

If the instructions shown in the operations section are followed, you should have no trouble actually doing the rebroadcasting.

(11) WGs tend to run over or start/stop unevenly. If the tape is left running between sessions, it's easier to be synchronized between the two carts -- everybody stops for lunch or dinner...8-).

Credits

Much of the information in this handout is provided by various people throughout the net. Kudos and thanks to Steve Casner, Steve Deering, Ron Frederick, Van Jacobson, Erik Huitzer, Michael Macedonia, Donald Brutzman, Bill Manning, Megan Walnut, and many many others for assistance and information in preparing this guide.

Appendix A: Wiring Diagrams

IETF Secretariat - Please send problem reports to ietf-web@ietf.org.

Return to IETF home page.