Provider Backbone Transport
MPLS-Konkurrenz für Metronetze?
Multi-Protocol Label Switching (MPLS) hat sich in Carrier-Backbones als Mittel der Wahl durchgesetzt, um IP-Verkehr mit Serviceklassen und in abgesicherten Tunneln zu übermitteln. Uneinigkeit herrscht unter den Carrier-Ausrüstern allerdings in der Frage, wie weit MPLS in die Stadt- oder Metronetze (Metropolitan Area Networks, MANs) vordringen sollte. In diese Debatte hat Nortel die Idee eingeworfen, dem etablierten, aber teuren MPLS einen abgespeckten Ethernet-Transport entgegenzusetzen: das Verfahren Provider Backbone Transport (PBT).
Am einfachsten wäre es für Netzwerkadministratoren, wenn die Welt tatsächlich ein Dorf und der
globale Netzwerkverbund ein einziges LAN wäre. Dann ließen sich Niederlassungen (sofern man diese
in einem Dorf überhaupt noch bräuchte) bequem mit bewährten Bordmitteln anbinden. Im richtigen
Leben jedoch hat sich zwar IP als Standardprotokoll bewährt, um das sich heute in Carrier-Netzen
alles dreht. Doch hat es sich als notwendig erwiesen, das IP-Routing um Zusatzmechanismen zu
erweitern, um die von Netzwerkbetreibern erwartete Dienstgüte (Carrier-grade Quality of Service,
QoS) und das Tunneling der IP-Pakete zu gewährleisten.
MPLS hat sich weltweit als maßgebliches Verfahren herauskristallisiert, um IP-Verkehr in
Carrier-gemäß geregelte Bahnen zu lenken: Label Edge Routers (LERs) versehen die Pakete mit
Markierungen (Labels), um den Datenverkehr auf vorgegebenen Routen (Label-Switched Paths, LSRs) und
mit definierter Serviceklasse an sein Ziel zu leiten. MPLS-Tunneling erlaubt dabei die Einrichtung
von VPNs entweder auf OSI-Layer 3 (IP-VPNs) oder auf Layer 2 (Virtual Private LAN Services, VPLS).
Ergänzungen wie MPLS Fast Reroute (FRR) sorgen für Hochverfügbarkeit und kurze Failover-Zeiten. Den
Referenzwert bilden hier nach wie vor die 50 Millisekunden Routenkonvergenz von SDH. Methoden wie
LSP Ping und LSP Traceroute erleichtern die MPLS-Verwaltung, im Carrier-Markt kurz OAM (Operations,
Administration, and Management) genannt. Der Vorteil von IP/MPLS: Dedizierte Netze für Daten- und
für Sprachverkehr entfallen, eine einheitliche Netzwerksprache herrscht vor. Von diesem aufwändigen
Unterfangen, den Flohzirkus der weltreisenden IP-Pakete zu bändigen, haben vor allem die großen
Router-Hersteller profitiert, allen voran Cisco und Juniper.
Die zunehmende Verbreitung unternehmenskritischer (Echtzeit-)Anwendungen und das in
Carrier-Kreisen als Umsatzbringer so heftig propagierte Triple Play (Daten, Sprache und Video über
die gleich Access-Infrastruktur) haben die Ansprüche an die Servicekriterien in Metronetzen
verschärft. Vor diesem Hintergrund wäre es technisch wünschenswert, die MPLS- Kontrollmechanismen
vom Core auf die Metronetze ausdehnen zu können – zumal viele Carrier noch zweifeln, ob ein zum
Carrier Ethernet aufgebohrtes LAN-Protokoll den WAN-Verkehr verkraftet, selbst wenn dies
Carrier-Ethernet-Verfechter wie Extreme Networks eisern beteuern. Im Vergleich zum nativen
Ethernet-MAN gilt ein MPLS-Netz als die ausgereiftere, aber eben auch teurere Variante.
In diese Debatte um die bestmögliche MAN-Architektur mischte sich Nortel im Sommer letzten
Jahres mit einem originellen Alternativvorschlag ein: Das von Nortel entwickelte und von der
British Telecom (BT) heftig geförderte Verfahren namens Provider Backbone Transport (PBT) sieht
vor, die Schwächen von Ethernet nicht durch Zusatzprotokolle auszugleichen, sondern die
problematischen Aspekte schlicht abzuschalten. Von SDH gewohntes verbindungsorientiertes Forwarding
soll Ethernet zu einer preiswerten MPLS-Alternative im MAN machen. Dazu will Nortel handelsübliches
Ethernet-Equipment verwenden.
Schwächen von Ethernet abschalten
Nortel argumentiert wie folgt: LAN-Switches leiten Ethernet-Frames mit unbekanntem Ziel an alle
Ausgangs-Ports weiter (Flooding). Aus der Antwort ermittelt der Switch die korrekte MAC-Adresse
(MAC Learning). Dieser LAN-Ansatz ist, so Nortel, für Metronetze ungeeignet, da er erheblichen
Traffic und Sicherheitsprobleme verursacht. Das hier eingesetzte STP (Spanning Tree Protocol)
erlaubt zwar die Etablierung eines alternativen Pfads im Fehlerfall, für Protection Switching –
also die geforderten 50 Millisekunden Failover-Zeit – ist es aber zu ineffektiv. Dies gilt laut
Nortel auch für STP-Erweiterungen wie RSTP (Rapid STP), da das Grundproblem – das zugleich auch der
Vorteil des klassischen Ethernet-Einsatzes ist – bestehen bleibt: der verbindungslose Transport. "
Spanning Tree Protocol wurde für die Baumtopologie entworfen, die natürlich im LAN existiert, nicht
für die komplexe vermaschte Topologie, die im MAN auftritt", heißt es dazu in einem Papier
(Technology Brief) des Herstellers.
Ziel deterministisches Verhalten
Aufgrund des verbindungslosen Charakters ist mit Ethernet eine garantierte QoS und ein
deterministisches Netzwerkverhalten wie bei SDH also nur sehr aufwändig zu realisieren. Deutliche
Fortschritte in Richtung Carrier-Tauglichkeit hat Ethernet in letzter Zeit vor allem durch die
IEEE-Standards 802.1ag (Fault-Management) und 802.3ah (Ethernet in the First Mile) sowie ITU Y.1731
(Ethernet-OAM) gemacht. Währenddessen hat Alcatel-Lucent mit T-MPLS (Transport-MPLS) eine schlanke
MPLS-Variante vorgeschlagen, die MPLS den Weg in die Metronetze ebnen soll. "T-MPLS zielt darauf
ab, das IP-/MPLS-Networking zu vereinfachen und kostengünstiger zu gestalten sowie bessere
Punkt-zu-Punkt-Dienstbereitstellung zu ermöglichen", so Simon Sherrington, Analyst bei Light
Reading Insider. "Es hat den Standardisierungsprozess schon weiter durchlaufen als PBT."
Nortels Ansatz greift direkt in die Grundcharakteristik von Ethernet ein: PBT umgeht den
Flooding-/Learning-Prozess und die STP-Probleme, indem es das Weiterleitungsverhalten von der
Forwarding Plane des Metro-Switches auf die Control Plane (die Managementebene) des Geräts
verlagert: Statt die Forwarding-Entscheidungen den Automatismen von Ethernet zu überlassen, sieht
PBT die explizite Konfiguration von Punkt-zu-Punkt-Verbindungen vor. Neben den vordefinierten
Pfaden geben Administratoren auch Backup-Verbindungen für den Fehlerfall vor. Diese Verbindungen
sind Service-agnostisch: Über sie können konventionelle Ethernet-Services ebenso laufen wie die
VPN-Varianten.
Ethernet-Switches leiten Frames auf der Basis eines 60-Bit-Lookups des VLAN-Tags und der
MAC-Adresse weiter; sowohl die VLAN-ID (VID) als auch die MAC-Adresse sind dabei einmalig – doch
dies, so argumentiert Nortel in den PBT-Materialien, muss gar nicht so sein: Konfiguriert man
mittels der MAC-Adressen einen schleifenfreien Pfad, dann stehen die VIDs für andere Aufgaben zur
Verfügung. PBT nutzt die VIDs, um Pfade zu einer MAC-Destination zu spezifizieren. Diese VID ist
dann nur für die Ziel-MAC-Adresse von Bedeutung; da jedoch die MAC-Adresse nach wie vor einmalig
ist, gelte dies auch für die 60-Bit-Kombination aus MAC und VID: "Jeder Frame trägt nach wie vor
eine MAC-Quelladresse", erklärt ein White Paper von Nortel. "So bietet PBT die Skalierung
zielbasierten Forwardings im Core, während es die Betriebsattribute von Punkt-zu-Punkt-Verbindungen
am Edge erhält." Da das VLAN-Tag nicht mehr einmalig sein müsse, ließen sich Skalierungslimits also
umgehen.
Monitoring mit Ethernet-Standards
Zum Monitoring von PBT-Verbindungen soll 802.1ag zum Einsatz kommen: Auf beiden Pfaden – dem
regulären und dem Backup-Pfad – wird eine CC-Session (Connectivity Check, Verbindungsprüfung)
etabliert. Beide Verbindungsendpunkte senden nun in regelmäßigen Abständen CC-Frames. Erreichen
drei CC-Meldungen in Folge ihr Ziel nicht, wird die Verbindung als ausgefallen eingestuft und das
Protection-Switching aktiviert. Als Alternative könnte auch ein Alarmsignal gemäß ITU-T Y.1731
diesen Schutzmechanismus auslösen. Da die Control Plane zwar dem Management und Monitoring der
Verbindungen diene, ohne aber am eigentlichen Protection Switching beteiligt zu sein, so Nortel,
seien die geforderten 50 Millisekunden Failover-Zeit einzuhalten. Damit positioniert Nortel die
PBT-Tunnel als direkte Konkurrenz zu den bei MPLS üblichen RSVP-TE-Tunneln (Resource Reservation
Protocol with Traffic Engineering). Ein solcher PBT-Tunnel soll dann das Multiplexing jeglichen
Ethernet- oder auch MPLS-Dienstes ermöglichen – Nortel denkt also auch an Services wie MPLS
Pseudowires over PBT.
Auf dem Weg zum Standard
Nortel hat PBT bereits bei der IEEE eingereicht. Das Verfahren wird voraussichtlich ab März ein
offizielles IEEE-Projekt sein. In den Standardisierungsgremien läuft es unter dem Namen PBB-TE
(Provider Backbone Bridge with Traffic Engineering). PBB-TE soll dabei als Ergänzung zu PBB (IEEE
802.1ah) dienen. Geht es nach Nortel, so würde PBB, wie Light-Reading-Analyst Sherrington erklärte,
"ein Ethernet-basiertes Punkt-zu-Mehrpunkt-Transportnetzwerk bieten. PBT würde dann einige Features
von PBB in einigen Netzwerk-Switches abschalten und ein Management-Interface für die Konfiguration
von Punkt-zu-Punkt-Schaltkreisen hinzufügen."
British Telecom, die schon früh als Förderer von PBT aufgetreten ist, hat sich im Januar
offiziell für Nortels Konzept als Basis für das Carrier-Ethernet-Deployment im Rahmen seiner
grundlegenden Netzwerkerneuerung unter dem Namen 21CN (Twenty-first Century Network) entschieden.
An dem Deal beteiligt ist auch Siemens, deren Surpass-Geräte PBT ebenfalls unterstützen. Mit
Shanghai Telecom hatte Nortel bereits im Herbst einen namhaften Kunden für seine PBT-Geräte
gemeldet. PBT scheint also auf dem besten Weg zu sein, sich als Konkurrenz zu MPLS im Metronetz und
eines Tages eventuell sogar im Core zu etablieren.
Wenig überraschend: Die Kommentare der von LANline befragten Vertreter etablierter MPLS-Player
rangieren zwischen abwartend und skeptisch: "Ich glaube nicht, dass PBT langfristig aus einem
Nischendasein herauskommt", meint zum Beispiel Thomas Ruban, Technology Director EMEA Edge und
Broadband bei Juniper. "Es gibt meines Erachtens nur ein Szenario, bei dem PBT besser dasteht als
MPLS: die Migration von SDH- zu Ethernet-Zugangsnetzen. In diesem Fall ist PBT einfacher, da das
OSS-Management fast unverändert den SDH-Paradigmen folgt. Allerdings werden viele Service-Provider
aber keine SDH-Migration durchführen, sondern einfach ein neues Carrier Ethernet installieren. Und
in ein paar Jahren wird es keine großen SDH-Netze mehr geben." Seine Folgerung: PBTs Zeitfenster
für eine erfolgreiche Markteinführung sei "übersichtlich".
Kritische Stimmen
Auch die reklamierte leichtere Verwaltung von PBT lässt Ruban nicht gelten. Denn PBT adressiere
nur ein kleines Subset der Probleme, die das etablierte MPLS bereits gelöst habe: "Um das
Versprechen der geringeren Komplexität einzulösen, muss PBT um diese Lösungen erweitert werden,
sonst haben die Service-Provider am Ende PBT plus MPLS statt ‚pures‘ MPLS oder ‚pures‘ PBT. Ob ein
erweitertes PBT dann aber noch Vorteile hat, ist ungewiss."
Zudem erinnert der Juniper-Mann daran, dass PBT neben dem Protokoll auch das Managementsystem
umfasst. "Richtigen Nutzen bringt im Wesentlichen das OSS (Operations Support System). Historisch
funktioniert das aber nur in "Mono"-Herstellernetzen mit voller Produktivität." Der Trend bei
Carriern gehe aber zu Netzen mit Equipment unterschiedlicher Hersteller (Multi-Vendor
Networks).
Auch Steffen Probst, Business Development Manager bei Cisco, äußerte sich zurückhaltend: "
Momentan ist es sicher noch zu früh, um zu bewerten, ob sich neue Technologieansätze wie PBT oder
T-MPLS durchsetzen werden. Beiden Ansätzen gemein ist, simpel gesagt, dass Intelligenz aus den
Netzelementen weg in die OSS-Schicht verlagert wird. Dieses Modell ist ja aus herkömmlichen
SDH-Transportnetzen bekannt. Es wird interessant sein zu sehen, ob die zu erwartenden Einsparungen
bei den Investitionen in die Netzelemente und das OSS wirklich höher sind als die steigenden
operativen Kosten durch manuelle Provisionierung." Es sei erst noch zu beweisen, "dass die
OSS-Systeme der einzelnen Hersteller hinsichtlich der Interoperabilität besser sind, als das in der
Vergangenheit bei SDH der Fall war." Zudem eigne sich PBT durch die Punkt-zu-Punkt-Orientierung
nicht für Triple-Play-Projekte.
Probst betont, Cisco evaluiere, wie die anderen Hersteller auch, neue Technologien und werde
abhängig vom Technik- und Marktpotenzial entscheiden, ob, wann und auf welcher Plattform PBT
implementiert wird. "Speziell bei PBT und T-MPLS ist es sicher besonders wichtig, auf reibungslose
Interoperabilität zu den vorhandenen MPLS-Netzen zu achten", warnt er. Doch auch Probst sieht hier
Potenzial schlummern: "Die wichtige Fragen für Service-Provider ist sicher, ob er Ethernet oder
MPLS für seine Aggregierungsnetze verwenden will. Sollte die Entscheidung zu Gunsten von Ethernet
fallen, dann könnte PBT eine Option neben PBB sein." Die Diskussion ist also in vollem Gang.
Lesen Sie mehr zum Thema
