Streaming content gets to the desktop in either of two ways: point-to-point unicast or multicast (see "Unicast vs. Multicast"). In unicast streaming, the method employed by Web and FTP servers, data is sent as a separate stream from the source to each user who requests it. This method works in situations where users all want different content, but not when many people want the same content at the same time. Delivering that same streaming content to thousands of users would be impractical, as the required bandwidth from the server -- not to mention the server and router horsepower necessary -- would be cost-prohibitive.
Multicast streaming eliminates this problem by using a one-to-many scenario: Instead of broadcasting thousands of streams, the server sends out only one. That stream is then propagated among the multiple users who want the content. Bandwidth is thus decreased not only at the server, but on the entire network; it's consumed in large quantities only from the multicast routers to the desktop receivers, of which there may be many on the same network. The bandwidth up to that point is equal to only one stream.
Enterprise customers can use multicast technology to distribute content both internally and externally. Whether that content consists of employee training courses, shareholder meeting reports or product announcements, using multicast technology saves bandwidth and server load.
M-bone Connected to the Backbone
Multicast relies on the M-Bone, or multicast backbone. Not a separate backbone, the M-Bone is an address space laid on the existing backbones that operate the Internet and intranets. The M-Bone was realized at the outset of IP address classes, and space was set aside for experimental use. It occupies the Class D address range -- that is, addresses between 224.0.0.0 and 239.255.255.255. Several addresses within the range are reserved; for example, 224.0.0.1 is reserved for all hosts connected directly to the local network, and 224.0.0.2 is designated for routers on a LAN. Other reserved addresses are listed in RFC 1700, "Assigned Numbers."
Multicast sessions are assigned a multicast group ID, which in essence is an IP address within the Class D range. A host may join as many multicast groups as needed and is able to leave at any time. Physical location is irrelevant, as is the number of members in a group. The IP packet sent to the hosts looks like all other IP packets, except that the destination address is the group IP. It's up to the multicast routers to distribute the packets to all members of the group that are downstream.
Here's how it works: A multicast stream is first assigned an address within the Class D range. Any host that wishes to receive the stream places that stream's Class D IP address on whichever interface it uses for IP. Because all clients of the stream would have the same Class D address, the multicast is sent to one address -- and many clients.
Multicast routers depend on a group membership protocol, such as IGMP (Internet Group Management Protocol), to learn about the hosts connected to the subnets. When a host wishes to join a group, it sends an IGMP message to the multicast router, indicating the sessions it wishes to receive. The multicast router begins broadcasting the sessions requested to the member's subnet, and the member adds the group ID address to its interface to begin reception. Scalability increases as more members join because there is a greater chance of locating a multicast router on a nearby upstream network.
It's All in the Routing
Multicast is useless unless the streams actually make it to their intended audience -- and that hinges on the routing. Multicast uses one of two spanning-tree technologies -- dense mode or sparse mode (see "Dense Mode vs. Sparse Mode") -- to get streaming media to its destinations.
RSS
