In the early 80s, multicast was mostly restricted to the LAN environment, as it is well supported by most local area network technologies, such as Ethernet and Token Rings. On the other hand, extended LANs interconnected with bridges and inter-networks did not support multicast data delivery. Although multicast addressing was as a separate address class from the beginning, there were no standard ways to use it. It was not until the late 80s that Deering introduced multicast extensions to the unicast routing mechanisms across datagram-based inter-networks [#!deering-ip-multicast!#], marking the beginning of IP multicast.
Following Deering's work, the Multicast Backbone (MBone) [#!mbone!#] was born and marked the first widespread use of multicast in the Internet. The MBone consists of tunnels whose end points are workstations that implement the Distance Vector Multicast Routing Protocol (DVMRP) [#!dvmrp!#] and are able to process unicast-encapsulated multicast packets and then forward the packets to the appropriate outgoing interfaces computed by the routing protocol. In March 1992, the MBone carried its first event with 20 sites worldwide received multicast audio streams from a meeting of the Internet Engineering Task Force (IETF) in San Diego.
However, DVMRP is inherently unscalable due to its ``flood and prune'' mechanism for building the multicast tree. In DVMRP, each router discovers the existence of group members by periodically issuing an Internet Group Management Protocol (IGMP) queries. Upon receiving the query, a leaf router will send a prune message indicating that it does not have directly attached group members. An intermediate router forwards the prune message towards the source if it receives prune messages on all its interfaces except the interface towards the source. Such a mechanism requires that every router that supports multicast, to keep state for each existing multicast group, regardless if the router itself actually belongs to the group tree or not. Thus DVMRP is also referred to as the dense mode protocol, as it assumes the dense spreading of group members where pruning is scarce.
With the growth of MBone and the appearance of native mode multicast, i.e. routers directly support multicast, the inefficiency of dense mode multicast routing protocols has to be addressed. This motivates a new class of multicast routing protocols - the sparse mode multicast routing protocols. The most widely implemented sparse mode protocol is the Protocol Independent Multicast Sparse Mode (PIM-SM) [#!pim-sm!#]. Although PIM-SM avoids some complexity of DVMRP, it also introduces many other issues that, to this date, are not adequately solved [#!almeroth-mcast-history!#].
Furthermore, in spite of the rigorous efforts of a generation of researchers, there remains many unresolved issues in the IP multicast model that hinder the development and deployment of IP multicast and multicast applications. The most prominent issues are the lack of a multicast address allocation scheme, the lack of access control and the lack of an inter-domain multicast routing protocol. A flexible and scalable address allocation scheme is critical to the development of any multicast applications as it allows the quick discovery of an multicast address available for immediate use. However, such scheme is not easily devisable in a flat multicast address space, where each IP multicast address is a 32-bit number (in the range of 224.0.0.0 to 239.255.255.255) with no geographical or topological meaning. Consequently, most multicast applications randomly pick a multicast address and hope that it is not currently in use. The possibility of address conflicts increases with the number of multicast groups and complicates the applications unnecessarily.
Second, the lack of access control raises increasing concerns with the recent wave of DDOS attacks. In the IP multicast model, any machine can send to a multicast address without registering itself with the group. Until the IGMPv3 [#!igmp!#], a multicast receiver had no means of selecting the data sources to receive packets from; by default, all packets sent to a multicast address are forwarded to all receivers. In IGMPv3, source filters are added to allow receivers to specify the sources they wish to listen to or specify all but those they don't wish to listen to, provided that receivers know in advance who the sources are. The IGMPv3 protocol suite so far has not been widely implemented in host operating systems and its scalability is still unclear.
Last, an inter-domain multicast routing protocol is vital to whether multicast technology would truly be universally deployed or not. An inter-domain routing protocol provides means for setting up policy based and aggregated routes between Autonomous Systems (AS). This allows service providers to connect their networks to each other without exposing their network topology. Additionally, route aggregation reduces the size of the routing tables and is essential to the scaling of the Internet. Unfortunately, the equivalent inter-domain multicast protocols proposed so far are unsatisfactorily complex and ineffectual [#!almeroth-mcast-history!#].
To reduce the complexities, a new generation of multicast protocols emerged to support a subclass of multicast applications - single source multicast applications. Express [#!express!#] and Source Specific Multicast (SSM) [#!ssm!#] are among such protocols. By restricting to single source multicast applications, a multicast group, which is also called a channel, is indicated by a pair of source and group addresses. This allows sources to select a locally unique group address which together with the source's own IP address, will uniquely identify the multicast channel. Thus, SSM solves some of the above mentioned issues such as the address allocation problems and the control of the data sources. This single source model argues that at least in the near future, large scale Internet broadcast service will dominate the multicast service market. Whether such belief stands or not, there are a range of other interesting applications that are not single-sourced and cannot be easily converted to multiple single-source data streams. It is not yet known if these new protocols are flexible enough to be extended to support these other types of applications. If not, solutions for supporting a wider range of multicast applications still need to be pursued.