Techniken für konvergente Netze – Das DCB Capability Exchange Protocol (DCBX)

Anbieter zum Thema

ALE Deutschland GmbH

Aagon GmbH

Vitel GmbH

ComConsult Akademie

ComConsult Beratung und Planung GmbH

Datenaustausch via Link Layer Discovery Protocol

DCBX benutzt das IEEE 802.1 AB Link Layer Discovery Protocol (LLDP) für den Austausch von Parametern zwischen zwei Link Peers. LLDP ist ein unidirektionales Protokoll. Es informiert die vermöge eines IEEE 802 LANs an eine lokale Station angeschlossenen anderen Stationen über die Konnektivitäts- und Management-Eigenschaften der lokalen Station. LLDP PDUs beinhalten zwingend notwendige und optionale Type Length Values (TLVs). Zwingend notwendig sind z.B. Chassis ID, Port ID, TTL Time to Live, End of LLDPDU. Optional sind Informationen über das grundsätzliche Management und organisationsspezifische Informationen zu 802.1- oder 802.3-Protokollen.

Parameter, die über DCBX ausgetauscht werden, gehören zu den organisationsspezifischen TLVs. Abhängig von der Menge der auszutauschenden Information für alle Features werden für DCBX ein oder mehrere TLVs mit entsprechenden Sub-Typen definiert. Die Sub-Typen für ein TLV werden für jedes Feature, das von diesem TLV unterstützt wird, definiert. Abbildung 3 zeigt das LLDP Frame-Format.

DCBX ist dazu gedacht, über eine Punkt-zu-Punkt-Verbindung zu arbeiten. Werden multiple LLDP-Nachbarn entdeckt ignoriert DCBX diese Nachbarn. Ein LLDP-Nachbar wird durch seinen logischen MAC Service Access Identifier (MSAP) identifiziert. Der MSAP ist eine Kombination aus Chassis-ID und Port-ID-Werten, die in der LLPDU transportiert werden.

Das hört sich zunächst einmal unnötig komplex an. Tatsache ist aber, dass nach heutigen Stand der Technik Protokolle wie FCoE mit der gewünschten „Lossless“-Eigenschaft nur über Punkt-zu-Punkt-Strecken sinnvoll realisiert werden können, weil sie eine geschützte reservierte Bandbreite benötigen.

Beidseitige Aktivierung

Ein Administrator kann LLDP sowohl an der Sende- als auch an der Empfangsseite aktivieren oder deaktivieren. DCBX ist aber ein Protokoll, welches Acknowledgements verwendet. Um sinnvoll arbeiten zu können, muss LLDP also sowohl an der Sende- als auch an der Empfangsseite des Interfaces, auf dem DCBX läuft, aktiviert sein. Ist eine der Seiten ausgeschaltet, wird auch DCBX deaktiviert.

Ist DCBX aktiv und die LLDP-Sendeseite wird deaktiviert, wird gemäß der LLDP-Spezifikation eine Shutdown-LLDPDU ausgesendet. Erhält der Peer diese Nachricht, wird dadurch bei ihm auch DCBX deaktiviert. Das ist äquivalent zu einem Timeout oder einem Frame-Verlust. Vergleichbares passiert, wenn die LLDP-Empfangsseite ausgeschaltet wird.

Die Initialisierungsphase kann bei LLDP zu einem größeren Delay führen, bevor DCB-Parameter ausgetauscht und initialisiert werden können. Dieses Problem kann relativ einfach abgestellt werden und die Gruppe IEEE 802.1 AB-REV arbeitet daran. Sobald es aus der Welt geschafft ist, wird DCBX auf die neuen Bedingungen eingestellt.

DCBX ist als endlicher DCBX Kontrollautomat mit einer Menge von endlichen Automaten für die DCB-Features definiert. Die Aufgabe des DCBX-Automaten ist die Sicherstellung der Tatsache, dass die zwei DCBX-Peers nach dem Hochfahren der Verbindung oder nach einer Änderung der Konfiguration durch den Austausch von LLDPDUs synchronisiert werden. Die Automaten für die DCB-Features handeln die lokale operationelle Konfiguration für jedes Feature aus. Die Informationen über den DCBX-Kontrollzustand und die Konfiguration der DCB-Features werden über den Peer mittels DCBX TLVs ausgetauscht, die wiederum über LLDPPDUs übertragen werden. Das DCBX TLV-Format zeigt Abbildung 4.

Die DCBX Control Sub-TLV und die Menge der Feature Sub-TLVs können innerhalb der DCBX TLV beliebig angeordnet sein, es darf jedoch keine Dubletten geben. Sie würden als Konfigurationsfehler gewertet. Weitere Einzelheiten zu den Bits in den Feldern oder zum Aufbau des endlichen Automaten ersparen wir uns hier. Im Gegensatz zu vielen anderen Protokollen ist jedoch hervorzuheben, dass DCBX aufgrund seiner Konstruktion vollständig und ausnahmslos deterministisch arbeitet.

DCB-Features

Blicken wir noch auf die DCB-Features, zunächst auf das Priority-Group-Feature. Die Priority Groups Specification liefert Konfigurationstabellen und ein Scheduling-Verfahren für die Verwaltung von Bandbreite verschiedener Verkehrsklassen auf einer konvergierten Verbindung. Auch wenn man für die Zukunft erwartet, dass DCB-Geräte eine Scheduling-Funktionalität gemäß den Priority Group Spezifikation oder besser haben, muss man berücksichtigen, dass es bereits Implementierungen ohne diese Funktionen gibt. Um eine hinreichend weite Akzeptanz für DCBX zu schaffen, werden daher auch Implementierungen unterstützt, die die Qualität der Priority Group Spezifikationen nicht ganz aber so weit wie möglich erreichen.

Das Priority Based Flow Control Feature ist wichtig, um einen möglichst verlustfreien Datentransport für diejenigen Verkehrsarten zu gewährleisten, bei denen dies notwendig ist. DCBX sieht vor, dass in einem Fall, bei dem nicht beide Peers PBFC unterstützen, die Verbindung auf den PAUSE-Mechanismus nach 802.3x zurückgeschaltet wird.

Auch wenn PBFC selbst zu einer nicht-deterministischen Reaktion eines Netzes führen kann, wird es dennoch im Rahmen von DCBX durch einen endlichen, deterministischen Automaten repräsentiert. DCBX fügt also PBFC keine weitere nicht-deterministische Komponente hinzu.