Die Schattenseite von MPLS

Multi Protocol Label Switching (MPLS) entwickelt sich mehr und mehr zur Haupttechnik für den Anschluss entfernt voneinander liegender Unternehmensbüros über ein Weitverkehrsnetz (Wide Area Network, WAN). Service Provider unterstützen diese Entwicklung, da sie es ihnen ermöglicht, Kunden zu verringerten Kosten anzuschliessen. MPLS vereinfacht die Verwaltung ihres Angebots, erlaubt es ihnen, einzelne Dienste mit umfangreicheren Servicefunktionen auszustatten und - am wichtigsten - es ermöglicht das Bereitstellen differenzierter Services. Der Aufbau von WAN auf der Basis von MPLS bringt nicht nur Service Providern Nutzen, auch geschäftliche Anwender profitieren davon. Erstmals ist es möglich, vollständig vermaschte Netzwerke ökonomisch aufzubauen. Mit MPLS lassen sich Anwendungen mit unterschiedlichen Prioritäten über das WAN übertragen. Geschäftskunden erhalten dadurch die Möglichkeit, ihre Kosten zu optimieren. MPLS macht echte Applikations-Konvergenz möglich, ohne zwingend mehrere Netzwerktechniken parallel einsetzen zu müssen.

Theorie und Praxis von MPLS

Die Kernfunktion von MPLS ist es, unterschiedlichen Datenverkehrstypen verschiedene «Classes of Service» (CoS) zuzuweisen. Jede Klasse kann eine oder mehrere Applikationen enthalten. Dahinter steht die Überlegung, dass jede Klasse unterschiedliche Performance-Charakteristiken erhält, die differenziert abgerechnet werden können. Dies und die Tatsache, dass es ein von Grund auf vermaschtes Netzwerk ist, macht MPLS zu einer brauchbaren Lösung für Unternehmen, die sicherstellen wollen, dass ihre wichtigsten Anwendungen mit einer definierten Priorität über das Netzwerk übertragen werden. Daher eignet sich MPLS auch ideal für Multimedia-Implementationen wie IP-Telefonie und Video over IP - das traditionelle Design von WAN hingegen würde beispielsweise eine zeitkritische Verbindung zwischen mehreren Aussenbüros erheblich verzögern. Zumindest in der Theorie funktioniert die Technik perfekt. Doch in der Praxis entdecken Unternehmen häufig, dass das Zuweisen einer Anwendung zu einer Premium-Service-Klasse alleine nicht den erwarteten Nutzen bringt. Was läuft verkehrt? Bandbreiten-Überlastungen innerhalb der Service-Klassen, verstopfte Premium-Klassen, Flaschenhälse ausserhalb des MPLS-Netzwerks - solche Faktoren münden in einer schwachen und nicht vorhersagbaren Applikations-Performance. Darüber hinaus führt die Aufgabe, viele Anwendungen - häufig einige hundert - auf relativ wenig MPLS-Klassen verteilen zu müssen, oft zu Fehlern und Missverständnissen. Das Ergebnis: Unternehmen erhalten nicht die erhoffte Performance, ihre Kosten-Nutzen-Erwartungen werden nicht erfüllt.

MPLS-Anwender müssen zunächst lernen, zwei Begriffe auseinander zu halten: «Class of Service» (CoS) und «Quality of Service» (QoS). Der Service Provider stellt CoS bereit, dem gegenüber steht das Verlangen des Unternehmens nach QoS. CoS ist der garantierte Transport von zusammengefassten Daten innerhalb des Service-Provider-Netzwerks. Das heisst, dass eine Datenverkehrsgruppe mit definierten Jitter-, Verlust- und Verzögerungs-Charakteristiken über das vom Service Provider kontrollierte WAN transportiert wird. QoS hingegen wird als garantierte Ende-zu-Ende-Übertragung von Applikationsdaten definiert. Dieser Hauptunterschied zwischen CoS und QoS spielt eine grosse Rolle für den Bedarf von Unternehmen: Sie wollen, dass einzelne Applikationen - genauer: einzelne Benutzer-Sessions - mit garantierter Performance vom Desktop bis zum Server und zurück übertragen werden.

Sobald ein Unternehmen entschieden hat, welche seiner Anwendungen den einzelnen Klassen mit hoher, mittlerer und niedriger Priorität zugeordnet werden sollen und klar ist, welchen Nutzen die unterschiedlichen Klassen bringen, kann die Zuweisung erfolgen. Es wäre sehr einfach, eine Applikation korrekt einer Klasse zuzuweisen, wenn die einzelnen Anwendungen bereits mit einer Prioritätsmarke versehen wären - etwa mit Hilfe der Type-of-Service-Bits (ToS) im IP-Adressfeld. Leider wird diese Möglichkeit kaum genutzt. Ein Netzwerk, das die ToS-zu-MPLS-Klassenkonvertierung verwendet, um Applikationen Klassen zuzuweisen, funktioniert jedoch nur korrekt, wenn alle Anwendungen per ToS markiert sind. Wenn MPLS-Lösungen sich nur auf Layer-4-Klassifizierung der Edge-Router für die Identifizierung der Applikationen verlassen, können nicht-geschäftskritische und unerwünschte Anwendungen unerkannt passieren. Sie belegen dann Bandbreite, die eigentlich den teuren Premium-MPLS-Klassen zugeteilt ist. Folgende Fragen zeigen typische Probleme im Umgang mit MPLS auf:

-Einige ERP-Anwendungen können jeden der 10000 Layer-4-Ports verwenden. Doch welche Datenströme werden tatsächlich als ERP-Datenverkehr erkannt? Der gesamte Verkehr? Nur ein Teil davon? Gar nichts?

-Durch privat genutzte Anwendungen erzeugter Datenverkehr sucht nach offenen Ports in Firewalls und maskiert sich selbst als ERP- oder HTTP-Verkehr.

-Wie sollte HTTP-Verkehr im Class-of-Service-Modell zugeordnet werden? So ist es wichtig zu erkennen, ob ein Mitarbeiter privat surft oder ob ein Kunde gerade auf der eigenen Homepage einkauft. Es ist nötig, geschäftswichtige HTTP-XML-Daten von privat genutzten HTTP-MPEG-Dateien unterscheiden zu können. Einige Web-basierte Clients wie Oracles Webforms und Web-basierte S390/AS400-Host-Zugriffe können wie herkömmlicher HTTP-Verkehr aussehen, müssen aber unbedingt unterschiedlichen Service-Klassen zugeordnet werden. Und es gibt Anwendungen wie Instant Messenger die ihren Datenverkehr maskieren und so versuchen, Sicherheits- und Steuerungsmechanismen zu umgehen. Dazu bauen sie einen HTTP-Tunnel auf und unterbrechen wichtige HTTP-Applikationen.

-Um eine Applikation der richtigen Klasse zuordnen zu können, ist eine automatische und differenzierte Klassifizierung der Anwendung nötig. Das erfordert die Analyse der Datenströme auf allen Netzwerkebenen inklusive der Anwendungsschicht. Die Verkehrsklassifizierung muss applikationsspezifische Informationen aus dem gesamten Datenstrom filtern und entziffern.

Der Edge-Router in einem MPLS-Netzwerk kann aber Datenströme nicht in der geforderten Tiefe analysieren. Daher wollen einige Unternehmen einen Performance-verbessernden Überbau am Zugangsbereich des MPLS-Netzwerks implementieren - eine Lösung, die alle Applikationen anhand der ihnen eigenen Signatur identifiziert und klassifiziert und danach das ToS-Bit innerhalb des Pakets setzt, so dass der MPLS-Edge-Router genau entscheiden kann, welcher Klasse er den Verkehrsstrom zuteilt. Hier liegt eine der Hauptschwächen von MPLS. Für die Mehrheit der MPLS-Implementierungen lässt sich nicht garantieren, dass der innerhalb einer Klasse transportierte Datenverkehr auch genau jener ist, der dieser Klasse zugeteilt werden sollte. Wenn diese Garantie jedoch nicht gegeben ist, lässt sich nicht sicherstellen, dass die vereinbarten Service-Level für die einzelnen Applikationen erreicht werden. QoS-Erwartungen bleiben unerfüllt.

Das Messen der Antwortzeiten (Response-time Management, RTM) ist essentiell für diese Aufgabe. RTM geht Beanstandungen von Anwendern auf den Grund und evaluiert Performance-Probleme, bevor sie geschäftliche Vorgänge schädigen. Erst mit dem passenden Mechanismus für den Vergleich der tatsächlichen und der vereinbarten Performance sind Service Level Agreements (SLA) mehr als ein leeres Versprechen. Zusätzlich helfen die Quantifizierung und die Untersuchung von Performance-Problemen bei der Argumentation für neue Ausrüstungen und bei der Planung zukünftiger IT-Infrastrukturen. RTM bietet Techniken zum Messen der Performance, zum Verbessern schlechter Antwortzeiten und zum Erreichen von Service-Level-Zielen - so lässt sich die Einhaltung von Service-Leveln kontrollieren. Mit RTM ist es möglich:

-Verzögerungsstatistiken von flexiblen Verkehrskategorien zu verfolgen. Antwortzeiten von einzelnen Anwendungen, Hosts, Subnetzen und jeder transaktionsorientierten TCP-Verkehrsklasse zu messen

-Aus jeder Messung einer Antwortzeit die Netzwerkverzögerung und Serververzögerung abzuleiten

-Benutzer und Server mit der schlechtesten Performance zu identifizieren

-Akzeptable Standards zu setzen und zu verfolgen, ob die Performance ihnen folgt. Dazu kann man die Geschwindigkeit definieren, die eine gute von einer schlechten Performance trennt und den Prozentsatz bestimmen, der die festgelegten Performanceziele erreichen soll

-SLA-Berichte sollten für verschiedene Applikationen, Aussenbüros, für die gesamte Verbindung oder andere Kriterien die Nutzung über der Zeit aufzeigen. Die Übersicht über die durchschnittliche Bandbreite über längere Zeiträume kann eine zusätzliche Sicherheit geben. Es ist wichtig, Spitzenbelastungen zu verfolgen und kürzere Intervalle verwenden zu können, als die Berichte des Service Providers es ermöglichen. Zusätzliche Grafiken können versteckte Kapazitätsprobleme aufzeigen.

-Das blosse Vertrauen auf Mittelwerte kann irreführend sein, da es häufig so scheint, als ob die Kapazität offenbar nie ausgeschöpft würde. Eine Spitzenwertmarkierung hingegen kann Peaks aufdecken, die kurzfristig die gesamte Bandbreite belegen. Oder das Gegenteil: Wenn ein Unternehmen die bezahlte Bandbreite gar nicht ausschöpft.

Fazit

Viele Unternehmen profitieren von den Fähigkeiten eines MPLS-Netzwerks, verschiedene Verkehrstypen unterschiedlichen Diensteklassen zuteilen zu können. Doch weil weder sie noch ihr Service Provider die Möglichkeit haben, die Applikations-Performance effektiv zu messen, kann keiner sagen, ob die vereinbarte Performance tatsächlich erreicht wird und sich die Investition für ein Service-Level-Agreement überhaupt rechnet. Wenn Unternehmen zwischen 10 und 25 Prozent ihres IT-Budgets für die WAN-Infrastruktur ausgeben und trotzdem nicht sichergehen können, dass die wichtigen Applikationen wie erwartet von Class of Service profitieren, und sie ausserdem keine Möglichkeit haben, die Einhaltung der SLA zu überprüfen, zeigt sich die Schattenseite von MPLS.