Shortest Path Bridging vs. TRILL – Ein Vergleich

2 Kommentare Drucken

Seit Monaten wird im Netzwerkmarkt über zwei neue, konkurrierende Technologie-Standards diskutiert: „Shortest Path Bridging“ und „TRILL“. Die Aussagen, die dabei über beide Technologien gemacht werden, sind äußerst vielfältig: Von „Ablösung des Spanning Trees“ über „optimiertes Netzwerkdesign für Rechenzentren“ und „enorme Durchsatzsteigerungen“ bis „Provider-Technik“ wird nahezu jedes Schlagwort bemüht, das heutzutage Aufmerksamkeit verspricht.

Worum geht es tatsächlich? Wir werden im folgenden Artikel die drei standardisierten bzw. sich im Standardisierungsprozess befindenden Verfahren in ihren Grundzügen vorstellen und gegeneinander abwägen.

Die hauptsächlichen Merkmale und Ziele aller drei Verfahren lassen sich schnell aus der Bezeichnung „Shortest Path Bridging“ ableiten:

  1. Es handelt sich um Layer-2-Verfahren.
  2. Es geht darum, zwischen Endknoten die schnellste („kürzeste“) Verbindung
    1. zu finden und
    2. zu nutzen.

Wo diese Anforderungen herkommen, liegt auf der Hand: Mit dem verstärkten Einzug von Virtualisierungstechniken in die Rechenzentren und insbesondere deren Evolution (Stichwort Hochverfügbarkeit) wächst der Bedarf an größeren Layer-2-Bereichen. Praktisch alle Hochverfügbarkeits-, Fail-over- und Lastverteilungsverfahren der bekannten Server-Virtualisierungsprodukte setzen eine Layer-2-Verbindung voraus. Ähnliches gilt für das Provisioning, also die Bereitstellung neuer Server, durch modere Technologie im Rahmen von Cloud Computing.

Viele Cluster-Techniken, die eventuell sogar zwischen virtuellen Maschinen eingesetzt werden, oder auch FCoE (Fibre Channel over Ethernet) sind weitere Bereiche, die ebenfalls eine Layer-2-Verbindung voraussetzen.

Darüber hinaus hat die IEEE in den letzten Jahren mit 802.1ad, 802.1ah und 802.1Qay wichtige Standards für den Provider-Markt entwickelt, die klar darauf zielen, MPLS als Transportprotokoll abzulösen und stattdessen Ethernet auch in Weitverkehrsnetzen einzusetzen.

Layer-2-Bereiche, insbesondere große Layer-2-Bereiche, haben aber zumindest zwei Nachteile:

  1. Natürlich die Multicasts, die offensichtlich mit der Anzahl der Knoten im Netz zunehmen.
  2. Etablierte Verfahren zur optimierten Nutzung der vorhandenen Wege im Netzwerk können nicht genutzt werden.

Punkt 1 ist heutzutage gar nicht mehr so gravierend, Multicasts hat man in modernen Netzen im Wesentlichen im Griff. Viel wichtiger ist aber Punkt 2: Alle bis dato eingesetzten Verfahren zur Wegewahl setzen auf Layer 3 auf. Auf Layer 2 gibt es im Wesentlichen nur ein einziges Verfahren: den Spanning Tree – wenn auch in mehreren Varianten.

Die Spanning-Tree-Protokolle haben aber nicht die optimale Wegewahl als Ziel, ihre Aufgabe ist einzig und allein dafür zu sorgen, dass sich im Netz keine Schleifen bilden. Das Ergebnis ist daher immer eine schleifenfreie Baumstruktur, vorhandene alternative Wege werden zur Verhinderung von Schleifen stillgelegt und nicht genutzt. Dies führt aber gerade in stark vernetzten Strukturen zu vielen brachliegenden Netzwerkressourcen und je nach Topologie zu mitunter verheerend schlechten Kommunikationspfaden (siehe Bild 1).

Die Art und Weise, wie wir heutzutage Netze aufbauen, ist wesentlich von solchen Baumstrukturen geprägt und damit zu einem guten Teil ineffektiv. Baum- oder sternförmige Topologien produzieren praktisch zwangsweise Engstellen, denen in „modernen“ Designs mit Overprovisioning entgegen gewirkt wird. Besser geeignete Designs wie Ringtopologien oder voll- oder teilvermaschte Topologien sind aber bislang nur auf Layer 3 realisierbar.

Wünschenswert ist daher eine Technik, die es erlaubt, dass auch auf Layer 2 alle Verbindungen aktiv genutzt werden können und so eine Wegewahl möglich wird, ähnlich wie wir es aus Layer-3-Netzen kennen.

Anforderungen
Damit sind also die wichtigsten Anforderungen an die neuen Layer-2-Protokolle motiviert. Weitere Anforderungen ergeben sich aus den Tatsachen, dass gleichzeitig auch die Bandbreitenansprüche an die Netze wachsen und die neuen Protokolle natürlich in bestehende Netze integriert werden müssen.

Wir formulieren daher folgenden Anforderungskatalog:

  1. Alle verfügbaren Netzwerkverbindungen sollen gleichzeitig aktiv genutzt werden können.
  2. Zwischen jeweils zwei Endknoten soll ein optimaler („kürzester“) Weg ausgewählt werden.
  3. Falls mehrere gleichwertige (equal cost) Wege zwischen zwei Knoten gefunden werden, sollen gegebenenfalls mehrere dieser Wege gleichzeitig genutzt werden können, um so die Gesamtlast im Netzwerk gleichmäßig verteilen zu können.
  4. Geräte, die die neuen Protokolle unterstützen, müssen zusammen mit herkömmlichen Brücken, die die neuen Protokolle nicht unterstützen, funktionieren (Abwärtskompatibilität).
  5. Vorhandene Management- und Fehlersuche-Tools müssen weiter funktionieren und genutzt werden können.

Zwei sind besser als keiner?
Wie beschrieben gibt es also einen deutlichen Bedarf an neuen Netzwerktechniken, die die genannten Anforderungen erfüllen. Wie so oft hat aber niemand diesen Bedarf rechtzeitig vorhergesehen, oder genauer gesagt, niemand hat in vernünftiger Zeit einen entsprechenden Standard zu Wege gebracht. Mit „niemand“ ist an dieser Stelle natürlich in erster Linie die IEEE gemeint, die ja bislang praktisch alle wichtigen Layer-1- und Layer-2-Protokolle standardisiert hat. Man kann sich also durchaus auf den Standpunkt stellen, dass die Entwicklung eines passenden Layer-2-Protokolls in den Aufgabenbereich der IEEE fällt. Und tatsächlich ist ja die IEEE seit einigen Jahren dabei, in der Arbeitsgruppe 802.1aq unter der Bezeichnung „Shortest Path Bridging“ (SPB) einen entsprechenden Standard zu entwickeln. Der erste Draft hierzu stammt aus dem Jahr 2006, aktuell ist der Draft 3.2 vom Oktober 2010, auf den wir uns in diesem Artikel beziehen.

Trotz der in der vergangenen Zeit durchaus erfolgreichen Arbeitsteilung zwischen IEEE und IETF beschäftigt sich aber auch die IETF schon seit circa 2005 (die ersten Dokumente zu RBridges stammen sogar aus dem Jahr 2004) mit der Entwicklung einer konkurrierenden Lösung unter der Bezeichnung „Transparent Interconnection of Lots of Links“, kurz TRILL. Die offizielle Begründung für dieses ja tatsächlich etwas befremdliche Vorgehen ist, dass die IEEE mit ihrer Arbeit nicht schnell genug vorankomme. Wie dem auch sei, auch die IETF ist mit ihrer Arbeit noch nicht am Ende. Lediglich eine so genannte „Base Protocol Specification“ ist mittlerweile verabschiedet, aber auch dieses Dokument hat noch keine RFC-Nummer und keinen Standardstatus, da das referenzierte IS-IS-Verfahren seinerseits noch nicht verabschiedet ist.

TRILL: Grundlagen und Begriffe

TRILL liegt die Idee zugrunde, Layer-3-Routing-Verfahren auf Layer-2-Netze zu übertragen. Hierzu wird ein neuer Typ von Netzwerkkomponenten eingeführt, die so genannte RBridge (Routing Bridge). Eine RBridge ist diejenige Komponente, die TRILL im Netzwerk verfügbar macht.

Die Grundzüge des Verfahrens sind:

  • Die Frames werden „Hop by Hop“ von RBridge zu RBridge durch das Netzwerk weitergereicht. Die erste RBridge auf dieser Abfolge von RBridges, die also den Original-Frame entgegennimmt, wird als „Ingress RBridge“ bezeichnet und entsprechend die letzte RBridge, die den Original-Frame ausliefert, als „Egress RBridge“.
  • Solange die „Ingress RBridge“ noch nicht gelernt hat, über welche „Egress RBridge“ eine bestimmte Ziel-MAC-Adresse (inkl. VLAN) zu erreichen ist, werden Multicasts zur Weiterleitung verwendet.
  • Außerdem lernt jede RBridge über IS-IS als „Routing“-Protokoll, über welche „Next-Hop“-RBridges die „Egress RBridges“ zu erreichen sind.
  • Zur Weiterleitung wird der Original-Frame durch ein MAC-in-MAC-Verfahren eingekapselt. Als neue (äußere) Ziel-MAC-Adresse dient dabei die MAC-Adresse der „Next-Hop“-RBridge. Außerdem erhält der Frame einen zusätzlichen „TRILL-Header“, in dem außer der letztendlichen „Egress RBridge“ auch ein Hop-Count zur Schleifen-Vermeidung kodiert ist (Details weiter unten).
  • An der „Next-Hop“-RBridge wird dann ähnlich bei einem Router der äußere MAC-Header ausgetauscht, der Hop-Count reduziert und der Frame weitergeschickt.
  • Dies wird solange fortgeführt, bis die „Egress RBridge“ erreicht ist (oder der Hop-Count auf Null steht). Auf der „Egress RBridge“ wird dann der Original-Frame wiederhergestellt und zugestellt.

IS-IS wurde dabei als Topologie-Protokoll (Routing-Protokoll) ausgewählt, da IS-IS einige Vorteile bietet:

  • IS-IS läuft direkt auf Layer 2. Es werden keine IP-Adressen benötigt wie etwa bei OSPF.
  • IS-IS kann ohne Konfiguration (Zero Configuration) betrieben werden.
  • IS-IS verwendet eine TLV-Kodierung (Typ, Length, Value); dieses vereinfacht die Definition und den Transport von neuen Arten von Daten.

Das skizzierte Verfahren hat offensichtlich folgende Vorteile:

  • So genannte „Transit RBridges“, also RBridges, die innerhalb des Pfades Frames lediglich weiterleiten, müssen keine MAC-Adressen von Endgeräten, sondern lediglich die MAC-Adressen anderer RBridges lernen. Dies reduziert den Umfang der Weiterleitungstabelle, der so genannten „Forwarding Information Base“, deutlich.
  • Mit Hilfe des Hop-by-Hop-Verfahrens unterstützen RBridges so genanntes „Multi-Pathing“, das ist die gleichzeitige Nutzung paralleler, kostengleicher Wege. Wie oben erwähnt, ermöglicht dies eine bessere Auslastung der Netzwerkknoten und so gegebenenfalls einen höheren Datendurchsatz. (siehe Bild 2)

TRILL: Aufbau der Header

Wie oben erwähnt nutzt TRILL zum Transport von Daten-Frames einen MAC-in-MAC-Einkapselungsmechanismus. Hierbei erhalten die Frames zum einen einen neuen äußeren Transport-Header und zum anderen einen so genannten „TRILL Header“. (siehe Bild 3)
Der TRILL-Header wird ausschließlich von der „Ingress RBridge“ gesetzt und bleibt bis auf den Hop Count während des gesamten Transports durch die TRILL-Domäne unverändert. Er hat folgendes Format (siehe Bild 4):

  • 16 Bit Ethertype (0x22F3)
  • 2 Bit Protokollversion (V)
  • 2 Bit reserviert (R)
  • 1 Bit Multi-Destination-Bit (M)
  • 5 Bit Option Length
  • 6 Bit Hop Count
  • 16 Bit Egress RBridge Name
  • 16 Bit Ingress RBridge Name

Über das Ethertype-Feld wird der gesamte Frame als TRILL-Daten-Frame gekennzeichnet.

Ingress und Egress RBridge Namen sind eindeutige Kennungen für die beiden Systeme, die automatisch für jede RBridge erzeugt werden, sobald die RBridge einer TRILL-Domäne beitritt. RBridge Namen sind jeweils 16 Bit lang.

Die „Egress RBridge“ bzw. deren Name wird für Unicast-Frames mit bereits gelernter Zieladresse aus der Weiterleitungstabelle (Forwarding Information Base) bestimmt.

Für Unicast-Frames mit unbekannter Zieladresse sowie für Multicast- und Broadcast-Frames wird dagegen ein spezielles Konzept genutzt, das auf so genannte „Distribution Trees“ aufsetzt. „Distribution Trees“ sind speziell für diesen Zweck berechnete VLAN-übergreifende Baumstrukturen, die jede RBridge mit jeder anderen schleifenfrei verbindet. Ein „Distribution Tree“ ist also vergleichbar mit dem Spanning Tree. Prinzipiell reicht daher ein einziger „Distribution Tree“, zur besseren Nutzung der vorhandenen Topologie können aber auch mehrere „Distribution Trees“ berechnet werden, von denen dann einer von der „Ingress Bridge“ ausgewählt wird.

Im Falle von Unicast-Frames lernt die letztliche erreichte „Egress RBridge“ über den TRILL-Header, von welcher „Ingress RBridge“ die Absenderadresse ursprünglich kam und kann mit einem Unicast-TRILL-Frame antworten. Sobald diese Antwort bei der ursprünglichen „Ingress RBridge“ eingetroffen ist, kennt auch diese RBridge die zuständige „Egress RBridge“ und ist ab dann nicht mehr auf Multicasts und „Distribution Trees“ angewiesen.

Der äußere Transport-Header besteht wie üblich aus

  • Zieladresse,
  • Absenderadresse und
  • VLAN-Tag

und wird an jeder RBridge für die nachfolgende Übertragung jeweils neu gesetzt. Absenderadresse ist dabei stets die MAC-Adresse der lokalen RBridge. Die Zieladresse wird anhand des „Egress RBridge Name“-Eintrags im TRILL-Header bestimmt. Wird dort auf eine „Egress RBridge“ verwiesen, dann der Frame über einen Unicast weitergeleitet und als Zieladresse wird die „Next-Hop“-RBridge eingetragen. Wird im „Egress RBridge Name“-Eintrag auf einen „Distribution Tree“ verwiesen, dann wird der Frame über eine entsprechende Multicast-Adresse weitergeleitet.

Der VLAN-Eintrag im äußeren Header wird nur dann benötigt, wenn die lokale RBridge und die nachfolgende RBridge nicht unmittelbar benachbart, sondern über ein herkömmliches, nicht TRILL-fähiges, LAN-Segment verbunden sind (siehe Bild) und der Transport über dieses LAN-Segment VLANs erfordert. Auch dieses Feld wird RBridge für RBridge neu gesetzt.

Damit sind wir bei einer Besonderheit des TRILL-Protokolls: Die Verbindung zwischen zwei RBridges muss nicht ein direkter Link sein, es können auch lokale Inseln aus herkömmlichen Brücken überquert werden. Diese Inseln werden dann natürlich durch Standardmechanismen, sprich Spanning-Tree-Protokolle gesteuert. Die Spanning Tree BPDUs werden von den RBridges terminiert, so dass die Wirkung der Spanning-Tree-Protokolle tatsächlich auf solche Bereiche beschränkt bleiben. (siehe Bild 5)

SPB: Grundlagen und Begriffe

Shortest Path Bridging (SPB) wird von der IEEE in der Arbeitsgruppe 802.1aq als Erweiterung des VLAN-Standards 802.1Q entwickelt und schon damit ist klar, dass sich SPB mehr oder weniger nahtlos in bestehende Netze nach IEEE 802.1D („MAC Bridges“) und IEEE 802.1Q („VLANs“) integrieren wird.

Damit diese Integration in die vorhandenen 802.1-Strukturen funktionieren kann, müssen einige Grundvoraussetzungen, die in diesen Netzen gelten, berücksichtigt werden:

  1. Unicasts, Multicasts und Broadcasts zwischen einem bestimmten Sender und einem bestimmten Ziel müssen über dieselben Wege transportiert werden (eine stabile Netzwerksituation vorausgesetzt).
  2. Hinweg und Rückweg müssen symmetrisch sein, das heißt über dieselben Brücken führen.

Die grundlegende Konzeption von SPB ist es daher, den Spanning-Tree-Protokollen einen besser und schneller skalierenden Mechanismus zur Seite zu stellen, der zwar die eingangs formulierten Ziele wie die aktive Nutzung aller Links durch die Bestimmung optimaler Wege unterstützt, gleichzeitig aber an der Idee vollständiger (d. h. es gibt zu jedem Ziel einen Weg) und einfacher (d. h. es gibt keine Schleifen bzw. es gibt zu jedem Ziel nur einen einzigen Weg) Baumstrukturen festzuhalten.

Die Grundzüge von Shortest Path Bridging sind also:

  • Über IS-IS werden pro VLAN von jeder Brücke optimale Wege durch das Netzwerk berechnet.
  • Über geeignete (im Grunde sehr einfache) Algorithmen (ECT algorithms) wird sichergestellt,
  • dass bei kostengleichen Wegen deterministisch ein eindeutiger Weg ausgewählt wird;
  • dass Brücken, die auf diesem Weg liegen, denselben (Rest-)Weg zu demselben Ziel berechnen;
  • dass die Rückwege symmetrisch zu den Hinwegen berechnet werden.
  • Diesen auf diese Weise berechneten, so genannten „Shortest Path Trees“ (SPTs) werden innerhalb einer SPB-Region eindeutige VLANs (Details siehe unten) zugeordnet.
  • Alle diese Informationen werden über IS-IS im Netzwerk propagiert.
  • Eingehende Frames werden am Rand der SPB-Region (also an der „Ingress Bridge“) dem entsprechenden SPT zugeordnet und dann unverändert durch die SPB-Region bis zur Ausgangsbrücke transportiert.
  • Unicast-, Multicast- und Broadcast-Frames werden auf diese Weise gleich behandelt.

SPBV

In den ersten Entwürfen von Shortest Path Bridging war nur ein Verfahren vorgesehen, um SPTs zu kennzeichnen und Frames durch eine SPB-Region zu transportieren, nämlich mittels VLANs. Dieses ursprüngliche Verfahren wird immer noch unterstützt und wird im aktuellen Draft als SPBV bezeichnet.

SPBV-Bridges verwalten je eine so genannte „Translation Table“, die am Rand der SPB-Region die außerhalb genutzten Original-VLAN-IDs in nur innerhalb der Region genutzte Transport-VLANs übersetzt und umgekehrt. Die für diesen Zweck verwendeten VLAN-IDs werden netzwerkweit dynamisch reserviert und den jeweiligen Transportbäumen (SPTs) zugeordnet.

Die Koordination dieser netzwerkweiten Reservierung und Zuordnung übernimmt dabei ebenfalls IS-IS. Aufgrund der vollständigen Automatisierung dieser Vorgänge kann SPBV ohne Konfiguration „Plug-and-Play“ betrieben werden.

Dieser auf den ersten Blick überflüssig erscheinende Schritt der Übersetzung von externen in interne VLANs und umgekehrt geschieht, weil diese Zuordnung keineswegs umgekehrt eindeutig sein muss. Auf diese Weise kann man beispielsweise Multi-Pathing unterstützen – man ordnet einfach ein und demselben externen VLAN mehrere Transport-VLANs zu, die ihrerseits zu unterschiedlichen SPTs gehören.

Mit SPBV erwartet die IEEE, dass Topologien mit bis zu 100 Brücken in einer SPB-Region unterstützt werden können.

SPBM

Im Laufe der Jahre seit der Gründung der SPB-Arbeitsgruppe wurde dann mindestens ein sehr wichtiger Standard bei der IEEE verabschiedet, nämlich Provider Backbone Bridging (IEEE 802.1ah-2008) und spätestens seitdem kann man sagen, dass für die IEEE der Carrier-Markt wesentlich stärker in den Vordergrund gerückt ist. Daher beschreibt der SPB-Draft mittlerweile ein zweites Verfahren, welches auf das MAC-in-MAC-Verfahren aus 802.1ah zurückgreift: SPBM.

SPBM ist aus Sicht der IEEE Provider-Technik. So erwartet die IEEE beispielsweise mit SPBM Topologien mit bis zu 1.000 Brücken in einer SPB-Region unterstützen zu können. Aber SPBM hat auch im Enterprise- und Rechenzentrumsumfeld einige Vorteile.

Zu den Details:

  • Die Original-Frames werden gemäß IEEE 802.1ah (siehe Bild 6) eingekapselt.
  • Als Zieladresse (B-DA) wird von der Ingress Bridge die MAC-Adresse der Egress Bridge gesetzt, falls die originale Zieladresse (C-DA) (inkl. VLAN) in der lokalen Weiterleitungstabelle bereits bekannt ist. Ansonsten wird eine Multicast- Adresse genutzt. In jedem Fall bleibt der eingekapselte Frame auf dem gesamten Weg durch die SPB-Region unverändert.
  • Durch die Einkapselung bleibt insbesondere das VLAN des Original-Frames erhalten. Das kann bei einer Fehlersuche hilfreich sein.
  • Den Shortest Path Trees (SPTs) kann – wie in PBBNs (Provider Backbone Bridged Networks) üblich – an den Eingangsports ein zusätzlicher Service (I-SID, innerhalb des I-TAG) zugeordnet werden. Damit können deutlich mehr VLANs durch das SPB-PBBN transportiert werden als bei SPBV. (siehe Bild 7)
  • Das Verfahren unterstützt damit alle typischen Carrier Ethernet Services wie E-Line, E-LAN, E-Tree.
  • Durch die Einkapselung kommen im Innern der SPB-Region nur die MAC-Adressen der teilnehmenden SPB-Brücken vor, was deren Weiterleitungstabellen deutlich verkleinert. Die MAC-Adressen von Endgeräten müssen nur an den Randports der SPB-Region gelernt werden.
  • Da die MAC-Adressen der SPB-Brücken durch IS-IS während der Pfadberechnung publiziert werden, ist das Lernen von MAC-Adressen an allen Ports, die mit anderen SPB-Brücken verbunden sind, unnötig und daher abgeschaltet.
  • Angrenzende 802.1ah-Netze können durch die Bildung spezieller MAC-Multicasts, in denen die I-SID und die Adresse der Egress-Bridge kodiert sind, ebenfalls durch die SPB-Region transportiert werden.

SPB: Multi-Pathing
Wie oben erwähnt, wird zum Transport eines bestimmten Frames durch die SPB-Region von der „Ingress Bridge“ genau ein kürzester (kostengünstigster) Pfad ausgewählt. Die Bestimmung dieses Pfads erfolgt durch IS-IS. IS-IS unterscheidet jedoch nicht zwischen kostengleichen Pfaden! Daher muss ein zusätzlicher Algorithmus (ein so genannter ECT (Equal Cost Tree) Algorithm) für eine deterministische Entscheidung sorgen.

Im aktuellen Draft von SPB sind beispielhaft 16 solcher Algorithmen verpflichtend vorgeschrieben. Der Sinn dieser Algorithmen ist es, andere Shortest Path Trees auswählen zu können und so beispielswiese verschiedene VLANs mittels verschiedener ECT-Algorithmen über verschiedene kostengleiche Pfade zu leiten. Weitere Algorithmen sind herstellerspezifisch möglich.

TRILL vs. SPB: Ein Vergleich

Auf den ersten Blick könnte man zu dem Ergebnis kommen, dass TRILL und SPB einander sehr ähnlich sind:

  • Beide liefern kostengünstigste Pfade durch ein Netzwerk.
  • Beide nutzen IS-IS zur Pfadbestimmung.
  • Beide unterstützen Multi-Pathing bei kostengleichen Pfaden.
  • Beide (wenn wir uns mal auf SPBM konzentrieren) nutzen ein MAC-in-MAC-Verfahren zum Transport der Daten-Frames.
  • Beide nutzen VLANs zur Kennzeichnung der Datenpfade durch das Netzwerk.

Damit erfüllen beide Protokolle insbesondere die Punkte 1 bis 3 aus unserem Anforderungskatalog vom Anfang dieses Artikels.

Andererseits gibt es aber auch gravierende Unterschiede! Insbesondere die Entscheidung der IETF, TRILL ein Hop-by-Hop-Verfahren zugrunde zu legen, ist im Layer-2-Umfeld ein absolutes Novum und macht es äußerst schwer, wenn nicht unmöglich, dieses Protokoll kompatibel auf Layer-2-Switche zu implementieren. Im Grunde wird mit dem RBridge-Konzept eine neue Geräteklasse eingeführt, man könnte sagen Layer-2½ -Geräte.

Und dies ist keine rein akademische Feststellung. RBridges verhalten sich definitiv anders als „normale“ Switche nach IEEE 802.1, was durchaus Auswirkungen auf den Betrieb solcher Netze haben wird. So gehen beispielsweise praktisch alle Statistik- und Fehlersuche-Tools davon aus, dass man anhand der ersten Bytes eines Frames erkennen kann, von wo nach wo die Datenströme fließen – 802.1-Brücken ändern nun mal den Frame-Header beim Weiterleiten nicht (daher die Bezeichnung „Switch“), RBridges machen das aber, RBridge sind daher in dem Sinne keine Switches. Und dass an jeder RBridge damit die FCS (Frame Check Sequence) für jedes Paket neu berechnet werden muss, muss man nicht extra erwähnen.

Apropos Fehlersuche: Ganz allgemein muss man sicherlich davon ausgehen, dass Management und Fehlersuche in Shortest-Path-Netzen schwieriger und anspruchsvoller werden. Das liegt schon allein daran, dass diese Netze deutlich dynamischer sein werden als herkömmliche Netze, aber eben auch dezentraler, vermaschter. So ohne weiteres wird es dann nicht mehr klar sein, wie und wo sich die Datenströme im Netzwerk verteilen.

Da ist es durchaus von Vorteil, dass SPB vollständig kompatibel zu dem OAM-Standard (OAM = Operations, Administrations and Maintenance) IEEE 802.1ag (Connectivity Fault Management) ist, welcher seinerseits in weiten Teilen identisch ist mit der ITU-Empfehlung Y.1731. Für TRILL trifft das nicht zu, die TRILL-Arbeitsgruppe bei der IETF hat angekündigt, eigene OAM-Vorschläge zu entwickeln – das kann aber dauern.

Aber TRILL bringt auch mit seinem Weiterleitungskonzept für Broadcasts und Multicasts (über „Distribution Trees“) und seiner Multi-Pathing-Lösung weitere Dynamik ins Spiel. Denn einerseits werden Broadcasts und Multicasts über andere Wege geleitet als Unicasts (und haben damit andere Laufzeiten) und andererseits verteilt TRILL Datenpakete zufällig (Hash-basierend) über gegebenenfalls vorhandene, kostengleiche Pfade. SPB hält sich an diesem Punkt streng an die Erfordernisse der 802.1-Protokollsuite. Das hat Vorteile beim Monitoring und Trouble-Shooting: Wenn Sie wissen, wie ein konkreter Datenfluss verläuft, können Sie diesen dann auch an einem passend platziertem TAP oder an einem passenden Monitor-Port vollständig überwachen.

Auf der anderen Seite muss man der TRILL-Lösung zugutehalten, dass ihr Multi-Pathing-Konzept die Netzwerkressourcen vermutlich besser nutzt, da die Daten gleichförmiger über vorhandene Pfade verteilt werden. Der Nachteil einer solchen Auffächerung des Datenstroms ist allerdings wiederrum: Die Reihenfolge der Frames kann nicht garantiert werden. SPB bringt mit seinen ECT-Algorithmen zwar ein gewisses Maß an Flexibilität, dies muss allerdings administrativ konfiguriert werden. Der standardmäßig ausgewählte Algorithmus wird immer bestimmte Pfade und damit bestimmte Brücken bevorzugen.

Ein weiterer Unterschied zwischen TRILL und SPB ist das Frame-Format. TRILL führt mit seinem neuen Header ein neues Format ein (neue Data Plane), während SPB auf bereits eingeführte Formate aus 802.1ad und 802.1ah setzt. Dies führt dazu, dass SPB zumindest auf modernen Switchen mit vorhandenen ASICs auskommt und per Software-Update nachgerüstet werden kann. TRILL benötigt im Gegensatz dazu in jedem Fall neue Hardware – und das kostet.

Die Tabelle (Bild 9) fasst die wesentlichen Merkmale von TRILL und SPB nochmals zusammen.

Fazit: Zwei sind einer zu viel

Schaut man sich einige Unterschiede zwischen TRILL und SPBM an:

  • ca. 4000 VLANs bei TRILL gegenüber 16 Millionen Service-Tags bei SPB,
  • Auffächerung des Datenstroms über verfügbare Pfade bei TRILL gegen die strikte Zuordnung von Verkehrs- bzw. Service-Klassen zu einzelnen SPTs bei SPB,
  • die explizite Unterstützung von OAM-Standards bei SPB gegen keine Unterstützung bei TRILL

erkennt man doch gewisse Tendenzen zu unterschiedlichen Zielmärkten: SPBM Richtung Carrier Markt, TRILL Richtung Data Center.

Das heißt keineswegs, dass sich SPB oder speziell SPBM nicht für Rechenzentrumsnetze eignet, im Gegenteil: Gerade um virtuelle Strukturen, wie sie in virtualisierten Rechenzentrum (oder in der neuen Bezeichnung Cloud Computing) zunehmend vorkommen, von der physikalischen Ebene zu abstrahieren, ist IEEE 802.1ah mit seinem I-TAG und damit auch SPB hervorragend geeignet. Aber SPBM ist offensichtlich für große, gemanagete Netze entworfen. Wie einfach oder komplex SPBM im Einzelfall zu konfigurieren sein wird, muss sich mit der Verfügbarkeit konkreter Produkte noch zeigen.

Damit kommen wir zum Schluss: Für SPB spricht eine Menge, insbesondere die höhere Kompatibilität sowohl mit existierenden Protokollen als auch mit existierender Hardware. Für TRILL spricht an erster Stelle die derzeit umfangreichere Herstellerunterstützung. Es bleibt abzuwarten, ob das so bleibt. Sobald der IEEE-Standard verabschiedet ist – und das könnte noch in diesem Jahr sein – können die Hersteller auf vorhandenen und gegebenenfalls sogar schon verbauten Chips implementieren. Avaya hat schon Ende letzten Jahres Prä-Standard-Implementierungen für einige ihrer großen Switche vorgestellt. Ciscos FabricPath wird zwar von vielen Kommentatoren als Prä-Standard-Implementation von TRILL angesehen, das Protokoll hat aber im Grunde viel mehr Ähnlichkeit mit SPB (so ändert FabricPath beispielsweise nicht den MAC-Header auf jedem Hop).

Ärgerlich bleibt die Entwicklung und letztlich auch Markteinführung zweier so ähnlicher Standards allemal. Die Unternehmen müssen sich auf absehbare Zeit zwischen beiden Verfahren entscheiden – und gehen damit letztlich eine Herstellerbindung ein, die eigentlich durch Standards vermieden werden sollte. Was bleibt, ist viel Beratungsbedarf, wenn solche Netze später einmal zusammengeführt oder umgestellt werden sollen.

Daher schließen wir mit einem Appell: IEEE und IETF mögen sich umgehend zusammensetzen und eine gemeinsame Lösung entwickeln.

zugeordnete Kategorien: Klassiker
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



2 Kommentare zu "Shortest Path Bridging vs. TRILL – Ein Vergleich":

  1. RajeshPerumal schreibt:

    Hi,
    I don’t understand German, but came across this article.. very useful..
    But In the figure „Bild 7: TAG-Formate bei 802.1ah“ , the ISID value is of 24bits,i guess. Please clarify it.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.