DE112012000393T5

DE112012000393T5 - Reservierung von Switch-Warteschlangenkapazität auf der Sicherungsschicht

Info

Publication number: DE112012000393T5
Application number: DE112012000393T
Authority: DE
Inventors: Vijoy Pandey; Vinit Jain; Renato Recio; James Franklin Macon jun.
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-03-09
Filing date: 2012-02-15
Publication date: 2013-10-10
Anticipated expiration: 2032-02-16
Also published as: US9007909B2; GB2502235A; US20120230196A1; CA2819209A1; JP2014502469A; JP5497246B2; DE112012000393B4; GB201316080D0; US20120230192A1; KR101455017B1; CN103404094A; TW201251374A; CA2819209C; WO2012120388A1; US8917594B2; TWI538437B; GB2502235B; CN103404094B; KR20130128440A

Abstract

Ein Netzwerk-Switch erstellt in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation eine Reservierung für eine Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation. In Reaktion auf eine Warteschlangen-Überlaufbedingung an der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, behält der Netzwerk-Switch Datenrahmen in dem Datenfluss der Quellstation bei, die in Übereinstimmung mit der Reservierung übertragen werden, und verwirft sonstige Datenrahmen.

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf Netzwerk-Datenaustausch und im Besonderen auf die Reservierung von Switch-Warteschlangenkapazität in einem Datenaustausch-Netzwerk.
Hintergrund der Erfindung
Wie nach dem Stand der Technik bekannt ist, beruht ein Netzwerk-Datenaustausch im Allgemeinen auf dem allgemein bekannten Modell der Kommunikation offener Systeme (Open Systems Interconnection, OSI) mit sieben Schichten, das die Funktionen verschiedener Protokollschichten definiert, die Schichtprotokolle selbst hingegen nicht definiert. Bei den sieben Schichten, die bisweilen als Schicht 7 bis Schicht 1 bezeichnet werden, handelt es sich um die Anwendungs-, Darstellungs-, Sitzungs-, Transport-, Vermittlungs-, Sicherungs- bzw. Bitübertragungsschicht.
An einer Quellstation beginnt ein Datenaustausch, wenn Daten von einem Quellprozess auf der obersten (Anwendungs-)Schicht des Stapels von Funktionen empfangen werden. Die Daten werden nacheinander auf jeder stufenweise niedrigeren Schicht des Stapels formatiert, bis auf der Sicherungsschicht ein Datenrahmen von Bits erzielt wird. Zum Schluss werden die Daten auf der Bitübertragungsschicht in Form von elektromagnetischen Signalen über eine Netzwerkverbindung zu einer Zielstation übertragen. Wenn sie an der Zielstation empfangen werden, werden die übertragenen Daten einem entsprechenden Stapel von Funktionen in umgekehrter Reihenfolge, in der die Daten an der Quellstation verarbeitet worden waren, aufwärts übergeben und auf diese Weise die Informationen einem Empfangsprozess an der Zielstation zugeführt.
Der Grundgedanke von Schichtprotokollen wie zum Beispiel derjenigen, die durch das OSI-Modell unterstützt werden, besteht darin, dass Daten die Modellschicht zwar vertikal durchlaufen, die Schichten jedoch an den Quell- und Zielstationen in einer Peer-to-Peer-Weise (d. h. von Schicht N zu Schicht N) interagieren und die Funktionen jeder einzelnen Schicht durchgeführt werden, ohne die Schnittstelle zwischen den Funktionen der einzelnen Schicht und der Protokollschichten unmittelbar darüber und darunter zu berühren. Um diese Wirkung zu erzielen, fügt jede Schicht des Protokollstapels an der Quellstation üblicherweise Informationen (in Form eines eingebundenen Header) zu den Daten hinzu, die durch den Sendeprozess erzeugt werden, während die Daten den Stapel abwärts durchlaufen. An der Zielstation werden diese eingebunden Headers der Reihe nach entfernt, während der Rahmen durch die Schichten des Stapels nach oben weitergegeben wird, bis die entkapselten Daten dem Empfangsprozess übergeben werden.
Das physische Netzwerk, das die Quell- und Zielstationen verbindet, kann eine beliebige Anzahl von Netzwerkknoten beinhalten, die durch eine oder mehrere drahtgebundene oder drahtlose Netzwerkverbindungen miteinander verbunden sind. Die Netzwerkknoten beinhalten im Allgemeinen Hosts (z. B. Server-Computer, Client-Computer, mobile Einheiten usw.), die Netzwerkverkehr, Switches und Router erzeugen und in Anspruch nehmen. Herkömmliche Netzwerk-Switches verbinden verschiedene Netzwerksegmente und -prozesse und leiten Daten auf der Sicherungsschicht (Schicht 2) des OSI-Modells weiter. Switches stellen üblicherweise zumindest grundlegende Brückenfunktionen bereit, zu denen ein Filtern von Datenverkehr durch eine Schicht-2-Media-Access-Control-(MAC-)Adresse, ein Erfahren der Quell-MAC-Adressen von Rahmen und ein Weiterleiten von Rahmen auf der Grundlage von Ziel-MAC-Adressen zählt. Router, die verschiedene Netzwerke auf der Vermittlungsschicht (Schicht 3) des OSI-Modells miteinander verbinden, implementieren üblicherweise Netzwerkdienste wie zum Beispiel Routenverarbeitung, Pfadermittlung und Pfadumschaltung.
Bei herkömmlichen Computernetzwerken, die Datenaustauschprotokolle mit Schichten implementieren, lag die Zuverlässigkeit von Datenverbindungen in der Zuständigkeit von Protokollen höherer Schichten (d. h. Schicht 4 und darüber). Falls zum Beispiel die Kapazität eines Eingangsanschlusses eines Switch zum Verarbeiten eingehender Datenrahmen durch die Quellstation, die mit diesem Eingangsanschluss verbunden ist, erschöpft ist, verwirft der Switch die eingehenden Rahmen, die nicht verarbeitet werden können, im Hintergrund, und die Transportschicht (Schicht 4) und die Protokolle höherer Schichten müssen einen Paketverlust erkennen und gegebenenfalls Wiederherstellungsmaßnahmen durchführen. Falls der Datenaustausch zwischen den Quell- und Zielstationen keinen Paketverlust toleriert, kann die Verarbeitung, die erforderlich ist, um den Sendeprozess an der Quellstation zu regulieren und die verlorenen Pakete wiederherzustellen und erneut zu übertragen, einen erheblichen Rechenaufwand für die Netzwerkknoten, die den Datenaustausch unterstützen, und besonders für den Host der Quellstation bedeuten.
In einem Versuch, den Rechenaufwand an den Netzwerkknoten zu verringern, die mit einer Paketwiederherstellung in Zusammenhang stehen, entwickelte die Internet Engineering Task Force das in der IETF RFC 2205 beschriebene Resource Reservation Protocol (RSVP) und seine Erweiterung, das in den IETF RFCs 3209 und 5151 beschriebene RSVP-Traffic Engineering (TE) Protocol. Bei dem RSVP und seiner Erweiterung RSVP-TE handelt es sich um Protokolle der Transportschicht (Schicht 4), die entweder durch Hosts oder durch Router eingesetzt werden können, um Ressourcen der Vermittlungsschicht über ein Netzwerk hinweg zu reservieren, um die Bereitstellung von integrierten Diensten durch Anwendungsdatenströme über das Internet auf bestimmten Stufen der Dienstqualität (quality of service, QoS) zu ermöglichen.
Offenbarung der Erfindung
Gemäß zumindest einer Ausführungsform erstellt ein Netzwerk-Switch in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation eine Reservierung für eine Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation. In Reaktion auf eine Warteschlangen-Überlaufbedingung an der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, behält der Netzwerk-Switch Datenrahmen in dem Datenfluss der Quellstation bei, die in Übereinstimmung mit der Reservierung übertragen werden, und verwirft sonstige Datenrahmen.
Bei der bevorzugten Ausführungsform ist der Datenfluss einer Vielzahl von Datenflüssen der Quellstation zugehörig; und ein Erstellen einer Reservierung weist ein Erstellen jeweils einer von einer Vielzahl von Reservierungen für jeden der Vielzahl von Datenflüssen der Quellstation auf. Der Datenfluss wird bevorzugt an eine Zielstation gerichtet; der Netzwerk-Switch ist einer Vielzahl von Switches in einem Datenpfad zwischen der Quellstation und der Zielstation zugehörig; und das Erstellen weist ein Erstellen der Reservierung an jedem der Vielzahl von Switches in dem Datenpfad auf. Bevorzugter empfängt der Netzwerk-Switch die Schicht-2-Reservierungsanforderung. Noch bevorzugter wird die Schicht-2-Reservierungsanforderung in einem Link-Layer-Discovery-Protocol-(LLDP-)Rahmen angegeben.
Bei der bevorzugten Ausführungsform kennzeichnet die Schicht-2-Reservierungsanforderung den Datenfluss durch eine Schicht-2-Adresse und eine Flusskennung der Quellstation. Das Erstellen der Reservierung weist bevorzugt ein Aufzeichnen der Reservierung in einer Reservierungsdatenstruktur des Netzwerk-Switch auf. Bevorzugter entfernt der Netzwerk-Switch die Reservierung in Reaktion auf ein Ablaufen eines Zeitgebers. Noch bevorzugter entfernt der Netzwerk-Switch die Reservierung in Reaktion auf ein Ausschöpfen eines reservierten Datenvolumens. Noch bevorzugter modifiziert der Netzwerk-Switch eine reservierte Kapazität bei der Eingangswarteschlange während der Reservierung. Noch bevorzugter überträgt die Quellstation die Schicht-2-Reservierungsanforderung.
Kurzbeschreibung der Zeichnungen
Ausführungsformen der vorliegenden Erfindung werden nun lediglich als Beispiele unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, für die gilt:
1 ist ein Übersichts-Blockschaubild einer Datenverarbeitungsumgebung gemäß einer Ausführungsform;
2 ist ein Übersichts-Blockschaubild eines Datenverarbeitungssystems gemäß einer Ausführungsform;
3 ist ein Übersichts-Blockschaubild eines Abschnitts einer Datenverarbeitungsumgebung, die Virtualisierung gemäß einer Ausführungsform einsetzt;
4 ist ein Übersichts-Blockschaubild einer beispielhaften Ausführungsform eines Schicht-2-Netzwerk-Switch gemäß einer Ausführungsform;
5 ist ein Übersichtsplan eines logischen Ablaufs eines beispielhaften Prozesses, durch den ein Host eine Eingangswarteschlangenkapazität eines virtuellen oder physischen Switch gemäß einer Ausführungsform reserviert;
6 stellt einen Übersichtsplan eines logischen Ablaufs eines beispielhaften Prozesses dar, durch den ein virtueller oder physischer Switch eine Eingangswarteschlangenkapazität des Datenflusses eines Host gemäß einer Ausführungsform reserviert;
7 veranschaulicht einen beispielhaften Link-Layer-Discovery-Protocol-(LLDP-)Rahmen, der dazu verwendet werden kann, einen QRsv-Datenaustausch zwischen einem Host und einem Switch und zwischen Switches gemäß einer Ausführungsform zu implementieren;
8 stellt ein beispielhaftes QRsv-Anforderungs-TLV dar, das durch einen Host in einem LLDP-Datenrahmen, der als QRsv-Anforderung dient, gemäß einer Ausführungsform an einen Switch gesendet werden kann;
9 veranschaulicht ein beispielhaftes QRsv-Anforderungs-TLV, das durch einen Switch in einem LLDP-Datenrahmen, der als QRsv-Antwort auf eine QRsv-Anforderung dient, gemäß einer Ausführungsform an einen Host gesendet werden kann;
10 stellt ein beispielhaftes QRsv-Anforderungs-TLV dar, das durch einen Switch in einem LLDP-Datenrahmen an einen weiteren Switch weitergeleitet werden kann, um das Erstellen einer durchgängigen QRsv für einen Datenfluss einer Quellstation gemäß einer Ausführungsform anzufordern; und
11 ist ein Zeit-Weg-Schaubild, das ein Beispiel für ein Erstellen und Verwenden eines QRsv auf der Schicht 2 gemäß einer Ausführungsform darstellt.
Ausführliche Beschreibung der bevorzugten Ausführungsform
Hierin werden Techniken zum Reservieren einer Eingangswarteschlangenkapazität bei einem Netzwerk-Switch auf der Schicht 2 offenbart. Eine Verwendung solcher Reservierungen stellt eine verbesserte Zuverlässigkeit eines Datenaustauschs ohne den großen Mehraufwand bei der Verarbeitung bereit, der mit Reservierungsprotokollen höherer Schichten wie zum Beispiel RSVP verbunden ist.
Unter Bezugnahme auf die Figuren und unter besonderer Bezugnahme auf 1 wird nun ein Übersichts-Blockschaubild einer beispielhaften Datenverarbeitungsumgebung 100 gemäß einer Ausführungsform veranschaulicht. Wie dargestellt, beinhaltet die Datenverarbeitungsumgebung 100 eine Sammlung von Ressourcen 102. Die Ressourcen 102, die verschiedene Hosts, Clients, Switches, Router, Speicher usw. beinhalten können, sind zum Datenaustausch miteinander verbunden und können physisch oder virtuell in einem oder mehreren öffentlichen, privaten, Gemeinschafts- oder Cloud-Netzwerken oder einer Kombination davon gruppiert sein (nicht dargestellt). Auf diese Weise kann die Datenverarbeitungsumgebung 100 Infrastruktur, Plattformen, Software und/oder Dienste bieten, die für verschiedene Client-Einheiten 110 wie etwa Personal(z. B. Desktop-, Laptop-, Netbook-, Tablet- oder Handheld-)Computer 110a, Smartphones 110b, Server-Computersysteme 110c und Unterhaltungselektronik wie etwa Medienabspielgeräte (z. B. Set-Top-Boxen, DVD-(digital versatile disk)Spieler oder digitale Videorecorder (DVRs)) 110d zugänglich sind. Es versteht sich, dass die in 1 dargestellten Typen von Client-Einheiten 110 lediglich zur Veranschaulichung dienen und dass es sich bei den Client-Einheiten 110 um einen beliebigen Typ einer elektronischen Einheit handeln kann, der in der Lage ist, Daten mit einem Paketnetzwerk auszutauschen und über dieses auf die Ressourcen 102 zuzugreifen.
Es wird nun auf 2 Bezug genommen, in der ein Übersichtsschaubild eines beispielhaften Datenverarbeitungssystems 200 veranschaulicht wird, das zum Implementieren eines physischen Host aus den Ressourcen 102 oder einer Client-Einheit 110 von 1 verwendet werden kann. Bei der veranschaulichten beispielhaften Ausführungsform beinhaltet das Datenverarbeitungssystem 200 eine oder mehrere Netzwerkschnittstellen 204, die dem Datenverarbeitungssystem 200 ermöglichen, Daten mit einer oder mehreren Rechen-Ressourcen 102 über eine Verkabelung und/oder ein oder mehrere drahtgebundene oder drahtlose, öffentliche oder private, lokale oder Weitverkehrs-Netzwerke (darunter das Internet) auszutauschen. Das Datenverarbeitungssystem 200 beinhaltet zusätzlich einen oder mehrere Prozessoren 202 (die üblicherweise eine oder mehrere integrierte Schaltungen aufweisen), die Daten und Programmcode verarbeiten, beispielsweise um Daten oder Software in der Datenverarbeitungsumgebung 100 zu verwalten, darauf zuzugreifen oder zu bearbeiten. Das Datenverarbeitungssystem 200 beinhaltet außerdem Eingabe/Ausgabe-(E/A-)Einheiten 206 wie zum Beispiel Anschlüsse, Bildschirme, Benutzereingabeeinheiten und angeschlossene Einheiten usw., die Eingaben empfangen und Ausgaben der Verarbeitung bereitstellen, die durch das Datenverarbeitungssystem 200 und/oder eine oder mehrere sonstige Ressourcen in der Datenverarbeitungsumgebung 100 durchgeführt werden. Schließlich beinhaltet das Datenverarbeitungssystem 200 einen Datenspeicher 210, der eine oder mehrere flüchtige oder nichtflüchtige Speichereinheiten beinhalten kann, zu denen Speicher, Halbleiter-Datenträger, optische oder Magnetplattenlaufwerke, Bandlaufwerke usw. zählen. Der Datenspeicher 210 kann zum Beispiel Programmcode (der Software, Firmware oder eine Kombination davon aufweist) speichern, der bei Ausführen durch den/die Prozessor(en) 202 das Datenverarbeitungssystem 200 veranlasst, zumindest einige der hierin beschriebenen Funktionen zu implementieren.
Es wird nun auf 3 Bezug genommen, in der ein Übersichts-Blockschaubild eines Abschnitts einer Datenverarbeitungsumgebung 300 veranschaulicht wird, die einen physischen Host 310 aufweist, der Virtualisierung gemäß einer Ausführungsform einsetzt. Beispielsweise kann die Datenverarbeitungsumgebung 300 einen Abschnitt der Datenverarbeitungsumgebung 100 von 1 implementieren, und der physische Host 310 kann eine der Ressourcen 102 oder eine Client-Einheit 110 implementieren.
Bei der dargestellten Ausführungsform beinhaltet die Datenverarbeitungsumgebung 300 ein Netzwerk 302, das ein oder mehrere drahtgebundene oder drahtlose lokale Netzwerke (local area networks, LANs) oder Weitverkehrs-Netzwerke (wide area networks, WANs) wie zum Beispiel das Internet beinhalten kann. Mit dem Netzwerk 302 ist ein Zugangs-Switch 304 verbunden, der eine OSI-Schicht-2-Konnektivität mit dem Netzwerk 302 für einen oder mehrere physische Hosts bereitstellt, zu denen der physische Host 310 zählt, der durch eine physische Verbindung 306 mit dem Zugangs-Switch 304 verbunden ist. Wie ersichtlich ist, weist die physische Verbindung 306 eine begrenzte verfügbare Bandbreite auf, die im Allgemeinen durch den Zugangs-Switch 304 und den physischen Host 310 entweder auf der Grundlage ihrer Datenaustauschfähigkeiten oder durch protokollabhängige Aushandlung festgelegt wird.
Der physische Host 310 von 3 kann zum Beispiel unter Verwendung eines Datenverarbeitungssystems 200 implementiert werden, wie in 2 dargestellt. In dem dargestellten Beispiel beinhaltet/beinhalten die Netzwerk-Schnittstelle(n) 204 des physischen Host 310 zum Beispiel einen konvergierten Peripheral-Component-Interconnect-Express-(PCIe-)Netzwerkadapter (Converged Network Adapter, CNA) 312. Bei der dargestellten Ausführungsform beinhaltet der PCIe-CNA 312 eine virtuelle Ethernet-Bridge (VEB) 314, die mit der physischen Verbindung 306 verbunden ist, sowie auch eine Unterstützung für eine Vielzahl verschiedener OSI-Schicht-2-Netzwerke. Folglich beinhaltet der PCIe-CNA 312 in diesem Beispiel zumindest einen Fibre Channel Host Bus Adapter (FC HBA) 316 und eine Converged-Enhanced-Ethernet-(CEE-)Netzwerk-Schnittstellenkarte (Network Interface Card, NIC) 318.
Der physische Host 310 führt einen Virtual Machine Monitor (VMM) 330 aus, der die Ressourcen des physischen Host 310 virtualisiert und verwaltet. Der VMM 330 unterstützt die Ausführung einer oder mehrerer (und möglicherweise Tausender) VMs, zu denen in dem dargestellten Beispiel VMs 350a bis 350n zählen. Bei der dargestellten Ausführungsform weist jede der VMs 350 zumindest eine (und in einigen Fällen mehrere) virtuelle Netzwerk-Schnittstellen 352a bis 352e auf, die eine Netzwerkkonnektivität zumindest auf der Schicht 2 des OSI-Modells bereitstellen.
Wie dargestellt, stellt der VMM 330 ein oder mehrere (und bei der dargestellten Ausführungsform zumindest zwei) virtuelle Netzwerke bereit, mit denen sich seine VMs 350 verbinden können. Beispielsweise stellt der VMM 330 bei der dargestellten Ausführungsform ein erstes virtuelles Schicht-2-Netzwerk durch die Implementierung eines virtuellen Switch (VS) 332 bereit, der eine VEB 334 aufweist. Der VMM 330 stellt in ähnlicher Weise ein zweites virtuelles Netzwerk durch die Implementierung einer FC N_Port Identifier Virtualization (FC NPIV) 336 bereit. Bei verschiedenen Ausführungsformen kann es sich bei jedem der virtuellen Netzwerke, die durch den VMM 330 unterstützt werden, zum Beispiel um ein privates Netzwerk eines bestimmten Teilnehmers, ein übergreifendes privates Netzwerk, das von mehreren Teilnehmern gemeinsam genutzt wird, oder ein öffentliches Netzwerk handeln.
Bei dem dargestellten Beispiel ist die Netzwerk-Schnittstelle 352a der VM 350a über die VEB 334 mit dem ersten virtuellen Netzwerk verbunden, und die Netzwerk-Schnittstelle 352b der VM 350a ist über die FC NPIV 336 mit dem zweiten virtuellen Netzwerk verbunden. In ähnlicher Weise ist die Netzwerk-Schnittstelle 352c der VM 350n über die VEB 334 mit dem ersten virtuellen Netzwerk verbunden, und die Netzwerk-Schnittstelle 352e der VM 350n ist über die FC NPIV 336 mit dem zweiten virtuellen Netzwerk verbunden. Die VM 350n beinhaltet eine zusätzliche Netzwerk-Schnittstelle 352d, die die virtuellen Netzwerke umgeht, die durch den VMM 330 (und den begleitenden Header) unterstützt werden, und ist über den VMM 330 direkt mit einem Stapel 320 verbunden, der als „virtuelle Funktion” der CEE NIC 318 bereitgestellt wird. Wie des Weiteren in 3 dargestellt, ist die FC NPIV 336 mit dem FC HBA 316 des PCIe CNA 312 verbunden, und die VEB 334 des VS 332 ist mit der CEE NIC 318 verbunden. Der Datenverkehr des FC HBA 316 und der CEE NIC 318 läuft bei der VEB 314 des PCIe CNA 312 zusammen.
Wie im Folgenden weiter erörtert, arbeiten der physische Host 310 und Netzwerk-Switches wie zum Beispiel der Zugangs-Switch 304 zusammen, um die Zuverlässigkeit eines Datenaustauschs durch Reservieren von Bandbreite zumindest des Zugangs-Switch 304 auf der Schicht 2 zu verbessern.
Es wird nun auf 4 Bezug genommen, in der ein Übersichtsschaubild einer beispielhaften Ausführungsform eines Schicht-2-Netzwerk-Switch 400 wie zum Beispiel des Zugangs-Switch 304 von 3 dargestellt wird. Ein virtueller Switch wie zum Beispiel der VS 332 kann auch in ähnlicher Weise strukturiert sein, wobei die dargestellten Anschlüsse und Warteschlangenstrukturen in dem Datenspeicher eines Host statt in einem physischen Netzwerk-Switch implementiert sind.
Wie dargestellt, beinhaltet der Netzwerk-Switch 400 eine Vielzahl von Anschlüssen 402a bis 402m. Jeder Anschluss 402 beinhaltet jeweils einen von einer Vielzahl von Empfangs-(receive, Rx-)Schnittstellen 404a bis 404m und jeweils eine von einer Vielzahl von Eingangswarteschlangen 406a bis 406m, die Datenrahmen zwischenspeichert, die durch die zugehörige Rx-Schnittstelle 404 empfangen wurden. Jeder der Anschlüsse 402a bis 402m beinhaltet des Weiteren jeweils eine von einer Vielzahl von Ausgangswarteschlangen 414a bis 414m und jeweils eine von einer Vielzahl von Übertragungs-(transmit, Tx-)Schnittstellen 420a bis 420m, die Datenrahmen von einer zugehörigen Ausgangswarteschlange 414 übertragen.
Der Netzwerk-Switch 400 beinhaltet einen Koordinatenschalter 410, der Datenrahmen intelligent von einer beliebigen der Eingangswarteschlangen 406a bis 406m unter Steuerung durch eine Switch-Steuereinheit 430 zu einer beliebigen der Ausgangswarteschlangen 414a bis 414m umschaltet. Um Datenrahmen intelligent umzuschalten, erfährt die Switch-Steuereinheit 430 von beobachteten Datenrahmen eine Zugehörigkeit von Anschlüssen und Ziel-MAC-Adressen, die durch die Datenrahmen angegeben wird, zeichnet die erfahrenen Zugehörigkeiten von Ziel-MAC-Adressen und Anschlüssen 402 in Einträgen einer Weiterleitungstabelle 432 auf und steuert dann den Koordinatenschalter 410 so, dass er Datenrahmen entsprechend den Zugehörigkeiten umschaltet, die in der Weiterleitungstabelle 432 aufgezeichnet worden sind. Die Switch-Steuereinheit 430 kann außerdem ein Richtlinienmodul 434 beinhalten, das eine gewünschte Richtlinienverwaltung und eine Durchsetzung für Datenrahmen implementiert, die vorgegebene Kriterien erfüllen.
Wie zuvor erörtert, werden, wenn die Eingangsrate von Datenrahmen bei einer bestimmten Rx-Schnittstelle 404 des Netzwerk-Switch 400 die Kapazität der zugehörigen Eingangswarteschlange 406 zum Zwischenspeichern der eingehenden Datenrahmen überschreitet, die überschüssigen Datenrahmen im Hintergrund verworfen. Ein Überlauf an den Eingangswarteschlangen 406 ist besonders in virtualisierten Umgebungen problematisch, beispielsweise in der Verarbeitungsumgebung 300 von 3, in der mehrere (und möglicherweise zahlreiche) VMs 350 unabhängig und gleichzeitig Daten an denselben Anschluss 402 eines Netzwerk-Switch 400 übertragen können.
Um den Überlauf der Eingangswarteschlangen 406 zu verringern und dadurch die Zuverlässigkeit des Datenaustauschs zu verbessern, unterstützt der Netzwerk-Switch 400 bevorzugt eine Reservierung von Kapazität bei den Eingangswarteschlangen 406 für bestimmte Datenflüsse. Wie im Folgenden weiter unter Bezugnahme auf die 5 bis 6 beschrieben, unterstützt die Switch-Steuereinheit 430 insbesondere die Fähigkeit einer Quellstation (z. B. eines Netzwerkadapters (z. B. des PCIe CNA 312 von 3), eines Treibers für einen Netzwerkadapter, eines Steuerprogramms (z. B. eines Betriebssystems oder des VMM 330), einer virtuellen Maschine (z. B. einer VM 350) oder eines Anwendungsprogramms), die Reservierung von Kapazität bei einer Eingangswarteschlange 406 eines oder mehrerer Netzwerk-Switches 400, die zwischen der Quellstation und einer Zielstation angeordnet sind, für einen ihrer Datenflüsse anzufordern. Anschließend genehmigt die Switch-Steuereinheit 430 des/der Netzwerk-Switch(es) 400 die Reservierungsanforderung oder weist sie zurück, beispielsweise auf der Grundlage eines oder mehrerer Faktoren wie etwa der Anzahl von Datenflüssen, des Umfangs der bereits reservierten Eingangswarteschlangenkapazität, und durch Richtlinienaspekte, die durch das Richtlinienmodul 434 angegeben werden. Wenn sie genehmigt wird, zeichnet die Switch-Steuereinheit 430 die Reservierung in einer Reservierungsdatenstruktur auf, zum Beispiel in einem Eintrag 442 einer Reservierungstabelle 440. Wie angegeben, kann bei einer Ausführungsform jeder Eintrag 442 der Reservierungstabelle 440 zum Beispiel ein Anschluss-ID-(port ID, PID-)Feld 444, das den Anschluss 402 kennzeichnet, an dem Bandbreite reserviert wird, ein Reservierungs-(Rsv-)ID-Feld 446, das zum Beispiel durch eine Quell-MAC-Adresse und/oder eine Fluss-ID die Datenrahmen kennzeichnet, für die Eingangswarteschlangenkapazität reserviert werden soll, und ein Reservierungs-(Rsv-)Größenfeld 448 beinhalten, das einen Umfang der Eingangswarteschlangenkapazität (z. B. ausgedrückt als Anzahl von Eingangswarteschlangeneinträgen, als Anteil der Eingangswarteschlangenkapazität und/oder als Gesamtvolumen an Daten) angibt, der für Datenrahmen des Datenflusses reserviert ist, der der Reservierungs-ID zugehörig ist. Auf diese Weise werden Rahmen eines Datenflusses, die über reservierte Eingangswarteschlangenkapazität bei einem Netzwerk-Switch 400 verfügen, bei einer Überlaufbedingung der Eingangswarteschlange nicht verworfen, sofern die Datenübertragungsgeschwindigkeit des Datenflusses geringer als oder gleich wie die reservierte Kapazität ist. Stattdessen werden Datenrahmen sonstiger Datenflüsse verworfen, die entweder nicht über eine Reservierung von Eingangswarteschlangenkapazität verfügen oder ihre reservierten Eingangswarteschlangenkapazitäten überschreiten.
Es wird nun auf 5 Bezug genommen, in der ein Übersichtsplan eines logischen Ablaufs eines beispielhaften Prozesses veranschaulicht wird, durch den ein Host wie zum Beispiel der physische Host 310 von 3 eine Eingangswarteschlangenkapazität eines Switch wie zum Beispiel des Netzwerk-Switch 400 von 4 gemäß einer Ausführungsform reserviert. Der veranschaulichte Prozess kann zum Beispiel durch eine Quellstation wie etwa einen Netzwerkadapter (z. B. PCIe CNA 312 von 3), einen Treiber für einen Netzwerkadapter, ein Steuerprogramm (z. B. ein Betriebssystem oder den VMM 330), eine virtuelle Maschine (z. B. eine VM 350) oder ein Anwendungsprogramm durchgeführt werden. Allgemein gilt, dass alle solchen Ausführungsformen den Betrieb des „Host” betreffen, auf dem sich die Quellstation befindet.
Der Prozess von 5 beginnt bei Block 500 und geht dann zu Block 502 über, der veranschaulicht, wie ein Host ermittelt, ob er eine Reservierung von Eingangswarteschlangenkapazität (im Folgenden als QRsv bezeichnet) für einen Datenfluss des Host anfordern soll. Der Host kann die in Block 502 dargestellte Ermittlung zum Beispiel auf der Grundlage einer erwarteten Bandbreite des Datenflusses, des Typs von Daten, der Toleranz des Datenflusses gegenüber Rahmenverlust und/oder der Anzahl sonstiger Datenflüsse, die dieselbe Eingangswarteschlange nutzen, usw. durchführen. In Reaktion auf eine Entscheidung bei Block 502, keine QRsv für den Datenfluss anzufordern, endet der Prozess bei Block 504. Dementsprechend überträgt der Host den Datenfluss an die Zielstation des Datenflusses ohne den Vorteil einer Eingangswarteschlangenreservierung an einem der Switches in dem Datenpfad zwischen dem Host und der Zielstation mit dem damit verbundenen Risiko eines Datenrahmenverlusts aufgrund eines Überlaufs der Eingangswarteschlange.
Zu Block 502 zurückkehrend, geht der Prozess in Reaktion darauf, dass der Host entscheidet, eine QRsv für den Datenfluss anzufordern, von Block 502 zu Block 510 über. Block 510 stellt dar, wie der Host eine QRsv-Anforderung für einen Datenfluss an einen Netzwerk-Switch in dem Datenpfad zwischen dem Host und einer Zielstation sendet. Die QRsv-Anforderung kennzeichnet den Datenfluss bevorzugt mit einer Rsv-ID. Wenn der Datenfluss, der der QRsv-Anforderung zugehörig ist, sämtliche Daten aufweist, die durch eine bestimmte Quellstation übertragen werden, kann es sich bei der Rsv-ID einfach um die Quell-MAC-Adresse der Quellstation handeln. Wenn die QRsv-Anforderung demgegenüber nur einen von möglicherweise mehreren Datenflüssen einer bestimmten Quellstation betrifft, kann die Rsv-ID die Quell-MAC-Adresse der Quellstation wie auch eine zusätzliche Fluss-ID aufweisen. In jedem Fall gibt die QRsv-Anforderung bevorzugt einen Umfang der Eingangswarteschlangenkapazität an, die für den Datenfluss reserviert werden soll, und sie kann des Weiteren ein Gesamtvolumen (oder eine Gesamtmenge) von Daten angeben, das/die im Rahmen der QRsv übertragen werden soll. Wie im Folgenden weiter erörtert, wird bei einer bevorzugten Ausführungsform die QRsv-Anforderung mithilfe eines Schicht-2-Protokolls wie zum Beispiel des durch die Spezifikation IEEE 802.1AB definierte Link Layer Discovery Protocol (LLDP) übermittelt, das durch Bezugnahme hierin eingeschlossen wird. Wie des Weiteren bei Block 510 angegeben, kann der Host zusätzlich einen Anforderungszeitgeber starten, der ein Fenster definiert, in dem die QRsv-Anforderung genehmigt oder zurückgewiesen werden muss.
Im Anschluss an Block 510 wartet der Host, wie in Block 512 dargestellt, bis eine QRsv-Antwort durch den Host empfangen wird, die die Anforderung genehmigt oder zurückweist, oder bis der Anforderungszeitgeber abläuft. Anschließend ermittelt der Host bei Block 514, ob die angeforderte QRsv innerhalb des durch den Anforderungszeitgeber definierten Fensters genehmigt wurde. Wenn dies nicht der Fall ist, kehrt der Prozess zu Block 502 zurück, der bereits beschrieben worden ist.
Falls der Host jedoch bei Block 514 feststellt, dass die QRsv-Anforderung genehmigt wurde, geht der Prozess zu Block 520 über, der darstellt, wie der Host seine QRsv lokal aufzeichnet (z. B. in einem Tabelleneintrag ähnlich dem Reservierungstabelleneintrag 442 von 4). Zusätzlich kann der Host optional einen Ablaufzeitgeber starten, der eine Dauer der QRsv überwacht, wobei der anfängliche Wert des Ablaufzeitgebers zum Beispiel durch eine Standard-QRsv-Dauer oder auf der Grundlage eines Zeitgeberwerts festgelegt werden kann, der durch die QRsv-Antwort bestimmt wird. An dieser Stelle wird garantiert, dass die Datenrahmen des Datenflusses, die durch den Host über den/die Switch(es) übertragen werden, bei dem/denen Eingangswarteschlangenkapazität reserviert wird, nicht in Reaktion auf eine Überlaufbedingung der Eingangswarteschlange verworfen werden.
Wie bei Block 522 angegeben, kann der Host während der Übertragung der Datenrahmen, die den Datenfluss aufweisen, durch Neuverhandlung mit einem oder mehreren Netzwerk-Switches in dem Datenpfad zwischen den Quell- und Zielstationen optional seine QRsv vergrößern oder verkleinern. Der Host kann die durch die QRsv reservierte Bandbreite zum Beispiel zumindest teilweise auf der Grundlage der tatsächlichen Datenübertragungsgeschwindigkeit des Datenflusses anpassen. Bei Block 524 ermittelt der Host, ob der Ablaufzeitgeber für die QRsv abgelaufen ist oder ob ein zulässiges Gesamtvolumen von Daten, die im Rahmen der QRsv übertragen werden, ausgeschöpft ist. Wenn dies nicht der Fall ist, kehrt der Prozess zu dem optionalen Block 522 zurück, der bereits beschrieben worden ist. Falls der Host dagegen bei Block 524 feststellt, dass die QRsv abgelaufen ist oder ausgeschöpft worden ist, kehrt der Prozess zu dem zuvor beschriebenen Block 502 zurück, der angibt, dass der Host gegebenenfalls eine Erneuerung der QRsv für den Datenfluss anfordern kann.
Es wird nun auf 6 Bezug genommen, in der ein Übersichtsplan eines logischen Ablaufs eines beispielhaften Prozesses dargestellt wird, durch den ein physischer Netzwerk-Switch wie zum Beispiel der Netzwerk-Switch 400 von 4 oder ein virtueller Switch Eingangswarteschlangenkapazität für den Datenfluss einer Quellstation gemäß einer Ausführungsform reserviert. Bei einer Ausführungsform ist der dargestellte Prozess in Hardware wie zum Beispiel der Switch-Steuereinheit 430 implementiert, die den Prozess in einer integrierten Schaltung mit oder ohne Ausführung von Software und/oder Firmware implementieren kann.
Wie dargestellt, beginnt der Prozess bei Block 600 und geht dann zu Block 602 über, der darstellt, wie der Switch eine Schicht-2-QRsv-Anforderung von einem Host empfängt, mit dem ein Anschluss des Switch durch eine Netzwerkverbindung verbunden ist. Wie oben angegeben, kennzeichnet die QRsv-Anforderung bevorzugt den Datenfluss mit einer Rsv-ID wie zum Beispiel einer Quell-MAC-Station und/oder einer Fluss-ID und gibt zusätzlich einen Umfang der Eingangswarteschlangenkapazität an, die für den Datenfluss reserviert werden soll, und kann des Weiteren ein Volumen von Daten angeben, die im Rahmen der QRsv übertragen werden sollen.
In Reaktion auf ein Empfangen der QRsv-Anforderung an Block 602 ermittelt der Switch bei Block 604, ob die QRsv-Anforderung genehmigt werden soll, beispielsweise auf der Grundlage der verfügbaren Gesamtbandbreite der entsprechenden Eingangswarteschlange 406, des Umfangs (der Datenübertragungsgeschwindigkeit und/oder des Volumens) der angeforderten QRsv, gegebenenfalls der übrigen QRsvs, die aktuell für die entsprechende Eingangswarteschlange 406 aktiv sind, und/oder der Anzahl sonstiger Datenflüsse an demselben Anschluss 402. In Reaktion auf eine Entscheidung bei Block 604, die QRsv-Anforderung zurückzuweisen, kann der Switch optional eine QRsv-Antwort senden, die die QRsv-Anforderung ausdrücklich zurückweist, oder er kann die QRsv-Anforderung einfach im Hintergrund verwerfen und auf diese Weise dem Anforderungszeitgeber des anfordernden Host ermöglichen, das Zeitlimit zu überschreiten, wie zuvor unter Bezugnahme auf die Blöcke 512 bis 514 von 5 beschrieben. In jedem Fall kehrt der Prozess von 6 von Block 604 zu Block 602 zurück, der bereits beschrieben worden ist.
Falls der Switch jedoch bei Block 604 feststellt, dass die QRsv des Host genehmigt werden kann und sollte, zeichnet der Switch die QRsv zum Beispiel in einem Reservierungstabelleneintrag 442 der Reservierungstabelle 440 auf. Zusätzlich kann der Switch einen Ablaufzeitgeber starten, der die Dauer der QRsv definiert, wie zuvor unter Bezugnahme auf Block 520 von 5 beschrieben worden ist. Bei Ausführungsformen, bei denen einem Host gestattet wird, eine QRsv für seinen Datenfluss lediglich in dem Switch zu erstellen, der der Quellstation am nächsten ist, oder er dies anfordert, geht der Prozess von Block 610 zu Block 620 über, der im Folgenden beschrieben wird. Bei sonstigen Ausführungsformen, bei denen einem Host gestattet wird, eine QRsv für seinen Datenfluss in mehr als einem Switch in dem Datenpfad zwischen den Quell- und Zielstationen zu erstellen, oder er dies anfordert, geht der Prozess zu Block 612 über.
Block 612 stellt dar, wie der Switch ermittelt, ob es sich bei dem Switch um die letzte Zwischenstation in dem Datenpfad zwischen den Quell- und Zielstationen handelt, das heißt, er ermittelt, ob die Zielstation durch eine Datenverbindung ohne dazwischenliegende Switches mit einem Anschluss des Switch verbunden ist. In dem Fall geht der Prozess zu Block 620 über, der im Folgenden beschrieben wird. Anderenfalls geht der Prozess zu Block 614 über, der veranschaulicht, wie der Switch die Quell-MAC-Adresse der QRsv-Anforderung auf die des Switch aktualisiert und die QRsv-Anforderung an den nächsten Switch in dem Datenpfad zu der Zielstation des Datenflusses weiterleitet, wo die QRsv-Anforderung ebenfalls verarbeitet wird, wie in 6 dargestellt. Anschließend geht der Prozess von Block 614 zu Block 620 über.
Block 620 stellt dar, wie der Switch eine QRsv-Bestätigung, die die Genehmigung der angeforderten QRsv bestätigt, an die anfordernde Station sendet, von der die QRsv-Anforderung empfangen worden war. Die QRsv-Bestätigung gibt bevorzugt eine Datenübertragungsgeschwindigkeit, die für den Datenfluss reserviert worden ist, ein zulässiges Gesamtvolumen von Daten, die im Rahmen der QRsv übertragen werden dürfen, und/oder eine Dauer der Reservierung an. Wie bei Block 622 angegeben, kann der Switch während der Übertragung der Datenrahmen, die den Datenfluss aufweisen, die QRsv für den Datenfluss durch Neuverhandlung mit der Quellstation optional vergrößern oder verkleinern. Der Switch kann die durch die QRsv reservierte Bandbreite zum Beispiel zumindest teilweise auf der Grundlage der tatsächlichen Datenübertragungsgeschwindigkeit des Datenflusses, der durch sonstige Datenflüsse reservierten Bandbreite und/oder von QRsv-Anforderungen anpassen, die aufgrund mangelnder Kapazität durch den Switch zurückgewiesen worden sind. Bei Block 624 ermittelt der Switch, ob der Ablaufzeitgeber für die QRsv abgelaufen ist oder ob ein zulässiges Gesamtvolumen von Daten, die im Rahmen der QRsv übertragen werden, ausgeschöpft ist. Wenn dies nicht der Fall ist, kehrt der Prozess zu dem optionalen Block 622 zurück, der bereits beschrieben worden ist. Falls der Host jedoch bei Block 624 feststellt, dass die QRsv abgelaufen ist oder ausgeschöpft worden ist, entfernt der Switch den Reservierungstabelleneintrag 442 für die QRsv aus der Reservierungstabelle 430 (Block 626), und der Prozess kehrt zu dem zuvor beschriebenen Block 602 zurück, der angibt, dass der Switch gegebenenfalls eine QRsv für den Datenfluss erneuern kann.
Es wird nun auf 7 Bezug genommen, in der ein LLDP-Rahmen (auch als LLDP-Dateneinheit (LLDP data unit, LLDPDU) bezeichnet) 700 dargestellt wird, wie er durch die IEEE 802.1AB definiert wird, der dazu verwendet werden kann, einen Schicht-2-QRsv-Datenaustausch zwischen einem Host und einem Switch und zwischen Switches gemäß einer Ausführungsform zu implementieren. Bei der dargestellten Ausführungsform beinhaltet der LLDP-Rahmen 700 ein Präambelfeld 700, auf das ein Ziel-MAC-Adressfeld 702 folgt. In Fällen, in denen ein Host eine QRsv lediglich an dem Switch anfordert, der der Quellstation am nächsten ist, (entweder absichtlich oder aufgrund von Implementierungsbeschränkungen) gibt das Ziel-MAC-Adressfeld 702 bevorzugt die Standardadresse der nächstgelegenen Bridge (d. h. 01:80:C2:00:00:0E) an. In anderen Fällen, in denen der Host ein Erstellen einer QRsv bei sämtlichen Switches in dem Datenpfad zwischen den Quell- und Zielstationen anfordert, gibt das Ziel-MAC-Adressfeld 702 bevorzugt die Ziel-MAC-Adresse der Zielstation an, an die der Datenfluss gesendet werden soll.
Der LLDP-Rahmen 700 beinhaltet zusätzlich ein Quell-MAC-Adressfeld 704, das die MAC-Adresse der Quellstation angibt, ein Ethernet-Typfeld 704, das den Ethernet-Typ (d. h. 0x88CC) enthält, der dem LLDP zugewiesen ist, und die drei (im Rahmen des LLDP) obligatorischen Felder Chassis-ID, Anschluss-ID und Gültigkeitsdauer (Time-to-Life, TTL) Type, Length, Value (TLV) 706, 708 bzw. 710. Im Anschluss an die durch das LLDP vorgegebenen TLVs gibt ein optionales TLV-Feld 712 ein auf die QRsv bezogenes TLV an, das dazu verwendet wird, eine QRsv anzufordern oder zu genehmigen/zurückzuweisen, wie im Folgenden ausführlicher unter Bezugnahme auf die 8 bis 10 beschrieben wird.
Es wird nun auf 8 Bezug genommen, in der ein beispielhaftes QRsv-Anforderungs-TLV 800 dargestellt wird, das durch einen Host in einem LLDP-Datenrahmen 700, der als QRsv-Anforderung dient, gemäß einer Ausführungsform an einen Switch gesendet werden kann. Das QRsv-Anforderungs-TLV 800 beinhaltet einen TLV-Header, der ein Typenfeld 800, das durch einen Wert von 127 angibt, dass es sich bei dem QRsv-Anforderungs-TLV 800 um ein benutzerdefiniertes TLV handelt, und ein Längenfeld 802 aufweist, das eine Länge des QRsv-Anforderungs-TLV 800 in Oktett angibt. Bei dem dargestellten Beispiel gibt das Längenfeld 802 eine Länge von 14 Oktett an, falls der Switch sämtlichen Datenverkehr der Quellstation als einen einzigen einheitlichen Datenfluss betrachten soll, und es gibt eine Länge von 30 Oktett an, falls der Switch aufgefordert wird, Reservierungen für einen der mehreren Datenflüsse der Quellstation unabhängig zu verarbeiten.
Das QRsv-Anforderungs-TLV 800 beinhaltet darüber hinaus eine TLV-Datenzeichenfolge, die ein Feld 804 für eine organisatorisch eindeutige Kennung (organizationally unique identifier, OUI), das die Organisation, die das TLV veröffentlicht, eindeutig kennzeichnet, ein Feld 806 für einen organisatorisch definierten Untertyp, das einen organisatorisch definierten Untertyp des TLV angibt, und eine organisatorisch definierte Datenzeichenkette 808 aufweist. In dem dargestellten Beispiel des Felds 806 für den organisatorisch definierten Untertyp wird ein Untertyp 1 für eine QRsv-Anforderung für einen einzigen einheitlichen Datenfluss der Quellstation angegeben, der lediglich an den Switch gerichtet ist, der der Quellstation am nächsten ist, es wird ein Untertyp 3 für eine QRsv-Anforderung angegeben, die eine durchgängige QRsv für einen einzigen einheitlichen Datenfluss der Quellstation an allen Switches in dem Datenpfad zwischen den Quell- und Zielstationen anfordert, es wird ein Untertyp 11 für eine QRsv-Anforderung für einen von mehreren Datenflüssen der Quellstation lediglich an dem Switch, der der Quellstation am nächsten ist, angegeben, und es wird ein Untertyp 13 für eine QRsv-Anforderung angegeben, die eine durchgängige QRsv für einen von mehreren Datenflüssen der Quellstation an allen Switches in dem Datenpfad zwischen den Quell- und Zielstationen anfordert. Des Weiteren gibt die organisatorisch definierte Datenzeichenkette 808 in dem dargestellten Beispiel an, dass es sich bei dem LLDP-Rahmen 700, der das QRsv-Anforderungs-TLV 800 enthält, um eine QRsv-Anforderung handelt, und gibt eine Anzahl von Bytes und Rahmen (d. h. das Datenverkehrsvolumen) an, für die eine QRsv angefordert wird. Falls ein Switch QRsvs für mehrere Datenflüsse der Quellstation getrennt verarbeiten soll, gibt die organisatorisch definierte Datenzeichenkette 808 darüber hinaus eindeutig an, für welchen der mehreren Datenflüsse der Quellstation die QRsv angefordert wird.
Es wird nun auf 9 Bezug genommen, in der ein beispielhaftes QRsv-Antwort-TLV 900 veranschaulicht wird, das durch einen Switch in einem LLDP-Datenrahmen 700, der als QRsv-Antwort dient, gemäß einer Ausführungsform an einen Host gesendet werden kann. In dem enthaltenden LLDP-Datenrahmen 700 geben Quell- und Ziel-MAC-Adressfelder 702 und 704 die MAC-Adresse des/der ursprünglichen Switch bzw. Quellstation an.
Das QRsv-Antwort-TLV 900 beinhaltet einen TLV-Header, der ein Typenfeld 900, das durch einen Wert von 127 angibt, dass es sich bei dem QRsv-Antwort-TLV 900 um ein benutzerdefiniertes TLV handelt, und ein Längenfeld 902 aufweist, das eine Länge des QRsv-Antwort-TLV 900 in Oktett angibt. In dem dargestellten Beispiel gibt das Längenfeld 902 eine Länge von 18 Oktett an, falls die QRsv-Antwort von dem Switch stammt, der der Quellstation am nächsten ist, und auf eine Anforderung einer QRsv für den einheitlichen Datenfluss der Quellstation antwortet, es gibt eine Länge von 14 Oktett an, falls die QRsv-Antwort von dem Switch am hinteren Ende stammt, der der Zielstation am nächsten ist, und auf eine Anforderung einer QRsv für den einheitlichen Datenfluss der Quellstation antwortet, es gibt eine Länge von 32 Oktett an, falls die QRsv-Antwort von dem Switch stammt, der der Quellstation am nächsten ist, und auf eine Anforderung einer QRsv für einen von mehreren Datenflüssen der Quellstation antwortet, und es gibt eine Länge von 34 Oktett an, falls die QRsv-Antwort von dem Switch am hinteren Ende stammt, der der Zielstation am nächsten ist, und auf eine Anforderung einer QRsv für einen von mehreren Datenflüssen der Quellstation antwortet.
Das QRsv-Anforderungs-TLV 900 beinhaltet darüber hinaus eine TLV-Datenzeichenfolge, die ein Feld 904 für eine organisatorisch eindeutige Kennung (OUI), das die Organisation, die das TLV veröffentlicht, eindeutig kennzeichnet, ein Feld 906 für einen organisatorisch definierten Untertyp, das einen organisatorisch definierten Untertyp des TLV angibt, und eine organisatorisch definierte Datenzeichenkette 908 aufweist. In dem dargestellten Beispiel des Felds 906 für den organisatorisch definierten Untertyp wird ein Untertyp 2 angegeben, falls die QRsv-Antwort von dem Switch stammt, der der Quellstation am nächsten ist, und auf eine Anforderung einer QRsv für den einheitlichen Datenfluss der Quellstation antwortet, es wird ein Untertyp 5 angegeben, falls die QRsv-Antwort von dem Switch am hinteren Ende stammt, der der Zielstation am nächsten ist, und auf eine Anforderung einer QRsv für den einheitlichen Datenfluss der Quellstation antwortet, es wird ein Untertyp 12 angegeben, falls die QRsv-Antwort von dem Switch stammt, der der Quellstation am nächsten ist, und auf eine Anforderung einer QRsv für einen von mehreren Datenflüssen der Quellstation antwortet, und es wird ein Untertyp 15 angegeben, falls die QRsv-Antwort von dem Switch am hinteren Ende stammt, der der Zielstation am nächsten ist, und auf eine Anforderung einer QRsv für einen von mehreren Datenflüssen der Quellstation antwortet.
In dem dargestellten Beispiel gibt die organisatorisch definierte Datenzeichenkette 908 an, dass es sich bei dem LLDP-Rahmen 700, der das QRsv-Antwort-TLV 900 enthält, um eine QRsv-Antwort handelt, und sie gibt eine Anzahl von Bytes und Rahmen (d. h. ein Datenverkehrsvolumen), für die eine QRsv genehmigt wird, sowie einen Wert des Ablaufzeitgebers für die QRsv an. Falls das QRsv-Antwort-TLV 900 eine Zurückweisung der angeforderten QRsv angeben soll, sind die Bytes und Rahmen, die durch die organisatorisch definierte Datenzeichenkette 908 angegeben werden, gleich null. Falls der Switch QRsvs für mehrere Datenflüsse der Quellstation getrennt verarbeiten soll, gibt die organisatorisch definierte Datenzeichenkette 808 darüber hinaus an, für welchen der mehreren Datenflüsse der Quellstation die QRsv genehmigt oder zurückgewiesen wird.
Es wird nun auf 10 Bezug genommen, in der ein beispielhaftes QRsv-Anforderungs-TLV 1000 dargestellt wird, das durch einen Switch in einem LLDP-Datenrahmen 700 an einen weiteren Switch weitergeleitet werden kann, um das Erstellen einer durchgängigen QRsv für einen Datenfluss einer Quellstation gemäß einer Ausführungsform anzufordern. Das QRsv-Anforderungs-TLV 1000 beinhaltet einen TLV-Header, der ein Typenfeld 1000, das durch einen Wert von 127 angibt, dass es sich bei dem QRsv-Anforderungs-TLV 1000 um ein benutzerdefiniertes TLV handelt, und ein Längenfeld 1002 aufweist, das eine Länge des QRsv-Anforderungs-TLV 1000 in Oktett angibt. In dem dargestellten Beispiel gibt das Längenfeld 802 eine Länge von 18 Oktett an, falls die Switches in dem Datenpfad zwischen den Quell- und Zielstationen sämtlichen Datenverkehr der Quellstation als einen einzigen einheitlichen Datenfluss betrachten sollen, und es gibt eine Länge von 34 Oktett an, falls die Switches in dem Datenpfad zwischen den Quell- und Zielstationen aufgefordert werden, Reservierungen für einen der mehreren Datenflüsse der Quellstation unabhängig zu verarbeiten.
Das QRsv-Anforderungs-TLV 1000 beinhaltet darüber hinaus eine TLV-Datenzeichenfolge, die ein Feld 1004 für eine organisatorisch eindeutige Kennung (OUI), das die Organisation, die das TLV veröffentlicht, eindeutig kennzeichnet, ein Feld 1006 für einen organisatorisch definierten Untertyp, das einen organisatorisch definierten Untertyp des TLV angibt, und eine organisatorisch definierte Datenzeichenkette 1008 aufweist. In dem dargestellten Beispiel für das Feld 1006 für einen organisatorisch definierten Untertyp wird ein Untertyp 4 für eine QRsv-Anforderung angegeben, die eine durchgängige QRsv für einen einzigen einheitlichen Datenfluss der Quellstation anfordert, und es wird ein Untertyp 14 für eine QRsv-Anforderung angegeben, die eine durchgängige QRsv für einen von mehreren Datenflüssen der Quellstation anfordert. In dem dargestellten Beispiel gibt die organisatorisch definierte Datenzeichenkette 1008 des Weiteren an, dass es sich bei dem LLDP-Rahmen 700, der das QRsv-Anforderungs-TLV 1000 enthält, um eine QRsv-Genehmigung handelt, und sie gibt eine Anzahl von Bytes und Rahmen (d. h. das Datenverkehrsvolumen), für die die QRsv angefordert wird, sowie eine Dauer an, während der die QRsv bereitgestellt wird. Falls das QRsv-Anforderungs-TLV 1000 eine Zurückweisung der angeforderten QRsv durch den weiterleitenden Switch oder einen vorangehenden Switch angeben soll, sind die Bytes und Rahmen, die durch die organisatorisch definierte Datenzeichenkette 1008 angegeben werden, gleich null. Falls der Switch QRsvs für mehrere Datenflüsse der Quellstation getrennt verarbeiten soll, gibt die organisatorisch definierte Datenzeichenkette 1008 darüber hinaus an, für welchen der mehreren Datenflüsse der Quellstation die QRsv genehmigt oder zurückgewiesen wird.
Es wird nun auf 11 Bezug genommen, in der ein Zeit-Weg-Schaubild veranschaulicht wird, das ein Beispiel für das Erstellen und Verwenden einer QRsv auf der Schicht 2 gemäß einer Ausführungsform darstellt. In dem dargestellten Beispiel beabsichtigt ein Host 1110, Datenrahmen über mehrere Schicht-2-Switches 1102 an eine Zielstation 1104 zu übertragen. Die Switches 1102a bis 1102n beinhalten zumindest einen Switch 1102a am näheren Ende, der der Quellstation/dem Host am nächsten ist, und einen Switch 1102n am hinteren Ende, der der Zielstation 1104 am nächsten ist.
Der Prozess beginnt damit, dass eine Quellstation (z. B. ein Netzwerkadapter, ein Treiber für einen Netzwerkadapter, ein Steuerprogramm wie zum Beispiel ein Betriebssystem oder ein VMM, eine virtuelle Maschine oder ein Anwendungsprogramm) an einem Host 1100 eine QRsv-Anforderung, beispielsweise ein LLDP 700, das ein QRsv-Anforderungs-TLV 800 aufweist, überträgt. Wie oben beschrieben, kann die QRsv-Anforderung 1110 lediglich eine QRsv an dem Switch 1102a, der dem Host 1100 am nächsten ist, oder eine durchgängige QRsv an sämtlichen Switches 1102a bis 1102n zwischen dem Host 1100 und der Zielstation 1104 anfordern.
Falls die QRsv-Anforderung 1110 eine QRsv lediglich an dem Switch 1102a anfordert, antwortet der Switch 1102a auf die QRsv-Anforderung 1110 mit einer QRsv-Antwort 1116 (z. B. mit einem LLDP 700 mit einer QRsv-Antwort 900), die die angeforderte QRsv entweder genehmigt oder zurückweist. Falls die QRsv-Anforderung 1110 demgegenüber eine durchgängige QRsv an sämtlichen Switches 1102a bis 1102n in dem Datenpfad zwischen dem Host 1100 und der Zielstation 1104 anfordert, wird eine QRsv-Anforderung 1112 (z. B. ein LLDP 700, das ein QRsv-Anforderungs-TLV 1000 aufweist) durch den Switch 1102a und die nachfolgenden Switches 1102 weitergeleitet, bis der Switch 1102n erreicht wird. In diesem Fall antwortet der Switch 1102n auf die QRsv-Anforderung 1112 mit einer QRsv-Antwort 1114 (z. B. mit einem LLDP 700, das ein entsprechend konfiguriertes QRsv-Antwort-TLV 900 aufweist), die durch die Switches 1102n bis 1102a weitergeleitet und dem Host 1100 als QRsv-Antwort 1116 zugestellt wird.
Anschließend überträgt der Host 1100 die Datenrahmen 1118 eines Datenflusses an die Zielstation 1104 über die Switches 1102a bis 1102n. In der Annahme, dass die QRsv-Anforderung genehmigt wurde, stellt zumindest der Switch 1102a (und in einigen Fällen sämtliche Switches 1102a bis 1102n) Datenrahmen innerhalb des Datenflusses bis zu den Parametern für die Datenübertragungsgeschwindigkeit, die Datenmenge und die Dauer, die in der QRsv vereinbart worden sind, einen garantierten Dienst bereit. Falls es zum Beispiel bei dem Switch 1102a zu einer Überlaufbedingung der Eingangswarteschlange an dem Anschluss kommt, an dem für den Host 1100 eine Reservierung besteht, während die Reservierung aktiv ist, behält der Switch 1102a auf diese Weise die Datenrahmen 1118 bei und verwirft sonstige Rahmen, um der Reservierung des Host 1100 gerecht zu werden. Nachdem die QRsv ausgeschöpft oder abgelaufen ist, kann der Host 1100 erneut eine QRsv für den Datenfluss anfordern, wie durch eine QRsv-Anforderung 1124 angegeben.
Wie beschrieben worden ist, erstellt bei einigen Ausführungsformen ein Netzwerk-Switch in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation eine Reservierung für eine Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation. In Reaktion auf eine Warteschlangen-Überlaufbedingung an der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, behält der Netzwerk-Switch Datenrahmen in dem Datenfluss der Quellstation bei, die in Übereinstimmung mit der Reservierung übertragen werden, und verwirft sonstige Datenrahmen, sodass der Quellstation trotz einer Überlaufbedingung der Eingangswarteschlange eine garantierte Weiterleitung ihres Datenflusses durch den Netzwerk-Switch zugutekommt. Bei verschiedenen Ausführungsformen kann es sich bei der Reservierung um eine von einer Vielzahl von Reservierungen handeln, die die Quellstation für eine Vielzahl von Datenflüssen erstellt. Des Weiteren kann die Reservierung an jedem von einer Vielzahl von Switches in dem Datenpfad zwischen den Quell- und Zielstationen angefordert und erstellt werden.
Die vorliegende Erfindung ist zwar so, wie sie unter Bezugnahme auf eine oder mehrere bevorzugte Ausführungsformen beschrieben worden ist, besonders dargestellt worden, es versteht sich jedoch für Fachleute, dass verschiedene Änderungen in der Form und den Einzelheiten darin vorgenommen werden können, ohne vom Gedanken und Umfang der Erfindung abzuweichen. Wenngleich Aspekte im Hinblick auf Hosts und Netzwerk-Switches beschrieben worden sind, die Programmcode (z. B. Software, Firmware oder eine Kombination davon) ausführen, der die hierin beschriebenen Funktionen steuert, versteht es sich zum Beispiel, dass Ausführungsformen alternativ als Programmprodukt implementiert werden können, das ein physisches maschinenlesbares Speichermedium oder ein Speichermedium (z. B. ein optisches Speichermedium, ein Hauptspeichermedium, ein Plattenspeichermedium usw.) aufweist, das Programmcode speichert, der durch eine Maschine ausgeführt werden kann, um die Maschine zu veranlassen, eine oder mehrere der beschriebenen Funktionen durchzuführen. Wenngleich die vorliegende Erfindung unter Bezugnahme auf die Reservierung von Eingangswarteschlangenkapazität auf der Schicht 2 bei einem physischen Netzwerk-Switch beschrieben worden ist, ist des Weiteren zu beachten, dass die veranschaulichten Prozesse gleichermaßen auf die Reservierung von Eingangswarteschlangenkapazität bei einem virtuellen Switch wie zum Beispiel dem VS 332 von 3 angewendet werden kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

RFC 2205 [0007]
RFCs 3209 und 5151 [0007]
IEEE 802.1AB [0040]
IEEE 802.1AB [0050]

Claims

Verfahren zur Datenverarbeitung, das die Schritte aufweist: in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation Erstellen einer Reservierung für eine Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation durch einen Netzwerk-Switch; und in Reaktion auf eine Warteschlangen-Überlaufbedingung an der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, Beibehalten von Datenrahmen in dem Datenfluss der Quellstation, die in Übereinstimmung mit der Reservierung übertragen werden, und Verwerfen sonstiger Datenrahmen durch den Netzwerk-Switch.
Verfahren nach Anspruch 1, wobei: der Datenfluss einer Vielzahl von Datenflüssen der Quellstation zugehörig ist; und das Erstellen einer Reservierung ein Erstellen jeweils einer von einer Vielzahl von Reservierungen für jeden der Vielzahl von Datenflüssen der Quellstation aufweist.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei: der Datenfluss an eine Zielstation gerichtet wird; der Netzwerk-Switch einer Vielzahl von Switches in einem Datenpfad zwischen der Quellstation und der Zielstation zugehörig ist; und das Erstellen ein Erstellen der Reservierung an jedem der Vielzahl von Switches in dem Datenpfad aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, und das des Weiteren aufweist: Empfangen der Schicht-2-Reservierungsanforderung durch den Netzwerk-Switch.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Schicht-2-Reservierungsanforderung in einem Link-Layer-Discovery-Protocol-(LLDP-)Rahmen angegeben wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Schicht-2-Reservierungsanforderung den Datenfluss durch eine Schicht-2-Adresse und eine Flusskennung der Quellstation kennzeichnet.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Erstellen der Reservierung ein Aufzeichnen der Reservierung in einer Reservierungsdatenstruktur des Netzwerk-Switch aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, und das des Weiteren aufweist: Entfernen der Reservierung in Reaktion auf ein Ablaufen eines Zeitgebers durch den Netzwerk-Switch.
Verfahren nach einem der vorhergehenden Ansprüche, und das des Weiteren den Schritt aufweist: Entfernen der Reservierung in Reaktion auf ein Ausschöpfen eines reservierten Datenvolumens durch den Netzwerk-Switch.
Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren den Schritt aufweist: Modifizieren einer reservierten Kapazität bei der Eingangswarteschlange während der Reservierung durch den Netzwerk-Switch.
Verfahren nach einem der vorhergehenden Ansprüche, das des Weiteren den Schritt aufweist: Übertragen der Schicht-2-Reservierungsanforderung durch die Quellstation.
Switch, der aufweist: eine Vielzahl von Anschlüssen, von denen jeder jeweils eine von einer Vielzahl von Eingangswarteschlangen aufweist; einen Koordinatenschalter, der in der Lage ist, Datenrahmen zwischen der Vielzahl von Anschlüssen umzuschalten; und eine Switch-Steuereinheit, die in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation in der Lage ist, eine Reservierung einer Kapazität einer der Vielzahl von Eingangswarteschlangen für einen Datenfluss der Quellstation anzufordern, wobei in Reaktion auf eine Warteschlangen-Überlaufbedingung der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, der Switch in der Lage ist, Datenrahmen in dem Datenfluss der Quellstation beizubehalten, die in Übereinstimmung mit der Reservierung übertragen werden, und sonstige Datenrahmen zu verwerfen.
Switch nach Anspruch 12, wobei: der Datenfluss einer Vielzahl von Datenflüssen der Quellstation zugehörig ist; und die Switch-Steuereinheit in der Lage ist, jeweils eine von einer Vielzahl von Reservierungen für jeden der Vielzahl von Datenflüssen der Quellstation zu erstellen.
Switch nach Anspruch 12 oder Anspruch 13, wobei: der Datenfluss an eine Zielstation gerichtet wird; der Netzwerk-Switch einer Vielzahl von Switches in einem Datenpfad zwischen der Quellstation und der Zielstation zugehörig ist; und der Switch in der Lage ist, die Schicht-2-Reservierungsanforderung von einem weiteren Switch zu empfangen, der der Quellstation näher ist.
Switch nach einem der Ansprüche 12 bis 14, wobei die Schicht-2-Reservierungsanforderung in einem Link-Layer-Discovery-Protocol-(LLDP-)Rahmen angebbar ist.
Verfahren nach einem der Ansprüche 12 bis 15, wobei die Schicht-2-Reservierungsanforderung den Datenfluss durch eine Schicht-2-Adresse und eine Flusskennung der Quellstation kennzeichnet.
Switch nach einem der Ansprüche 12 bis 16, wobei die Switch-Steuereinheit eine zugehörige Reservierungsdatenstruktur aufweist, in der die Switch-Steuereinheit die Reservierung aufzeichnet.
Switch nach einem der Ansprüche 12 bis 17, wobei die Switch-Steuereinheit in der Lage ist, die Reservierung in Reaktion auf ein Ablaufen eines Zeitgebers zu entfernen.
Switch nach einem der Ansprüche 12 bis 18, wobei die Switch-Steuereinheit in der Lage ist, die Reservierung in Reaktion auf ein Ausschöpfen eines reservierten Datenvolumens zu entfernen.
Switch nach einem der Ansprüche 12 bis 19, wobei die Switch-Steuereinheit in der Lage ist, eine reservierte Kapazität bei der Eingangswarteschlange während der Reservierung zu modifizieren.
System, das aufweist: den Switch nach einem der Ansprüche 12 bis 19; und ein Datenverarbeitungssystem, das durch eine Datenverbindung mit dem Switch verbindbar ist, wobei das Datenverarbeitungssystem aufweist: einen Prozessor; einen Datenspeicher, der mit dem Prozessor verbindbar ist; und die Quellstation, wobei die Quellstation innerhalb des Datenverarbeitungssystems anordenbar ist und in der Lage ist, die Schicht-2-Reservierungsanforderung an den Switch zu übertragen, um eine Reservierung von Kapazität der Eingangswarteschlange des Netzwerk-Switch für den Datenfluss der Quellstation anzufordern, und wobei die Quellstation in Reaktion auf ein Genehmigen der Reservierung Datenrahmen des Datenflusses entsprechend der reservierten Kapazität an den Switch überträgt, sodass das Datenverarbeitungssystem in der Lage ist, ein garantiertes Weiterleiten der Datenrahmen durch den Switch zu erzielen.
Datenverarbeitungssystem, das aufweist: einen Prozessor; einen Datenspeicher, der mit dem Prozessor verbunden ist; und eine Quellstation innerhalb des Datenverarbeitungssystems, die in der Lage ist, eine Schicht-2-Reservierungsanforderung an einen Netzwerk-Switch zu übertragen, um eine Reservierung von Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation anzufordern, und die in Reaktion auf ein Genehmigen der Reservierung in der Lage ist, Datenrahmen des Datenflusses entsprechend der reservierten Kapazität an den Netzwerk-Switch zu übertragen, sodass das Datenverarbeitungssystem in der Lage ist, ein garantiertes Weiterleiten der Datenrahmen durch den Netzwerk-Switch zu erzielen.
Computerprogrammprodukt, das aufweist: ein computerlesbares Speichermedium, das einen Computerprogrammcode aufweist, der bei Ausführen durch eine Maschine einen Computer veranlasst, einen Schicht-2-Switch zu implementieren, indem er die Schritte durchführt: in Reaktion auf ein Empfangen einer Schicht-2-Reservierungsanforderung von einer Quellstation Erstellen einer Reservierung für eine Kapazität einer Eingangswarteschlange des Netzwerk-Switch für einen Datenfluss der Quellstation; und in Reaktion auf eine Warteschlangen-Überlaufbedingung an der Eingangswarteschlange des Netzwerk-Switch, während die Reservierung aktiv ist, Beibehalten von Datenrahmen in dem Datenfluss der Quellstation, die in Übereinstimmung mit der Reservierung übertragen werden, und Verwerfen sonstiger Datenrahmen.
Computerprogrammprodukt nach Anspruch 23, wobei: der Datenfluss einer Vielzahl von Datenflüssen der Quellstation zugehörig ist; und das Erstellen einer Reservierung ein Erstellen jeweils einer von einer Vielzahl von Reservierungen für jeden der Vielzahl von Datenflüssen der Quellstation aufweist.
Computerprogrammprodukt nach Anspruch 23 oder Anspruch 24, wobei: der Datenfluss an eine Zielstation gerichtet wird; der Netzwerk-Switch einer Vielzahl von Switches in einem Datenpfad zwischen der Quellstation und der Zielstation zugehörig ist; und das Erstellen ein Erstellen der Reservierung an jedem der Vielzahl von Switches in dem Datenpfad aufweist.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 25, wobei die Schicht-2-Reservierungsanforderung in einem Link-Layer-Discovery-Protocol-(LLDP-)Rahmen angegeben wird.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 26, wobei die Schicht-2-Reservierungsanforderung den Datenfluss durch eine Schicht-2-Adresse und eine Flusskennung der Quellstation kennzeichnet.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 27, wobei das Erstellen der Reservierung ein Aufzeichnen der Reservierung in einer Reservierungsdatenstruktur des Netzwerk-Switch aufweist.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 28, wobei der Programmcode des Weiteren den Computer veranlasst, die Schritte durchzuführen: Entfernen der Reservierung in Reaktion auf ein Ablaufen eines Zeitgebers.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 29, wobei der Programmcode des Weiteren den Computer veranlasst, die Schritte durchzuführen: Entfernen der Reservierung in Reaktion auf ein Ausschöpfen eines reservierten Datenvolumens.
Computerprogrammprodukt nach einem der Ansprüche 23 bis 30, wobei der Programmcode des Weiteren den Computer veranlasst, die Schritte durchzuführen: Modifizieren einer reservierten Kapazität bei der Eingangswarteschlange während der Reservierung.