IP-Multicasting auf der Internetwork-Ebene wird durch das Internet Group Message Protocol IGMP [32] realisiert; dieses Protokoll wird von Nachbar-Routern benutzt, um sich gegenseitig über Gruppenzugehörigkeiten zu informieren.
Bei der Verteilung von Multicast-Paketen im Subnetwork geht IP davon aus, daß der Datalink-Layer seinerseits Multicasting zur Verfügung stellt. Im Falle Ethernet sind Multicast-Adressen vorhanden, mit denen ein durch sie adressiertes Paket durch eine einzige Sendeoperation am mehrere Empfänger verschickt wird. Hier stützt man sich darauf, daß ein gemeinsames Medium die Möglichkeit bietet, Pakete an mehrere Empfänger gleichzeitig zu senden. Die Stationen untereinander müssen sich nicht informieren, wer zu einer Multicastadresse gehört - jede Station empfängt physikalisch jedes Paket. Die Adreßauflösung von IP-Adresse zu Ethernet-Adresse wird algorithmisch gelöst, IP-Multicast-Adressen werden in Ethernet-Multicastadressen eingebettet.
In einem ATM-Netz ist eine Multicastadressierung von vornherein nicht gegeben. Der Verbindungstyp Point-to-Multipoint bietet zwar die Möglichkeit, an mehrere Empfänger gleichzeitig zu senden, allerdings müssen dem Sender die Empfängeradressen vorher bekannt sein.
Generell ist ein ähnliches Adreßauflösungsproblem gegeben wie beim Versenden eines Unicast-Paketes.
Internet Draft Support for Multicast over UNI 3.0/3.1 based ATM Networks [24] ergänzt den von Stationen (Workstations und Router) benutzten Classical IP over ATM-Ansatz dahingehend, daß ein Multicast Address Resolution Server MARS benutzt wird, um eine Abbildung von IP-Multicastadressen auf ATM-Adressen zu ermöglichen. Das Verfahren ist dem ATMARP-Mechanismus sehr ähnlich und in [24] ausführlich beschrieben.
Die Bereitstellung von Multicasting ist jetzt um das Problem der Adreßauflösung reduziert. Will ein Host ein mit einer IP-Multicast-Adresse versehenes Paket verschicken, werden durch Befragen des MARS die ATM-Adressen derjenigen Rechner ermittelt, die an der IP-Multicast-Group teilnehmen.
Dann kann eine Point-to-Multipoint-Verbindung (PtoMP) aufgebaut und das Paket übertragen werden. Dies setzt voraus, daß das ATM-Netz vermittelte virtuelle Verbindungen (SVCs) zur Verfügung stellt.
Dieser Ansatz kann aber sehr schnell an seine Grenzen stoßen:
Da PtoMP-Verbindungen unidirektional sind, muß eine sendewillige Station, die bisher nur Pakete empfangen hat, eine eigene PtoMP-Verbindung zu allen ihren Nachbarn aufbauen, die im gleichen Subnetz liegen.
Bei einer häufigen Änderung der Gruppenzugehörigkeiten muß dies jedem sendenden Teilnehmer mitgeteilt werden, und dieser muß daraufhin seine PtoMP-Verbindung(en) anpassen.
Es entsteht damit ein vermaschtes Netz von PtoMP-Verbindungen, die gegebenenfalls häufig geändert werden. Im Hinblick auf den Overhead der notwendigen Signalisierung innerhalb des ATM-Netzes, den Overhead, allen Stationen die Änderungen bekanntzugeben, und da SVCs kostbare Ressourcen sind, beschreibt [24] deshalb den Einsatz eines Multicast Servers MCS, der die Verteilung von Multicast-Paketen übernimmt. Er ist dann die einzige Stelle, an der auf eine Änderung der Kommunikationsbeziehungen reagiert werden muß. Pro IP-Multicast-Group wird damit nur noch eine PtoMP-Verbindung notwendig, um die Pakete an die Empfänger weiterzuleiten. Sendewillige Stationen müssen eine Verbindung zum MCS aufbauen, da PtoMP-Verbindungen unidirektional sind. Der Overhead und die Anzahl der bestehenden SVCs reduziert sich beträchtlich. Nachteilig ist, daß ein single point of failure vorhanden ist, und alle Stationen die gleichen QoS-Eigenschaften haben, was unter Umständen unerwünscht sein kann. Da eine Sendestation nun ihr eigenes Paket als Echo zurückerhält, muß dieses durch Filtermaßnahmen aufgefangen werden.
Auf diese Aspekte, und die Architektur von Multicast-Servern wird in einem eigenen Internet Draft Multicast Server Architectures for MARS-based ATM Multicasting [25] eingegangen.
Manchmal kann es sinnvoll sein, eine Kombination von direkten Verbindungen und Multicast-Servern einzusetzen. QoS-Vereinbarungen lassen sich dann je Verbindung treffen. An extension to the MARS model [26] schlägt ein Verfahren vor, in dem eine Applikation selbst entscheiden kann, welche Verbindungen mit welchem QoS benutzt werden, bzw. ob für die Teilnahme am Multicast der MCS benutzt wird oder nicht.
Zu bemerken bleibt, daß das MARS-Protokoll protokollunabhängig ist und auch zur Auflösung anderer (Schicht 3-)Protokolladressen geeignet ist.