MPLS wurde ursprünglich entwickelt um Pakete sehr effizient durch ein Provider-Netzwerk zu transportieren, in dem man vorberechnete Pfade (LSPs) von einem PE-Router zu einem anderen PE-Router berechnet und nur einmal entscheidet, welches Paket über welchen Pfad versendet wird. Die Router, die auf dem Weg vom eingehenden zum ausgehenden PE-Router liegen, treffen keine eigene Routing-Entscheidung, sondern folgen dem vordefinierten Weg. Es wurden zwei Protokolle entwickelt, die solche Pfad aufbauen können: Label Distribution Protokoll (LDP) und Resource Reservation Protokoll (RSVP). Beide Protokolle wurden ursprünglich allerdings nur für Punkt-zu-Punkt LSPs entwickelt, das heißt, ein LSP hat einen definierten Anfangs- und einen definierten Endpunkt.
Für Multicast-Umgebungen sind Punkt-zu-Punkt LSPs sehr ineffizient, da ein Sender mehrere Ziele hat und für jedes Ziel ein anderer Punkt-zu-Punkt LSP benötigt wird, damit müsste der eingehende PE-Router bereits die Multicast-Replikation durchführen.
In jüngster Vergangenheit wurden sowohl für RSVP und LDP Erweiterungen definiert, die den Aufbau von Punkt-zu-Multipunkt (P2MP) LSPs erlauben. Neben den typischen MPLS-Operationen muss ein Router für Punkt-zu-Multipunkt LSPs zusätzlich die Replikation von MPLS Frames unterstützen, d.h. ein ankommender MPLS-Frame muss kopiert und an mehrere Interfaces mit unterschiedlichen Labels weitergeleitet.
Ein interessanter Nebeneffekt von Punkt-zu-Multipunkt LSPs ist, dass ein Router je nach Netzwerk-Topologie und Verteilung der Empfänger im Netzwerk gleichzeitig Transit-Router und Edge-Router sein kein, was trivial erscheinen mag, aber in der Programmierung der Router-Hardware systemintern erhebliche Auswirkung hat. Bei einem Punkt-zu-Punkt LSP ist das nicht möglich.
Im IP Multicast spielt das Konzept des RPF-Checks eine wichtige Rolle. Um den RPF-Check durchführen zu können, muss ein PE-Router wissen, woher er ein Multicast-Paket bekommen hat. Ein Punkt-zu-Punkt MPLS LSP verwendet einen Mechanismus namens Penultimate Hop Popping (PHP), der dafür sorgt, dass bereits der vorgelagerte P-Router das Label eines MPLS-Frames entfernt um das Routing auf dem ausgehenden PE-Router zu vereinfachen. Unglücklicherweise geht damit die Information verloren, über welchem LSP der Frame empfangen wurde. Im Unicast-Fall ist das unproblematisch. Im Multicast-Fall hingegen muss diese Zuordnung möglich sein. Somit darf ein P2MP LSPs kein PHP verwendet werden.
Obwohl LDP und RSVP beide Erweiterungen zum Aufbau von Punkt-zu-Multipunkt LSPs besitzen und letztlich auch zur gleichen Data Plane führen, arbeiten beide Protokolle sehr unterschiedlich. Multicast LDP (mLDP) besitzt keine eigene Routen-Berechnung, sondern verwendet das Unicast-Routing-Protokoll. Der Aufbau des LSPs wird wie im IP-Multicast von den Empfängern initiiert. Die PE-Router, an denen Multicast-Empfänger angeschlossen sind, senden Anfragen für Label-Zuweisung für einen Multicast-Stream in Richtung des PE-Routers, an dem der Sender verbunden ist. Die P-Router konsolidieren diese Anfragen nach Label-Zuweisung anhand des angeforderten Multicast-Streams und senden jeweils eine Anfrage pro Multicast-Gruppe weiter. Die Information, wo der PE-Router mit dem Sender sich befindet, ist nicht Bestandteil der mLDP-Signalisierung und setzt einen externen Mechanismus voraus.
Im Fall von RSVP-TE wird der P2MP LSP vom Sender-PE aus aufgebaut. Das bedeutet im Umkehrschluss, dass dieser die PE-Router kennen muss, die interessierte Empfänger angeschlossen haben. Diese Kenntnis muss ebenfalls über einen externen Mechanismus erlangt werden. Die Signalisierung ist dabei analog zum p2p LSP Aufbau; es wird zunächst für jeden Empfänger ein separater sub-LSP aufgebaut.. Zusätzlich enthalten die Signalisierungsnachrichten aber eine P2MP ID an Hand derer die P-Router die unterschiedlichen sub-LSPs zu einem P2MP LSP zusammensetzen können.
Die Signalisierung mit RSVP ist deutlich komplexer, als mit mLDP, dafür bietet RSVP allerdings einige Vorteile, die hauptsächlich darin liegen, dass man MPLS Fast Reroute-Protection nutzen kann und RSVP außerdem Traffic Engineering erlaubt. Damit kann man LSPs oder sub-LSPs auf Pfade durch das Netzwerk zwingen, die aus Sicht des Unicast-Routings nicht optimal sind.