Hardly a day passes when newspapers, magazines, or television commentators don't report a new idea or application that will change computing or the Internet forever. But if you step back from the hype and promises, the mostly static images accessible on the World Wide Web are only of limited interest and use to businesses and individuals. The truth is that the current capabilities of the Web are just the first stage in the evolution of the Internet. In fact, we are on the verge of another communications revolution that will transform the desktop from a rather limited piece of machinery into an intelligent agent capable of things never thought possible just a few years ago.
The technology that will change the Internet experience is the Multicast Backbone, or MBone for short. The MBone is the scalable portion of the Internet that facilitates live broadcasts of real-time video, audio, text, and graphics to Internet desktops. The MBone is quietly gaining momentum as the preferred method for hosting and broadcasting live events such as meetings, workshops, conferences, radio news, and music concerts to desktop users. Last year the Rolling Stones broadcast a live concert over the MBone, complete with audio and video. The show was watched simultaneously by thousands of people all over the world. That event is only the beginning. The MBone's potential users include financial traders who want to watch the stock and bond markets while viewing the chairman of the Federal Reserve making a report to Congress. They include executives taking university courses without having to leave their offices. There is speculation that the MBone, not standard cable, will be the carrier of the "500 channels" of the future.
The magic of the MBone is that it can deliver real-time multimedia broadcasts in the easiest, most efficient way from one source to thousands of receivers while saving network bandwidth and CPU cycles. It permits the sender of the information to reduce the bandwidth bottleneck by routing information only to those users interested in receiving the information. Multicasting is quickly transforming the Internet as we know it today.
In March 1992, a group of Internet researchers decided to a test a bold idea: use the Internet to conduct a live meeting via PC. Even more radical is that they tried to organize the teleconference from their desktops while sitting in their offices-without meeting face to face. Most of the researchers were in California, but a few were on the East Coast, and some were in Sweden and England. Nonetheless, all were connected via the Internet. The result? For the first time, a meeting of this kind was successfully conducted from remote desktops. Afterward, the researchers moved quickly to make available the technology and application software that facilitated the historic meeting on the Internet. This small experiment gave birth to what has become known as the MBone. Today, the public part of the MBone is supported on more than 3,200 public networks and boasts more than 10,000 organizations connected worldwide.
The Internet Multicast technology is deployed today in the Internet infrastructure all the way from switches and routers to the operating systems and desktop applications. Some of the commercial vendors of this technology include:
Multicast Routers3Com, Ascend, BayNetworks, Cisco Systems
Multicast Switches3Com, PACE Switch
Multicast Operating SystemsWindows 95 and Windows NT, Mac OS, all versions of Unix
Multicast StackFTP Software, ICAST Communications, Microsoft, NetManage,
Multicast ApplicationsICAST Communications, Starburst
To date, the MBone has been primarily used over the Internet for conducting multiparty videoconferences. Some, but not all, ISPs already support the handling of multicast IP packets. Several products, such as RealAudio, Xing, and VDOnet, have recently been released to market that deliver real-time audio or video. Their version of multicast delivery has significant limitations, and will lack significant applicability in the future. They're proprietary and not standards-based, compared to Internet multicast streaming, and the network delivery mechanism consumes N times more bandwidth and server CPU cycles than multicast applications. (N is the number of clients connecting to the server. More about this later.)
Internet multicasting, on the other hand, is already a standard developed and tested by the Internet engineering community. The IETF (Internet Engineering Task Force) takes responsibility for creating and monitoring these standards, and in turn assigns a number and a document that describes the standard; Internet Multicasting has been assigned the number RFC 1112.
The Internet was first created as a personal point-to-point communication medium for researchers. Today, the Internet looks very different. Internet usage among businesses is an important issue because the needs of commercial operations are somewhat different-and more aggressive-than those of researchers. On the whole, businesses tend to engage in large-scale communication. They operate in "just-in-time" mode in which large amounts of information or products need to be delivered to multiple sites in real time. They have practically no time to wait, and there's not much tolerance for bottlenecks, delays, and limited capacities.
The problem for those businesses seeking to exploit the Internet by using multimedia is that current commercial Internet software is built on a point-to-point, or unicast, infrastructure. In other words, as popular as the Web is now, it is still a highly inefficient point-to-point information delivery scheme (see Figure 1).
Figure 1: Inefficient point-to-point information delivery
But the Web today is a workable storefront model of delivering static text and graphics information. And the Web is a great search tool for information, where passive or static information is archived in a database on a remote server.
In this world, newspapers and magazines are the potential losers in the sweepstakes for advertising dollars. The winner is the real-time information industry, which is doing things like helping raise productivity of a stock broker who routinely uses a Bloomberg news terminal or a TV set with a CNBC news feed to view real-time information. By contrast, information delivered through a storefront just sits there
waiting to be accessed. And consumers as well as businesses are interested in receiving real-time information delivered to desktops.
Internet multicasting is the only standards-based solution that can support thousands of users simultaneously without affecting bandwidth requirements. A user does not have to upgrade to a higher bandwidth or a faster CPU as the number of clients connecting to the server increases.
A good example of the impact of Internet multicasting is MSN™, the Microsoft Network. In the future, it's likely that MSN will be used by Microsoft and other companies for product launches, followed by product delivery to viewers and users of MSN. Product launches and product delivery are two business functions that are, by definition, real-time in nature. The Web may not cater to this need because its underlying technology is user driven, not information-server driven. For instance, the video clip of a CEO at a product launch will be statically stored on the Web server, where users may never view it unless they go search for it. Most users just don't have time to keep track of so much information.
Internet multicasting and the MBone solves that problem. With multicasting, companies will be able to deliver software products, as well as product launch video or audio clips, in real time to thousands of MSN subscribers in a bandwidth-efficient and scalableable manner. Microsoft and UUNet (MSN's ISP associate) will not have to upgrade network bandwidth to handle millions of MSN subscriber connections if the MBone is used as the delivery mechanism.
Figure 2 clearly shows the value of Internet multicasting. One stream of live real-time feed is multicasted to all the clients who explicitly express an interest in the media stream. Only the interested parties/sites/clients receive the feed;
others do not. The powerful infrastructure IP routers, not the end server, handle the job of replicating data. Thus, in essence, the clients do not connect directly to the end server, they request the stream from their local IP router. This results in huge server and bandwidth scalability since the
end server system is no longer overloaded with individual client connections.
Figure 2: Internet Multicast Routing
Providers of live, dynamically changing, real-time information feeds can benefit from Internet multicasting. Some providers of real-time content include CNN, CNN fn, CNBC, ESPN, Home Shopping Network, Bloomberg, Reuters, Stanford Instructional Television Network, MSN, and others. So why do they use multicasting?
IGMP (Internet Group Management Protocol) became an IETF standard in March 1992 (see RFC 1112). IGMP enables Internet multicasting or IP class-D addressing. Currently all operating systems support the IGMP layer in their IP stack. Therefore, the IP stack looks like this:
The header fields in an IGMP message looks like this:
The class-D IP addresses range from 224.0.0.0 to 239.255. 255.255. These addresses are routed via standard IP routers with multicast routing support. Most IP routers in the market today support multicast routing.
An MBone-compliant audio/video streaming application stamps the multimedia data packets with RTP and IGMP before releasing the data onto the network. The IP routers are intelligent enough to realize that these packets are the class-D IP multicast packets.
The IGMP packets consist primarily of three message types: group membership queries, group membership reports, and IGMP routing updates. Figure 3 shows how the three IGMP message types are used on a subnet connected to the public Internet MBone for routing multicast packet. The routing updates that are sent between adjacent routers on two different subnets may follow different available routing algorithms such as PIM (protocol independent multicasting), DVMRP (distance vector multicast routing protocol), or CBT (core based trees).
Figure 3: IGMP message types
RTP (Real Time Protocol) is another Internet standard followed by all MBone-compliant applications. RTP is designed and optimized for real-time media delivery over private and public IP networks. These IP networks change their behavior every millisecond, going from a heavily congested state to normal loads in a matter of seconds. But real-time data such as stock quotes requires fast, speedy delivery to all the sites. RTP is designed to work under such harsh, unstable, congested network conditions-it's a derivation of ALF (Application Level Framing), first published in a 1990 ACM Sigcom paper by Dave Clark and David Tenenhouse at MIT.
Where do RTP and ALF fit into MBone? As HTTP is to the Web, RTP is to MBone, and as HTML is to the Web, ALF is to MBone.
On the Web, everything is a page. With MBone, everything is a frame; RTP essentially revolves around the concept of a frame. Each application has an application-specific frame. The frames may have a size (width, height, and depth), display frequency, internal sampling rate, and other characteristics. The RTP protocol can be easily modified and optimized for each application. While streaming real-time data via RTP, information is packetized and encapsulated inside an IP packet as shown here:
The RTP stack can be compared to the Web stack as shown below. RTP carries only 28 bytes of header information, as compared to several thousand bytes of header information each HTTP request is bundled with. That's why RTP is a highly efficient protocol for real-time media delivery.
Another important thing to note about RTP is that it provides packet sequencing and time-stamping services to the data being transported across networks. These parameters allow RTP-based clients and servers to deliver real-time services such as synchronized presentations on end-systems even under badly congested network conditions.
After almost three years of revision and optimization, RTP has finally been granted the status of an Internet standard, RFC 1889. A copy of the draft can be downloaded from http://www.mbone.com/references.html.
Another protocol that is currently being developed by researchers, engineers, product vendors and ISPs is RSVP, or Resource Reservation Setup Protocol. RSVP will enable the reservation and allocation of network bandwidth resources over the Internet.
RTCP (Real Time Control Protocol) is a companion protocol that is carried with the RTP protocol messages on the MBone. RTCP is now an Internet standard described in RFC 1890. Each MBone-compliant application built on top of RTP must also support RTCP. As the name suggests, this protocol only carries control messaging information, not the actual data. RTCP control messages are sent and received on a separate channel by all clients and servers in a multicast session. Some of the RTCP message types include:
| Packet | Type |
| RTCP_SR | Sender report packet |
| RTCP_RR | Receiver report packet |
| RTCP_SDES | Source descriptor packet |
| RTCP_APP | Application-specific packet |
RTCP provides a feedback mechanism for Internet multicast clients and servers that enables network-adaptive behavior. Each RTCP-compliant network application can listen to traffic statistics on the network and adapt its behavior accordingly. With RTCP, you can create smart network media applications. RTCP also provides the capability to monitor and report the total number of bytes/packets consumed by each client, which gives a measure of quality of service (QoS) rendered over the network. An RTCP packet looks much the same way as an RTP packet except for the data part:
The RTCP packets are not sent by each client and server in a multicast session at the same time and frequency. A smart algorithm controls the sending interval for these packets, adjusting it to prevent congestion or loading on the network. Overall, both the RTP and RTCP provide a solid backbone to any real-time media application on the MBone.
Unlike MBone, other alternatives like RealAudio, Xing, and VDOnet do not scale well, either in terms of CPU scalability or network bandwidth use. Also, they happen to be proprietary solutions and not based on open standards.
The main cause of the inherent nonscalability comes from their underlying architecture, based upon the old unicast point-to-point IP routing you saw in Figure 1.
The unicast IP architecture is least suitable for delivering live real-time media, though it may provide great quick demos.
RealAudio, Xing, and VDOnet products are based on the unicast architecture shown in Figure 4. Notice that each client is served a separate unicast point-to-point media stream by the same server. This means that such client/server systems cannot deliver live real-time media. Live real-time feeds require instant delivery to the network. In Figure 4, the unicast server has to make copies of the data for each connection before delivering it to each client. While the server is busy making copies of the data, it is missing the live feed that needs to be digitized and packetized before network delivery.
Figure 4: Unicast and multicast compared
This also means that bandwidth use increases linearly with each client connection. Throughput is 28.8Kbps if only one client is connected, 28.8 ¥ 2=57.6Kbps if two clients are connected, 28.8 ¥ 6=172.8Kbps in Figure 4, and so on. Thus, this does not scale when it comes to bandwidth.
This is why these products are sold on the basis of number of simultaneous connections to their server. The fact is, if you have a 128Kbps link to your server and if you buy any of these unicast point-to-point solutions, then purchasing a solution that supports a large number of clients will not help much. The underlying product architecture is already limited by bandwidth, so increasing the number of connections on the server does not help.
These products may have limited applicability if they continue to stay proprietary and unicast in nature. The products are popular, however, because they do real-time media delivery today. They have done a tremendous pioneering job in making the Internet community aware of real-time media and its potential.
The basic components of a streaming client/server network application are shown in Figure 5, which shows the server-side real-time media delivery architecture. A live feed is normally converted using a digitizer board with a specific sampling frequency. The sampled digitized data is then compressed using a software or hardware codec such as the following:
AudioGSM, PCM, DVI, LPC, DigiTalk, TrueSpeech, RealAudio
VideoH.261, H.323, MPEG, M-JPEG, NV
Once compressed, the data is then packetized and encapsulated inside an application transport protocol such as RTP before delivery on the network. After the streaming data reaches the destination, the client software processes the data. The client application is listening on the network for the specified data to arrive. Once the multimedia data packet arrives, the client parses the packet and buffers the data into memory. The buffered data is then subjected to the appropriate decoder software or hardware followed by playout to the output device. The playout device can be a speaker or video display, or the data can be archived to a file on the file system.
Figure 5: Real-time media delivery
Besides the core client/server design, several other design issues need to be looked into as well, such as the congestion and admission control parameters. These issues are much more important in lossy and congested networks such as
the Internet since the streaming clients and servers have to attempt to deliver good-quality media at all times. This is where protocols such as RTP and RTCP come very handy. Such real-time media transport protocols enable end systems to adapt and modify their behavior with changing network conditions.
The MBone homepage at http://www.mbone.com/ provides information on papers, literature, public domain tools, and commercial products related to MBone.