IP-Multicast in VPNs
Optimierte Übertragung
Performance-intensive Anwendungen wie kommerzielle VPN- und VoIP-Services stellen hohe Anforderungen an Service-Provider. Deren Kabelinfrastrukturen müssen deshalb immer besser funktionieren. Während aber viele Provider bereits Layer-3-VPNs verwenden, ist die zusätzliche Unterstützung von IP-Multicast-Diensten innerhalb dieser VPNs immer noch eine Herausforderung. Viele Hersteller von Netzwerkkomponenten bieten dafür bisher nur unvollständige Lösungen an, die zudem mit Geräten anderer Hersteller weitgehend nicht interoperabel sind.
In Service-Provider-Netzen sind Layer-3-VPNs (L3VPNs) sehr weit verbreitet. Eine Lücke in L3VPNs ist allerdings die fehlende Unterstützung von IP-Multicast. Innerhalb der letzten Jahre ist die Nachfrage seitens Geschäftskunden nach L3VPNs mit IP-Multicast-Unterstützung stark gewachsen. Vornehmlich zur Datenvermittlung innerhalb so genannter Content Networks, aber auch für Newsticker, Finanzmarktdaten für den Börsenhandel oder Broadcast-TV-Anwendungen. Ein Multicast-VPN (MVPN) ist definiert als ein L3VPN, das den Transport von IP-Multicast-Paketen nativ unterstützt. Ein MVPN ist immer auch ein Unicast-VPN, da die Natur von IP-Multicast erfordert, dass Unicast-Routen zu den Sendern bekannt sind.
Unicast und Multicast
Der grundlegende Unterschied zwischen IP Unicast und IP-Multicast besteht darin, dass im IP-Multicast die Ziel-IP-Adresse eines IP-Pakets nicht länger einen einzelnen Knoten, sondern eine Gruppe von Empfängern darstellt, die über das komplette Netzwerk verteilt sein können. Zudem kann sich die Gruppenzugehörigkeit dynamisch ändern. Damit man ein IP-Paket einer Gruppe von Empfängern zustellen kann, muss dieses IP-Paket an einer bestimmten Stelle im Netzwerk repliziert werden. Für eine Multicast-Gruppe bezeichnet man den Datenpfad als Multicast-Verteilbaum. Man unterscheidet zwischen zwei Multicast-Varianten. Kennt der Empfänger zwar die Multicast-Gruppe G, die er empfangen möchte, aber nicht den Sender oder ist es ihm gleich, von welchem Sender er den Inhalt empfängt, so spricht man von Any Source Multicast (ASM). Will der Empfänger die Multicast-Gruppe explizit von einem oder mehreren vordefinierten Sendern empfangen, so spricht man von Source Specific Multicast (SSM).
In Multicast-fähigen IP-Netzwerken existiert ein Protokoll, das es ermöglicht, effiziente Multicast-Verteilbäume vom Sender zu den Empfängern aufzubauen und entsprechende Replikationspunkte im Netzwerk zu definieren. Im Allgemeinen kommt hier Protocol Independent Multicast (PIM) zum Einsatz, das selbst keine IP-Routing-Informationen verteilt, sondern auf einem Unicast-IP-Protokoll aufsetzt. Die resultierenden Verteilbäume heißen Shortest Path Tree im SSM-Modell und Rendezvous Path Tree im ASM-Modell. Damit sichergestellt ist, dass IP-Multicast-Pakete nicht über verschiedene Verteilbäume mehrfach übertragen werden oder Forwarding-Schleifen entstehen, existiert ein Mechanismus auf den Routern, der nur Multicast-Pakete an dem Interface akzeptiert, das aus Sicht des Unicast Routings das beste Interface in Richtung Sender ist. Man spricht daher von Kontrolle durch Reverse Path Forwarding.
Multicast-VPNs mit PIM/GRE-Implementierung
Der erste Ansatz, Multicast in ein Layer-3-VPN einzuführen, ist als Rosen-Draft bekannt. Diese Lösung verfolgt die Idee, das Multicast-Signalisierungsprotokoll PIM nicht nur zwischen dem PE- (Provider Edge) und dem CE-Router (Customer Edge) einzusetzen, sondern für den Austausch von Multicast-Informationen VRF-Instanzen (Virtual Routing and Forwarding) von PE-Routern zu verwenden, die zum gleichen VPN gehören. Um diesen Austausch zu erlauben, müssen die VRF-Instanzen über einen Multicast-fähigen Transportmechanismus miteinander verbunden sein. Einen solchen Transportmechanismus nennt man 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. P-Tunnel können entweder das ASM-Modell oder das SSM-Modell zum Aufbau nutzen, wobei die verwendeten Multicast-Gruppen Transport-Gruppen innerhalb des Service-Provider-Netzwerks sind und somit keinen Zusammenhang mit den Multicast-Gruppen der Kunden haben. Der Multicast-Sender eines P-Tunnel ist kein Server, sondern vielmehr der PE-Router, an denen die Sender der VPN-Kunden angeschlossen sind.
Multicast über Punkt-zu-Multipunkt
MPLS (Multiprotocol Label Switching) ist dafür konzipiert, Pakete sehr effizient durch ein Provider-Netzwerk zu transportieren, in dem man vorberechnete Pfade (Label-Switching Paths, LSPs) von einem PE-Router zu einem anderen PE-Router berechnet und nur einmal entscheidet, welches Paket über welchen Pfad zu senden ist. Die Router, die auf dem Weg vom eingehenden zum ausgehenden PE-Router liegen, treffen keine eigene Routing-Entscheidung, sondern folgen dem vordefinierten Weg. Zwei Protokolle können solche Pfad aufbauen: Label Distribution Protokoll (LDP) und Resource Reservation Protokoll (RSVP). Beide Protokolle wurden ursprünglich für Punkt-zu-Punkt-LSPs entwickelt; sie besitzen 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 eigener Punkt-zu-Punkt-LSP erforderlich ist. Der eingehende PE-Router müsste bereits die Multicast-Replikation durchführen. In jüngster Vergangenheit hat man sowohl für RSVP und LDP Erweiterungen definiert, die den Aufbau von Punkt-zu-Multipunkt- oder kurz P2MP-LSPs erlauben. Neben den typischen MPLS-Operationen muss ein Router für P2MP-LSPs zusätzlich die Replikation von MPLS-Frames unterstützen.
Im IP-Multicast spielt das Konzept des Reverse Path Forwarding Checks eine wichtige Rolle. Um den 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, 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 dies unproblematisch. Im Multicast-Fall hingegen muss diese Zuordnung möglich sein, weshalb dieser Mechanismus abgeschaltet sein muss.
Obwohl LDP und RSVP Erweiterungen zum Aufbau von P2MP-LSPs besitzen und letztlich auch zum gleichen Datenpfad führen, arbeiten beide Protokolle sehr unterschiedlich. Multicast LDP (mLDP) besitzt keine eigene Routen-Berechnung, sondern verwendet das Unicast-Routing-Protokoll. Wie beim IP-Multicast initiieren die Empfänger den Aufbau des LSPs. 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.
Multicast-VPNs mit BGP/MPLS-Implementierung
Die Entwicklung von P2MP-LSPs ist ein Schritt, um die Inkonsistenzen im PIM/GRE-Multicast-VPN-Modell (GRE: Generic Routing Encapsulation) zu beheben. Damit ist man in der Lage, den IP/GRE-Datenpfad durch einen MPLS-Datenpfad zu ersetzen. Der zweite Schritt besteht darin, auch die Signalisierung derart zu modifizieren, dass sie Anforderungen an Skalierbarkeit und Flexibilität, die Kunden heute haben, gerecht wird.
Der natürliche Ansatz besteht darin, den Aufbau der P-Tunnel nicht länger mit P-PIM zu signalisieren, sondern hierfür Multiprotocol-BGP (Border Gateway Protocol) zu nutzen. Da BGP ohnehin für die Signalisierung der Unicast-VPN-Routen zum Einsatz kommt, bedeutet dies kein zusätzliches Protokoll, sondern lediglich eine Erweiterung des bestehenden Protokolls um eine Multicast-Adressfamilie. Es sei darauf hingewiesen, dass im zuvor beschriebenen Rosen-Draft für jedes VPN und jeden PE-Router PIM-Nachbarschaften aufzubauen sind. Beim Einsatz von BGP ist lediglich eine BGP-Nachbarschaft pro PE-Router erforderlich. In großen Netzen kann man durch den Einsatz von BGP-Route-Reflektoren die Anzahl der BGP-Nachbarn weiter reduzieren.
Multicast-VPN-Extranet
Erst kürzlich zeigte die Industrie Interesse am so genannten Extranet mVPN. Dabei handelt es sich um spezielle Multicast-VPN-Szenarien, in denen der Multicast-Sender einem anderen VPN angehört als der Multicast-Empfänger. Ein Anwendungsbeispiel hierfür ist die IPTV-Verteilung, in denen eine Sendeanstalt unterschiedlichen Verteilnetzwerken den gleichen Videoverkehr gleichzeitig anbieten will, wobei die jeweiligen Abnehmer nicht miteinander kommunizieren dürfen. Ein anderes Beispiel sind Handelsplätze, die Börseninformationen verschiedenen Händlern bereitstellen, wobei jeder Händler sein eignes VPN betreibt.
VPN-Extranets für Unicast-Datenströme stehen seit vielen Jahren zur Verfügung. Technisch gesehen besteht im Unicast-Fall aus Sicht des Router-Netzwerks kein Unterschied zwischen einem Intranet und einem Extranet. Es existiert lediglich eine Filterfunktion, die es einem VPN erlaubt, IP-Routen eines anderen VPNs in seine Routing-Tabelle zu importieren, wodurch das entsprechende IP-Netzwerk erreichbar wird.
Der Import von IP-Routen reicht im Fall des Multicast-VPN-Extranets nicht aus, da der Aufbau des Datenpfades vom Empfänger zum Sender initiiert wird und die Bindung des Multicast-Stroms an einen Label-Switch-Pfad somit fehlen würde. Daher sind zusätzlich Regeln notwendig, die zusätzlich zu den IP-Routen zu den Multicast-Sendern auch den Austausch der Multicast-Signalisierungen über BGP entsprechend steuern. Die Verwendung einer MBGP (Multicast-BGP) Control Plane erlaubt auch den einfachen Aufbau von Extranets durch die Manipulation von Route Targets analog dem Modell wie Unicast-BGP/MPLS-VPNs, wobei für Unicast- und Multicast-Verkehr typischerweise unterschiedliche Route Targets Verwendung finden, um Unicast- und Multicast-Kommunikation besser voneinander trennen zu können.
Fazit
BGP ist als Signalisierungsprotokoll hoch skalierbar, weil es die bereits vorhandenen iBGP-Sessions verwendet. Zusätzlich lassen sich bei einer steigenden Anzahl von PE-Routern auch Route-Reflektoren nutzen. Obwohl die Verwendung von P2MP-LSP als Datenpfad zu bevorzugen ist, beschränkt sich die BGP-Signalisierung nicht darauf, sondern erlaubt auch PIM-SM/GRE oder „Ingress Replication“ auf P2P-LSPs als mögliche Optionen für den Datenpfad.
Selbst für Service-Provider, die keinen Kundenbedarf an MPLS-Layer-3-VPNs haben, kann der Einsatz von Multicast-VPNs sinnvoll sein. Will man im Kernnetzwerk kein natives PIM einsetzen, kann man die BGP Control Plane im Kernnetz nutzen, um PIM-Inseln am Rande des Netzes miteinander zu verbinden und den Multicast-Verkehr in P2MP-LSPs abzubilden.
Lesen Sie mehr zum Thema
