MPLS macht Fortschritte
Mehrere Testszenarien
Hierfür setzten die Hersteller und EANTC ein gemeinsames Netz mit allen getesteten Routern auf, in dem die beiden MPLS-Signalisierungsprotokolle entsprechend ihrer Stärken in einer hierarchischen Implementation eingesetzt wurden: Im Kernnetz kam RSVP-TE (Resource Reservation Protocol - Traffic Engineering) zum Einsatz, während am Edge LDP (Label Distribution Protocol) genutzt wurde, um die VPN-Services über das Gesamtnetz hinweg zu betreiben.
Beim Test der Layer-3-VPNs ging es im ersten Teil darum, festzustellen, wie gut die Interoperabilität zwischen den Implementierungen des vorläufigen Standards RFC-2547bis zwischen den verschiedenen MPLS-Herstellern ist. Hierfür prüften wir den Aufbau von VPN-Verbindungen zwischen unterschiedlichen Paaren von Routern an der Schnittstelle vom Netzbetreiber zum Kunden (Provider Edge - PE), die die VPN-Dienste bereitstellen. Der zweite Testteil zielte darauf ab, die Skalierbarkeit dieser PE-Router zu bestimmen.
Während der Vorbereitungen hatten EANTC und MPLS-Forum die aktuellen Anforderungen der Serviceprovider erfragt. Da-rauf basierend wurden insgesamt 255 VPNs mit jeweils zwischen 10 und 1000 Routen je Kundenanschluss (Virtual Router Function) gewählt. Wir untersuchten, ob alle Geräte diese Zahlen erreichten.
Die große Anzahl von Kundenanschlüssen und zusätzliche Provider-Edge-Router wurden mit Analysatoren von Agilent, Ixia und Spirent emuliert. Im gesamten Netz kamen dabei die Routing-Protokolle OSPF-TE (Kernnetz), iBGP-MP (Verbindung der VPN-Provider-Edge-Router), OSPF und eBGP zum Einsatz.
Um die Skalierbarkeit von Layer-2-VPNs zu überprüfen, konfigurierten wir entsprechend dem "Martini Draft" für jeden MPLS-Router bis zu 200 parallele Ethernet-VLAN-Tunnel. Lastgeneratoren erzeugten und analysierten bidirektionalen Datenverkehr zwischen den Ethernet-VLAN-Interfaces (IEEE 802.1q) der beiden PE-Router.
Die Fast-Rerouting-Tests zielten darauf ab, die Bereitstellung garantierter Dienste in einem MPLS-Netz nachzuweisen. Der neu entwickelte vorläufige MPLS-Standard "Fast Reroute" ist eine Erweiterung der "Traffic-Engineering"-Funktionen. Er wird noch bearbeitet. Aufgrund der starken Kundennachfrage implementierten ihn dennoch bereits fünf der Teilnehmer.
Fast Reroute ist ein Schutzmechanismus für die MPLS-Verbindungen und -Knoten, der bei einem Ausfall eines Label-Switched-Pfades (LSP) den Paketverlust drastisch reduziert, indem er den Datenverkehr innerhalb von etwa 50 ms auf einen vorbereiteten Backup-Pfad umleitet.
Diese Funktion überprüften wir in Tests mit jeweils zwei oder drei Herstellern. Der Standard definiert zwei alternative Mechanismen, "Facility Backup" und "Detour Backup", die nicht mitei-nander kompatibel sind, aber an verschiedenen Stellen eines Netzes gleichzeitig eingesetzt werden können. Vier Teilnehmer unterstützten Detour, zwei Facility.
Wir führten die Tests in drei verschiedenen Bereichen (Ethernet-VPNs, IP-VPNs, Fast Reroute) parallel durch. Um möglichst schnell und vollständig einen Überblick über die Interoperabilität und Skalierbarkeit zu erhalten, setzten wir kleinere Testgruppen ein. Schritt für Schritt bauten wir dann das endgültige Multi-Vendor-Netzwerk auf, das die MPLS-Geräte aller Testteilnehmer integrierte (siehe Abbildungen).
Mit dem öffentlichen MPLS-Interoperabilitätstest sollten zwei Ziele erreicht werden: Zum einen ging es darum, die Zusammenarbeit der unterschiedlichen Hersteller-Implementierungen in einem Netzwerk zu überprüfen und zu verbessern. Zum anderen sollte nachgewiesen werden, dass Serviceprovider heterogene MPLS-Netze einsetzen können, die den derzeitigen Skalierbarkeits-Anforderungen gerecht werden.
Dies bedeutet weit mehr, als lediglich Bugs zu finden und zu beheben. In vielen Fällen sind die Hersteller heute gezwungen, Standards noch im Entwurfszustand zu implementieren, um auf Kundenerfordernisse zu reagieren. Dieser Test diente deshalb auch dazu, die Eindeutigkeit aktueller Standards zu überprüfen.