Figure 1. Growth in the MBone by year
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>.
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.
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.
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.
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.
At present, most MBone applications are oriented towards group communication and productivity.
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.
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.
A combination of wb, vat and sd gives a ``standard'' multimedia setup for conferencing over the MBone.
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:
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.