Alternative im Weitverkehr

NETZE
Alternative im Weitverkehr
Mit Carrier Ethernet - Provider Backbone Transport in die Zukunft?
Burkhard Germer
Im Transport-/Netzbereich der
Carrier-Welt, einer Infrastruktur, die
entscheidend zu den gesamten
Servicekosten des Carriers beiträgt,
vollzieht sich ein Wandel.
Mit Multiprotocol Label Switching
(MPLS) glaubte man noch vor
kurzem, jetzt endlich das Protokoll
gefunden zu haben, um alle Services
und Netzstrukturen optimal abbilden
zu können. Jetzt sieht man sich mit
neuen Möglichkeiten konfrontiert, die
einen Großteil der Netzintelligenz
und Netzsteuerung in den Ethernet
Layer verlagern und ohne MPLS
auskommen.
Burkhard Germer ist Business Development Manager Metro Ethernet bei Nortel
32
Der sicherlich prominenteste – und
wohl kontroverseste – Ansatz zur
MPLS-Alternative ist Provider Backbone Transport (PBT). Die unter diesem Namen bekanntgewordene Funktion wird derzeit als Provider Backbone Bridging – Traffic Engineering
(802.1Qay) von der IEEE standardisiert. Einige Hersteller integrierten die
Funktion bereits in ihre Komponenten, und viele Service Provider bekunden ihr Interesse. So kündigte die British Telekom (BT) unlängst an, große
Bereiche ihres 21st-Century-Netzes
mit der Funktion zu realisieren.
Situation der Service Provider
Überall gibt es heute die Erwartungshaltung nach hohen Bandbreiten zu
attraktiven Preisen, ohne jedoch große Abstriche in der Servicequalität in
Kauf nehmen zu wollen. Der Aufbau
von sehr leistungsfähigen und flexiblen Netzen ist daher unabdingbar.
Aber das Geld fließt nicht mehr in
klassische Netzstrukturen auf Basis
von ATM oder SDH: Ethernet hat sich
in den letzten zwei Jahren als attraktive Lösung für Carrier in den Vordergrund geschoben. Keine andere Technologie ist so gut in der Bandbreite
skalierbar, keine andere bietet ein besseres Kosten-zu-Megabit-Verhältnis.
Geschwindigkeiten bis zu 10 Gbit/s
sind heute problemlos möglich, mit
einer deutlichen Preisdifferenz zu beispielsweise STM-64 Packet over Sonet
(POS). Die Ethernet-Schnittstelle ist
deshalb in allen Gerätebereichen unaufhaltsam auf dem Vormarsch.
Im Umfeld der Geschäftskunden werden breitbandige Ethernet-Anschlüsse
für den Zugang zu IP-VPNs zunehmend interessant. Außerdem steigt
die Nachfrage nach reinen Layer-2Ethernet-Diensten, die die heutigen
ATM- und Frame-Relay-basierten Services ersetzen sollen. Mit diesen Lösungen behält der Kunde die Auto-
rität über die IP-Routing-Funktionen
und benutzt das Carrier-Netz lediglich
als Transportmedium. Es wird angenommen, daß schon in wenigen Jahren die Standardbandbreite nicht
mehr unter 2 Mbit/s liegen wird, sondern bei 11 bis 100 Mbit/s. Das bedeutet eine Erhöhung der Bandbreite
um den Faktor 10, wofür der Carrier
Backbone vorbereitet sein muß.
Ethernet auch im Mobilfunk: Neue
datenbasierte Dienste wie Highspeed
Downlink Packet Access (HSDPA) sollen nicht mehr durch direkte E1-Verbindungen realisiert werden, sondern
mittels E1 Circuit Emulation über
Ethernet/DSL; 3G Base Stations mittelfristig sogar direkt über Ethernet.
DSLAMs werden heute überwiegend
mit Gigabit Ethernet ausgestattet.
Und diese breitbandigen Anschlüsse
sind für heutige und zukünftige Multimediaanwendungen auch nötig.
Die Beispiele verdeutlichen die Motivation in Richtung Ethernet: Kostenvorteile bei möglichen sehr hohen
Bandbreiten. Ethernet dringt deshalb
in alle Netzbereiche eines Carriers vor,
so in den
• Access Layer (Ethernet in the First
Mile, VDSL, PON oder Active Ethernet to the Home über Glasfaser);
Das Thema in Kürze
Mit den Varianten MPLS und dem
neueren Provider Backbone Bridging – Traffic Engineering (PBBTE) lassen sich leistungsfähige Aggregationsnetze aufbauen. Doch
ist es falsch, hier einen Konflikt zu
sehen, bei dem nur ein Protokoll
Sieger sein kann. Somit lohnt die
vom Autor vorgenommene genauere Betrachtung beider Techniken – auch unter der Fragestellung, warum es überhaupt zu dieser Diskussion kommt.
NET 7-8/07
Alternative im Weitverkehr
• Aggregation/Metro Layer (Ethernet
over Optics oder Native Ethernet
über Dark Fiber);
• Core Layer (Interconnect von CoreKomponenten als Ersatz zu POS).
Der problematische Punkt ist der
Aggregation/Metro Layer. Er ist im
Normalfall in bezug auf die geographische Ausdehnung und die Zahl der
Knoten weit größer als der Core Layer.
Entscheidungen über die Realisierung
und Funktionsweise haben daher entscheidenden Einfluß auf die operationalen Kosten eines Netzbetreibers.
Das Aggregationsnetz muß in der Lage sein, verschiedene Dienste mit
möglichst hoher Servicegüte und klarer Trennung vom Access zum Core zu
transportieren und auch redundante
Verbindungen erlauben. Die Transportleistungen stehen hier im Vordergrund. Die Weiterverarbeitung der IPInformationen vom Access Layer findet typischerweise am Service Edge
Layer des Core-Netzes statt. Das klassische Ethernet-Protokoll kann die
meisten dieser Transportanforderungen nur unzureichend erfüllen. Bedenkt man seinen Ursprung in Local
Area Networks, ist dies nicht weiter
verwunderlich. Daher gilt es, folgende
Aspekte zu erfüllen:
• Sichere Separierung verschiedener
Kunden und klare Abgrenzung zwischen Carrier und Kunde;
• Service-Skalierbarkeit;
• Traffic Engineering und Quality of
Service;
• „Carrier-grade“-Verfügbarkeit und
Bandbreiteneffizienz;
• mindestens vergleichbar gute Operation, Administration and Maintenance (OAM) wie bei klassischen
Transportprotokollen.
Wo liegt also die Lösung?
Multiprotocol Label Switching
Die MPLS-Basisfunktionalität behebt
bestimmte Routing-Problematiken in
großen IP-Netzen. Den „Durchbruch“
in der Wahrnehmung hat MPLS aber
sicher durch die Spezifikation für IPVPNs erlangt (allgemein als RFC2547
bekannt). Man hört nicht selten die
Aussage, daß MPLS nur aufgrund von
IP-VPNs eine derartige Bedeutung für
Carrier erlangt hat. Aus Sicht der Ser-
NET 7-8/07
vice-Layer sind aber neben IP-VPNs
auch andere Dienste spezifiziert:
• Virtual Private LAN Services (VPLS)
für Ethernet-LAN-Dienste;
nen sowie Labels für die Tunnel als
auch Services. Das innere Label definiert den Service. Das äußere TunnelLabel definiert den Weg durch das
Möglichkeiten der Verkapselung im Vergleich
(SA – Source MAC Address; DA – Destination
MAC Address; VID –
VLAN ID; C-VID – Customer VID; I-SID – Service
ID; B-VID – Backbone
VID; BDA – Backbone
DA; B-SA – Backbone
SA; MPLS SL – Service
Label; MPLS TL – Tunnel
Label)
• Pseudo Wire Emulation (PWE) für
den Punkt-zu-Punkt-Transport diverser Protokolle über MPLS (inklusive Ethernet PWEs zur Abbildung
von Ethernet LINE-Diensten).
MPLS arbeitet verbindungsorientiert
und bringt damit einen wesentlichen
Aspekt in das verbindungslose Ethernet-Protokoll. Denn nur durch vordefinierte „Pfade“ lassen sich viele der
genannten Aspekte wirklich lösen.
Mit MPLS auf Basis von Ethernet können alle genannten Anforderungen
erfüllt werden.
Der Grundgedanke für MPLS war, ein
Protokoll zu kreieren, das generell auf
alle Netztopologien und -technologien anwendbar ist. Daher gibt es eine klare Definition von verschiedenen
Funktionseinheiten, die letztlich auf
sich ändernde Anforderungen angepaßt werden kann. Die Funktionseinheiten sind zum einen Kontroll-Layer
zur Signalisierung zwischen den Netzknoten und zum anderen Daten-Layer
für den eigentlichen Datentransport.
Letzterer mit Tunnel-Layer mit Möglichkeiten zu Traffic Engineering, FastReroute und QoS sowie Service Layer
zur Abbildung von unterschiedlichen
Diensten und VPNs.
Über den Kontroll-Layer mittels klassischer Routing-Protokolle signalisieren
sich die Router Topologie-Informatio-
Netz. Hier sind viele Optionen vorhanden, wie unterschiedliche Strecken für
Hin- und Rückweg, lokale Signifikanz
der Label-Nummer oder auch LSP
„merging“ (mehrere LSPs können an
einem Knoten zusamengefaßt werden und als ein LSP weiterlaufen).
Dies sind alles grundsätzlich gute Optionen, um für alle möglichen Netzszenarien die passende Lösung zu haben. Aber letztlich auch viele Funktionen, die die Konfiguration, den Betrieb und vor allen Dingen das Troubleshooting eines großen MPLS-Netzes komplex machen können. Beim
„Debuggen“ eines LSPs geben die Label-Nummern keinen Hinweis auf die
echte Quell- und Zieladresse des Dienstes. Durch unterschiedliche Wege für
die Hin- und Rückverbindung müssen
beide Wege auf ihre Funktionsfähigkeit überprüft werden. Und leider ist
die Definition von umfangreichen
OAM-Funktionen lange Zeit nicht mit
voller Konsequenz erfolgt und auch
heute noch nicht abgeschlossen.
Provider Backbone Bridging Traffic Engineering
Genau an diesem Punkt setzt PBB-TE
an. Durch die Reduzierung der Optionen und statische Programierung von
Forwarding-Informationen anstelle dy33
Alternative im Weitverkehr
namischer Protokolle wird eine deutliche Vereinfachung der gesamten
Netzstruktur erreicht. Auch PBB-TE ermöglicht eine verbindungsorientierte
Arbeitsweise im Ethernet, verlagert
die „Tunnel“-Informationen allerdings
in den Ethernet Layer selbst. Dabei
werden grundsätzliche Ethernet-Mechanismen weitestgehend beibehalten, die Integration in bestehende
Switche ist daher relativ einfach.
PBB-TE wurde möglich durch die
Kombination verschiedener Funktionen, die momentan von der IEEE standardisiert werden. Dies sind IEEE
802.1ah Provider Backbone Bridging
und IEEE 802.1ag Connectivity Fault
Management (Bild).
PBB ermöglicht eine klare Hierarchie
im Netz und eine saubere Trennung
von Kundennetz und Providernetz.
Ethernet-Pakete von Kundenseite
werden am Eingangspunkt in das Providernetz in ein Provider-Ethernet-Paket verpackt, bestehend aus Source/
Destination-Backbone-MAC-Adresse
Backbone VLAN-ID und Service-IDFeld. Es findet also ein Ethernet-inEthernet-Tunneling statt, was auch oft
als Mac-in-Mac bezeichnet wird. Auf
dem Backbone werden keine Kundenadressen zur Wegewahl benutzt, sondern nur Adressen aus dem ServiceProvider-MAC-Bereich. Verschiedene
Kunden-VPNs werden durch eindeutige, bis zu 16 Mio. mögliche, ServiceID-Nummern gekennzeichnet.
Die Traffic-Engineering-Aspekte von
PBB-TE werden zu PBB hinzugefügt,
indem die Forwarding-Tabellen der
Switche durch das Provisionierungssystem statisch gefüllt werden. Die
Kombination aus Destination-Backbone-Adresse und Backbone VLAN-ID ist
ein eindeutiger Pfad-Identifier. Dieses
„Label“ hat globale Signifikanz, bleibt
also von Anfang bis Ende ohne Veränderung. Bei insgesamt 60 bit (48 für
MAC und 12 für VLAN) stehen trotzdem genügend viele – bidirektionale –
Pfade auch für sehr große Netze zur
Verfügung. Die Kundenpakete durchlaufen das Backbone-Netz auf diesen
vordefinierten Pfaden.
Pfade können zu „Pfad-Gruppen“,
bestehend aus Working- und Protection-Pfad, zusammengefaßt werden.
Die Überwachung der Pfade ge34
schieht mittels IEEE 802.1ag durch
kontinuierliche „Heartbeat“-Pakete
zwischen den Switchen an beiden Enden eines Pfades. Werden diese von
der Gegenseite nicht mehr empfangen, sind die Switche in der Lage, eigenständig auf den Protection-Pfad
umzuschalten. Netzweite Umschaltzeiten von 50 ms werden so möglich.
802.1ag definiert noch einige weitere
Funktionen auf dem Ethernet Layer,
etwa Loopback, Traceroute und AIS.
Darüber hinaus existiert eine enge
Verbindung zu Y.1731 aus der ITU-T,
über die in den gleichen Statuspaketen auch Performance-Managementinformationen zwischen den Switchen
ausgetauscht werden können. Umfangreiche OAM-Funktionen sind daher mittlerweile auch auf dem Ethernet-Layer vorhanden.
PBB-TE erfüllt alle definierten Anforderungen an einen Transport-Layer:
Eine klare Trennung zwischen Kunden
und Provider, Skalierbarkeit der Dienste, Traffic Engineering, 50 ms Umschaltzeiten für hohe Verfügbarkeit
der Dienste. Dies alles wird ohne aufwendige Kontrollprotokolle „nah“ am
klassischen Ethernet erreicht. Durch
die vordefinierten Pfade sind auch voll
vermaschte Ethernet-Netze ohne Mechanismen zur Schleifenunterdrükkung wie etwa Spanning-Tree möglich – die Effizienz im Netz steigt.
Vergleich
Mit beiden Varianten lassen sich leistungsfähige Aggregationsnetze aufbauen. MPLS bietet mehr Optionen,
den Aufbau von Verbindungen dynamisch zu signalisieren. Dies klingt
zunächst weniger aufwendig, verlangt aber im Hintergrund eine Fülle
von Protokollen. Und gerade darin
kann das Problem stecken.
PBB-TE umgeht diese Probleme durch
die statische Konfiguration von Forwarding-Informationen in den Switchen. Dies klingt für sehr große Netze
nach viel Vorarbeit. Hier sollten leistungsfähige „Offline“-Planungstools
helfen. Die vorhandenen SDH-Netze
überall auf der Welt sind letztendlich
der beste Beweis dafür, daß man mit
dieser planerischen Arbeitsweise sehr
große Netze realisieren kann.
MPLS hat die Option für Any-to-AnyVPNs auf Basis von VPLS. Es gibt allerdings auch Skalierungsprobleme von
großen VPLS-VPNs, bedingt durch die
Edge-basierte Replikation von Broadcasts/Multicasts und unbekannten
Unicasts. Dies sollte man auf jeden
Fall berücksichtigen, speziell im Umfeld des IPTV.
PBB-TE ist heute ausschließlich für
Punkt-zu-Punkt-Verbindungen spezifiziert (vergleichbar mit Ethernet-Pseudowires auf Basis von MPLS). Punktzu-Mehrpunkt-Verbindungen lassen
sich durch natives 802.1ah realisieren.
Dabei werden die im Ethernet vorhandenen effizienten Mechanismen zur
Paket-Replikation verteilt genutzt.
Natürlich ist eine dem VPLS angelehnte Funktionsweise mittels PBB-TETrunks anstelle von PWE-Trunks zwischen den Virtual Switch Instances generell technisch möglich. Zudem ist
ein Großteil aller notwendigen Kommunikationsbeziehungen eben durch
Punkt-zu-Punkt-Verbindungen realisierbar (einzeln oder durch Kombination vieler Einzelverbindungen).
Fazit
Für welche Variante soll sich der Netzbetreiber entscheiden? Viele sehen
hier fälschlicherweise einen Konflikt,
aus dem nur ein Protokoll als Sieger
hervorgehen kann. Dies ist nicht zu
erwarten, da PBB-TE den EthernetTransport adressiert, während MPLS
auch viele Funktionen für andere Protokoll-Layer mitbringt. MPLS ist im
Core des Netzes – dort wo auch IPFunktionalität bereitgestellt wird –
etabliert; PBB-TE adressiert vordringlich den Aggregation/Metro Layer.
Der Netzbetreiber muß sich im Zuge
des Aufbaus einer Ende-zu-EndeEthernet-Infrastruktur unter Beachtung von Capex und Opex also fragen: Ergibt die Erweiterung von MPLS
von wenigen Core/Edge-Knoten auf
den gesamten Aggregationsbereich
einen Sinn und ist dies handhabbar?
Ist ein nativer Ethernet-Mechanismus
wie PBB-TE für Transportaufgaben im
Aggregation Layer sinnvoller, da weniger aufwendig? Mit der Beantwortung der Fragen sollte er sich nicht zu
lange Zeit nehmen.
(we)
NET 7-8/07