The Internet Multicast Backbone

This page gives a brief overview of the Internet Multicast Backbone, its applications, and how to connect to it. Please direct your comments or suggestions to Bryan O'Sullivan <bosullvn@maths.tcd.ie>.

Contents

  1. Background
  2. Structure
  3. Applications on the MBone
  4. Getting started on the MBone
  5. Other resources of interest


Background

The IP Multicast Protocol (RFC 1112) was adopted by the Internet Engineering Task Force (IETF) in March of 1992 as the standard protocol for building multicast applications on the Internet.

The Virtual Internet Backbone for Multicast IP, or MBone, is an experimental system which is acting as a testbed for multicast application and protocol design and refinement. It is an outgrowth of the first two experimental ``audiocasts'' which were run by the IETF in 1992, and its purpose is to support continued experimentation between IETF meetings.

The MBone is currently a co-operative voluntary effort, consisting of Internet service providers who route multicast traffic over their networks, and end users who install multicast routers at their sites. In spite of this, the MBone has experienced exponential growth in the number of participating sites since its inception in 1992.


Figure 1. Growth in the MBone by year

At the moment, the MBone spans several continents; there are a few intercontinental links in place, but most activity takes place within continental (and, more specifically, national) boundaries. For all that, the MBone still represents a tiny disjoint fragment of the entire Internet. With the current growth in popularity of multimedia applications and the work being done on moving multicast support into IPng, though, it seems reasonable to expect that the size of the multicast user community relative to the size of the Internet as a whole will continue to grow for the foreseeable future.


Figure 2. Gross topology of the MBone in May of 1994


Structure

The MBone is based around the use of the IP Multicast Protocol and the use of tunnels. At the moment, sections of the MBone form a virtual network of ``islands'', interconnected using tunnels over the physical Internet. Ordinary routers along a tunnel know nothing about the multicast IP packets they carry, as they are encapsulated in ordinary IP packets; multicast packets are transmitted point-to-point between multicast routers (mrouters). Once an mrouter receives a multicast packet, it plucks out the encapsulated packet and processes it as appropriate. This may involve using native LAN technology (such as Ethernet or FDDI) to multicast or broadcast the packet locally, and perhaps also re-encapsulating the packet to send it on to several more mrouters in the chain.


Figure 3. Encapsulating multicast packets in normal IP datagrams

Since the current applications of the MBone do not need reliable delivery or flow control, TCP is not used to transmit data. Instead, the Real-Time Transport Protocol (RTP) is used. RTP provides sequenced datagram delivery, but makes no guarantees about delivery, and does not provide flow control. The idea is that applications should generate as much data as their clients need ``on the fly'', and that clients should be adaptable to varying degrees of network lag.


Applications on the MBone

At present, most MBone applications are oriented towards group communication and productivity.

Audio tools
  • Visual Audio Tool (vat) from Lawrence Berkeley Laboratories (LBL)
  • Network Voice Terminal (nvt) from the University of Massachusetts
    Audio is encoded uncompressed as 8Kb/s u-law data; compressed audio streams run at half, one quarter, or one eighth of that speed.

    LBL's vat application allows users to communicate vocally over a segment of the MBone; it uses a workstation's built-in audio capabilities to encode sound from a user's workstation and to play sound that it receives. Vat can be used for remote teleconferencing.

    Video tools
  • Network Video (nv) from Xerox PARC
  • INRIA Videoconferencing System (ivs)
    Typical video resolution is 320x200, using either eight or 24 bits per pixel. Frame differencing and transform encoding are used to compress video streams, achieving a ``typical'' compression ratio of about 20:1. Frame rates vary with picture resolution, and with machine and network load.


    Figure 4. A sample session with vat (point-to-point only)

    Session control
  • Session Directory (sd) from LBL
  • Multimedia Conference Control (mmcc) from University of Southern California ISI
    When MBone ``events'' take place, they are advertised to all parties running sd using multicast; users can then take part in the events themselves with the click of a mouse.

    The sd tool provides a straightforward front end to the Internet Group Management Protocol (IGMP, described in RFC 1112), which allows users to have their workstations join and leave particular multicast groups.

    Other applications
  • Whiteboard (wb) from LBL
  • Multicast Usenet feeds (muse)
    For some multicast applications (e.g. news delivery), real-time response is not needed, and lossy delivery cannot be tolerated. Hence the development of the Multicast Transport Protocol (RFC 1301). Muse is a system for multicasting network news articles as they are posted at different sites, in contrast to the normal NNTP-based system used on the Internet.

    A combination of wb, vat and sd gives a ``standard'' multimedia setup for conferencing over the MBone.


  • Getting started on the MBone

    Line requirements

    If you wish to connect to the MBone and are connected to your service provider on a line of capacity 128Kbps or below, you can more or less forget connecting to the MBone for now, as the sort of service you are likely to get will be extremely unsatisfactory. For simple audio multicasts, you should hope to have at least 16Kbps of free capacity, and for anything like acceptable video performance, you would want to be able to spare 150Kbps of throughput. Other needful things you should do before you can get started include:

    See the MBone FAQ (listed in the references section below) for further details of current participants in the MBone and software requirements.

    How well does it all work?

    A reasonably experienced system administrator can expect to get an MBone island up and running with two to three weeks of part-time work. As has been mentioned, this may require kernel reconfigurations and tweaking of router settings. Due to the current state of the technology being used, the MBone works best on lightly-loaded links. The results of all this effort are useful to be sure, but not always as good as one might hope.

    Why is this? The Internet was not designed for interactive use, but rather for ``best effort'' delivery; real-time traffic requires low latency and low packet loss rates, neither of which hold true in many cases.

    Because the MBone is still in the developmental stage, both the protocols themselves and the applications used are being actively worked on; much of what is currently available is in prototype form. For this reason, if you do not have some degree of technical knowledge or access to someone who does, it is probably too early yet to start working with the MBone. The technology will mature and become more stable over the next decade or so, and its user base will broaden during that time.


    Other resources of interest


    Bryan O'Sullivan
    graphics by Steve Casner