Challenging the conventional wisdom of IP multicast, ALMI explores an alternative architecture for multicast in the Internet. There are two closely related projects, emerging independently which have very similar objectives to ALMI. Yallcast [#!yallcast!#], aims to extend the Internet multicast architecture and defines a set of protocols for host-based content distribution either through tunneled unicast connections or IP multicast wherever available. It uses a rendezvous host to bootstrap group members into the multicast tree. The functionality of the rendezvous host is similar to ALMI's group controller; it is only used to inform new members about several current members in the tree and is not connected to the multicast data paths. Yallcast creates a shared multicast tree using a distributed routing protocol. It also maintains a mesh topology among group members to ensure that the multicast group is not partitioned. Overall, Yallcast envisions the deployment of IP multicast into small and disjoint network islands and provides a rudimentary architecture for global multicast. In contrast to Yallcast, Endsystem Multicast [#!narada!#] is more similar to ALMI in aiming towards small and sparse group communication applications. In Endsystem Multicast, group members are self-organized into multicast trees using a DVMRP [#!dvmrp!#] like routing protocol which creates source-based multicast trees. It require members to periodically broadcast refresh messages to keep the multicast tree partition free. A companion protocol of Endsystem Multicast is called Narada, which focuses on optimizing the efficiency of the overlay, in terms of delay bounds, based on end-to-end measurements. Although, Yallcast and Endsystem Multicast have similar end goals to ALMI, the tree construction algorithms are very different in all three protocols. Both Yallcast and Endsystem Multicast try to leverage the existing multicast routing protocols and re-apply them at the application level. However, we argue that one of the fundamental problems with IP multicast is its routing protocols. Although, at the application level, the severity of these problems is greatly reduced since the number of nodes involved is much less than the number of routers in the Internet, the problems of excessive control overheads and poor reliability remain to be issues. A centralized control protocol like the one in ALMI, with careful design of redundancy, can simplify the problem greatly and provides a more reliable mechanism to prevent tree partitions and routing loops.
There are other relevant projects that also deploy multicast at the application level, with more emphasis on each specific applications. RMX [#!rmx!#] is a project that installs multicast proxies to connect islands of IP multicast with co-located homogeneous receivers. Besides relaying data, an RMX proxy also adapts to the heterogeneous environment using detailed application knowledge. For example, an RMX proxy can act as a transcoder to accommodate low bandwidth receivers. The tree configuration among RMX proxies is static right now and there is no self-configuration and adaptation aspects to the multicast overlay, as of this writing. AMRoute [#!amroute!#] is a protocol for host-based multicast over mobile wireless networks. It assumes the existence of an underlying broadcast mechanism for configuration purposes. AMRoute continuously creates a mesh of bidirectional tunnels between pairs of group members. Additionally, each multicast group has a core node which is responsible for the initial signaling and tree creation. The AMRoute core uses a source routing approach, where the source is the core node itself, and selects a subset of the available virtual mesh links to form a multicast distribution tree. The core can also migrate dynamically according to group membership and network connectivity. Both of these projects bear similarities to ALMI, yet ALMI is defined as a more general infrastructure for a wide range of applications rather than for a specific application or environment.