What is multicasting? Any description of multicast must start with unicast. Unicast is what many of us know as the basis for World Wide Web communications. In the unicast world of the Internet a user requests information from a server and the server sends that information to each user.
The unicast model works very well for page views and text — relatively low bandwidth. As the demands on the network grow with the use of more high bandwidth media, we have had to build up the networking capability.
Currently, in the unicast world, you have to create a separate connection to each receiver. Imagine, if you will, that your broadcast station had to be wired in a star configuration from your transmitter directly to each and every listener — or worse yet, each and every potential listener.
Over the long run this is not affordable — either in terms of actual data delivery or server infrastructure. If for a moment we do a little math — let's say you have 100,000 users/viewers of your content and their average bit rate requirements are a measly 128k (equivalent to ISDN): 128K * 100,000 users = 12,800,000,000 bit per sec, or 12.8Gb/s. That's an awful lot of OC-3 pipes just to serve 100,000 users. The costs of transmission alone make this prohibitive. This does not even account for the servers, space and power required to “broadcast” to your users.
Unicast broadcast
Unicast broadcast is a caching solution that is being used by many today. Media is sent to every host/server on the network with no regard for when and where it will actually be used. In this caching scheme data is moved from a centralized server to specialized caching servers at the edge of a network. The problem is that only a few servers actually need the data within the network. Others outside your network are also requesting the information. Once you try to move data to specific servers outside of your own network, you are back to the same unicast problem of setting up extremely large data requirements.
Multicast
When it comes to streaming high bandwidth audio and video there is a problem with the Internet. As stated earlier, the Internet and the protocols used were originally designed for a unicast environment. In steps multicast, we have a solution to a problem that didn't really exist in 1992 when some of the first RFCs were written about multicast protocols. RFC 1301, February 1992, defines a multicast protocol as “a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform real-time collaborations without requiring networking clients [or applications] to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting [or broadcasting] at the data link level, as well as some means of communicating that capability up through the layers to the transport.”
Multicast is communication between a single sender and multiple receivers on a network. Using a multicast design, an application can send one copy of each packet and address it to the group of computers that want to receive it. The network then forwards the packets only to the computers that need to receive them. It was designed to more efficiently distribute real-time audio and video to the set of hosts that have “tuned” in. Multicasting is not connection-oriented and all traffic is handled at the transport layer with UDP.
In a multicast environment the “broadcast” server sends data to a very specific address. Any user/device that chooses to receive the broadcast “tunes” to that address and becomes aware of all media with that destination address.
The nuts and bolts
IP addresses are divided into “classes” based on the high order bits of a 32-bit IP address.
Every IP whose destination address starts with “1110” is an IP multicast; the multicast “group” is identified by the remaining 28 bits. Multicast group addresses range from 224.0.0.0 to 239.255.255.255.
There are three fundamental types of addresses: unicast, broadcast and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks.
Network devices can conform to the multicast specifications at any one of the following three levels.
- Level 0: No support for IP multicasting. Support for multicast is not currently a requirement and most network equipment is set to level 0, although this is changing. Devices set to level 0 must ignore all multicast packets.
- Level 1: Support for sending but not receiving multicast IP datagrams.
- Level 2: Full support for IP multicasting level. All Level 2 devices are able to send and receive multicast traffic, “join and leave” multicast groups, and propagate information to other multicast routers. To fully conform to multicast Level 2 specifications, a network device must implement the Internet Group Management Protocol (IGMP) in their TCP/IP stack. This allows an application to open a UDP socket and specify a class D multicast address that it wants to send/get data to/from.
A multicast application transmits the address of the multicast group it is interested in. Multicast datagrams are then filtered and only those with a destination group matching the address transmitted via a “join” request are accepted. When we join a group, the application is told to disregard all other data except for the datagrams in the multicast group. The protocol by its very nature is simple. This makes the difficult task of tuning and finding the data easy and the whole system scalable.
IP multicasting is a best-effort protocol, it assumes some data can be lost or dropped. What's a few missing bytes to a digital video?
Multicasting has a long way to go before it will be able to truly deliver on the promise of high-bandwidth media distributed over the Internet. The challenge this protocol faces is finding a financial model so a mix of hardware, software and network service companies will be encouraged to promote it.
Steven Blumenfeld is currently the GM/CTO of AOL-Nullsoft, the creators of Winamp and SHOUTcast.
Fantastic format-independent digital content
One of the benefits of the partnership between digital content and broadband is that new possibilities are emerging for shopping, distance learning and customized entertainment. The efforts of MediaGateway and the Fantastic Corporation are lighting the way toward a new revenue stream for broadcasters.
Major retailers will soon be able to market their goods and services to television viewers without concern for digital content format. Consumers will view tailored product information based on individual preference and interests and make purchases using a remote control.
No big deal. Except the technology is not limited to a device—it could easily be broadcast to a broadband enabled PC. Various forms of media can be delivered simultaneously, allowing viewers to shop while watching an actual program. The service could also be expanded to offer distance learning and facilitate customized entertainment.
MediaGateway's technology currently adapts to the various digital set-top boxes in use by cable and satellite TV operators in Scandinavia. By applying the software to the digital set-top box, retailers will have direct access to consumers regardless of cable or satellite provider.
Fantastic Corporation's software allows retailers to aggregate packaged content tailored to a specific audience regardless of data format. The Fantastic broadband platform manages point to multipoint delivery and can schedule broadcasts, track revenue and define subscribers and channels.
