Führt man das IP-Multicast Konzept in eine bestehende MPLS L3VPN Architektur ein, so sind zwei Aspekte von Bedeutung. Einerseits muss die Unicast L3VPN-Umgebung derart erweitert werden, dass auf dem CE-PE-Link (Customer Edge /Provider Edge), also der Demarkation zwischen Kunde und Service Provider, zusätzlich zum IP Routing und Forwarding jetzt auch IP Multicast Routing und Forwarding nativ unterstützt wird. Die Tatsache, dass man im Unicast-Fall Transparenz für Routing-Protokoll und verwendete Kunden-IP-Adressen fordert, bedeutet für Multicast VPNs folgerichtig, dass auf dem CE-PE-Link alle standarisierten Signalisierungsprotokolle (insbesondere PIM-Sparse Mode und Internet Group Membership Protocol) unterstützt werden müssen und der Kunden ohne Einschränkungen in der Wahl seiner Multicast Gruppen-Adressen sein muss.
Andererseits muss das Backbone-Netzwerk des Service Providers aktiv an der Replikation der Multicast-Pakete mitwirken ohne gleichzeitig VPN-Kundenspezifische Informationen zu haben. Im Unicast VPN besitzen Backbone (P-Router) überhaupt keine Kenntnis von Kunden VPNs. Im Fall des MVPNs entsteht so ein Konflikt zwischen optimaler Wegeführung durch das Backbone-Netz und der Anzahl an Kundenzuständen auf den Core-Routern.
Multicast VPNs mit PIM/GRE (Generic Routing Encapsulation) Implementierung
Der ersten Ansatz Multicast in ein L3VPN einzuführen wurde von Eric Rosen vorgeschlagen und ist daher als Rosen-Draft bekannt. Diese Lösung verfolgt die Idee, das Multicast-Signalisierungsprotokoll PIM nicht nur zwischen dem PE- und dem CE-Router einzusetzen, sondern für den Austausch von Multicast-Informationen zwischen VRF-Instanzen von PE-Routern zu verwenden, die zum gleichen VPN gehören. Um diesen Austausch zu erlauben, müssen die VRF-Instanzen über eine Multicast- oder Broadcast-fähigen Transportmechanismus miteinander verbunden werden. Einen solchen Transportmechanismus nennt man einen Provider-Tunnel (P-Tunnel).
Die P-Tunnel werden ihrerseits mittels PIM-Signalisierung zwischen den PE-Routern aufgebaut. Um die PIM-Signalisierung im Backbone-Netzwerk von der PIM-Signalisierung zwischen PE- und CE-Router und zwischen den VRF-Instanzen zu unterscheiden, bezeichnet man die PIM-Signalisierung für den Aufbau der P-Tunnel als P-PIM und die PIM-Instanzen der Kunden als C-PIM. Zum Aufbau der P-Tunnel kann man entweder das ASM-Modell oder das SSM-Modell verwenden. Es ist zu beachten, dass die Multicast-Gruppen P-G Transport-Gruppen sind und nur innerhalb des Service Provider-Netzwerks für die PE- und P-Router von Bedeutung sind, und somit keinen Zusammenhang mit den Multicast-Gruppen der Kunden haben. Die Multicast-Sender P-S sind für die P-Tunnel keine Server, sondern vielmehr die PE-Router, an denen die Sender der VPN-Kunden angeschlossen sind.
Die P-Tunnel werden nicht nur zum Austausch der C-PIM Nachrichten, sondern auch zum Transport der Kunden-IP-Multicastpakete verwendet. Dazu werden die IP-Multicast-Pakete des Kunden mittels IP/GRE mit P-G als Ziel-IP-Adresse eingepackt und über das Core-Netzwerk transportiert. Man beachte, dass bei diesem Ansatz das Core-Netzwerk in der Lage sein muss, natives IP-Multicast weiterzuleiten. Während die Unicast-Pakete MPLS-Forwarding-Technologie verwenden, werden alle Multicast-Pakete über einen separaten Datenpfad ohne MPLS verschickt. Der wesentliche Nachteil an diesem Ansatz ist, dass innerhalb eines L3VPN, das eine BGP Control Plane und eine MPLS Data Plane verwendet, mehr oder weniger eine parallele Infrastruktur mit PIM Control Plane und IP/GRE Data Plane aufgebaut wird, um IP Multicast Unterstützung anzubieten. Zudem ist das Einpacken und Auspacken von IP-Paketen mit GRE sehr rechenintensiv und setzt bei vielen Router-Herstellern zusätzliche Hardware-Unterstützung voraus.