IP Multicast
IP Multicast is what makes push mode data work over point-to-point networks. In particular, it reduces signaling. It also reduces data volume and tends to synchronize reception of common data flows to multiple receivers. These are useful—even necessary—characteristics for mass market network services.
In the hybrid fiber coax and wireless cases, broadcasting of data is a natural consequence of the physical medium. In the point-to-point wired case, multicast, a software technique that replicates packets efficiently, achieves broadcasting of data. Multicast is more difficult to implement than broadcast because it must track who will and who won't receive packets. Broadcast simply assumes that everyone within receiving range should receive the packet.
IP Multicast Description
Figure 2-12 depicts the unicast case in which there are three clients on a network. Rosie and Jimmy are supposed to receive packets for a particular application from the server, and Junior is not. In this case, the server replicates packets for Rosie and Jimmy, and the router R1 forwards both packets.
Figure 2-12. Unicast Replication of Packets
Figure 2-13 depicts the multicast case for the same application . In this case, the server emits one packet, and the router R1 replicates the packet for Rosie and Jimmy. Work is distributed from the server, a single point, to the network, where many routers can replicate packets. The link between the server and R1 carries only one packet, versus two for the unicast case. Note that R1 is smart enough not to replicate a packet for Junior. Multicasting requires considerably more intelligence in the routers than either the unicast or broadcast models. One reason is the requirement to build packet-distribution trees, which list the nodes through which packets travel to reach all multicast receivers. In Figure 2-13, the distribution tree consists of the server (which serves as the root of the tree) and routers R1, R2, and R3, but not R4.
Figure 2-13. Multicast Replication of Packets
A primary goal of these packet-distribution trees is to identify locations where packet replication is performed and thereby minimize replication. That is, if there are multiple receivers on a given branch of the network, only one copy of the packet should be sent to that branch, where it can then be replicated by an appropriate router.
To take a more complicated scenario, the server can be providing broadcast video services to possibly hundreds of viewers. The server is connected to 10 routers, each of which is connected to 10 routers, which in turn are connected to 10 more, and so on. Figure 2-14 illustrates this example. Let's say there is a total population of 100,000 viewers of whom 1000 are viewing a program at a particular moment.
It would be infeasible for the server to create 1000 copies of every packet to go to each viewer. In this case, the server creates only five packets, and other routers downstream from the server replicate as needed so that all 1000 viewers get the bit stream. As long as there is only one server or source of video, then this is a system that can scale to ultimately serve perhaps millions of viewers.
Multicast is a crucial technology for scaling for RBB networks over wired, point-to-point networks. This technology enables a sender and the point-to-point network delivering the content to transmit the minimal amount of data to the consumer with a minimal amount of signaling.
Figure 2-14. A More Complex Multicast
Benefits of IP Multicast
It is believed (we don't know for sure yet because no one has built a large consumer multicast network) that multicast flows tend to be longer in time duration and that packets will on balance be larger than flows and packets in a unicast model. Longer flows occur because user-initiated signaling does not interrupt them as frequently. Longer packets exist on average because the server can package data into larger packets, and there will likely be fewer acknowledgments, which are of minimal packet size. Longer flows and longer packets tend to increase bandwidth and decrease switch utilization.
Finally, there is conjecture that multicast is more compatible with an advertising model for data distribution than HTTP. In an advertising model, content is controlled at a central source for wide distribution with minimal consumer interaction. The advertiser is not relying on the client to click on an icon to receive a screen full of advertising; the advertising is simply sent.
Challenges of Multicast
Multicast can be quite CPU-intensive for large multicast groups in which receivers can come and go frequently, as with the viewing of TV. Another issue of IP multicast is that it uses the UDP rather than TCP at the IP transport layer. UDP improves performance but has the side effect of lacking some robustness.
Other concerns are conditional access (who has access to the multicast stream and how are users are authenticated), invoicing (whether advertising is the only revenue model suitable for multicast), and normal operational management and monitoring. Complex multicast schemes over wires require very careful thought.
Charging for participation in multicast groups will stimulate ISPs to provide more multicast services. The problem is how to charge for the service. Tariffing can be enforced by duration of the multicast, the speed at which the receiver can accept packets and membership fees. To apply tariffs, the service provider must know who is on the multicast at any time, when they leave, at what quality of service they connect, and total duration of the session. Because there is a single source with clients in multiple geographic areas, it is unlikely that multicast tariffing will have any distance sensitivity. Such measurements are works in progress as of this writing.
Content providers of multicasts may have restrictions on who can participate and whether traffic is encrypted. Along with the requirement to tariff the service, some form of directory service probably is required. Variations of security are listed here:
Unrestricted (anybody can come and go as desired, and traffic is not encrypted)
Restricted and not encrypted (a limited list of subscribers can come and go as desired, but the traffic is not secured via encryption)
Restricted, encrypted
An encrypted multicast group will have a unique key that will be distributed securely to users while the multicast is in session.
Because of these concerns, there is relatively little deployment of IP multicast to date. In fact, some thought is being given to an alternative that uses TCP as the transport protocol, called TCPSAT. As its name implies, the original motivation comes from the transmission of IP over satellites. Because satellite is inherently a broadcast medium, observers are wondering out loud whether multicast over satellite (or cable, for that matter) is superior to IP multicast in its pure form.