Multicast over ATM A comparison of various approaches to implementing multicast functionality over ATM computer networks May 1997 Summary Overview Multicasting is an important feature of modern computer networking, and it is gaining in importance as multicast applications gain in popularity. However, whereas multicasting has been a common feature over most "classic" networking technologies for quite some time - such as Ethernet and FDDI - it is only now becoming a common feature over ATM [Asynchronous Transfer Mode] networks. As ATM becomes more popular and is more widely applied as a computer network technology, the need for ATM to support multicasting will rise. This paper examines and compares some of the approaches which have been made to implementing multicast functionality over ATM computer networks. Although some of these proposals have not yet been fully implemented, it is nonetheless informative to look at their specifications and to compare their various approaches. An obvious requirement of any proposal for multicast over ATM is that the implementation actually work over ATM, while delivering "expected" multicast service to higher protocol layers, and we will see how the various proposals tackle this requirement. In the end, we will see that the most complete proposals, with the best chance of being realized, are those which strike a balance between the way multicast is implemented in "classical" networks today, and the requirements that ATM places on implementors. Highlights * There is significant demand for a viable multicast solution for ATM computer networks. * Multicasting over ATM presents a complex problem, to which there have been a number of solutions proposed. * In order to be successful, multicasting over ATM must take advantage of the characteristics of ATM technology, while meeting the needs of higher layers in the networking hierarchy. * The most complete solutions strike a balance between the design of multicasting over "classical" network technologies and the requirements of ATM. Paper Organization The remainder of the paper is organized as follows. In the next section, we will look at the background and motivation for a multicast solution over ATM. Following that, we will investigate the key issues involved in evaluating viable multicast solutions for ATM computer networks. We will then analyze several different proposals for multicast over ATM, and how they address the key issues. Finally, we will wrap up with a discussion of conclusions we can draw from the analysis. Background Multicasting has been established as an essential networking technology, and it continues to grow in importance. If we accept that multicasting is the general case of unicasting and broadcasting, for instance [where unicasting is just a trivial multicast to one node, and broadcasting is the all-inclusive multicast to all nodes], then multicasting lies at the very heart of getting information around a network. But even if we don't accept this idea, there are some more practical reasons why multicasting is essential. Consider the current install base of the Internet: The lifeblood of the Internet is IP, and the implementors and users of IP have made some significant assumptions about the underlying network technology's ability to broadcast and multicast. There is an entire IP address class devoted to multicast addresses ["Class D" addresses], which by itself would indicate that multicasting is a popular networking feature. Many of the general routing protocols used on the Internet [RIP, OSPF] rely on the underlying network's ability to broadcast in order to distribute routing information, and multicast routing protocols such as DVMRP and PIM use multicasting itself to reduce network traffic when distributing routing information. Finally, many of the applications currently running on the internet rely on multicasting [or *should* rely on multicasting] for their core functionality: Audio/video streaming [Internet radio and Internet TV], video conferencing applications, and "push" technologies are all ideal applications for multicasting. Much of the networked world has come to depend on multicasting already, and much *more* of the networked world will come to rely on it as broadcasting loses viability due to scaling problems. What happens, however, if we decide to use ATM as an underlying network technology in our network? Multicasting implementations over "classical" network technologies such as Ethernet or FDDI have taken advantage of these technologies' inherent support for broadcasting. These "classical" technologies are connectionless, and multicasting in this context becomes a special case of broadcast: The multicast packet goes to all nodes on a physical network, and only those nodes that "want" it [i.e. know they belong to the multicast group to which the packet is addressed] copy and read it, while the others ignore it. ATM, on the other hand, is inherently connection-oriented, and any communication between two hosts requires that a connection [a virtual circuit, or VC] be established between them first. This makes any potential implementation of multicast functionality over ATM essentially the reverse of multicast over "classical" technologies: Over ATM, instead of sending out a broadcast to every host and then excluding those that don't want to hear it, we must first figure out which hosts we want to include in the multicast, set up connections to them, then send our packets to the established group. The problem of multicasting over ATM is bigger and more complex than multicasting over "classical" network technologies, and it sounds like it *must* result in multicasting implementations that are less efficient and more costly than those we already have. So why bother? There are three basic reasons why we need a viable multicast solution for ATM networks: First, ATM network technology can make quality of service [QoS] guarantees, and QoS is gaining in popularity among computer network consumers. This is because the same applications that rely on multicast functionality [video conferencing, "push" applications] also benefit greatly from QoS guarantees, as these applications tend to be sensitive to problems such as jitter. It would therefore be nice if we could implement computer networks that had the "best of both worlds," that is, QoS guarantees and multicast all in one. Secondly, ATM was designed to be implemented on a very large scale, and it is therefore gaining in popularity as a computer network "backbone" technology. It won't do us much good, however, to link two multicast-enabled child networks via an ATM backbone, then try to multicast from a source on one of the child networks to destinations on the other child network, if the ATM backbone doesn't support multicasting [or at least tunneling the multicast between the two child networks]. Finally, we need to come up with a viable multicast solution for ATM networks because of the hype. The telephone companies have been plugging ATM for quite some time. As a result, the computer industry and Academia have become increasingly involved in ATM research and development, and now that everyone has spent a lot of money, they want to see results [e.g. viable replacements for "classical" computer network technologies]. Because of the Internet install base, however, ATM will never be viable as a computer networking technology if we cannot implement multicast over it, and we therefore won't be able to implement ATM replacements for "classical" network technologies until ATM supports multicast. Even though the prospect of implementing an efficient multicast solution over ATM may seem dim, it is for all of these reasons that it is important to try. Key Issues There are several key issues we need to consider when evaluating the viability of a multicast solution for ATM computer networks. Depending on how the proposed solution addresses these issues, we can then judge whether the solution as a whole will meet our needs, and if it does not, which parts of the solution are worth remembering in a better solution: * We must investigate how the proposed solution is to be implemented. What infrastructural requirements does the solution demand, especially those above and beyond the infrastructure which is available on the Internet today? How will the solution tackle address resolution, resolving "multicast addresses" [from higher layers] to link-layer ATM addresses? How will the solution handle distribution of routing information, so that multicast packets can be routed properly between networks? And finally, how will the solution actually get packets from a single source to multiple destinations? * We need to consider the proposed solution's compatibility with existing networks. Presumably, the solution will interoperate well with the ATM link-layer, but maybe it won't. And how well will the solution interoperate with the networking layers above it when it is actually put into production? * We must examine the scalability and performance of the proposed solution. What are the performance implications for the solution at a small scale? And even if the solution is elegant and efficient at a small scale, what happens when we try to apply it to larger networks? * We should look into the kind of QoS guarantees the solution can actually provide, since QoS is one of the primary characteristics that make ATM a promising network technology for applications that use multicasting functionality. * Finally, we should examine the flexibility and extensibility of the proposed solution. How closely bound is the proposed solution to underlying [lower layer] technologies? How adaptable is the solution to dynamic changes in the network? And how extensible is the solution, as demands on it [from higher layers] change? After evaluating the proposed solutions according to these criteria, we will have a better idea of which ones, or which parts of each, are worth considering further. Analysis We now turn to examining several approaches to multicasting over ATM networks. First, we will take a detailed look at the Multicast Address Resolution Server [MARS]. After we have a sound understanding of how the MARS solution tackles the key issues, we will review some of the other solutions that have been proposed and implemented, comparing and contrasting their features to MARS. The other solutions we will review including an idea to make the MARS solution more efficient by using PIM [or CBT] and NHRP to create "shortcuts" through the ATM network; a proposal to use "Connectionless Servers" [CLSs] to forward connectionless protocol packets through an ATM network; and Cisco's implementation of the ATM Forum's LANE 1.0 standard. Throughout the following discussion, IP is used as the example protocol to illustrate the features of each approach, although the approaches described here are all protocol independent, and do not care what higher-layer protocol they are encapsulating and sending. Furthermore, the method of encapsulation and transmission of IP packets over ATM networks as specified in RFCs 1483 and 1577 is assumed. MARS The idea behind MARS [RFC 2022] is very similar to the idea behind the Address Resolution Protocol [ARP] in "classical" networks: A designated host on the subnet runs an ARP server, which resolves IP addresses to MAC addresses. This service is then utilized by other hosts and routers on the subnet to determine to which actual machine a particular IP address corresponds. MARS performs the same basic functionality for ATM networks [indeed it is a direct extension of the ATMARP service proposed in RFC 1577], except that in MARS, IP addresses are resolved to ATM addresses; and, whereas in "classical" networks a single IP multicast group address corresponds to a single multicast MAC address, in MARS a single IP multicast group address will correspond to 0, 1, or many ATM addresses belonging to the multicast group. Also note that whereas the distinction between address resolution and packet forwarding may get clouded in "classical" multicast IP routers, these functions are very distinct over ATM networks: In particular, the MARS itself plays no part in the actual forwarding of packets, but rather only serves to administer and resolve multicast addresses to ATM layer addresses; in the MARS context, forwarding is handled explicitly by the source of a multicast, which sets up its own connections to the destination hosts. The implementation of a MARS-enabled system is fairly straightforward. First of all, the MARS specification introduces the idea of a "Cluster," which is the administrative domain of a MARS. A cluster simply consists of a group of hosts on an ATM network which utilize a single MARS for their address resolution needs. For simplicity's sake, this group of hosts can be thought of as corresponding directly to a single Logical IP Subnet [LIS], as described in the ATM Forum's LANE 1.0 specification. It is important to note however that this is not required, and that there can be multiple MARS clusters per LIS, although the designers of MARS are opposed to the idea of extending a single MARS cluster over more than one LIS [See the Internet Draft on VENUS]. In any case, there is one MARS per cluster, which means we will require one host in the cluster to run the MARS, and we will have to inform each of the other hosts which want to belong to the cluster of the ATM address of the host running the MARS [i.e. via manual configuration]. Furthermore, we will have to establish communication between the MARS and the hosts belonging to its cluster, and for this purpose there is a point to multipoint [pt2mpt] VC established by the MARS to the hosts, called the ClusterControlVC. A host is added to this VC when it registers with the MARS; and a host registers by establishing a point to point [pt2pt] VC to the MARS using the manually-configured ATM address it was given for the MARS, then sending a registration message. It is precisely the host leaf nodes of the ClusterControlVC which comprise the MARS cluster. The ClusterControlVC, along with the messages exchanged over it between the MARS and the hosts, correspond to the intra-subnet functionality of IGMP in "classical" networks [see RFC 1112]. Finally, if Multicast Servers are used [also called MCSs, as described in the ATM Forum's UNI 3.1 spec], the MARS will have to establish a pt2mpt ServerControlVC with them in order to control them. This is the sum total of our infrastructural requirements for implementing MARS, assuming of course that the underlying ATM network supports the UNI 3.1 specification for point-to-multipoint virtual circuits. Given this basic structure, we are ready to look at the functionality of a MARS. First, we will look at how a MARS handles inter-cluster multicasts, then we will look at the intra-cluster functionality of a MARS. Basically, the MARS in each cluster handles inter-cluster multicasts by forwarding packets across cluster boundaries using IP routers. LANE LISs are interconnected with one another using IP routers, in the same way that subnets are interconnected using IP routers in "classical" networks, and since MARS clusters are closely correlated with LISs, these are the routers that the MARS in each cluster uses to forward inter-cluster multicast packets. If there are multiple MARS clusters per single LIS, then extra IP routers will have to be introduced for forwarding inter-cluster traffic within the LIS, or a single LIS's IP routers will have to know how to forward packets from one MARS in the LIS to another MARS in the same LIS. As we shall see in a moment, for the purposes of joining, leaving, and querying information about multicast groups in a single cluster, IP routers are treated as if they were hosts belonging to the cluster. The distribution of routing information *among* IP routers themselves, however, is not specified in the MARS RFC. One important difference to note between "classical" IP subnets and ATM network LISs is that multiple LISs can partition a *single* physical ATM network. Because of this, two hosts residing in two different LISs will have to communicate with one another via the IP router connecting the two subnets [assuming there is one], even though both hosts may reside on the same physical network. In other words, whereas subnetting is used to make several separate physical networks appear as one logical entity in "classical" networks [and thus IP routers are a necessity for connecting the two separate physical entities], subnetting can be used according to the LANE specification to subdivide a single physical ATM network into separate logical parts [and IP routers become a logical rather than physical necessity]. Again, since MARS clusters follow the same basic pattern of LISs over an ATM network, this means that inter-cluster multicast traffic is forced through routers, even though the multicast source and destination may reside on the same physical ATM network. As we will see, this turns out to be a limiting factor in the scalability of MARS. As mentioned above, intra-cluster MARS functionality is much like ATMARP server functionality within an LIS, except that the MARS generalizes address resolution for the purposes of multicasting. Instead of single [IP, ATM address] pairs like those stored in an ATMARP server, MARS servers store [IP multicast address; ATM address 1, ATM address 2, ..., ATM address n] associations, where each of the ATM addresses corresponds to a single host that has joined the multicast group specified by the IP multicast address. When a MARS server receives a "join" message from a host in the cluster, the host's ATM address is added to the association with the IP multicast address to which is wants to join; when a MARS server receives a "query" message from a host or router wishing to send packets to a multicast group, it replies with a special MARS message listing all of the ATM addresses associated with the IP multicast address. It is via join and "leave" messages that the MARS compiles and modifies address resolution information. Note that hosts *and* routers may join and leave multicast groups, which means that routers may join a multicast group on one cluster on behalf of hosts from another cluster, and this provides part of the means by which inter-cluster multicasting is established. Also note that MARS control messages are LLC/SNAP-encapsulated as specified in RFC 1483, and thus are treated by the underlying ATM link-layer in the same way as any other higher-layer protocol. In fact, this brings up an interesting point: From the perspective of the ATM link-layer, the MARS control message protocol does constitute a higher-layer protocol, whereas from the perspective of higher network-layer protocols such as IP, the MARS control message protocol constitutes a lower-layer. In other words, MARS address resolution comprises another layer of abstraction between the ISO link layer and network layer. This makes perfect sense if we consider the transition from "classical" network technology, where broadcast is a characteristic of the link-layer technology, to ATM, where broadcast and multicast are needed abstractions which must be implemented over a link-layer that does not support them natively. Looking at multicast over ATM solutions in this light underscores the assumptions that "classical" multicast solutions make about the underlying link layer [RFC 1112]. It also emphasizes the fact that, however inefficient multicast over ATM may be, it adheres more strongly to the object-oriented design aesthetic of encapsulation than does multicast over "classical" networks. Besides compiling multicast address resolution information by processing join and leave messages from hosts and routers in its cluster, the MARS provides means for distributing this information among the cluster hosts, to MCSs, and to interested IP routers. RFC 2022 specifies three methods for distributing forwarding information: explicit queries from hosts or routers to the MARS, updates to hosts and routers in the cluster sent out over the ClusterControlVC, and updates to MCSs sent out over the ServerControlVC. The Explicit query mechanism allows hosts to set up a multicast session to other hosts. It also allows IP routers on the periphery of the cluster to inquire whether there are any members of a particular IP multicast group in the cluster. The updates sent out via the ClusterControlVC allow the MARS to inform hosts and routers when changes occur in its address resolution information, and if the host or router that receives such an update determines that they belong to the group that was modified, they can update their own cached information about the group. Finally, the ServerControlVC allows the MARS to inform the ATM-level MCSs of changes in the group memberships of groups for which they are responsible. Now that we have established the basic structure of the MARS multicast system, and have seen how multicast address resolution information gets around the system, how is multicasting actually done? As mentioned above, the MARS server does not play any part in the actual multicast. Rather, the multicast itself is set up by the source host. This is in contrast to multicasting over "classical" networks, where multicast set up is local to the receiver [the potential receiver issues a local command to join a multicast group, and thereafter its net card accepts packets addressed to the corresponding MAC multicast MAC address]. In the MARS model, the source host has two choices for setting up the multicast. If the LIS in which the source host resides relies on VC meshes for multicasting, then it must establish a pt2mpt VC with itself as the root, and the multicast group members other than itself as the leaf nodes. If the LIS uses MCSs, then the host probably already has a single pt2pt VC set up to the MCS it was configured at startup to use. Once the appropriate VC is established, the source host can then start sending multicast packets. The choice of whether to use VC meshes or MCSs in an LIS to support multicast is left up to the LIS administrator; the MARS specification does not require either method. There are several major factors to take into account, however, in deciding which method to use, including connection availability and cost, packet latency, and MARS signalling traffic. When VC meshes are used, then a lot of pt2mpt VCs will be established, and this will quickly eat up the available connections in an LIS. If the number of connections is limited, or if connections are expensive, this could be an unacceptable situation. Also, since each host must maintain its own cache of ATM addresses corresponding to multicast group addresses, the memory resources on hosts will be taxed, and there will be a heavy MARS signalling load over the ClusterControlVC. On the other hand, using VC meshes provides two significant advantages: Since individual pt2mpt VCs are established for each multicast, much higher bandwidth is reserved per multicast than if MCSs are used; and since only one multicast is going on a given VC, packet latency will be lower. When MCSs are used to conduct multicasting over an LIS, there are also significant tradeoffs. On the up side, MCSs behave as "hubs" in the LIS, through which incoming multicasts are forwarded radially to connected hosts. MCSs are updated directly by the MARS via the ServerControlVC, and so can serve as central collections of multicast forwarding information, which reduces the amount of information a regular host needs to store in order to multicast, and reduces the overall MARS signalling load on the network: Instead of storing and updating the association of one IP multicast address to multiple ATM host addresses, each host need only store and maintain the association between the IP multicast address and the [typically fewer] ATM addresses of the MCSs that are set up to forward for that multicast address. Using MCSs also drastically reduces the number of connections which must be set up in order to support multicasting: When sending multicasts, a host need only set up a single pt2mpt VC to the appropriate MCSs that have registered to multicast to that group, instead of to every host in the group; and when receiving multicasts, a host need only establish a single pt2pt VC to an MCS through which the multicast is forwarded. On the down side, since all multicast traffic is routed through a small number of MCSs on the LIS, there may be higher packet latency than when using VC meshes. There is also a significant problem with detecting and avoiding reflected packets when using MCSs. With a solid understanding of the MARS approach to multicasting under our belts, we can now investigate the implications of the MARS model. In particular, we will consider the issues surrounding its interoperability with other standards and approaches, its scalability and performance, its QoS guarantees, and its flexibility and extensibility. The MARS model is compatible with several existing standards. Foremost among these is the UNI 3.0/3.1 standard for ATM networks, on which the MARS specification [RFC 2022] is based. MARS could also be suitable as an underlying technology for the ATM Forum's LANE [LAN Emulation] specification, which requires but does not specify a multicast address resolution mechanism [LANE assumes the "classical" method of resolving a single IP multicast group address to a single multicast MAC address, then places the burden of resolving the MAC address to individual ATM addresses on the LAN Emulation Server]. The MARS could serve as the LAN Emulation Server [LES] in the LANE model, albeit only if the MARS resolved MAC addresses to ATM addresses, instead of IP addresses to ATM addresses. This shouldn't be a problem in theory, as MARS is designed to be protocol independent. Since the MARS model is closely coupled with the concept of an LIS, the MARS/LIS combination is also a good candidate for interoperability between multicast over "classical" networks and multicast over ATM networks. That is, there would not have to be much *semantic* translation from what it means to forward multicast packets among "classical" networks to what it means to forward multicast packets from a "classical" network to an ATM network [or vice versa]. All that is required is that the IP multicast router sitting between the "classical" and ATM networks have the proper implementation for communicating with the MARS server and for forwarding packets to ATM addresses. This is a relatively tall implementation order, but companies such as Cisco have already released ATM interfaces for some of their routers, and although they are not equipped to communicate with a MARS implementation, they are capable of forwarding packets to ATM addresses. Finally, as an underlying technology for LANE or some other IP-over-ATM solution, the MARS model could play a part in a system that was highly backward compatible with higher layers. For instance, LANE was specifically designed to emulate existing "classical" LAN functionality over an ATM link-layer, so that protocols and applications at the network layer and above would not have to be altered in order to run over ATM. If MARS were used to resolve MAC addresses to ATM addresses, it would fit perfectly into the LANE model. The LANE model, however, is bound to suffer the same performance problems that any emulation layer suffers, and it may not be the ideal context in which to employ MARS [i.e. it is pure overhead, designed to make two incompatible technologies fit together, and it will therefore perform worse than the slowest of the technologies being interfaced]. The MARS model itself also suffers from some scalability and performance problems. The biggest of its scalability problems is its relatively arbitrary adherence to the partition of a single physical ATM network into multiple LISs. Constraining a cluster to communicate with other clusters strictly via IP routers in this situation ends up costing a lot in connection resources, involves more IP router "hops" than is really necessary, and requires more forwarding information to be maintained on hosts and in routers than should be necessary. As we shall see below, we can actually get around these problems without changing the semantics of the MARS/LIS model, by establishing "shortcuts" between multicast sources and destinations. The most significant performance testing for MARS has been carried out at the University of Pennsylvania, where Bellcore conscripted teams of graduate students to implement MARS test tools. Other than these tests, there is not much performance data available for MARS implementations, and what little there is hasn't been correlated with the performance of other multicast over ATM solutions. It is therefore hard to compare the MARS approach to other approaches based on performance, though we can evaluate MARS in an objective sense. The UPenn teams measured latency and throughput for basic MARS operations [see references for Senji and Huque], and found them to have fairly poor performance, at least in Bellcore's implementation of MARS. For instance, the mean time for registering a host with the MARS was about 320 milliseconds [ms], and the mean time for deregistration was a little under 100 ms. Joining a multicast group was found to take anywhere from 20 ms to 100 ms [with no clear correlation between the number of groups being joined and the time taken to process the join message], and leaving a group was found to take anywhere from 20 ms to 130 ms. Finally, querying multicast groups from the MARS was found to take anywhere from 5 ms to 70 ms, and again there was no clear correlation between processing time and number of groups queried. Throughput in the MARS was measured at an average of 80 Mbps over a 155 Mbps OC-3 line with no other traffic. These numbers aren't very promising for a "shim" layer above ATM and below IP, especially if we consider that these measurements were taken under rather ideal circumstances. Performance would almost surely degrade even more under more realistic conditions, such as contending with other network traffic [the default for MARS is Unspecified Bit Rate, though the UPenn test tools used Constant Bit Rate or Peak Bit Rate during tests], much larger numbers of hosts utilizing the same MARS, larger network latency due to larger networks, and dynamically changing multicast groups [meaning more MARS signalling traffic]. Despite performance problems with *managing* multicast group address resolution information, once the information gets to where it needs to be, the characteristics of ATM that make it attractive as a networking technology can take over, and this may compensate somewhat for poor performance elsewhere. In particular, once a multicast is established and running, the underlying ATM network can guarantee a constant bit rate or a peak bit rate, and the multicast will suffer significantly less from jitter than it would on a "classical" network. Whereas in "classical" networks we may suffer significantly less of a performance hit during multicast set up, and then suffer relatively more problems during the multicast; over ATM the distribution is reversed, and the combination of longer set up time and better transmission quality may actually be more acceptable to consumers of multicast applications. In addition to good performance and QoS after multicasts are established and running, the design of the MARS solution offers some attractive extensibility and flexibility features. For extensibility, MARS offers a section of "Supplementary TLVs" [type, length, value] pairs at the end of its control messages, which make it possible to extend the functionality of the MARS in the future without altering the size or format of its control messages. Extensibility has proven to be a valuable feature in the Internet, where it is not feasible to upgrade the whole install base when there is a packet format change or system functionality change. The MARS solution is particularly flexible for two reasons: First, it is designed to be protocol independent, so that it would fit equally well into a context where IP -to- ATM address resolution is needed, and into a context [such as a LANE implementation] where MAC -to- ATM address resolution is needed. Second, as mentioned earlier, MARS serves as an additional layer of abstraction between the ATM link layer and the IP network layer; and although for the time being this just means address resolution has to penetrate one more layer before it is complete, and thus incur one more layer of processing delay, it does nonetheless insulate the network layer from the link layer and makes changes in either layer more feasible and less restricted. From a design perspective, having an "address resolution layer" sandwitched inbetween the link layer and the network layer would be a useful abstraction to implement over all networks. Now that we have taken a detailed look at how the MARS multicast solution approaches the key issues we outlined at the beginning of this paper, we can briefly look at some of the other proposals for multicasting over ATM, and how they compare and contrast with the MARS solution. Cisco "shortcuts" The Cisco "shortcuts" proposal [Rekhter] is actually an improvement on the implementation of the MARS solution, wherein the forwarding information provided by MARS to the inter-LIS IP routers for inter-cluster multicasts is streamlined so that it can take advantage of source and destination locality on the ATM network. Recall that one of the major scalability issues in MARS is the fact that, as specified in RFC 2022, the MARS model follows very closely the LANE LIS model, and as a result it requires packets to pass through an IP router when travelling between LISs, even when the two LISs are configured over the same physical ATM network. This is a rather arbitrary requirement, and the "shortcuts" proposal attempts to do away with it. The authors of the "shortcuts" proposal point out that as a result of the close affiliation of the MARS model with the LIS model, the multicast trees that can be constructed from MARS forwarding information through the use of protocols such as sparse-mode PIM are constrained to follow unnecessarily circuitous paths through the underlying ATM network, since the paths must include IP router hops when crossing LIS boundaries. The crux of the "shortcuts" proposal is a mechanism for streamlining these paths and avoiding the router hops, by using NHRP to find the ATM address of the leaf-node hosts or of the appropriate egress router [if the leaf node does not reside on the same physical ATM network], as hosts join the multicast. NHRP [Next Hop Resolution Protocol] will return the direct ATM address of the leaf-node host or router, given its IP address, and the source host can then use this ATM address to add the leaf-node host or router directly to its pt2mpt VC for the multicast. The source host can also update the MARS for its cluster with the new, more direct route to the leaf-node host, so that in the future, NHRP may not have to be run. The net effect of constructing multicast trees in this way is that all intermediate hops are removed from the paths between source hosts and leaf node hosts [or egress routers] residing on the same physical network. One of the most valuable insights in the "shortcuts" proposal is that unicast and multicast addressing in ATM networks can be thought of as completely separate address modes. In this proposal, multicast trees are constructed using the unicast IP routing information from inter-LIS routers first, then these trees are streamlined using NHRP, and finally, the MARS [and not the inter-LIS unicast routers] is updated with the new streamlined paths to hosts in the multicast group. This creates a logical separation between unicast and multicast forwarding, so that the same packet sent in a unicast may follow a completely different path through the network if sent in a multicast, yet it will reach the same destination: The unicast path will follow all the necessary hops through inter-LIS routers, and will adhere nicely to the LIS model, while the multicast path will be the most direct possible path, making the multicast itself as efficient as possible. The net effect of establishing multicast shortcuts in this way will thus be improved multicast performance and better scalability of the multicast solution. Connectionless Servers The Connectionless Servers approach [Hong] has been proposed as a way to handle connectionless servers over a public wide-area ATM network, where implementing additional layers over the whole ATM network to make it behave like a "classical" network is impractical. In the Connectionless Server approach -- also called the CLS or "direct" approach -- Connectionless Servers are set up at switches around the ATM network, and Switched Virtual Circuits [SVCs] are established between them. Together, the CLSs form a semi-permanent virtual connectionless network over the connection-oriented ATM link-layer, but they do not alter the nature of the entire ATM network. The CLSs serve essentially the same function as IP routers in a "classical" network, and users can connect to the virtual connectionless network they comprise by making a single connection to one of the CLSs. The CLS approach is fundamentally different from the MARS/LIS approach, in that it attempts to create "horizontal" interoperability rather than "vertical" interoperability. That is, whereas the goal of MARS is to support multicasting over an ATM network [e.g. placing an extra layer of abstraction vertically over the ATM link-layer], the goal of the CLS approach is to support general connectionless networking [including multicast] through the ATM network [e.g. lining-up a "classical" LAN horizontally alongside the ATM network, and having the two networks interoperate]. The CLS approach is in many respects a better solution to the general problem of connectionless networking over ATM than is LANE and the LIS model. First, the CLS approach does not attempt to emulate LAN behaviour over ATM, but rather simply provides a way for two LANs to communicate effectively through an ATM network; for this reason, CLS can avoid the costly overhead of a complete emulation layer. In particular, the CLS approach avoids the complexity of implementing a special ATM multicast solution such as MARS, and leaves multicasting as an issue for the IP layer to resolve. Finally, CLS avoids consuming a lot of connections by aggregating traffic over relatively fewer connections. On the other hand, each of the afore mentioned advantages can also be turned against CLS: Although leaving "classical" networking implementations alone and simply providing a means for LANs to communicate over ATM is the most simple and direct way to implement "interoperability" [i.e. since no special interpretation is being done to get "classical" LAN traffic over ATM, save for AAL 5 encapsulation] it may not be the most efficient way to implement. In particular, the same criticism leveled at MARS in the "shortcuts" proposal explained above may be leveled against the CLS approach: the paths through the virtual connectionless network may not be the most direct, and may be introducing unnecessary delay into the transport of packets. Secondly, leaving "classical" IP multicasting alone to persist in the domain of the network layer is probably not a good choice either: The lower down in the networking stack we can get multicasting, the more efficient it will be. Finally, using fewer connections is a valuable feature when connections are expensive, but it also means heavier traffic on fewer connections, and thus possibly higher average packet latency through the virtual network. In general, however, the CLS approach to providing connectionless networking over ATM is more feasible for the immediate future than are other solutions. CLS is easier to implement than a full-featured emulation layer, while at the same time it preserves the "classical" LAN functionality that networking applications rely on. Furthermore, the use of fewer VCs makes the CLS approach scalable for moderate-load networking over wide area ATM networks. Cisco started to support Connectionless Server functionality beginning with its Internetwork Operating System Release 10.2, but there is no data on how popular or widely used this feature is. LANE Finally, we should mention the work being done at Cisco to implement the ATM Forum's LANE 1.0 model. Cisco has been integrating the LANE spec into a number of its products, including its 4000 and 7000 series, so that its switches and routers emulate IEEE 802 "classical" LAN behavior over an ATM link layer. Cisco also now supports RFC 1577 "Classical IP and ARP over ATM," which is a key part of the environment in which MARS was designed to run. However, Cisco has not explicitly adopted the MARS model for address resolution, and their LES implementation currently sticks very close to the LANE specification. With respect to multicasting using the Cisco LANE implementation, the Canadian Broadband Applications and Demonstration Laboratory [Chan] has done some independent product evaluation of the Cisco 7000 router as part of a project to interconnect Canadian and European cities with a video conferencing system. The BADLAB test results indicate that, with the exception of some bugs in the implementation, the Cisco 7000 router delivered acceptable LAN emulation and configurability, though performance was found to be poor. In implementing a multicast connection to several European cities, BADLAB actually avoided using the router altogether, and instead created a static multicast tree using PVCs and a workstation to aggregate them onto a single root PVC. This approach is obviously unsuitable for a dynamic multicast environment, which means Cisco and other companies have their work cut out for them in improving the automated creation and management of multicast sessions over ATM networks. Conclusions There is a significant and growing demand for multicast functionality in general, and as ATM networks grow in popularity, there is an increasing demand for a viable multicast solution over ATM networks. As we have seen, multicast over ATM presents a particularly complex problem, since multicast is most efficiently implemented over a connectionless network, and ATM is a connection-oriented networking technology. As a result, the various approaches to multicasting presented in this paper have all recognized the need to establish some kind of "connectionless networking" layer over ATM, and then to implement multicasting over this new layer. To a large degree, it is the efficiency of the "connectionless networking" layer which defines the efficiency of the approach. In the ATM Forum's LANE model, a fully functional LAN emulation layer is envisioned, which can make a single physical ATM network look like a collection of "classical" IP subnets. In the Connectionless Server approach, the ATM network is used as a "connectionless" intermediary between actual LANs. And in the MARS approach, RFC 1577-style IP over ATM provides a "connectionless" layer under which MARS fits as the multicast address management system. None of these approaches has been shown to have spectacular performance, however each has interesting and useful design elements. For the time being, the Connectionless Server approach is probably the best balance of performance with functionality: There is no LAN emulation over the ATM link-layer in this approach, but it does provide an immediate way for existing LANs to take advantage of some of ATM's attractive features while still maintaining "classical" LAN features [such as IP, broadcasting, and multicasting]. The LANE model is in principal designed to support multicast, but its design is a rather inefficient attempt at reproducing [rather than improving on] LAN technology. Although the current Cisco implementation of LANE is becoming more widely used, evaluators still report poor performance using it; and although this should make it a less attractive choice, Cisco is pushing the administrative flexibility of VLANs over ATM, which may turn out to be a more powerful selling point than performance. Finally, the MARS/LIS approach to implementing multicast over ATM shows some promise, and although commercial products are not yet using the MARS model -- and may never -- the model nonetheless provides great insight into the problem of multicast over ATM. References [1] Armitage. "Support for Multicast over UNI 3.0/3.1 based ATM Networks." RFC 2022. Bellcore, November 1996. [2] Armitage. "VENUS - Very Extensive Non-Unicast Service." ION Internet Draft. draft-armitage-ion-venus-02.txt. Bellcore, April 1997. [3] ATM Forum. "ATM User Network Interface [UNI] Specification Version 3.1." June, 1995. http://www.atmforum.com/atmforum/specpage.html. [4] ATM Forum. "LAN Emulation Over ATM Version 1.0." January, 1995. http://www.atmforum.com/atmforum/specpage.html. [5] Chan and Savoie. "TCP/IP Unicast and Multicast trials for the Wide Area over ATM." Broadband Applications and Demonstration Laboratory, August 1996. http://www.crc.doc.ca/crc/ieee-atm96/atm-96-paper.html. [6] Cisco Systems. "Product Overview: LAN Emulation." 1995. http://www.cisco.com/warp/public/729/c5000/c5000_tc.htm. [7] Deering. "Host Extensions for IP Multicasting." RFC 1112. Stanford University, August 1989. [8] Heinanen. "Multiprotocol Encapsulation over ATM Adaption Layer 5." RFC 1483. Telecom Finland, July 1993. [9] Hong, Vickers, Suda, and Carlos Oliveira. "The Internetworking of Connectionless Data Networks over Public ATM: Connectionless Server Design and Performance." University of California, Irvine. 1994. [10] Huque, Nenashev, and Govindaswamy. "MARTIAN: A Throughput Tester for Multicast Networks." University of Pennsylvania, 1996. http://www.sas.upenn.edu/~shuque/tcom/. [11] Laubach. "Classical IP and ARP over ATM." RFC 1577. Hewlett-Packard Laboratories, January 1994. [12] Rekhter and Farinacci. IP Multicast over ATM. Cisco Systems. February, 1996. [13] Senji, Reisslein, and Ho. "Latency Tester for MARS." University of Pennsylvania, 1996. http://www.cis.upenn.edu/~psh/pr.html. [14] Smith and Armitage. "IP Broadcast over ATM Networks." IETF Internet Draft. draft-ietf-ion-bcast-01.txt. IBM, November 1996. [15] Wiltzius. "LLNL ATM Performance Data, Local and BAGNet Multicast tests." Lawrence Livermore National Laboratories, 1995. http://www.llnl.gov/bagnet/mcast-limit.html.