The correct and consistent description of networks and network protocols is difficult, especially when the network and protocols are internet networks and the TCP/IP protocol suite. The protocols of the TCP/IP protocol suite are not designed from formal specifications but on an ``as needed'' basis, which makes the task of describing them more like reverse engineering.
Multicasting was added to the TCP/IP protocol suite when IP was already widely used in the Internet. This late addition and the lack of ``killer'' applications may explain the trouble in integrating multicasting support in the Internet. Another factor could be the lack of fully developed multicast routing protocols.
ATM is very attractive as network technology on its own, but the integration of ATM within existing networks is difficult at best. LAN Emulation and Classical IP and ARP over ATM help this integration but both are less than optimal for complete integration of IP with multicasting support in the ATM world. LANE introduces too much protocol overhead and it is not optimised for IP. Classical IP over ATM is optimised and IP can use the ATM Quality of Service directly. In most cases, when IP multicasting (or broadcast) is not needed, Classical IP over ATM is perfectly useable.
At Bellcore (and other places) this limitation was recognized and before
and during the time this thesis was written, a set of protocols was
developed and standardized in a.o. RFC 2022
and RFC 2149. In RFC 2022 the
issues of IP multicast address resolution to ATM addresses (using the
MARS) and the forwarding/copying of the packets to the destinations
(using either a point-to-multipoint VC-mesh or a Multicast Server) are
discussed and solved.
To be able to use a specification such as RFC 2022, an implementation must be created. Implementations are usually specific for one type of computer and operating system. For several reasons, the Linux operating system on common PCs has been chosen for this project. One of the reasons was that a free ATM driver is being developed with on-line support in the form of a mailing-list. In a followup to this project, alternatives (like Windows NT or Solaris) could be considered if those platforms provide better support for an implementation and for inter-operability with other RFC 2022 implementations.
Adding the IP multicasting functions to the Linux-ATM implementation is not a trivial matter. The Linux implementation of the UNI 3.1 signalling specification does not include complete support for setting up or terminating switched point-to-multipoint Virtual Channel Connections. This limitation in the point-to-multipoint support seriously impairs attempts to work on a worthwhile implementation of IP multicasting support on the Linux-ATM system. If the termination of switched point-to-multipoint VCCs are fully supported, it would allow a Linux MARS-Cluster member to inter-operate with an external MARS server and MCS. Extending the signalling implementation to include native ATM multicast support appears to be an attainable goal and a necessary step in the path towards a meaningful RFC 2022 implementation.