Suchen

Die (R)Evolution der Rechenzentren; Teil 37 FCoE nach FC-BB-5 – Modelle für die Funktionalität von FC-BB_E

| Autor / Redakteur: Dr. Franz-Joachim Kauffels / Dipl.-Ing. (FH) Andreas Donner

Schon in der letzten Folge haben wir Aufbau, Funktionen und Möglichkeiten von FC-BB_E näher betrachtet und entsprechende Schlüsse gezogen. Das Verständnis von FC-BB_E ist wesentlich für sichere Entscheidungen bei Planung, Konfiguration und Aufbau konvergierter RZ-Netze. Heute geht es um die Definition der Funktionalität und damit um die Modelle für die gewünschte Funktionalität von Controllern.

Firmen zum Thema

Das FCF-Funktionalmodell; Bild: Dr. Franz-Joachim Kauffels
Das FCF-Funktionalmodell; Bild: Dr. Franz-Joachim Kauffels
( Archiv: Vogel Business Media )

Der Standard definiert Modelle für die gewünschte Funktionalität von Controllern. Wir fassen dies hier insoweit zusammen, wie es für das Verständnis wichtig ist. Insgesamt entsteht dadurch ein schönes geschlossenes Gesamtbild.

Funktionsmodell für einen ENode

Abbildung 1 zeigt das Modell. Die in Klammern gesetzten Elemente sind optional. Ein ENode besteht mindestens aus einer Lossless Ethernet MAC und einer FCoE Controller Funktion.

Bildergalerie

Bildergalerie mit 5 Bildern

Hier sehen wir sog. LEPs. Das sind FCoE Link End Points. Der zu einem ENode gehörende und mit der betreffenden MAC-Adresse assoziierte FCoE-Controller muss die Schaffung mindestens einer Instanz eines VN_Port/FCoE-LEP-Paares unterstützen. Der Controller ist eine Funktionaleinheit, die das FCoE Initialisierungs-Protokoll FIP durchführt und Instanzen von VN_Port/LEP-Paaren erzeugt und auflöst. Weitere Aufgaben sind:

  • Optionale Initialisierung des FIP VLAN-Discovery Protocols, welches FCoE-VLANs entdecken kann.
  • Initiierung des FIP-Discovery Protokolls, welches alle am gleichen Lossless Ethernet angeschlossenen FCF-MACs entdeckt, die in der Lage sind, VF-Ports zu unterstützen.
  • Initialisierung so genannter FIP FLOGI-Informationsaustausch-Prozeduren, und Schaffung eines VN_Port/LEP-Paares, wenn der FLOGI-Austausch mit einer VF_Port-fähigen FCF-MAC erfolgreich war oder wenn man einen expliziten Fabric Logout benötigt
  • Das Gleiche mit dem FIP NPIV FDISK Exchange-Protokoll für eine VF-Port-fähige FCF-MAC
  • Auflösung von Instanzen, wenn ein VN_Port sich bei der Fabric ausloggt oder wenn ein FIP Clear Virtual Link Befehl kommt
  • Aussendung periodischer FIP Keep Alive Nachrichten
  • Beobachtung des Zustandes der Instanzen von VN_Port/FCoE-LEP-Paaren
  • Monitoring der VF-Ports, an die Instanzen von VN_Port/LEP-Paaren eingeloggt sind

Die LEP ist diejenige Funktionaleinheit, die FC-Frames in FCoE-Pakete einpackt und ankommende FCoE-Frames wieder auspackt. An diese Funktion kann man einige Kontrollfunktionen hängen. So kennt die LEP nicht nur die „eigene“ MAC, sondern auch die des Zielpunktes. Sie kann bei einem ankommenden FCoE-Paket also prüfen, ob das auch von der richtigen Stelle kommt. Für eine FCoE-LEP auf einem ENode ist die MAC-Adresse des lokalen Link-Endpunktes diejenige, die mit dem VN_Port assoziiert ist, auf dem die LEP arbeitet. Die MAC-Adresse des entfernten Link-Endpunktes ist dagegen die FCF-MAC-Adresse des entfernten VF_Ports. Die VN_Ports sind Instanzen des FC-2V Sublevels des FC-Protokollstacks, der als N_Port arbeitet. Sie werden nach erfolgreichem Abschluss der FIP FLOGI und FIP NPIV FDISK Protokolle erzeugt. Ein VN_Port kann eine oder mehrere Arbeitseinheiten der FC-4-Protokollschicht unterstützen.

Kontrollprozeduren

Die Kontrollprozeduren mögen zunächst einmal als überflüssiger Overhead erscheinen. Sie sind aber nicht nur die Gewährleistung dafür, dass alle Datenströme auch die richtigen Wege gehen, sondern fangen auch viele mögliche Fehler, die in der Ethernet Switching Fabric passieren können, so wirkungsvoll ab, dass sie sich nicht auf den FC-Verkehr auswirken – wenn man einmal davon absieht, dass er im Extremfall stehen bleiben kann. Das aber wiederum ist in FC ja vorgesehen, dann gibt es eben für eine gewisse Zeit keine neuen BB_Credits.

Es sei allerdings noch bemerkt, dass diese Funktionen unbedingt auf der CEE/DCE/DCB-Ebene des Ethernets die DCBX-Kontrollfunktion benötigen, ohne die das für die Entscheidungen der Prozeduren notwendige Wissen nicht eingeholt werden kann.

weiter mit: Funktionsmodell für eine FCF

Artikelfiles und Artikellinks

(ID:2050954)