NEW DIRECTIONS IN Internet Multicasting J.J. Garcia-Luna-Aceves and Brian Levine Computer Engineering Department University of California Santa Cruz, CA 95064 The Internet is experiencing the widespread adoption of applications that support real-time reliable or unreliable distribution of multimedia information to multiple destinations (e.g., nv, vat, NeVot, wb, and shdr). With the continuing decrease in hardware costs, very simple or special- purpose devices will soon have computing and communications capabilities of their own and enjoy Internetwork addressability, paving the way for the evolution of networked imbedded-computing environments (NICE) that require interconnecting vast numbers of internetwork-addressable devices and traditional networked resources to the national information infrastructure (NII). In addition, unidirectional wideband links are rapidly becoming part of this NII, which increases the asymmetries between the paths used to multicast information and the paths used to provide feedback to sources of information. These developments present many new challenges on multicasting and routing in internets. Today, multicasting in large internetworks is based on the IP multicast architecture. The strength of the IP-multicast design is the anonymity of the sources and receivers involved in the session. Sources may send information to a known multicast address without explicitly knowing the constituency of the receiver set, and similarly, receivers are not required to announce their presence to any other member of the multicast session. This anonymity greatly reduces the complexity of the mechanisms needed to provide the multipoint distribution. Unfortunately, there is little opportunity for cooperation between applications and the protocols providing the IP-multicast service. For example, if the source does happen to know information about the receiver set, IP-multicast does not provide any way in which to take advantage of that information; nor does IP-multicast assist routers or hosts in discovering information about the session membership or topology. Accurately determining the relative location on the multicast routing tree of hosts or routers involved in the session is difficult at best. Furthermore, IP-multicast lacks strong semantics for restricting delivery to a subset of routers in the multicast session on a per- packet basis; a separate multicast group must be constructed, which is a lengthy and costly process. When protocols and distributed algorithms working over IP-multicast require some notion of relative position between two hosts, or when it is required that the scope of a packet be restricted, several inadequate work- around solutions must be employed. Roundtrip delay is often used as a heuristic for determining the relative location of two hosts, despite the fact that roundtrip delay in the Internet is very dynamic and is a poor measure of relative location. When attempting to restrict the scope of a multicast transmission on a per-packet basis, many protocols utilize the time-to-live field present in all IP packets to limit delivery to a locus of routers a limited hop count away. However, hop counts are a crude measure of locality of reference for most applications. Alternatively, some protocols may choose to create and tear down separate multicast groups, but this approach is efficient only when a series of packets justifies the overhead. We propose several architectural improvements for IP-multicast. The first is called LMAS (labeled multicast architecture and service). LMAS provides a strong set of delivery semantics and allows higher-level protocols access to information about the underlying routing tree, thereby encouraging greater cooperation with higher-level protocols and applications, without requiring any changes to the mechanisms used to compute such a tree. LMAS extends IP-multicast with two new types of routing: positional routing and reachcasting. Positional routing assigns routers an implicit label, which allows sources to dynamically specify the destination of a packet to some or all routers involved in a multicast session on a per-packet basis with very little overhead. Additionally, the implicit labels allow routers and hosts to determine their relative locations on the multicast routing trees, without passing complete state information. Reachcasting assigns each router's interface a distance-based label, which allows packets to be routed to the closest host reachable through the multicast tree. Both positional routing and reachcasting retain the anonymity of IP-multicast: the specific identity of a router is not required for delivery, it suffices to identify the relative location of a destination via a descriptive label, or to allow reachcast routing determine the correct destination. Just as multicast services are a generalization of unicast services in that one multicast routing tree replaces the use of many unicast routes to a receiver set, LMAS generalizes existing multicast services in that one LMAS-capable multicast routing tree replaces the use of many traditional multicast trees to a set of receiver sets. Our second architectural enhancement for IP-multicast is called Streams. Stream routing allows applications to group packets logically, and allows hosts to receive or not receive specific streams. Accordingly, the routing tree can be pruned not just in terms of specific sources, but also in logical groupings of data (e.g., audio or video). Streams requires the use of positional routing when working over a shared-routing tree, but does not for a source- based tree. Our third architectural enhancement for IP-multicast focuses on providing special routing services to reliable concurrent multicast protocols, and is called RMA (Reliable Multicast Architecture). RMA is not a single protocol, rather it is meant to support reliable protocols. In fact, RMA provides a common interface to reliable protocols so that multiple reliable protocols can cooperate in the same session. RMA implements the first known approach for correct ``ack-avoidance''. RMA is based on routing provided by LMAS. Our work brings about greater cooperation between the network layer and higher-level protocols, and extends thee delivery options and services available in IP-multicast.