Neue Netzwerk-Architekturen für das Rechenzentrum mit den aktuellen Shortest Path Bridging Technologien

Transkript

1 Neue Netzwerk-Architekturen für das Rechenzentrum mit den aktuellen Shortest Path Bridging Technologien IEEE 802.1aq kontra IETF TRILL von Cornelius Höchel-Winter 2011 ComConsult Technologie Information GmbH, Aachen

2 3 ZWEI STANDARDS 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. Hilfreich ist diese Entwicklung zweier konkurrierender Standards jedenfalls nicht. Ganz im Gegenteil trägt dies vermutlich eher zur Verunsicherung im Markt und damit zur Zurückhaltung von Investitionen bei. Wie dem auch sei, jedenfalls liegen also zwei unterschiedliche Protokollentwürfe vor und wir werden im Folgenden die technischen Details beider Protokolle näher beleuchten ComConsult Technologie Information GmbH, Aachen Seite 21

3 3.1 DIE BASIS: IS-IS Basis beider Standards ist IS-IS. IS-IS steht für Intermediate System to Intermediate System Protocol und ist ursprünglich ein dynamisches Routing- Protokoll für OSI. Daher spricht der IS-IS-Standard (ISO 10589) von Intermediate Systems, kurz IS. Ein IS ist also eine aktive Netzwerkkomponente mit mehreren Netzwerkschnittstellen, auf dem IS-IS ausgeführt wird und das basierend auf IS-IS Weiterleitungsentscheidung trifft. Die in Folgenden besprochenen Standards bleiben zwar jeweils in ihrer eigenen Nomenklatur und sprechen von Bridge beziehungsweise RBridge bei TRILL. Aus der Sicht von IS-IS sind beide Begriffe aber jeweils ein Synonym für IS. IS-IS wurde als Topologie-Protokoll (Routing-Protokoll) ausgewählt, da IS-IS einige entscheidende Vorteile bietet: IS-IS ist ein OSI-Protokoll (spezifiziert in ISO 10589) und daher unabhängig von einem speziellen Adressformat. Es werden also beispielsweise keine IP-Adressen benötigt wie etwa bei OSPF, sondern es läuft auch direkt auf Layer 2. IS-IS ist ein Link State -Protokoll (wie im Übrigen auch OSPF). Link-state- Protokolle haben verschiedene Vorteile gegenüber sogenannten Distance Vector -Protokollen (wie beispielsweise IGRP oder RIP). So konvergieren sie schneller, sind weniger anfällig gegen Routing-Loops und unterstützen größere Netze. IS-IS kann ohne Konfiguration (sogenannte Zero Configuration ) betrieben werden. IS-IS verwendet eine TLV-Kodierung (Type, Length, Value); dies vereinfacht die Definition und den Transport von neuen Arten von Daten. IS-IS unterstützt zwei Hierarchie-Ebenen (Level 1 und Level 2) und außerdem die Gruppierung der Systeme in verschiedene Areas: Routing auf Level 1 verbindet Knoten (IS) innerhalb einer Area, Routing auf Level 2 verbindet verschiedene Areas miteinander (Backbone). Einige grundlegende Mechanismen von IS-IS, die auch von TRILL und SPB verwendet werden, sind: Über regelmäßige Hello -Pakete stellen die Intermediate Systems fest, über welche Ports welche weiteren IS wie erreichbar sind und ob sie weiterhin erreichbar sind. Mit den so gefundenen Nachbarn werden sogenannte Nachbarschaftsbeziehungen ( Adjacencies ) aufgebaut. Hierbei wird beispielsweise notiert, welches IS mit welcher Link-Geschwindigkeit (Kosten!) über welchen Port erreicht werden kann. Darüber hinaus wird eine ganze Reihe weiterer pro ComConsult Technologie Information GmbH, Aachen Seite 22

4 tokollspezifischer Informationen gesammelt. Bei den hier betrachteten Protokollen sind das unter anderem Informationen darüber, welche VLANs und Multicast-Gruppen erreicht werden können, welche MTU-Größe verwendet werden darf etc. Alle diese Informationen werden über Link-state PDUs (kurz LSP) in der gesamten Area verteilt, jede LSP wird dabei über eine eindeutige LSPID gekennzeichnet. Jedes System sammelt alle diese Informationen in einer eigenen Linkstate Database und berechnet daraus selbst die jeweils kürzesten Wege zu den anderen Systemen. Weitere Datenpakete, die ausgetauscht werden, sind Complete sequence number PDU (CSNP) und Partial sequence number PDU (PSNP). Über CSNPs tauschen sich die Systeme regelmäßig aus, welche Datensätze (LSPID) sich jeweils in ihrer Datendank befinden, und über PSNPs können einzelne LSPs angefordert werden, falls festgestellt wurde, dass bestimmte Einträge fehlen oder geändert wurden. Auf diese Weise wird die Link-state- Datenbank auf allen Systemen in der gesamten Area aktuell gehalten. Die Daten selbst werden in sogenannten TLVs und sub-tlvs kodiert. TLV steht für Type Length Value. Jede TLV und sub-tlv hat den folgenden Aufbau: - Type (1 Byte) dieses Feld kennzeichnet, welche Daten in Value kodiert werden - Length (1 Byte) die Länge des Value-Feldes in Byte - Value (n Byte) die eigentlichen Daten, deren Struktur in verschiedenen RFCs zu IS-IS definiert ist. Zu TRILL und SPB sind jeweils einige spezielle TLVs definiert. Die folgenden Tabellen zeigen beispielhaft die Definition des Router Capability TLV aus RFC 4971 und zweier sub-tlvs aus RFC IS-IS Router Capability TLV type 1 Byte 6 length 1 Byte 5 + length(sub-tlvs) value Router ID 4 Byte Flags 1 Byte sub-tlvs optional Tabelle 1: IS-IS Router Capability TLV 2011 ComConsult Technologie Information GmbH, Aachen Seite 23

5 TRILL Version sub-tlv (IS-IS Router Capability TLV) type 1 Byte 13 length 1 Byte 1 value Max-version 1 Byte Tabelle 2: TRILL Version sub-tlv Nickname sub-tlv (IS-IS Router Capability TLV) type 1 Byte 6 length 1 Byte 5 * n value Nickname Record Nickname Priority 1 Byte Tree Root Priority 2 Byte Nickname 2 Byte weitere Nickname Records 5 Byte optional Tabelle 3: Nickname sub-tlv 2011 ComConsult Technologie Information GmbH, Aachen Seite 24