DE60029221T2

DE60029221T2 - Begrenztes automatisches wiederholungsaufforderungsprotokoll für rahmenbasierte kommunikationskanäle

Info

Publication number: DE60029221T2
Application number: DE60029221T
Authority: DE
Inventors: D. Tracy Palo Alto MALLORY
Original assignee: Broadcom Corp
Current assignee: Broadcom Corp
Priority date: 1999-05-21
Filing date: 2000-05-19
Publication date: 2007-06-28
Anticipated expiration: 2020-05-20
Also published as: US8503451B2; US20020034182A1; DE60029221D1; EP1183814A1; WO2000072498A1; ATE332598T1; US7236494B2; EP1183814B1; US6335933B1; AU4857600A; US20070263631A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein Kommunikationssysteme und spezifischer Verfahren und eine Vorrichtung zum Verringern von Datenverlusten bei einem Netzwerk mit unzuverlässiger Bitübertragungsschicht.
Viele Frame-Handhabungsschemata und -protokolle sind zum Datentransport verwendet worden. Bei Systemen, die diese Schemata und Protokolle ausführen, werden die Daten zu Frames "gepackt" und von einem Sender an einen Empfänger (oder, im Broadcast-Modus, an mehrere Empfänger) gesendet. Wenn der Empfänger einen Frame empfängt, entpackt er die Daten und verwendet sie. Bei dem standardisierten ISO-Sieben-Schichten-Netzwerk bewegt eine Sendeanwendung Daten zu einer Empfangsanwendung, indem die Daten einer Schicht unterhalb einer Anwendungsschicht zugeführt werden, die sie wiederum der nächstniedrigeren Schicht zuführt, bis die Daten die Bitübertragungsschicht erreichen und an den Empfänger gesendet werden. Am Empfänger wird das Verfahren umgekehrt, wobei die Daten von der Bitübertragungsschicht des Empfängers zu seiner Anwendungsschicht empor fließen. Die sieben Schichten, von unten nach oben, lauten: 1) Bitübertragungsschicht, 2) Sicherungsschicht, 3) Vermittlungsschicht, 4) Transportschicht, 5) Sitzungsschicht, 6) Darstellungsschicht und 7) Anwendungsschicht. 1 stellt dieses Konzept dar.
Es ist viel über die Vorteile einer solchen Anordnung von Schichten geschrieben worden und muss daher an dieser Stelle nicht wiederholt werden. Es wurden viele Standards zur Datenübertragung zwischen Peer-Schichten (Partnerschichten) vorgeschlagen und sind allgemein gebräuchlich. Die gebräuchlichste Form der vernetzten Datenübertragung bei einem lokalen Netz ist heutzutage die Ethernet/IEEE-802.3-Netzwerkprotokollkommunikation (kurz "Ethernet"). Aufgrund ihrer Allgegenwärtigkeit sind viele Ethernet-Komponenten leicht und kostengünstig erhältlich. Beispielsweise sind einzelne Chips leicht erhältlich, die einen Großteil der Logik ausführen, die erforderlich ist, um Ethernet-Datenübertragungen durchzuführen. Des Weiteren sind diese Chips aufgrund ihrer Allgegenwärtigkeit ausgiebig getestet worden und die Technologie ist, zusätzlich zu ihrer leichten Verfügbarkeit, bis zu dem Punkt gereift, an dem ihre Verwendbarkeit und Beschränkungen wohlbekannt sind.
Die Ethernet-Sicherungsschicht, wurde so konstruiert, dass sie durch eine relativ zuverlässige Bitübertragungsschicht unterhalb der Sicherungsschicht unterstützt wird. Aufgrund dessen führt die Ethernet-Sicherungsschicht in ihrer Standardbetriebsart weder eine Fehlerkorrektur von Frames durch noch sendet sie verloren gegangene Frames erneut. Viele zuverlässige Bitübertragungsschichten wurden für Ethernet standardisiert, diese umfassen solche, die auf Koaxialkabeln, qualitativ hochwertigen Twisted-Pair-Kabeln und Glasfasern basieren. Diese ergeben im Allgemeinen äußerst niedrige Fehlerraten (z.B. weniger als 1 fehlerhafter Frame pro Million gesendeter Frames). Folglich wurden viele Protokolle höherer Schichten im Hinblick auf niedrige Fehlerraten entworfen, die bei höheren Raten eine schlechte Leistung haben. Streaming-Video-Anwendungen beispielsweise benötigen niedrige Fehlerraten, da der Verlust von 1 Frame oder mehr pro 1.000 Frames sichtbare Fehler verursachen kann. Als ein weiteres Beispiel hat das Transportsteuerungsprotokoll (TCP – Transport Control Protocol), das praktisch für den gesamten zuverlässigen Fernnetz-(Internet-)Transport verwendet wird, eine schlechte Leistung, wenn mehr als 1 Frame von 20 verloren geht. Sollte eine unzuverlässige Bitübertragungsschicht mit einer standardgemäßen Ethernet-Sicherungsschicht verwendet werden, würden Protokolle höherer Schichten höhere Frame-Verluste haben.
Aufgrund des Wachstums der Heimvernetzung (home networking) erwarten immer mehr Computerbenutzer, ihre Heimcomputer mit anderen Haushaltsgeräten verbinden zu können. Aufgrund der leichten Verfügbarkeit kostengünstiger Ethernet-Komponenten möchten viele Computerbenutzer ein Ethernet-Netzwerk für die miteinander verbundenen Haushaltsgeräte einrichten. Sofern das Haus jedoch nicht mit standardisierten Medien, wie etwa CAT-5-Twisted-Pair-Kabeln oder dergleichen, verdrahtet ist, muss das Netzwerk über bestehende Leitungen eingerichtet werden, die für gewöhnlich entweder Telefonleitungen oder Stromleitungen umfassen (es sei denn das Netzwerk ist drahtlos). Obgleich Telefonleitungen und Stromleitungen leicht Datenströme mit niedrigen Bitraten transportieren können, stellt das Senden von Daten mit Ethernet-Raten eine Herausforderung dar, da weder Telefonleitungen noch Stromleitungen dafür ausgelegt sind, Datenübertragungen mit hoher Bandbreite zu transportieren. Die typische Telefonleitung besteht aus einem Satz verdrillter Adern (Twisted Pair), die in RJ11-Steckern ohne passende Anschlusswiderstände enden und von Telefonsteckverbinder zu Telefonsteckverbinder hintereinander geschaltet (daisy-chained) werden können, wobei viele Abzweigungen die Leitungen weiter verschlechtern und den Leitungen Rauschen hinzufügen. Stromleitungen haben ihre eigenen Probleme mit dem Energieversorgungsnetz und Geräten, die Rauschen in die Leitungen einspeisen.
Die Unzuverlässigkeit dieser Leitungen bei hohen Bandbreiten führt zu Frame-Verlusten oder Verzögerungen. Wenn das Rauschen oder andere Beeinträchtigungen einer Leitung bewirken, dass der Empfänger beim Decodieren der Daten des Frames auch nur einen einzigen Fehler macht, geht dieser Frame verloren. Der Verlust von Frames führt zu Datenverlusten oder Verzögerungen aufgrund der erneuten Übertragung der verlorenen Daten. Bei zeitempfindlichen Anwendungen können Verzögerungen ein erhebliches Problem darstellen. Bei anderen Anwendungen, wie etwa einem UDP-basierten Multicast von Audio-/Videoströmen, stellen häufige Frame-Verluste ein Problem dar.
Versuche, die Zuverlässigkeit eines unzuverlässigen Kanals zu verbessern, fallen im Allgemeinen in zwei Kategorien: das Verwenden von Fehlerkorrekturcodes (Vorwärtsfehlerkorrektur) oder das Verwenden eines zuverlässigen Datenstromprotokolls. Fehlerkorrekturcodes machen es erforderlich, zusätzliche Daten zu senden, wobei zusätzliche Kanalkapazität für den gesamten Datenverkehr und zusätzliche Rechenressourcen im Sender auch dann verbraucht werden, wenn keine Fehler vorhanden sind. Sogar bei leistungsfähigen Fehlerkorrekturcodes können dennoch Frames verloren gehen, weil der Frame zu stark beschädigt wurde oder einfach aufgrund von Fehlern am Anfang oder Ende des Frames verloren gegangen ist. Daher sind zusätzliche Anstrengungen nötig, um zusätzliche Bits zu berechnen und zu transportieren, die entweder, im Falle von unbeschädigten Frames, nicht verwendet werden oder, im Falle von stark beschädigten Frames, nicht verwendet werden können.
Zuverlässige Datenstromprotokolle, wie etwa HDLC LAPB, stellen einen zuverlässigen Datenkanal über ein unzuverlässiges Medium bereit, wobei der Empfänger den Empfang von Frames bestätigen und der Sender unbestätigte Frames erneut senden muss. Ein zuverlässiges Datenstromprotokoll wird dazu verwendet, sicherzustellen, dass alle Frame erfolgreich empfangen werden, ungeachtet dessen, ob dies rechtzeitig geschieht, weshalb es das Protokoll verlangt, dass der Empfänger relativ häufig Bestätigungen an den Sender sendet und eine Flusssteuerung bereitgestellt wird, um den Datenfluss zu stoppen. Diese Protokolle benötigen außerdem eine explizite Verbindungseinrichtung zwischen den Stationspaaren (einem Sender und einem Empfänger) und unterstützen keine Multicast-Anwendungen. Die obigen Faktoren machen zusätzliche Bandbreiten erforderlich, die Verzögerungen einführen und das Netzwerk weniger robust machen können. Aus diesen Gründen umfasst die Verwendung zuverlässiger Datenstromprotokolle Beschränkungen als Methode zur Erhöhung der Zuverlässigkeit.
Daher sind ein Protokoll sowie Unterstützungsverfahren und -vorrichtungen erforderlich, die die effektiven Frame-Verlustraten und Verzögerungen auf das Niveau von standardgemäßen Ethernet-Frame-Verlustraten und Verzögerungen senken können, und zwar über eine Bitübertragungsschicht, von der annimmt, dass sie unzuverlässig ist, und die dies im Hinblick auf die Netzwerkbandbreite und Host-Ressourcen bei minimalen Kosten durchführen und dabei den verbindungslosen Multicast-Dienst mit geringer Latenzzeit aufrechterhalten, der normalerweise von Ethernet erwartet wird.
ZUSAMMENFASSUNG DER ERFINDUNG
Bei einem Frame-Switched-Netzwerk (Frame-vermittelten Netzwerk) gemäß einer Ausführungsform der vorliegenden Erfindung sendet ein Sender Frames über einen möglicherweise unzuverlässigen Kanal an einen Empfänger. Ein gesendeter Frame umfasst eine Frame-Kennung (Frame-ID), die aus einem Satz wieder verwendbarer Frame-Kennungen ausgewählt wird. Der Sender speichert den Frame in einem Frame-Puffer für einen Pufferzeitraum. Bei Empfang des Frames bestimmt der Empfänger anhand der Frame-Kennung, ob vor dem empfangenen Frame bei der Übertragung Frames verloren gegangen sind. Wenn der Empfänger bestimmt, dass ein früherer Frame verloren gegangen ist, sendet der Empfänger für den oder die fehlenden früheren Frames eine negative Bestätigung (NACK – negative acknowledgement) an den Sender. Wenn der Sender eine NACK erhält, bestimmt der Sender die Frame-Kennung(en) des oder der fehlenden früheren Frames und sendet den oder die fehlenden Frames erneut, wenn der oder die fehlenden Frames im Frame-Puffer vorhanden sind. Am Ende eines Pufferzeitraums entlässt der Sender den gesendeten Frame aus dem Frame-Puffer.
Bei einigen spezifischen Ausführungsformen sendet der Sender den gesendeten Frame an mehr als einen Empfänger, etwa in einem Multicast- oder Broadcast-Modus. Die Frame-Kennungen können aus einem Satz sequenzieller ganzer Zahlen bestehen, wobei Frames in einer sequenziellen Frame-Reihenfolge gesendet werden. Bei einigen Ausführungsformen speichert ein Empfänger, wenn er einen Frame empfängt, der sich nicht in der richtigen Reihenfolge befindet, den außer Reihenfolge befindlichen Frame in einem Empfänger-Puffer für einen Empfangs-Pufferzeitraum zwischen, bis frühere Frame empfangen werden oder der Empfangs-Pufferzeitraum abläuft.
Bei einigen Ausführungsformen sendet der Sender einen Erinnerungs-Frame an den Empfänger, um es dem Empfänger zu ermöglichen, einen fehlenden früheren Frame zu ermitteln, der an einem Ende einer Frame-Sequenz fehlt. Der Kanal zwischen dem Sender und dem Empfänger kann ein bidirektionaler Kanal über eine Telefonleitung, ein Kabel, eine Hochfrequenzverbindung oder eine Stromleitung sein. Mehrere logische Kanäle könnten zwischen einem gegebenen Sender-/Empfängerpaar eingerichtet werden, um Datenverkehr unterschiedlicher Prioritäten zuzulassen.
Ein Vorteil der vorliegenden Erfindung besteht darin, dass zwischen einem Sender und einem Empfänger neue Daten gesendet werden können, ohne dass der Sender bestätigen muss, dass ältere Daten gesendet und korrekt empfangen wurden, wobei dennoch ein Gelegenheitsfenster für Frames bereitgestellt wird, die schnell erneut gesendet werden sollen. Das Gelegenheitsfenster wird vorgerückt, wenn neue Frames gesendet werden. Infolge des Vorrückens des Fensters können einige Frames verloren gehen, wobei das Protokoll jedoch dafür ausgelegt ist, dass diese verlorenen Frames auf einer höheren Schicht gehandhabt werden. Es ist keine Flusssteuerung am Senderende erforderlich, weshalb keine Kanalinstallation oder Empfängerflusssteuerungsinstallation nötig ist.
Ein genaueres Verständnis der Art und der Vorteile der Erfindung geht aus den übrigen Abschnitten der Beschreibung und den beigefügten Zeichnungen hervor.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Diagramm, das den standardgemäßen Sieben-Schichten-Netzwerkstapel darstellt.
2 ist ein Blockdiagramm, das den standardgemäßen Datenfluss in den unteren drei Schichten eines Netzwerkstapels zeigt.
3 ist ein Blockdiagramm, das einen Datenfluss gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
4 ist ein Blockdiagramm eines Sender- und Empfänger-Schaltungsaufbaus gemäß einer Ausführungsform der vorliegenden Erfindung für eine Station, die unter Verwendung eines LARQ-(Limited Automatic Repeat reQuest) Protokolls kommuniziert.
5 ist eine Frame-Karte (Frame Map), die die Felder eines herkömmlichen Ethernet-Frames zeigt.
6 ist eine Frame-Karte, die die Felder eines LARQ-Daten-Frames und seinen LARQ-Header zeigt.
7 ist eine Frame Karte, die die Felder eines LARQ-Erinnerungssteuer-Frames und seinen LARQ-Header zeigt.
8 ist eine Frame-Karte, die die Felder eines LARQ-NACK-Steuer-Frames und seinen LARQ-Header zeigt.
9 ist eine Darstellung von Beispielen einiger Tabellen, die von einem LARQ-Handler verwendet werden, wobei 9(a) eine Kanalzustandsinformationstabelle, 9(b) eine Frame-Senderzustandstabelle und 9(c) eine Frame-Empfängerzustandstabelle zeigt.
10 ist ein Flussdiagramm eines LARQ-Frame-Sendeverfahrens.
11 ist ein Flussdiagramm eines LARQ-Frame-Empfangsverfahrens.
12 ist ein Frame-Flussdiagramm, das mehrere Beispiele für ein Frame-Handhabungsverfahren darstellt, das zwischen einem Sender und einem Empfänger durchgeführt wird.
13 ist ein Frame-Flussdiagramm, das mehrere weitere Beispiele für ein Frame-Handhabungsverfahren darstellt, das zwischen dem Sender und dem Empfänger durchgeführt wird.
14 ist eine Darstellung einer Anwendung des erfindungsgemäßen Frame-Switched-Netzwerks über einen potenziell unzuverlässigen Kanal.
BESCHREIBUNG DER SPEZIFISCHEN AUSFÜHRUNGSFORMEN
Hierin sind mehrere Ausführungsformen zum Implementieren eines Protokolls beschrieben, das hierin als "LARQ-"Protokoll (für Limited Automatic Repeat reQuest – für eine begrenzte automatische Wiederholungsanfrage) bezeichnet wird. Wie aus einem Studium dieser Beschreibung hervorgeht, verringert das LARQ-Protokoll die effektive Fehlerrate eines unzuverlässigen Frame-basierten Kommunikationskanals oder -netzes. Anders als bei den meisten sequenznummerbasierten Protokollen versucht LARQ nicht, eine zuverlässige Lieferung eines jeden Frames zu garantieren, sondern versucht stattdessen, einige Verluste in der Bitübertragungsschicht durch eine schnelle erneute Übertragung verloren gegangener Frames zu kompensieren, und überlässt die zuverlässige Lieferung eines jeden Frames den höheren Netzwerkschichten. Dies steigert die Verwendbarkeit von Netzwerken erheblich, die, zumindest gelegentlich, Verlustraten von einem Frame pro hundert Frames oder schlechter haben, und stellt diese Steigerung bei minimaler zusätzlicher Komplexität auf den unteren Netzwerkschichten bereit.
Eine solche Anwendung für das LARQ-Protokoll besteht darin, Verfahren, die für äußerst zuverlässige Kanäle verwendet werden, für unzuverlässige Kanäle anzupassen. LARQ-Protokolle können beispielsweise zum Implementieren eines Ethernet-Netzwerks (das für gewöhnlich mit zuverlässigen Kanälen betrieben wird, wie etwa einem Ethernet-spezifischen Koaxialkabel) über Telefonleitungen oder Stromleitungen genutzt werden, die auch für analoge Telefondienste oder zur Gleichstromverteilung verwendet werden.
1 zeigt den grundlegenden Aufbau eines Netzwerkstapels zwischen zwei Datenverarbeitungs- oder Kommunikationssystemen. Aus der Sicht der ISO-Vernetzung überträgt eine Anwendung (AW "X") eines Systems (System A) Anwendungsdaten an eine Anwendung (AW "Y") eines anderen Systems (System B). Obgleich die Datenübertragung zwischen diesen Anwendungen den Anwendungen eine Peer-zu-Peer-Übertragung zu sein scheint, ist sie tatsächlich eine Kommunikation mit der nächstniedrigeren Netzwerkschicht, in diesem Fall der Darstellungsschicht. Während Daten abwärts durch jede Schicht des Systems A weitergeleitet werden, umhüllt diese Schicht die Daten. Sobald die Daten die niedrigste Schicht, die Bitübertragungsschicht, erreichen, werden sie an das System B gesendet, wo sich die Daten dann durch die Schichten im System B hocharbeiten, wobei sie auf jeder Schicht von der Umhüllung befreit werden.
Bezug nehmend nun auf 2 sind die unteren drei Schichten des Netzwerkstapels genauer dargestellt. Wie wohlbekannt ist, werden Daten an die Vermittlungsschicht 10 des Senders weitergeleitet, die Netzwerk-Frames bildet und die Netzwerk-Frames an eine Sicherungsschicht 20 weiterleitet, die wiederum aus diesen Netzwerk-Frames Daten-Frames bildet und diese Daten-Frames an eine Bitübertragungs schicht 30 sendet. Es versteht sich, dass diese Schichten typischerweise als Kombination aus Logik und Speicherung ausgeführt werden, die dafür konfiguriert ist, die Aufgabe der Schicht zu erfüllen. Die Logik kann entweder in Form von Hardware, Software, Firmware oder einer Kombination daraus ausgeführt werden. Wie wohlbekannt ist, werden in Massenproduktion hergestellte Ausführungen und/oder Hochgeschwindigkeitsausführungen im Allgemeinen in zweckbestimmter Hardware ausgeführt, während kundenspezifische, zweckorientierte und/oder kostengünstige Ausführungen in Software oder Firmware implementiert werden können, wobei ein Universalprozessor Instruktionen ausführt, um die Aufgaben der Schicht auszuführen. Eine Schicht könnte auch, zumindest teilweise, unter Verwendung programmierbarer Gate-Arrays (Gatteranordnungen) oder dergleichen implementiert werden. Mehr als eine Schicht könnte zu einer integrierten Schaltung oder Software-Ausführung kombiniert werden. Es sollte nach einem Studium dieser Beschreibung ersichtlich sein, dass es viele Möglichkeiten zur Ausführung der hierin beschriebenen Erfindung gibt, die Kombinationen aus herkömmlichen Schaltungselementen und/oder Software-Techniken umfassen.
3 zeigt, wie das Vernetzungsmodell gemäß 2 modifiziert wird, um das LARQ-Protokoll zu handhaben. Wie in 3 gezeigt, ist ein LARQ-Handler (LARQ-Handhabungseinrichtung) 100 in der Sicherungsschicht 20 enthalten. Beim Senden von Daten nimmt der LARQ-Handler 100 Daten-Frames von einer oberen Schnittstelle 21 der Sicherungsschicht 20 an und gibt LARQ-Frames 102 an eine untere Schnittstelle 23 der Sicherungsschicht 20 aus (die für gewöhnlich in der Hardware unter der Steuerung eines Software-Treibers implementiert ist). Beim Datenempfang nimmt der LARQ-Handler 100 LARQ-Frames vom unteren Abschnitt der Sicherungsschicht an und gibt Daten-Frames an die obere Schnittstelle 21 aus. Wie nachfolgend erläutert, können einige Ausführungsformen des LARQ-Handlers 100 LARQ- und "Nicht-LARQ" (d.h. herkömmliche) Frames senden sowie LARQ- und "Nicht-LARQ" Frames empfangen, obgleich bei Nicht-LARQ-Frames die Vorteile von LARQ-Protokollen nicht voll genutzt werden können. Aus 3 sollte ersichtlich sein, dass die Sicherungsschicht weitere Verarbeitungselemente zwischen dem LARQ-Handler 100 und einer oder beiden Schnittstellen zu benachbarten Schichten umfassen könnte.
4 ist ein Blockdiagramm einer Schaltung zur Ausführung des LARQ-Handlers 100. Die LARQ-Schicht ist typischerweise eine Teilschicht innerhalb der Schicht 2 (Sicherungsschicht) im ISO-Netzwerkaufbau. Wie in 4 gezeigt, umfasst der LARQ-Handler 100 eine Sendersteuerlogik 104 und eine Empfängersteuerlogik 106.
Die Sendersteuerlogik 104 handhabt den Eingang von Frames von der oberen Schicht, den Ausgang von Daten-Frames an die untere Schicht und den Eingang von Steuer-Frames von der unteren Schicht sowie andere hierin beschriebene Steuerfunktionen. Die Sendersteuerlogik 104 steuert außerdem eine Kanaltabelle 110 und einen Sendepuffer 114, die nachfolgend genauer beschrieben sind. Die Empfängersteuerlogik 106 handhabt die Umkehrung dieser Funktionen, wie etwa den Ausgang von Frames an die obere Schicht, den Eingang von Daten-Frames von der unteren Schicht und den Ausgang von Steuer-Frames an die untere Schicht sowie andere hierin beschriebene Funktionen und steuert außerdem einen Neuordnungspuffer 120 und eine Empfangszustandstabelle 122, die ebenfalls nachfolgend genauer beschrieben sind.
In 4 ist nur ein LARQ-Handler 100 gezeigt, es versteht sich jedoch, dass an jedem LARQ-fähigen Knoten des Netzwerks ein LARQ-Handler 100 bereitgestellt werden würde. Aus 4 sollte des Weiteren ersichtlich sein, dass die Empfangsseite und die Sendeseite eines LARQ-Handlers 100 typischerweise mit anderen Sendeseiten und Empfangsseiten häufiger kommunizieren als sie dies miteinander tun. Es versteht sich ferner, dass die Funktionalität der Empfangsseite und der Sendeseite nicht in dem Ausmaß voneinander getrennt sind, wie in 4 dargestellt. Ein Grund, die zwei Seiten getrennt voneinander darzustellen, besteht darin, das Verständnis des Betriebs des LARQ-Handlers 100 zu erleichtern. Bei einer tatsächlichen Ausführung könnten aus Gründen der Konstruktions- und Verarbeitungseffizienz Elemente miteinander kombiniert werden. Wie nachfolgend erläutert, könnte beispielsweise die Kanaltabelle 110 Informationen sowohl für die Sendeseite als auch für die Empfangsseite enthalten.
Bei der bevorzugten Ausführungsform arbeitet ein LARQ-Protokolle verwendendes Netzwerk gemäß einer Modifikation des Ethernet-Protokolls. Dies ermöglicht die Verwendung der vielen Standard-Tools und -Komponenten, die bereits entwickelt worden und zur Verwendung mit dem Ethernet-Protokoll leicht erhältlich sind. Beim Ethernet-Protokoll hat ein zwischen einer Sicherungsschicht und einer Bitübertragungsschicht weitergeleiteter Ethernet-Frame die in 5 gezeigte Struktur.
Der in 5 gezeigte Frame ist ein standardgemäßer Ethernet/IEEE-802.3-MAC-(Media Access Control – Medienzugangssteuerungs-)Frame und -Header mit 48-Bit-Adressierung. Der Frame umfasst eine Sechs-Byte-(48-Bit-)Ziel-MAC-Adresse, eine Sechs-Byte-Quellen-MAC-Adresse, ein Zwei-Byte-Typ-/Längenfeld, auf den eine Nutzlast (Payload) und ein Vier-Byte-FCS-(Frame Check Sequence – Frame- Prüfsequenz-)Feld folgen. Die Nutzlast besteht aus den durch den Frame transportierten Daten und kann zwischen 0 Bytes und 1500 Bytes lang sein.
6 zeigt die Struktur eines LARQ-Daten-Frames 102, der zwischen einer LARQ-Schicht und einer Bitübertragungsschicht weitergeleitet werden könnte. Wie dort gezeigt, ist der LARQ-Daten-Frame 102 ein modifizierter Ethernet-Frame und umfasst Ziel- und Quellenadressenfelder, ein LARQ-Header-Feld, ein Typ-/Längenfeld, ein Nutzlastfeld (das die gesendeten Daten enthält) und möglicherweise ein FCS-Feld. Ein typischer LARQ-Header umfasst die in Tabelle 1 gezeigten Felder. Es wird darauf hingewiesen, dass nicht alle Felder aus Tabelle 1 erforderlich sind, so dass ein LARQ-Header nur acht Bytes oder weniger umfassen oder vierzehn Bytes groß sein könnte. Bei den verschiedenen Beschreibungen von LARQ-Frames wird eine Mindestgröße von acht Bytes für einen LARQ-Header angenommen.
TABELLE 1 – LARQ-HEADER-FELDER
Ein Empfänger kann einen LARQ-Frame von einem Nicht-LARQ-Frame anhand des Ethertyps des Frames unterscheiden, da der Ethertyp eines Nicht-LARQ-Frames in einem Frame dieselbe Stelle wie in einem LARQ-Frame einnehmen würde. Bei den hier ausgeführten Beispielen wird ein Ethertyp von 0x886c dazu verwendet, LARQ-Frames zu bezeichnen. Dieser 32-Bit-Wert wurde Epigram, dem Anmelder der vorliegenden Anmeldung, vom IEEE zugewiesen, welches die Instanz ist, die Ethertypen zuweist. Ein Ethertypwert kann von Längenwerten unterschieden werden, da gültige Längen kleiner als 0x0600 sein müssen, während gültige Ethertypen größer als 0x0600 sind. Andere Protokolle werden für den einzelnen Ethertyp unterstützt, indem verschiedene Subtypen dazu verwendet werden, die Verwendung eines anderen Protokolls zu signalisieren.
Das FCS-Feld ist für gewöhnlich nicht bei Frames vorhanden, die zwischen den oberen und unteren Schnittstellenabschnitten der Sicherungsschicht weitergeleitet werden, da die meisten Implementierungen der MAC-Schicht in Hardware erfolgen und die FCS (Frame Check Sequence – Frame-Prüfsequenz) direkt handhaben, hinzufügen und sie transparent entfernen. Mit der FCS beträgt die Gesamtgröße des Frames 1518 Bytes. Wenn in der empfangenen FCS ein Fehler vorhanden ist, wird der Frame verworfen. Wenn ein LARQ-Handler eng eingebunden ist, kann er Zugriff auf Frames mit schlechten FCS-Werten haben, bevor die Frames verworfen werden, was in manchen Fällen eine schnellere erneute Übertragung ermöglicht.
Wenn ein Frame empfangen wird und das NACK-Feld auf einen anderen Wert als 000 eingestellt ist, gibt dies eine Anfrage für eine erneute Übertragung an. Der nicht null betragende Wert von NACK gibt an, wie viele Frames "negativ bestätigt" ("nacked") werden (bis zu sieben). Bei diesem Schema kann der NACK-Frame nur sequenzielle Frames negativ bestätigen. Wenn daher NACK = 001 beträgt, dann gibt das Sequenznummernfeld den fehlenden/verlorenen Frame an, während wenn NACK = 011 beträgt, die drei Frames, die mit der angegebenen Sequenznummer beginnen, negativ bestätigt werden. Bei mehreren, nicht sequenziellen Frames würden bei der bevorzugten Ausführungsform mehrere NACK-Frames gesendet werden.
Wenn ein bidirektionaler Datenfluss vorhanden ist, könnten die NACKs in Frames eingesetzt werden, die sich vom negativen bestätigenden Empfänger zum Sender bewegen, auch wenn die beschriebene Implementierung dies nicht tut. Wenn der Datenfluss unidirektional ist, würden die NACKs in Steuer-Frames gesendet werden (d.h. CTL = 1). Wenn mehr als ein Frame in einer Sequenz verloren geht, kann eine NACK den Verlust von bis zu sieben sequenziellen Frames signalisieren, indem das NACK-Feld auf die Anzahl der verlorenen Frames eingestellt wird.
Wenn NACK = 000, aber CTL = 1, dann ist der Frame eine "Erinnerungs-"Frame vom Sender an den Empfänger. Bei einem Erinnerungs-Frame wird die Sequenznummer auf die Sequenznummer des zuletzt gesendeten Daten-Frames eingestellt, falls er dem Empfänger fehlt. Ansonsten könnte, wenn der Empfänger diesen zuletzt gesendeten Frame vollständig verloren hat, dieser den verlorenen Frame niemals negativ bestätigen, da das typische Ereignis, das den Empfänger auf den Verlust eines Frames aufmerksam macht, der Empfang eines Frames ist, der in der Sequenz weiter zurückliegt.
Das Sequenznummernfeld enthält eine Acht-Bit-Sequenznummer, die bei jedem neuen gesendeten Daten-Frame um eins inkrementiert wird, Modulo 256. Sie wird bei erneut gesendeten Frames nicht inkrementiert, welche mit dem Sequenzfeld gesendet werden, das auf die ursprünglichen Sequenznummern des Frames eingestellt ist. Der Sender unterhält eine Sequenz für jedes Ziel, wenn der Sender an mehr als ein Ziel Frames sendet. Beim Senden eines Frames an ein gegebenes Ziel, inkrementiert der Sender nur die Sequenznummer für dieses Ziel, so dass jedes Ziel von jeder Quelle sequenzielle Frames empfängt, die Frames an dieses Ziel sendet.
Das Ziel kann sich darauf verlassen, Frames einer gegebenen Prioritätsebene sequenziell von einem gegebenen Sender zu empfangen, ausgenommen natürlich verloren gegangene Frames. Wenn nicht mehrere Prioritätsebenen unterstützt werden, dann werden die Frames von einem gegebenen Sender in Folge empfangen, sofern sie nicht verloren gehen. Da der Empfang eines außer Reihenfolge befindlichen Frames den Verlust von weiter vorne in der Sequenz befindlichen Frames, bezogen auf den empfangenen Frame, angibt, würde der Empfänger bei Erhalt des empfangenen außer Reihenfolge befindlichen Frames NACKs für die fehlenden früheren Frames senden. Da einige Frame-Handhabungssysteme eine auf unterschiedlichen Prioritäten der Frames basierende Neuordnung von Frames während des Transports ermöglichen, verwendet der Sender bevorzugt eine separa te Sequenznummer für jede Prioritätsebene. Damit der Empfänger die Priorität eines empfangenen Frames bestimmen kann (was erforderlich ist, um zu bestimmen, mit welcher Sequenz er abgeglichen werden soll), ist ein Drei-Bit-Prioritätsfeld im LARQ-Header enthalten, wodurch bis zu acht verschiedene Prioritätsebenen ermöglicht werden. Mit anderen Worten, die Sequenznummern werden einem Sender pro Ziel und pro Prioritätsebene zugewiesen, um Sequenznummernumkehrungsprobleme in Netzwerken zu verhindern, die zulassen, dass Frames mit unterschiedlichen Prioritäten auf einer unteren Schicht neu geordnet werden, wie etwa im Software-Treiber oder im Hardware-Abschnitt der Sicherungsschicht, nachdem der LARQ-Header hinzugefügt worden ist.
Die Maximalgröße des Nutzlastfeldes des LARQ-Daten-Frames 102 könnte um acht Bytes verringert werden müssen, um es im Hinblick auf den LARQ-Header anzupassen, wenn die darunter liegenden Schichten keinen Frame handhaben können, der acht Bytes länger ist. Bei einem Zwischentreiber in MS-Win-32-Stapeln von Microsoft beispielsweise, könnte die Maximum Transmission Unit (MTU – größtmögliche übertragbare Dateneinheit) der oberen Schicht kürzer als normal spezifiziert werden. Bei Netzwerken, bei denen die Bitübertragungsschicht (und ihr Treiber) Frames unterstützen, die mindestens acht Bytes größer als das Ethernet-Maximum von 1518 (1522 bei einem VLAN) sind, könnte die MTU unverändert bleiben.
7 zeigt die Felder eines LARQ-Erinnerungssteuer-Frames 102', der dem LARQ-Daten-Frame 102 ähnelt, außer dass das Typ-/Längenfeld und die Nutzlastfelder nicht vorhanden sind. Das Steuerfeld ist auf eins gesetzt, um zu signalisieren, dass kein Nutzlastfeld vorhanden ist. Wenn das zugrunde liegende Netzwerk eine Frame-Mindestgröße benötigt, wird der Frame mit Füll-Bytes auf diese Mindestgröße gebracht. LARQ-Steuer-Frames werden nach Bedarf mit Füll-Bytes auf die Mindestgröße von Ethernet (oder einer anderen Bitübertragungsschicht) gebracht, werden jedoch ansonsten so kurz wie möglich gehalten, um den Netzwerk-Overhead zu minimieren. Bei Ethernet-Netzwerken beträgt die Frame-Mindestgröße 64 Bytes, so dass der Frame mit einem Füll-Byte aufgefüllt werden würde, das zwischen null Bytes und der Frame-Mindestgröße beträgt. An manchen Stellen dieser Offenbarung wird eine LARQ-Header-Größe von acht Bytes als Beispiel verwendet, es können jedoch stattdessen auch andere Größen, wie etwa sieben Bytes oder sechs Bytes, verwendet werden.
8 zeigt die Felder eines LARQ-NACK-Steuer-Frames 102''. Der LARQ-NACK-Steuer-Frame 102'' ähnelt dem LARQ-Erinnerungssteuer-Frame 102', außer dass der LARQ-NACK-Steuer-Frame 102'' ein Sechs-Byte-NACK-Erweiterungsfeld umfasst (und folglich, wenn überhaupt, mit sechs Bytes weniger aufgefüllt werden muss). Das NACK-Erweiterungsfeld enthält die Ziel-MAC-Adresse des ursprünglichen Senders. Dies ist die Ziel-MAC-Adresse für den negativ bestätigten Frame. Bei Unicast-Zielen ist diese Adresse dieselbe wie die Quellenadresse des Steuer-Frames. Bei Gruppenzielen (Multicast/Broadcast) ist dies die ursprüngliche Gruppenadresse, an die der Frame gesendet wurde. Die zusätzliche Adresse ist erforderlich, da, wenn eine Station einen Frame sendet, diese ihre eigene MAC-Adresse als Quellenadresse für den Frame verwenden muss, da sie aus Protokollgründen keine Multicast-Adresse verwenden kann. Wenn ein Multicast-Frame empfangen wird, ist die Zieladresse des Frames die Multicast-Adresse und nicht die eigene MAC-Adresse der Station. Der ursprüngliche Sender muss die Multicast-Adresse kennen, die für den negativ bestätigten Frame verwendet wurde und interessiert sich nicht für die MAC-Adresse des Empfängers. Des Weiteren muss die LARQ-NACK zurück zum ursprünglichen Sender gesendet werden, da es für dieselbe Multicast-Adresse mehrere Sender geben kann, von denen jeder seinen eigenen Sequenznummernraum besitzt. Dies ist der Fall, da jede Kombination aus Quelle, Ziel und Priorität einen separaten logischen Kanal darstellt und jeder logische Kanal seinen eigenen Sequenznummernraum hat.
Bezug nehmend nun auf 9, sind die von den Stationen unterhaltenen Tabellen in dieser Figur dargestellt. Jeder Sender unterhält eine Kanaltabelle, wie etwa die Kanaltabelle 110, die in 4 und genauer in 9(a) gezeigt ist. Jeder Eintrag in die Kanaltabelle 110 stellt einen Kanal zwischen dem Sender und einem Empfänger dar. Andere von den Sendern und Empfängern unterhaltene Daten sind in den 9(b)–(c) gezeigt. Wenn ein Sender unterschiedliche Prioritäts-Frames an einen gegebenen Empfänger sendet, werden separate logische Kanäle verwendet.
Bei Verwendung der vorstehend beschriebenen LARQ-Frames können sowohl LARQ- als auch Nicht-LARQ-Frames gleichzeitig in einem Ethernet-Netzwerk vorhanden sein. Jeder Sender notiert in seiner Kanaltabelle, ob die Ziele LARQ-fähig sind oder nicht. Herkömmliche Ethernet-Frames werden gesendet, es sei denn sowohl der Sender als auch der Empfänger sind LARQ-fähig. Es ist möglich, das gesamte Netzwerk LARQ-fähig auszuführen, dies ist jedoch nicht notwendig. Ein Paketprozessor kann, wie vorstehend beschrieben, leicht einen LARQ-Frame von einem Nicht-LARQ-Frame unterscheiden.
Die Handhabung von NACKs wird nun unter Bezugnahme auf die Flussdiagramme des Sendeverfahrens für LARQ-Frames (10) und das Empfangsverfahren für LARQ-Frames (11) sowie den in 4 gezeigten LARQ-Handler 100 beschrieben. Zunächst wird eine Basisimplementierung beschrieben, worauf Beispiele für Variationen folgen, die auf spezifischere Ausführungsformen anwendbar sind. Die Logik gemäß den 10 und 11 könnte von der Sendersteuerlogik 104 bzw. der Empfängersteuerlogik 106 ausgeführt werden, die in 4 gezeigt sind.
Das Sendeverfahren ist in 10 gezeigt. Das dort gezeigte Flussdiagramm lässt einige periphere Schritte aus, um die Klarheit des Dargestellten zu erhalten. Beispielsweise widmet sich das Flussdiagramm nicht dem Einrichten neuer Kanäle und arbeitet mit Frames von vorhandenen logischen Kanälen. Aus dem Rest dieser Offenbarung sollte ersichtlich sein, wie ein Empfänger oder Sender einen logischen Kanal einrichtet und dass eine solche Einrichtung oder Installation "on the fly" erfolgen kann, d.h. ein Empfänger könnte nach und in Antwort auf den Empfang eines Frames für einen logischen Kanal, der noch nicht an diesem Empfänger eingerichtet ist, einen logischen Kanal installieren. Es versteht sich außerdem, dass viele Variationen des in 10 Dargestellten möglich sind, ohne die wesentlichen Schritte des Verfahrens zu beeinträchtigen. Das gezeigte Verfahren beginnt beispielsweise in einem Zustand, in dem ein LARQ-Handler auf den Empfang eines Frames von einer unteren Schicht wartet, und diesen Zustand verlässt, wenn ein Frame empfangen wird. Bei manchen nicht dargestellten Variationen könnte der LARQ-Handler diesen Zustand in Antwort auf ein Timeout-Signal (Zeitüberwachungssignal) eines Zeitgebers verlassen und nach dem Verarbeiten eines zeitlich festgelegten Ereignisses zu diesem Zustand zurückkehren.
Der Anfangszustand ist in 10 mit "S1" und die auf diesen Zustand folgenden Schritte sind mit den Zustands- oder Schrittnummern S2, S3, S4 etc. bezeichnet, die hier im Text in Klammern angegeben sind. Sobald ein Frame von der unteren Schicht empfangen wird, wird er überprüft (Schritt S2), um zu bestimmen, ob es sich um einen LARQ-Frame handelt. Wenn dies nicht der Fall ist, wird der Frame zur nächsten Schicht empor gesendet (S3) und der LARQ-Handler kehrt zum Anfangszustand S1 zurück. Wenn es sich bei dem Frame um einen LARQ-Frame handelt und der Frame ein NACK-Frame ist, wird er als NACK-Frame verarbeitet (S4) und der LARQ-Handler kehrt zum Anfangszustand zurück. An diesem Punkt wird der Frame, wenn er kein NACK-Frame ist, überprüft.
Wenn sich der Frame in schlechtem Zustand befindet (z.B. schlechter Header oder außerhalb des Bereichs liegende Sequenznummer), wird er verworfen (S5) und der LARQ-Handler kehrt zum Anfangszustand zurück. Wenn der Frame eine schlechte FCS (Frame Check Sequence – Frame-Prüfsequenz), aber einen guten Header und die nächste Sequenznummer für seinen logischen Kanal aufweist, wird die Sequenznummer vorgerückt (S6) und eine NACK für den aktuellen Frame gesendet (S7). Ein NACK-Neuübertragungszeitgeber wird für den negativ bestätigten Frame eingestellt (S8), der aktuelle Frame verworfen (S9) und der LARQ-Handler kehrt zum Anfangszustand zurück. Wenn der Header beschädigt ist, aber der Sender und die Sequenznummer feststellbar sind, könnte eine NACK gesendet werden.
Wenn der Frame ein LARQ-Frame ist und sich der Frame in gutem Zustand befindet, wird die Sequenznummer überprüft. Wenn die Sequenznummer nicht neu und die Sequenznummer zu alt oder ein Duplikat einer früher empfangenen Sequenznummer ist, wird der Frame verworfen (S10) und der LARQ-Handler kehrt zum Anfangszustand zurück. Wenn jedoch die alte Sequenznummer kein Duplikat oder nicht zu alt ist, werden die Tabellen des Empfängers überprüft, um zu bestimmen, ob der aktuelle Frame der älteste fehlende Frame ist (S11). Wenn dies der Fall ist, wird der aktuelle Frame empor gesendet (S12) und alle darauf folgenden, im Neuordnungspuffer gespeicherten Frames werden ebenfalls empor gesendet (S13). Wenn der aktuelle Frame nicht der älteste fehlende Frame ist, wird er im Neuordnungspuffer des Empfängers gespeichert (S14). In jedem Fall kehrt der LARQ-Handler dann zum Anfangszustand zurück.
Wenn der aktuelle Frame gut und die Sequenz neu ist (noch nicht für den logischen Kanal empfangen wurde), wird die Sequenznummer für diesen Kanal vorgerückt (S15), alte Frames werden empor gesendet, wenn eine Frame-Speichergrenze erreicht ist (S16), und der LARQ-Handler führt eine Überprüfung durch, um zu bestimmen, ob neue Sequenznummern fehlen (S17). Eine Frame-Speichergrenze könnte erreicht werden, da die Sequenznummer des aktuellen Frames bewirken könnte, dass die Sequenznummern von Frames im Neuordnungspuffer außerhalb des Bereichs geraten. Anstatt weiter auf die fehlenden Frames zu warten, die zwischen dem zuletzt empor gesendeten Frame und dem ältesten Frame im Neuordnungspuffer fehlen, werden diese fehlenden Frame als verloren erklärt und der älteste Frame empor gesendet. Alle in Sequenz befindlichen Frames nach diesem ältesten Frame bis zur nächsten Lücke in den Sequenznummern werden an diesem Punkt empor gesendet.
Wenn die nächsthöhere Schicht nicht verlangt, dass die Frames in Folge abgegeben werden, leitet der LARQ-Handler die Frames so weiter wie sie empfangen wurden, anstatt die außer Reihenfolge befindlichen Frames zu speichern. Wenn die nächsthöhere Schicht jedoch verlangt, dass sich die Frames in Reihenfolge befinden oder von einem Verlust von Frames ausgeht, wenn sie sich außer Reihenfolge befinden, sollte der LARQ-Handler dafür konfiguriert sein, auf eine Lücke folgende Frames für einen gewissen Zeitraum in einem Neuordnungspuffer zwischenzuspeichern, so dass, wenn der Empfänger die Lücke rechtzeitig mit erneut gesendeten Frames füllen kann, die Frames in Folge an die nächsthöhere Schicht weitergeleitet werden können.
Wenn die Sequenznummer des aktuellen Frames nicht die nächste in der Sequenz ist, gibt dies an, dass Frames fehlen. Insbesondere, dass Frames mit Sequenznummern zwischen der zuletzt empfangenen Sequenznummer und der aktuellen Sequenznummer fehlen. Der LARQ-Handler sendet NACKs für diese fehlenden Frames (S18) und stellt die NACK-Neuübertragungszeitgeber für diese fehlenden Frames ein (S19). Wie nachfolgend genauer erläutert, werden, wenn die Lücke größer als ein Schwellenwert ist, nicht für alle Frames in der Lücke NACKs gesendet und die Lücke wird den höheren Schichten zur Handhabung überlassen.
Ein Empfänger sendet einen NACK-Steuer-Frame, wenn er eine fehlende Sequenznummer von einem Sender ermittelt, und zwar entweder aufgrund des Empfangs einer späteren Sequenznummer oder weil ein Nutzlastfehler die Abgabe der restlichen Nutzlast an die nächsthöhere Schicht verhindert hat. Die NACK enthält die erste Sequenznummer eines oder mehrerer fehlender Frames und eine Zählung der Anzahl der fehlenden Frames. Die NACK ist eine Anfrage zur erneuten Übertragung der angegebenen ursprünglichen Frames. Bei Empfang einer NACK sollte ein Sender sofort so viele der angegebenen Frames wie möglich erneut in ihrer ursprünglichen Reihenfolge senden.
An diesem Punkt überprüft der LARQ-Handler den Frame, um zu bestimmen, ob er ein Erinnerungssteuer-Frame ist. Wenn dies der Fall ist, wird der Frame verworfen (S20). Wenn nicht, wird der Frame empor gesendet, wenn im Neuordnungspuffer keine weiteren Frames vorhanden sind (S21), anderenfalls wird der aktuelle Frame im Neuordnungspuffer gespeichert (S22). Der LARQ-Handler kehrt dann zum Anfangszustand zurück.
Bei manchen Ausführungsform werden, wenn ein "Empfang-verloren-"("receive lost")Zeitgeber abläuft (der den Zeitraum zum Halten der Frames angibt), die zwischengespeicherten Frames ungeachtet dessen, ob in der Sequenz Lücken vorhanden sind oder nicht, an die nächsthöhere Schicht gesendet. Daher hört der Empfänger auf, auf einen Frame zu warten, erklärt ihn für verloren und sendet die sequenziell folgenden Frames an die nächste Schicht empor. Wenn ein Frame an die nächsthöhere Schicht gesendet wird, werden die erwartete nächste Sequenznummer des Senders des Frames und die Priorität um eins inkrementiert, Modulo der Größe des Sequenznummernfeldes.
Das Empfangsverfahren wurde nun beschrieben. Das Sendeverfahren wird nun unter Bezugnahme auf das Flussdiagramm gemäß 11 beschrieben. Beim Sendeverfahren wartet der Sender auf ein Ereignis (S41), wie etwa den Empfang eines Frames, den Ablauf eines Zeitgebers oder den Empfang eines Steuer-Frames (signalisiert durch die Empfangsseite des LARQ-Handlers). Wenn der Sender einen Frame von der darüber liegenden Schicht empfängt, nimmt er den Frame an und fügt, wie vorstehend beschrieben, einen LARQ-Header hinzu (S42). Der Sender konsultiert seine Kanaltabelle, um die nächste zu verwendende Sequenznummer zu bestimmen (S43). Die Sequenznummer für diesen Kanal (die für ein Ziel und eine Priorität spezifisch ist) wird in der Kanaltabelle inkrementiert, Modulo der Größe des Sequenznummernfeldes (im obigen Fall, Modulo 256), und zwar vor dem Senden eines neuen Nicht-Steuer-Frames. Die anderen Felder des LARQ-Headers werden wie vorstehend beschrieben initialisiert.
Der Frame wird dann in einem Sendepuffer gespeichert (S44) und der Erinnerungszeitgeber für diesen Frame zurückgestellt. Der Sendepuffer ist bevorzugt so bemessen, dass eine gewisse Anzahl an Frames für eine mögliche schnelle erneute Übertragung gespeichert werden kann. Der Sendepuffer handhabt bevorzugt nur eine begrenzte Anzahl an Frames, um die für den Sendepuffer erforderliche Platzmenge zu begrenzen. Wie nachfolgend erläutert, könnte ein Sender dafür konfiguriert sein, insgesamt eine maximale Anzahl an Frames (MaxTxSaveCount), eine maximale Anzahl an Frames für einen gegebenen Kanal (MaxTxSaveCountChannel) und eine maximale Zeitspanne zum Halten des Frames (MaxTxHoldInterval) zuzulassen.
Der LARQ-Daten-Frame wird dann an die nächstniedrigere Schicht zur Übertragung an den Empfänger gesendet (S45). Da der LARQ-Header mit einem standardgemäßen vom IEEE zugewiesenen 16-Bit-Ethertyp-Feld beginnt, verwerfen Nicht-LARQ- Empfänger einfach LARQ-Daten-Frames als einen ihnen unbekannten Ethertyp. Im normalen Betrieb werden LARQ-Daten-Frames nicht an Nicht-LARQ-Empfänger gesendet, dieses Verwerfen von LARQ-Daten-Frames wird jedoch, wie nachfolgend beschrieben, dazu verwendet, zu ermitteln, ob ein neuer Empfänger LARQ-fähig ist oder nicht.
An diesem Punkt kehrt der Sender zum Schritt S41 zurück und wartet auf ein weiteres Ereignis. Bei Auflauf mancher Zeitgeber führt der Sender eine Aktion durch (S46). Wenn beispielsweise der "Sende-/Halte-"("SendHold")Zeitgeber abläuft, werden im Frame-Puffer befindliche Frames, die älter als eine vordefinierte Zeitspanne sind, aus dem Frame-Puffer entfernt. Wenn ein "Erinnerungs-"("reminder")Zeitgeber abläuft, wird ein Erinnerungs-Frame gesendet. Eine Sendestation sendet nach einer Inaktivitätszeitspanne, in der keine Frames an eine kürzlich verwendete Ziel-MAC-Adresse und Priorität gesendet wurden, eine Erinnerung. Wie vorstehend erläutert, enthält der Erinnerungs-Frame die Sequenznummer des zuletzt gesendeten Daten-Frames des Senders, was es dem oder den Empfängern ermöglicht, verloren gegangene Frames relativ schnell zu ermitteln, die ansonsten erst viel später vermisst werden würden. Sobald er sich um den Zeitgeber gekümmert hat, kehrt der Sender, sofern keine anderen Zeitgeber abgelaufen sind, zu Schritt S41 zurück.
Wenn der Sender in Schritt S41 einen Steuer-Frame empfängt, signalisiert durch die Empfangsseite, sofern die Empfangs- und Sendeseiten des LARQ-Handlers getrennt sind, verarbeitet der LARQ-Handler den Steuer-Frame, wobei er zunächst eine Überprüfung durchführt, um zu bestimmen, ob der Frame ein NACK-Frame ist. Wenn der Steuer-Frame ein NACK-Steuer-Frame ist (oder eine NACK-Angabe auf einem zurückgeführten Daten-Frame ist, wobei ein Huckepackverfahren verwendet wird), sendet der Sender die negativ bestätigten Frames erneut (S47), anderenfalls handhabt der Sender, wenn der Steuer-Frame kein NACK-Steuer-Frame ist, den Steuer-Frame entsprechend (S48). In jedem Fall kehrt der Sender dann zu Schritt S1 zurück, um auf ein weiteres Ereignis zu warten. Vor dem erneuten Senden des oder der negativ bestätigten Frames ermittelt der Sender, ob der negativ bestätigte Frame im Sendepuffer verfügbar ist. Wenn er verfügbar ist, sendet der Sender den Frame erneut. Anderenfalls führt der Sender keine Aktion durch.
Wenn der negativ bestätigte Frame nicht erneut durch den Sender gesendet wird, hört der Empfänger schließlich auf, NACK-Anfragen zu senden und betrachtet den Frame als verloren. Der Empfänger sendet dann alle darauf folgenden Frames, die in seinem Neuordnungspuffer gespeichert sind, an die nächsthöhere Schicht. Das Fehlerhandhabungsverfahren dieser oberen Ebenen wird wahrscheinlich zwischen diesen höheren Schichten eine Peer-zu-Peer-Anfrage durchführen, um den verlorenen Frame erneut zu senden.
Inbetriebnahme und Rückstellung (Reset)
Wenn ein Ethernet-Daten-Frame zur Übertragung über einen neuen Kanal (neues Ziel oder neue Priorität) an einen LARQ-Handler weitergeleitet wird, handhabt der Sender die Kanalinitialisierung auf eine von zwei Arten. Wenn bekannt ist, dass alle Stationen des Netzwerks LARQ implementieren, oder wenn ein anderer Kanal zu demselben Empfänger bereits LARQ verwendet, dann wählt der Sender einfach eine Startsequenznummer aus, stellt den "Typ" dieses logischen Kanals in der Kanaltabelle auf EMPFÄNGER ein ("Empfänger führt LARQ durch"), fügt dem Frame den LARQ-Header hinzu und sendet ihn abwärts an den Treiber. Wenn erforderlich, wird der Kanaltabelle eine neue Zeile hinzugefügt.
Wenn der Sender nicht weiß, ob der Empfänger LARQ ausführt oder nicht, richtet der Sender den Kanal mit einer Startsequenznummer und einem "Führt-Möglicherweise-nicht-LARQ-durch-"Typ ein (wie es bei Kanal 5 in der in 9 gezeigten Kanaltabelle 110 der Fall ist). Der Sender sendet dann den Daten-Frame ohne LARQ-Header und sendet außerdem einen LARQ-Erinnerungs-Frame an den Empfänger unter Verwendung der Ziel-MAC-Adresse und Priorität des Daten-Frames. Sollte vom Empfänger eine NACK erhalten werden, dann wird der Typ dieses Kanals auf "Empfänger führt LARQ durch" eingestellt. Wenn nach einer gewissen Anzahl an Erinnerungsversuchen keine NACK empfangen wird, wird der Kanal als "Empfänger führt nicht LARQ durch" markiert.
Wenn der Empfänger einen Frame mit einem LARQ-Header über einen neuen Kanal (neue Quelle, Gruppenzieladresse oder Priorität) empfängt, initialisiert der Empfänger Kanalzustandsinformationen in seinem Empfangsstatustabelleneintrag für diesen Kanal. Wenn der Frame ein Daten-Frame ist, stellt sich der Empfänger dafür ein, den Frame als den nächsten in Reihenfolge befindlichen Frame für den Kanal zu empfangen. Wenn der Frame ein Erinnerungs-Frame ist, dann initialisiert sich der Empfänger so, als ob ihm der Frame mit der in der Erinnerung angegebenen Sequenznummer fehlen würde, und sendet eine NACK zurück zur Quelle. Dies dient dazu, die Sendestation wissen zu lassen, dass dieser Empfänger für den Kanal auch LARQ unterstützt.
Empfänger bestätigen erfolgreich empfangene Frames nicht positiv. Bei Ermittlung einer ausreichend großen Lücke in den Sequenznummern von einem bestimmten Sender bestätigt ein Empfänger die Frames in der Lücke nicht negativ, sondern stellt einfach seinen Sequenznummernzustand für diesen Kanal auf die aktuelle Sequenznummer zurück und überlässt es den höheren Schichten, die Lücke zu handhaben. Der typische Schwellenwert für eine ausreichend große Lücke ist bei einer Implementierung eine Lücke, bei der der absolute Wert der Differenz zwischen der neuen Sequenznummer und der vormals neuen Sequenznummer größer ist als die maximale Anzahl an Frames, für die der Empfänger den Zustand aufrechterhält.
Ressourcenbeschränkungen
Der Sender steuert, wie viele Daten (in Frames, Bytes oder beidem) für eine mögliche erneute Übertragung gespeichert werden und für wie lange. Dies ermöglicht es, Beschränkungen dafür einzurichten, wie spät ein Frame erneut gesendet werden kann, und zwar sowohl in Echtzeit als auch wie weit außer Reihenfolge er sich befinden kann, wenn er empfangen wird. Das LARQ-Protokoll benötigt keine explizite Kanalinitialisierung zwischen Stationen. Der Empfänger beschränkt außerdem die Zeitspanne, in der er Frames hält, die auf die erneute Übertragung eines früheren Frames warten, sowie die Anzahl an Frames, die er hält. Die vom Sender und vom Empfänger eingerichteten Beschränkungen müssen nicht identisch sein. Wenn der Sender bereit ist, mehr als der Empfänger zwischenzuspeichern, dann kann der Sender Speicherplatz für Frames verschwenden, die niemals erneut gesendet werden können. Wenn der Empfänger ausgedehntere Beschränkungen besitzt, dann kann er NACK-Anfragen für Frames senden, die bereits nicht mehr verfügbar sind, was zu zusätzlichem Steuerverkehr im Netzwerk führt. Die Basisimplementierung verlangt nicht, dass die Senderzwischenspeicherung mit der Empfängerzwischenspeicherung übereinstimmt, einige Implementierungen können jedoch einen Konfigurations-Handshaking-Betrieb (Quittungsbetrieb) umfassen, um den überflüssigen Verkehr zu reduzieren.
In-Reihenfolge-Abgabe von Frames
Die meisten modernen Protokolle tolerieren eine Außer-Reihenfolge-Abgabe, ausgenommen diejenigen, die ausschließlich zum Betrieb mit Punkt-zu-Punkt-Verbindungen ausgelegt sind, wie etwa PPP. Unausgereifte und ineffiziente Implementierungen von Protokollen höherer Schichten, einschließlich Transport- und Anwendungsprotokolle, machen jedoch eine In-Reihenfolge-Abgabe höchst wünschenswert. Des Weiteren ist eine Außer-Reihenfolge-Abgabe bei normalem Ethernet (einschließlich durch Brücken verbundene Mehrsegmentnetze) nicht möglich. Bei vielen Netzwerkarten, einschließlich Ethernet-artigen Netzwerken, sollte eine LARQ-Implementierung bevorzugt erfolgreich empfangene Frames in der ursprünglich vom Sender gesendeten Reihenfolge abgeben. Obgleich die Neuordnung vorstehend angesprochen wurde, ist es notwendig, verloren gegangene Frames rechtzeitig und sorgfältig zu handhaben, wenn die verlorenen Frames durch erneut gesendete Frames transparent ersetzt werden sollen.
Größe und Verwendung von Sequenznummern – alte und neue Nummern
Die Größe des Sequenznummernfeldes könnte verändert werden, acht Bits scheinen jedoch eine gute Wahl für einen Betrieb mit mehreren verschiedenen Netzwerkgeschwindigkeiten zu sein. Zwölf Bits stellen eine weitere Möglichkeit dar. Bei Geschwindigkeiten, die deutlich höher als 10 MBps sind, könnten ein paar Dutzend Frames während bestimmter Arten von Netzwerkunterbrechungen verloren gehen. Aus Gründen der Robustheit ist es erwünscht, beim Sequenznummernraum etwas Spielraum zu haben, so dass sehr lange Unterbrechungen als große Lücken ermittelt werden (die wiederum Sequenznummerrückstellungen am Empfänger bewirken), anstatt dass Sequenznummern ihren Modulo überlagern, ohne ermittelt zu werden. Um zu vermeiden, dass die Überlagerung (Wraparound) des Modulo nicht festgestellt wird, ist die bevorzugte Ausführungsform auf einen Sequenznummernraum gerichtet, der aufgeteilt werden kann in: neue Nummern, die auf die aktuelle Nummer folgen, alte Nummern, die der aktuellen Nummer vorausgehen, und einige Nummern, die als "außer Sequenz befindliche" Nummern bezeichnet werden, welche den alten Nummern vorausgehen und auf die neuen Nummern folgen (was möglich ist, da der Nummernraum in einer Schleife zu sich selbst zurückgeführt wird). Beispielsweise bei einem Nummernraum von 256 Nummern könnten, wenn die aktuelle Sequenznummer C ist, die Nummern C – 63 bis C alte Nummern, C + 1 bis C + 64 neue Nummern (alle Modulo 256) und der Rest der Nummern außer Sequenz befindlichen Nummern sein.
"Neue" und "alte" Nummern werden in Bezug auf eine aktuelle Empfangssequenznummer definiert. Für den Sender ist die aktuelle Sequenz diejenige, die zuletzt einem Daten-Frame zugeordnet wurde, der von der nächsthöheren Schicht zur Übertragung empfangen wurde. Für den Empfänger ist die aktuelle Sequenznummer die Sequenznummer des zuletzt empfangenen neuen Frames oder die Sequenz nummer des Frames, der zuerst empfangen wurde als der Kanal initialisiert wurde. Es wird darauf hingewiesen, dass der Sender und der Empfänger manchmal unterschiedliche aktuelle Nummern haben können.
Formal ist eine alte Sequenznummer eine Sequenznummer, deren Differenz von der aktuellen Sequenznummer, Modulo der Größe des Sequenznummernraums, kleiner oder gleich null ist, während eine neue Sequenznummer eine Sequenznummer ist, deren Differenz von der aktuellen Sequenznummer, Modulo der Größe des Sequenznummernraumes, größer als null ist. "Jüngere" Sequenznummern sind alte Sequenznummern, die nahe genug bei der aktuellen Sequenznummer liegen, dass sie gespeicherte Zustandsinformationen aufweisen, die möglicherweise eine gespeicherte Kopie eines Daten-Frames umfassen. Neben den jüngeren Sequenznummern gibt es die außer Sequenz befindlichen Sequenznummern, die nicht in allen Versionen des LARQ-Protokolls definiert sein können, wenn sie jedoch definiert sind, sind diese sehr alte oder sehr neue Sequenznummern, die in Anbetracht der aktuellen Sequenznummer weder vom Sender noch vom Empfänger verwendet werden sollten.
Wenn ein Empfänger einen Frame mit einer alten Sequenznummer empfängt, wird der Frame als normaler Empfangs-Frame verarbeitet, sofern er kein Duplikat eines bereits empfangenen Frames ist. Ein neuer Frame wird immer als normaler Empfangs-Frame verarbeitet und führt auch dazu, dass NACKs gesendet werden, wenn eine oder mehrere vormals neue Sequenznummern jetzt fehlen. Wenn eine außer Sequenz befindliche Nummer empfangen wird, behandelt sie der Empfänger einfach wie eine Rückstellung des Sequenznummernraumes.
Wenn der LARQ-Handler Frames nicht in Folge an die nächsthöhere Schicht abgeben muss, dann besteht die normale Empfangsverarbeitung bei einem Daten-Frame, der kein Duplikat ist, ob neu oder alt, darin, den Frame empor an die nächsthöhere Schicht zu senden. Bei der In-Reihenfolge-Abgabe wird ein alter Frame den Stapel empor gesendet, wenn er der älteste ausstehende, fehlende Frame ist, gehalten, wenn noch ältere Frames fehlen, oder verworfen, wenn er ein Duplikat ist. Neue Frames werden den Stapel empor gesendet, wenn es keine früheren, fehlenden Frame gibt, oder gehalten, wenn es fehlende Frame mit früheren Sequenznummern gibt. Darüber hinaus bewegt das Vorrücken der aktuellen Empfangssequenznummer den Bereich der alten Sequenznummern, wobei möglicherweise bewirkt wird, dass alte, gehaltene Frame den Stapel empor gesendet werden, wenn sie zur ältesten ausstehenden Sequenznummer werden (z.B. aktuell –63).
NACK-Handhabung und angehäufte NACKs
Bei der Basisimplementierung wird eine NACK-Angabe für jede fehlende Sequenznummer auf einer Pro-Kanal-Basis zum Sender transportiert. Wenn ein NACK-Steuer-Frame empfangen wird, müssen die Quellen- und Zieladressen im Ethernet-Header umgekehrt werden, um den Kanal-Lookup durchzuführen. Ein NACK-Steuer-Frame sollte aufgrund seiner Voreinstellung nicht bewirken, dass ein neuer Kanal mit der ursprünglichen Sendestation als Empfänger eingerichtet wird. Die NACK wird im Zusammenhang mit dem Sender verarbeitet. Der Sender sendet normalerweise alle angegebenen Frames erneut, die noch immer zur Verfügung stehen, obgleich das MinimumRtxInverval (eine Erläuterung der hier verwendeten Variablen ist nachfolgend angegeben) dazu verwendet werden kann, eine zu häufige erneute Übertragung einzelner Frames zu verhindern.
Als Optimierung umfasst der NACK-Steuer-Frame sowohl eine Sequenznummer als auch die Anzahl der fehlenden Frames, so dass ein einzelner NACK-Steuer-Frame für mehrere sequenzielle fehlende Frames gesendet werden kann. Wenn die Anzahl der fehlenden Frames die Größe des NACK-Zahlfeldes (drei, bei den obigen Beispielen) übersteigt, werden mehrere NACK-Steuer-Frames gesendet, um den gesamten Bereich der fehlenden Frames abzufragen.
Erweiterungen der Basisimplementierung
Die Basisimplementierung sendet nach einer Inaktivitätszeitspanne eine einzelne Erinnerung für die jüngste Sequenznummer. Eine erweiterte Implementierung könnte es zulassen, mehrere Erinnerungen zu senden, es gibt jedoch mehrere Gründe dafür, warum eine einzelne Erinnerung, die im Vergleich zu NACKs nach einem relativ langen Intervall gesendet wird, die bessere Wahl zu sein scheint. Die Erinnerung wird nur gesendet, wenn kein weiterer Datenverkehr vorhanden ist. Wenn nach einem ähnlichen Intervall eine zweite Erinnerung gesendet werden würde, könnte sich der Frame nahe dem Ende seiner "Lebensdauer" befinden, bevor er als alt verworfen wird, was die Wahrscheinlichkeit, dass die zweite Erinnerung nutzlos ist, weiter erhöht. Außerdem macht es das relativ lange Intervall deutlich weniger wahrscheinlich, dass ein einzelnes Fehlerereignis sowohl den ursprünglichen Frame als auch die erste Erinnerung unbrauchbar macht. Die Tatsache, dass auf demselben Kanal kein weiterer Verkehr vorhanden ist, weist darauf hin, dass es sich dabei nicht um einen Teil eines Stromes von latenzzeitempfindlichen Frames handelt, was es einem Protokoll einer höheren Schicht ermöglicht, den Spielraum zu straften, wenn ein doppelter Verlust im Vergleich dazu, die Anzahl an Overhead-Frames im Netzwerk nahezu zu verdoppeln, ein guter Kompromiss zu sein scheint.
Andererseits sollten NACKs erneut gesendet werden, wenn es guten Grund gibt, anzunehmen, dass die erste NACK nicht erfolgreich war. Die nachfolgend ausgeführten Vorgehensweisen sollen diesen Fall abdecken, idealerweise durch Verwendung adaptiver Timeouts, um die Anzahl an Neuübertragungsgelegenheiten zu maximieren.
Eine Basisimplementierung verfügt möglicherweise nicht über mehrere Prioritäten, in welchem Fall das Prioritätsfeld aus dem LARQ-Header weggelassen werden kann, das Prioritätenfeld sollte jedoch verwendet werden, wenn die unteren Schichten Frames basierend auf einer Priorität neu ordnen.
Gruppenadressen (Multicast/Broadcast)
Die Basisimplementierung kann zur Verwendung mit Gruppenadressen erweitert werden, indem der Kanalzustand definiert wird, der für jede Kombination aus Quelle, Ziel und Priorität aufrechterhalten werden soll, sowie durch Erweitern des NACK-Steuer-Frame-Formats. Bei dieser Erweiterung umfasst der NACK-Steuer-Frame die ursprüngliche Ziel-MAC-Adresse des Frames, da die eigene MAC-Adresse des Empfängers, die im NACK-Steuer-Frame als Quellenadresse verwendet wird, keine Gruppenadresse sein kann.
Huckepack-NACKs, Fragmentierung, selektiver Betrieb, etc.
Ein erweiterter Format-Header mit zwei Sequenznummernfeldern kann verwendet werden, so dass jeder Frame Huckepack-NACK-Angaben mitführen kann. Dies kann die Anzahl an zusätzlichen Steuer-Frames minimieren, die für bidirektionale Verkehrsflüsse von einem LARQ-Handler erzeugt werden, was jedoch zusätzlichen Header-Raum für jeden Frame, zusätzliche Komplexität und eine gewisse zusätzliche Latenzzeit verursacht, wenn NACKs für ein kurzes Intervall gehalten werden, während auf einen potenziellen Daten-Frame gewartet wird, auf dem sie huckepack (piggyback) befördert werden können.
Weitere Erweiterungen
Es sind mehrere weitere Erweiterungen des Basisprotokolls und des Handlers vorgesehen. Bei Netzwerken, bei denen es erheblich wahrscheinlicher ist, dass längere Frames beschädigt werden oder verloren gehen, ist es möglich, größere Frames in zwei oder mehr Segmente aufzuteilen. Da Nicht-LARQ-Frames normalerweise nicht durch einen LARQ-Empfänger verarbeitet werden, der einen LARQ-Frame erwartet, ist es möglich, LARQ-Header nur gewissen Frame-Typen hinzuzufügen (möglicherweise basierend auf dem Protokoll oder der Priorität). Es ist ebenfalls möglich, nur dann einen LARQ-Betrieb zuzulassen, wenn die Fehlercharakteristika des Netzwerks schlechter als ein spezifizierter Schwellenwert werden.
Das LARQ-Basisprotokoll kann unter Verwendung der hierin angegebenen Lehren leicht zur Verwendung mit beinahe jedem Netzwerktyp modifiziert werden, der einen Mechanismus zum Definieren logischer Kanäle vorsieht, wenn das Netzwerk mehr als zwei Stationen unterstützt.
Parameteraushandlung
Eine weitere, möglicherweise nützliche Erweiterung von LARQ besteht darin, eine Parameteraushandlung (parameter negotiation) oder wenigstens Konfigurationsangaben aufzunehmen. Beispielsweise kann der angewandte Austausch von Erinnerungs- und NACK-Frames dazu genutzt werden, die Verwendung von LARQ auf einem neuen Kanal zu überprüfen und zu bestätigen. Die Erinnerungs-Frames können erweitert werden, um wahlweise Konfigurationswerte des Senders zu enthalten, und NACK-Frames könnten wahlweise Konfigurationswerte des Empfängers enthalten. Der Sender würde Werte des logischen Kanals im Hinblick auf MaxTxSaveCountChannel, MaxTxHoldInterval und MinimumRtxInterval bereitstellen, während der Empfänger MaxRxSaveCountChannel, MaxRxHoldInterval und RepeatRequestInterval senden würde (eine Erläuterung dieser Konfigurationsvariablen folgt nachstehend).
Ein Empfänger könnte diese Variablen dazu verwenden, seine eigene Pro-Kanal-Konfiguration anzupassen, besonders wenn die Ressourcenbeschränkungen des Senders geringer als die Voreinstellungsbeschränkungen des Empfängers sind. Das MinimumRtxInterval könnte außerdem dabei behilflich sein, unnötige erneute Übertragungen von NACKs zu verhindern. Ein Sender wäre auch dazu imstande, die Anzahl gespeicherter Frames oder die Zeitspanne, in der gespeicherte Frames gehalten werden können, auf niedrigere Werte zu beschränken, sollte der Empfänger geringere Beschränkungen haben.
Ein detailliertes Beispiel
Es folgt nun eine genauere Beschreibung einer spezifischen Ausführungsform eines LARQ-Handlers in einem das LARQ-Protokoll unterstützenden Netzwerk.
Bei dieser spezifischen Ausführungsform wird das LARQ-Protokoll zunächst für einen logischen Kanal zwischen einem Stationspaar definiert, wobei Benutzerdaten in eine Richtung gesendet werden. Der logische Basiskanal wird durch das Tupel definiert, das die Quellen- und Ziel-MAC-Adressen der Benutzerdaten-Frames umfasst. Eine erweiterte Definition des logischen Kanals fügt dem Tupel die Priorität der Benutzerdaten hinzu. Obgleich dies nicht Teil von standardgemäßem Ethernet ist, steht die Priorität als zusätzlicher Parameter für Frames in Win32-Netzwerkstapeln zur Verfügung und wird bei manchen Netzwerktypen unterstützt, die IEEE-Ethernet-Header verwenden, einschließlich eines von Epigram entwickelten, auf Telefonleitungen basierenden Netzwerks.
Ein noch nicht empfangener Frame wird als "fehlend" erklärt, wenn seine Sequenznummer zwischen der jüngsten bekannten Sequenznummer und der ältestmöglichen Sequenznummer liegt, bei der der Empfänger eine erneute Übertragung annehmen würde. Ein Frame wird als "verloren" erklärt, wenn er zu dem Zeitpunkt fehlt, an dem der Empfänger entscheidet, dass er einen Frame mit einer jüngeren Sequenznummer empor senden muss, unabhängig davon, ob dies aufgrund von Zeitplanungs-, Ressourcen- oder Sequenznummerierungsbeschränkungen geschieht. Wenn ein Frame empfangen wird, nachdem er für verloren erklärt worden ist, sollte er verworfen werden.

Diese spezifische Implementierung überwacht die Zeit in Einheiten von Millisekunden unter Verwendung eines 32-Bit-Millisekunden-Tickzählers, der vom System unterhalten wird, um verschiedene Ereignisse mit Zeitstempeln zu versehen. Zeitgeber werden durch Berechnen des Intervalls (in Millisekunden) bis zum nächsten auf dem Zeitgeber basierenden Ereignis für jeden logischen Kanal und das Aufrufen einer WaitForNextEvent-Funktion (Warte-auf-nächstes-Ereignis-Funktion) implementiert. TABELLE 2 – TIMEOUT-INTERVALLZEITGEBER

Intervall	Beschreibung
T_sendHold	Die maximale Zeitspanne, in der der gesendete Frame [oder eine Kopie] von einem LARQ-Handler einer Sendestation gehalten wird, der auf eine mögliche erneute Übertragung wartet.
T_rcvLost	Die maximale Zeitspanne, die ein Empfänger abwartet, nachdem der Verlust eines (fehlenden oder fehlerhaften) Frames ermittelt wurde, bevor der Frame als verloren erklärt wird. Wenn ein Frame als verloren erklärt wird, können nachfolgende Frames, die gehalten wurden, während auf den Empfang des verlorenen Frames gewartet wurde, dann den Stapel empor zur nächsthöheren Schicht gesendet werden. Durch Voreinstellung hat dieser Parameter denselben Wert wie T_sendHold.
T_remind	Die Dauer einer Inaktivitätszeitspanne nach dem Senden des letzten Daten-Frames auf einem Kanal, die ablaufen muss, bevor ein Erinnerungs-Steuer-Frame gesendet wird.
T_minRtx	Das minimale Zeitintervall zwischen aufeinander folgenden erneuten Übertragungen desselben Daten-Frames. Wenn eine zweite Anfrage für denselben Frame empfangen wird, bevor dieses Intervall abgelaufen ist, wird die Anfrage ignoriert. Dies ist eine Funktion des geglätteten durchschnittlichen Neuübertragungsanfrageintervalls aus der Sicht des Senders des Kanals.
T_request	Das Intervall zwischen aufeinander folgenden erneuten Übertragungen einer NACK für einen fehlenden Frame. Dies ist eine Funktion des geglätteten durchschnittlichen Neuübertragungsintervalls aus der Sicht des Empfängers des Kanals.

Der LARQ-Handler unterhält außerdem einen Satz Konfigurationsparameter, die den Betrieb des LARQ-Protokolls in Bezug auf diesen LARQ-Handler steuern. Einige dieser Parameter sind in Tabelle 3 gezeigt, zusammen mit einer Beschreibung und typischen Werten für jeden Konfigurationsparameter.
TABELLE 3 – KONFIGURATIONSPARAMETER
Ein "langsames" Gerät mit einer relativ niedrigen maximalen Frame-Rate könnte einen kleinen Wert für MaxTxSaveCountChannel verwenden, etwa eins oder zwei, während Hochgeschwindigkeitsgeräte deutlich höhere Werte benötigen. Bei einem Sequenzraum von 256 Sequenznummern und bei Verwendung des obigen Schemas von alten, neuen und ungültigen Sequenznummern, beträgt der obere Grenzwert für MaxTxSaveCountChannel 64, da dies ein Viertel des Sequenznummernraumes ist.
MaxTxSaveCount ist bevorzugt eine Funktion von MaxTxSaveCountChannel, der Anzahl an Kanälen, der maximalen Datenrate des Netzwerks, der Menge des Systemspeicherplatzes, etc.
MaxRxSaveCountChannel sollte kleiner oder gleich dem Wert von MaxTxSaveCountChannel sein, wobei es möglich ist, einen Parameter zur Steuerung beider Funktionen zu verwenden. Wenn ein Empfänger in seinem Neuordnungspuffer bereits MaxRxSaveCountChannel-Frames gespeichert hat, würde dieser Grenzwert überschritten werden, wenn ein neuer Frame empfangen wird. Daher sollte, wenn diese Bedingung vorhanden ist, der Empfänger den ältesten gespeicherten Frame zur nächsten Schicht empor senden und die fehlenden Frames, die älter als der empor gesendete Frame sind, für verloren erklären lassen.
MaxProbeCount ist die Anzahl an Erinnerungsprüfungen, die gesendet werden soll, bevor entschieden wird, dass ein Empfänger auf einem bestimmten Kanal LARQ nicht durchführt. Wenn der Verkehr zu einem Empfänger derart abläuft, dass MaxProbeCount-Frames in einem schnellen Burst gesendet werden, kann der Sender daraus schnell schließen, dass der Empfänger nicht LARQ-fähig ist, auch wenn er es ist. Zur Vermeidung dieser Situation kann es erwünscht sein, ein Timeout-Intervall hinzuzufügen, so dass nur eine Erinnerungsprüfung in jedem Timeout-Intervall ausgesendet wird.
Die folgenden Tabellen 4–8 legen einige Informationen das, die für die LARQ-Verfahren unterhalten werden. Tabelle 4 legt die Informationen dar, die für jeden einem LARQ-Schicht-Handler bekannten Kanal unterhalten werden, unabhängig davon, ob der LARQ-Schicht-Handler den Kanal als Empfänger oder Sender verwendet. Wie vorstehend erläutert, hat jede Sender-Ziel-Prioritäts-Permutation ihren eigenen logischen Kanal. Ein Beispiel für die Daten einer solchen Kanalzustandsinformationstabelle ist in 9(a) gezeigt. Einige der in Tabelle 4 gezeigten Felder sind in 9(a) weggelassen worden, um die Darstellung in einem vernünftigen Rahmen zu halten.

Tabelle 5 legt die Informationen dar, die für jeden Kanal am Senderende des Kanals unterhalten werden. Tabelle 6 legt die Informationen dar, die für jeden vom sendenden LARQ-Schicht-Handler gespeicherten Frame unterhalten werden. Ein Beispiel für Senderdaten ist in 9(b) gezeigt. Tabelle 7 legt die Informationen dar, die für jeden Kanal am Empfängerende des Kanals unterhalten werden. Tabelle 8 legt die Zustandsinformationen dar, die am Empfänger für jeden durch den LARQ-Handler gehandhabten Frame gespeichert werden. Ein Beispiel für Empfängerdaten ist in 9(c) gezeigt. TABELLE 4 – KANALZUSTANDSINFORMATIONEN

Feld	Beschreibung
Kanal-ID	Eine Kanalnummer.
Sender-ID	Die MAC-Adresse der Sendestation.
Ziel-ID	Die von der Sendestation verwendete Ziel-MAC-Adresse. Dies ist für gewöhnlich die MAC-Adresse der Empfangs-Station bei Unicast-Frames und die Zielgruppen-MAC-Adresse bei Multicast-Frames.
Priorität	Die Priorität des Frames, wie durch den Sender spezifiziert.
Kanaltyp	Ein Typ, der ausgewählt wird unter: UNBEKANNTER-EMPFÄNGER, KEIN-EMPFÄNGER, KEIN-SENDER, EMPFÄNGER, SENDER. UNBEKANNTER-EMPFÄNGER gibt an, dass der Sender nicht weiß, ob der Empfänger LARQ unterstützt. Bis zu MaxProbeCount Erinnerungssteuer-Frames werden als Überprüfungen gesendet, einer mit jedem über den Kanal gesendeten Frame. Wenn eine positive Antwort empfangen wird, wird der Typ in EMPFÄNGER geändert, anderenfalls wird der Typ in KEIN-EMPFÄNGER geändert. KEIN-EMPFÄNGER gibt an, dass der Empfänger auf diesem Kanal LARQ nicht unterstützt. KEIN-SENDER gibt an, dass der Sender auf diesem Kanal LARQ nicht unterstützt. Der Empfang eines LARQ-Frames bewirkt, dass der Typ in SENDER geändert wird. EMPFÄNGER gibt an, dass diese Station bei dem Kanal als Empfänger arbeitet. SENDER gibt an, dass diese Station bei dem Kanal als Sender arbeitet.
Akt. Seq.	Die aktuelle Sequenznummer für diesen Kanal.
Älteste Seq.	Die älteste verarbeitbare Sequenznummer für diesen Kanal.
Frame-Tabelle	Eine Referenz auf eine Frame-Tabelle.

ProbeCount

Die Anzahl an nicht erfolgreichen Überprüfungen, die an den Empfänger über einen Kanal vom Typ UNBEKANNTER-EMPFÄNGER gesendet wurden.

TABELLE 5 – SENDERKANALZUSTANDSINFORMATIONEN

Feld	Beschreibung
Sendesequenznummer	Dieses Acht-Bit-Feld wird um eins inkrementiert, Modulo 256, und zwar bei jedem neuen an den Empfänger zu sendenden Benutzerdaten-Frame. Der neue Wert wird in einem LARQ-Header platziert, der in den Frame eingefügt wird, bevor er an den Treiber gesendet wird.
Neuübertragungsintervall	Wie implementiert, ist dies eine Funktion eines geglätteten Mittelwerts und einer geglätteten Mittelwertableitung für Neuübertragungsintervalle, gemessen von dem Zeitpunkt, zu dem ein Frame gesendet wurde, bis zu dem Zeitpunkt, zu dem er erneut gesendet wurde, unter Verwendung einer dynamischen Verfolgung von Frame-Umlaufbewegungslinien. Bei einigen Implementierungen könnte dies ein fester oder konfigurierbarer konstanter Wert sein. Die aktuelle Implementierung verwendet einen Anfangswert von 25 Millisekunden.
Frame-Sendezustand [MaxTxSaveCount]	Dies ist eine Größenordnung von MaxTxSaveCount. Zustandsinformationen werden bei jedem Benutzer-Frame für ebenso viele MaxTxSaveCount-Sequenznummern aufrechterhalten. Die Zustandsinformationen können bei jedem Frame eine Kopie des Frames sowie die in Tabelle 6 gezeigten Felder umfassen.

TABELLE 6 – FRAME-SENDERZUSTANDSINFORMATIONEN

Feld	Beschreibung
TxFrameFlag	1 = gespeicherter Frame vorhanden, 0 = kein gespeicherter Frame vorhanden. Dieses Feld könnte ein implizites Feld sein, wobei nur gespeicherte Frames in der Tabelle aufgeführt werden.
Neuübertragungsmarke	1 = wenigstens einmal erneut gesendet, 0 = noch nicht erneut gesendet. Dieses Feld könnte nicht explizit sein, es könnte implizit anhand der Neuübertragungszeit bestimmt werden.
Sende-Frame	Wenn TxFrameFlag 1 beträgt, ist dieses Feld eine Kopie des Frames, der zur erneuten Übertragung verwendet werden kann. Dies kann ein Zeiger auf Frame-Daten sein.

Sendezeit	Der Zeitpunkt, zu dem der Frame ursprünglich gesendet wurde.
Neuübertragungszeit	Der Zeitpunkt, zu dem der Frame erneut gesendet wurde, nur gültig, wenn die Neuübertragungsmarke 1 beträgt.

TABELLE 7 – EMPFÄNGERKANALZUSTANDSINFORMATIONEN

Feld	Beschreibung
Empfangssequenznummer	Die zuletzt über den logischen Kanal empfangene Sequenznummer.
Durchschnittliches Anfrageintervall	Wie implementiert, ist dies eine Funktion eines geglätteten Mittelwerts und einer geglätteten Mittelwertableitung für Neuübertragungsintervalle, gemessen von dem Zeitpunkt, zu dem der Frame verlogen ging, bis zu dem Zeitpunkt, zu dem der erneut gesendete Frame empfangen wurde. Bei einigen Implementierungen könnte dies ein fester oder konfigurierbarer konstanter Wert sein. Ein typischer Anfangswert beträgt 25 Millisekunden.
Frame-Empfangstabelle [MaxRxSaveCnt]	Dies ist eine Größenanordnung von MaxRxSaveCnt. Zustandsinformationen werden bei jedem Benutzer-Frame für ebenso viele MaxRxSaveCnt-Sequenznummern aufrechterhalten. Die Zustandsinformationen können bei jedem Frame eine Kopie des Frames sowie die in Tabelle 8 gezeigten Felder umfassen.

TABELLE 8 – FRAME-EMPFÄNGERZUSTANDSINFORMATIONEN

Feld	Beschreibung
Empfangsmarke	1 = ein guter Frame wurde empfangen, 0 = Frame nicht empfangen (entweder gar nicht oder fehlerhaft). Dieses Feld könnte implizit sein, wenn nur gute Frames in der Tabelle gespeichert werden.
RxFrameFlag	1 = Frame wird gehalten, 0 = kein Frame wird gehalten.
RxLostFlag	1 = Sequenznummer wurde aufgrund der Zeitüberschreitung entfernt und Frames mit höherer Nummer werden nicht mehr für sie gehalten, 0 = Frame nicht als "verloren" ("lost") erklärt.
Empfangs-Frame	Wenn RxFrameFlag 1 beträgt, ist dieses Feld der gehaltene Frame (oder ein Zeiger auf Frame-Daten), der darauf wartet, zur nächsten Schicht empor gesendet zu werden.

Verlustzeit	Der Zeitpunkt, zu dem der Frame verloren ging (d.h. als ein Frame mit höherer Nummer oder eine fehlerhafte Kopie des Frames empfangen wurde). Dieses Feld wird zum Berechnen des durchschnittlichen Neuübertragungsintervalls verwendet, aus Sicht des Empfängers.
NACK-Anfragezeit	Der Zeitpunkt, zu dem die letzte NACK-Anfrage erzeugt wurde. Wird zum Erzeugen des nächsten Neuübertragungsanfrage-Timeouts verwendet.
Empfangszeit	Der Zeitpunkt, zu dem der Frame empfangen wurde (Zeitstempel).

Die ersten drei oder vier Felder der Frame-Empfängerzustandsinformationen können explizit oder implizit anhand des Zeitstempels (Empfangszeit) bestimmt werden. Ein Beispiel einer Kommunikationssitzung unter Verwendung der obigen Tabellen und Parameter wird nun beschrieben.
Kanalinitialisierung
Zum Beginnen der Datenübertragungen zwischen einem Sender und einem Empfänger wird ein logischer Kanal initialisiert. Die einzige explizite Steuerkommunikation, die zwischen Sendern und Empfängern erforderlich ist, kann unter Verwendung von NACK-Angaben gehandhabt werden. Wenn ein Sender erstmals ein neues Ziel bzw. eine neue Priorität verwendet, richtet das LARQ-Modul des Senders einen neuen logischen Kanal ein und weist dem ersten Frame eine Anfangssequenznummer zu. Alle Zeitgeber werden zu Anfang deaktiviert, die Liste der gespeicherten Frames für den neuen Kanal gelöscht, die Kanalparameter auf ihre Voreinstellungswerte initialisiert und andere Zustandsinformationen (Zähler, etc.) in geeigneter Weise initialisiert.
Wenn bekannt ist, dass der Empfänger LARQ implementiert, dann wird der Kanaltyp auf SENDER eingestellt. Anderenfalls wird der Kanaltyp auf UNBEKANNTER-EMPFÄNGER eingestellt. An diesem Punkt sendet der Sender einen Erinnerungssteuer-Frame an den Empfänger und die Kanalvariable ProbeCount (initialisiert auf 0) wird inkrementiert (auf 1).
Wenn ein Empfänger erstmals von einem neuen Ziel oder mit einer neuen Priorität einen Frame mit einem LARQ-Header über einen neuen Kanal empfängt, wobei ein neuer Kanal eine beliebige Datenübertragung einer neuen Quelle ist, richtet der Empfänger einen neuen logischen Kanal ein. Die Liste der gehaltenen Frame für diesen neuen Kanal wird, sofern erforderlich, gelöscht ebenso wie alle Zähler und ähnlichen Zustandsvariablen für diesen Kanal und die Kanalkonfigurationsparameter werden auf ihre Anfangswerte eingestellt. Der Zustand wird initialisiert, um den neuen Frame als den nächsten in Sequenz befindlichen Frame anzunehmen, indem die Empfangssequenznummer auf die Sequenznummer eingestellt wird, die derjenigen im neuen Frame vorausgeht, wobei alle Sequenznummern markiert werden, für die der Zustand wie empfangen aufrechterhalten wird.
Ein Empfänger kann eine neue Sequenznummer von einer Quelle als völlig außer Sequenz befinden, entweder aufgrund von zu vielen verlorenen Frames oder einer Rückstellung durch den Sender. In diesem Fall sendet der Empfänger einfach alle gespeicherten Frames empor und stellt seinen Kanalzustand so zurück, als ob die neue Sequenznummer die erste von der Quelle des logischen Kanals wäre. Die Statistikzähler für den Kanal werden jedoch nicht zurückgestellt.
Nach der Überprüfung beginnt der Sender damit, Daten-Frames zu senden.
Senden eines Daten-Frames
Bei einem Ethernet-Netzwerk wird LARQ als Protokollschicht zwischen der Ethernet-Sicherungsschicht und dem Ethernet-Netztreiber implementiert. Daher passieren Ethernet-Frames, die zur Übertragung in das Netzwerk bereit sind, die LARQ-Protokollschicht. Wenn ein LARQ-Sendemodul einen Ethernet-Frame zur Übertragung empfängt, überprüft es seine Kanaltabelle, um zu bestimmen, ob der Frame für einen logischen Kanal bestimmt ist, der bereits existiert und ob er vom SENDER-Typ ist. Anderenfalls wird, wie vorstehend beschrieben, ein neuer Kanal initialisiert.
Wenn der Kanal bereits existiert, wird die Sendesequenznummer für den Kanal inkrementiert und ihr neuer Wert in einen LARQ-Header aufgenommen, der in den Frame unmittelbar nach dem Quellen-MAC-Adressenfeld eingefügt wird. Das Prioritätsfeld wird auf die durch die nächsthöhere Schicht spezifizierte Priorität oder auf null eingestellt, wenn der Sender keine Prioritäten verwendet. Die Steuer-Marke (Steuer-Flag) wird auf null eingestellt, ebenso wie andere im LARQ-Header nicht genutzte Felder. Der Frame wird dann abwärts an den Treiber zur normalen Übertragung weitergeleitet. Der Zeitpunkt, zu dem der Frame erstmals gesendet wurde, wird aufgezeichnet. Ein logischer Zeitgeber wird gestartet, der auf das Intervall T_sendHold eingestellt ist, dessen Ablauf bewirkt, dass der gespeicherte Frame freigegeben wird, es sei denn der Zeitgeber wurde aufgrund einer früheren Freigabe des Frames aus anderen Gründen angehalten. Ein logischer Erinnerungszeitgeber, der im nächsten Abschnitt beschrieben ist, wie ebenfalls (neu) gestartet.
Wenn der Kanaltyp des Senders bei dem Kanal, der mit dem neuen nun zu sendenden Frame übereinstimmt, KEIN-EMPFÄNGER ist, wird der Frame unverändert an den Treiber der unteren Schicht gesendet (ohne LARQ-Header).
Wenn der Typ UNBEKANNTER-EMPFÄNGER ist, wird der neue Daten-Frame unverändert gesendet, wobei der Sender jedoch auch den ProbeCount-Parameter des Kanals überprüft. Wenn ProbeCount kleiner als MaxProbeCount ist, sendet der Sender einen Erinnerungssteuer-Frame mit dem Ziel und der Priorität des Kanals (ohne den Anfangswert der Sendesequenznummer zu inkrementieren) und inkrementiert ProbeCount. Wenn ProbeCount seinen Grenzwert erreicht hat, wird der Kanaltyp in KEIN-EMPFÄNGER geändert.
Erinnerungssteuer-Frame-Erzeugung
Um die einzelnen Frames oder die letzten Frames in einer Folge zu schützen, wird ein kurzer Erinnerungssteuer-Frame gesendet, nachdem ein Intervall verstrichen ist, ohne dass weitere Frames zu senden waren. Der Erinnerungssteuer-Frame enthält die Sequenznummer des zuletzt gesendeten Frames, die Sendesequenznummer, so dass ein Empfänger den Verlust des Frames ermitteln und eine NACK senden kann. Die logische Implementierung für diese Funktion verwendet einen Zeitgeber, der auf T_remind eingestellt ist und jedes Mal gestartet wird, wenn ein neuer Frame über einen Kanal gesendet wird. Der Ablauf des Zeitgebers bewirkt, dass ein Erinnerungssteuer-Frame gesendet wird. Der Zeitgeber kann entweder nach dem Ablauf des Zeitgebers neu gestartet werden oder der Zeitgeber wird, bei manchen Ausführungsformen, erst dann neu gestartet, wenn ein neuer Frame gesendet wird.
Handhabung von NACKs und Neuübertragungen
Wenn ein NACK-Steuer-Frame empfangen wird, werden die Quellen- und Zieladressen im Ethernet-Header logisch umgekehrt, um den Kanal-Lookup durchzuführen. Die NACK wird im Zusammenhang mit dem Sender verarbeitet. Ein NACK-Steuer-Frame sollte nicht dazu verwendet werden, zu bewirken, dass ein neuer Kanal mit der ursprünglichen Sendestation als Empfänger eingerichtet wird, da die einzige Sequenznummer im LARQ-Header den ursprünglichen Kanal des Senders betrifft. Der Sender sendet normalerweise sämtliche angezeigten Frames erneut, die noch verfügbar sind, obgleich das MinimumRxtInterval verwendet werden kann, um zu häufige Neuübertragungen einzelner Frames zu verhindern.
Wenn eine NACK empfangen wurde, wird jede der angegebenen Sequenznummern verarbeitet, von der ältesten zur neuesten. Wenn die Sequenznummer neu und der Frame noch verfügbar ist, überprüft der Sender, ob der Frame überhaupt schon erneut gesendet worden ist (Neuübertragungsmarke oder Neuübertragungs-Flag). Wenn nicht, wird der Frame sofort erneut gesendet, die Neuübertragungsmarke gesetzt und ein Zeitstempel der Neuübertragungszeit des Frames gespeichert. Manche Implementierungen können die Statistik hinsichtlich des Intervalls zwischen dem ursprünglichen Senden der Frames und erneuten Übertragungen aktualisieren. Wenn der Frame zuvor bereits erneut gesendet worden ist, dann wird das Intervall vom Zeitpunkt seiner erneuten Übertragung bis zur Gegenwart berechnet und mit dem Neuübertragungsintervall verglichen. Wenn zu wenig Zeit verstrichen ist, wird der Frame nicht erneut gesendet, anderenfalls wird der Frame erneut gesendet und sein Neuübertragungszeitstempel aktualisiert.
Empfang von Frames
Empfangene Frames mit dem LARQ-Ethertyp werden durch das LARQ-Protokollmodul verarbeitet. NACK-Steuer-Frames werden unabhängig von anderen empfangenen LARQ-Frames gehandhabt, wie vorstehend beschrieben. LARQ-Daten-Frames und Erinnerungssteuer-Frames werden ähnlich gehandhabt, da der Großteil der komplexen Verarbeitung das Management des Sequenznummernzustandes umfasst. Wenn das LARQ-Modul bestimmt hat, dass ein Frame zur nächsthöheren Schicht gesendet empor werden soll, wird der LARQ-Header entfernt, so dass die Ethernet-Quellen- und -Ziel-MAC-Adressen wieder an das ursprüngliche Ethernet-Typ-/Längenfeld angrenzen, und der Frame empor geleitet. Die Frame-Handhabung hängt sowohl von der Sequenznummer des empfangenen Frames als auch vom Zustand der jüngeren Sequenznummern ab. Einige Implementierungen können sich dafür entscheiden, die In-Reihenfolge-Abgabe von Frames an die nächsthöhere Schicht nicht auszuführen, wobei in diesem Fall die Handhabung der aktuellen Empfangs-Frames deutlich einfacher ist, da keine Zwischenspeicherung erforderlich ist.
Wenn die Sequenznummer des empfangenen Frames nicht außer Sequenz, aber auch keine jüngere Nummer ist (älter als MaxRxSaveCount der aktuellen Empfangssequenznummer), wird er verworfen, wobei eine geeignete statistische Erfassung durchgeführt wird. Wenn die Sequenznummer des empfangenen Frames eine jüngere Nummer ist (innerhalb von MaxRxSaveCount der Empfangssequenznummer), jedoch bereits als empfangen oder verloren markiert worden ist, wird er verworfen, wobei eine geeignete statistische Erfassung durchgeführt wird. Wenn er nicht verworfen wird, wird ein empfangener Frame mit einer jüngeren Sequenznummer als empfangen markiert. Der Empfänger kann die Statistik anhand der Zeit berechnen, die es gedauert hat, einen erneut gesendeten Frame zu empfangen, und zwar ab dem Zeitpunkt, zu dem er erstmals vermisst wurde, um eine adaptive Neuübertragung von NACKs zu unterstützen.
Dann wird der Frame, wenn keine Neuordnung ausgeführt wird, zur nächsthöheren Schicht empor gesendet. Wenn Frames neu geordnet werden und der empfangene Frame nicht über die älteste fehlende Sequenznummer verfügt, wird der Frame gespeichert und das RxFrameFlag (Empfangs-Frame-Marke) für seine Sequenznummer auf 1 gesetzt. Wenn der empfange Frame die älteste fehlende Sequenznummer besitzt, wird der Frame zur nächsthöheren Schicht empor gesendet, zusammen mit sämtlichen weiteren, in Sequenz befindlichen, gespeicherten Frames. Wenn gespeicherte Frames empor gesendet werden, wird das RxFrameFlag für jeden Frame auf 0 gesetzt.
Wenn die Sequenznummer eines empfangenen Frames (kein NACK-Steuer-Frame) neu ist und sich innerhalb eines Fensters von MaxRxSaveCountChannel der Empfangssequenznummer befindet, aktualisiert der Empfänger seinen Zustand, indem er das Fenster von jüngeren Sequenznummern vorrückt, bis die Sequenznummer des empfangenen Frames aktuell ist. Wenn sich die neue Sequenznummer des empfangenen Frames außerhalb der gültigen Sequenznummern befindet, sollten die Sequenznummern als außerhalb der Sequenz befindlich und die Kanalrückstellungsfunktion durchgeführt werden, so dass sich der neue Frame in Sequenz befindet.
Die Empfangssequenznummer wird wiederholt um 1 inkrementiert (Modulo 256 oder einer anderen Größe des Sequenzraumes), bis sie der Sequenznummer des empfangenen Frames entspricht. Bei jeder Aktualisierung wird der Zustand der neuen aktuellen Sequenznummer als fehlend initialisiert und der Zeitpunkt, zu dem sie erstmals vermisst wurde, aufgezeichnet, es sei denn die aktuelle Nummer ist die des empfangenen Frames und der empfangene Frame ist ein gültiger Daten-Frame (keine Erinnerung und nicht fehlerhaft). Wenn der Frame als empfangen markiert wird, wird er außerdem gespeichert, möglicherweise temporär. Bei jeder neuen Sequenznummer verändert sich auch die hintere Kante des Schiebefensters von jüngeren Sequenznummern. Die neue älteste jüngere Sequenznummer wird überprüft, um festzustellen, ob ein gehaltener Frame vorhanden ist. Wenn ein gespeicherter Frame (RxFrameFlag = 1) vorhanden ist, wird dieser Frame an die nächsthöhere Schicht empor gesendet und RxFrameFlag auf 0 gesetzt. Wenn die aktuelle Sequenznummer vollständig auf die empfangene Sequenznummer aktualisiert worden ist, ruft der Empfänger die Geschichte der jüngeren Frames ab, beginnend mit der ältesten Sequenznummer, die noch nicht verloren gegangen oder empor gesendet worden ist. Wenn diese Sequenznummer einen gehaltenen Frame umfasst, dann wird dieser Frame und jeder andere darauf folgende, in Sequenz befindliche, gehaltene Frame, zur nächsthöheren Schicht empor gesendet. Dies führt dazu, dass der soeben empfangene Frame, sofern angemessen, an die nächsthöhere Schicht empor gesendet wird.
Timeouts (Zeitüberschreitungen) bei verlorenen Frames
Zu dem Zeitpunkt, zu dem eine fehlende Sequenznummer erstmals bemerkt wurde, wurde ein Zeitstempel aufgezeichnet. Ein Zeitgeber mit dem Wert T_rcvLost wurde für diese Sequenznummer logisch gestartet. Wenn der Frame empfangen wird, dann wird der Zeitgeber (logisch) gestoppt. Wenn der Frame nie empfangen wurde und der Zeitgeber abläuft, dann wird die Sequenznummer als verloren markiert (RxLostFlag = 1). Wenn eine Sequenznummer als verloren markiert wird, wird die nächsthöhere Sequenznummer überprüft, um festzustellen, ob ein gehaltener Frame vorhanden ist. Wenn ja, wird der gehaltene Frame (nun der älteste, noch nicht empor gesendete Frame) zusammen mit allen darauf folgenden, in Sequenz befindlichen, gehaltenen Frames zur nächsthöheren Schicht empor gesendet.
Das vorstehend beschriebene Verfahren wird wiederholt, so lange der Kanal offen bleibt. Die 12–13 zeigen Beispiele dafür, wie LARQ-Frames gehandhabt werden könnten.
14 zeigt ein typisches Netzwerk 200, bei dem die vorliegende Erfindung verwendet werden könnte. Wie in 14 gezeigt, verwendet das Netzwerk 200 vorhandene Haustelefonleitungen, um ein Netzwerk zu bilden. Ein Personal-Computer 202 enthält eine Netzwerkkarte 204, die über eine Verbindung zu einem RJ11-Stecker 206 an das Netzwerk 200 angeschlossen wird. Andere Netzwerkgeräte, wie etwa ein vernetztes Haushaltsgerät 208 (ein Drucker, ein Videorecorder, eine Klimaanlage oder dergleichen), könnten ebenfalls in ähnlicher Weise an das Netzwerk 200 angeschlossen werden. Unter Verwendung des LARQ-Protokolls könnten die an das Netzwerk 200 angeschlossenen Geräte mit höheren effektiven Datenraten kommunizieren als dies der Fall wäre, wenn LARQ nicht verwendet würde.
Die vorstehende Beschreibung dient der Veranschaulichung und nicht der Einschränkung. Für Fachleute auf dem Gebiet gehen aus einem Studium dieser Offenbarung viele Variationen der Erfindung hervor. In der vorstehenden Beschreibung sind, rein beispielhaft, Modifikationen eines Ethernet-Netzwerks zur Unterstützung des LARQ-Protokolls ausgeführt, das LARQ-Protokoll ist jedoch nicht auf ein solches Netzwerk beschränkt und kann unter Anwendung der Lehren dieser Offenbarung leicht modifiziert werden, um über andere Netzwerktypen betrieben zu werden. Der Schutzumfang der Erfindung sollte daher nicht anhand der vorstehend Beschreibung bestimmt werden, sondern stattdessen anhand der anhängigen Ansprüche zusammen mit sämtlichen Entsprechungen derselben.

Claims

Verfahren, das in einer Frame-Switched-Netzwerkvorrichtung zum Senden von Frames von einem Sender an einen Empfänger über einen möglicherweise unzuverlässigen Kanal verwendbar ist, wobei das Verfahren das Bilden eines Frame am Sender umfasst und der Frame an den Empfänger zu sendende Daten enthält, wobei das Verfahren umfasst: Einfügen einer aus einem Satz von Frame-Kennungen ausgewählten Frame-Kennung in den Frame, Zurückhalten einer Kopie des Frames am Sender, Senden des Frames vom Sender an den Empfänger über den möglicherweise unzuverlässigen Kanal, und zwar unabhängig von der Verfügbarkeit des Empfängers, Bestimmen einer Frame-Kennung für den empfangenen Frame, bei Empfang eines Frames am Empfänger, durch ein LARQ-Protokoll in einem LARQ-Handler (100) des Empfängers, wobei der LARQ-Handler (100) in der Sicherungsschicht des ISO-Modells enthalten ist, Ermitteln, durch das LARQ-Protokoll in dem LARQ-Handler (100), anhand der Frame-Kennung, ob ein früherer Frame in der physikalischen Schicht des ISO-Modells gefehlt hat, Senden einer negativen Bestätigung vom Empfänger an den Sender durch den LARQ-Handler (100) des Empfängers, wenn ein fehlender früherer Frame ermittelt wird, wobei die negative Bestätigung eine Angabe des fehlenden früheren Frames umfasst, Bestimmen der Frame-Kennung des fehlenden früheren Frames durch das LARQ-Protokoll im LARQ-Handler (100) des Senders, wenn eine negative Bestätigung am Sender empfangen wird, und erneutes Senden des fehlenden früheren Frames, wenn eine Kopie des fehlenden früheren Frames noch immer am Sender zurückgehalten wird, und Freigeben der zurückgehaltenen Kopie des gesendeten Frames, und zwar unabhängig von der Bestätigung eines erfolgreichen Empfangs des gesendeten Frames durch den Empfänger, wenn eine Speicherbeschränkung erreicht wird.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch die negative Bestätigung, die eine Frame-Kennung und eine Zählung fehlender Frames enthält, welche zusammen einen oder mehrere Frames, einschließlich des fehlenden früheren Frames, bestimmen.
Verfahren nach Anspruch, das ferner gekennzeichnet ist durch das Senden eines Erinnerungs-Frames vom Sender an den Empfänger, um es dem Empfänger zu ermöglichen, einen fehlenden früheren Frame zu ermitteln, der an einem Ende einer Frame-Sequenz fehlt.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch das Einfügen negativer Bestätigungsangaben in Frames, die vom Empfänger an den Sender gesendete Daten enthalten, wenn der Empfänger an den Sender zu sendende Daten aufweist und wenigstens einen fehlenden früheren Frame ermittelt hat.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch: Senden der negativen Bestätigung wenigstens zweimal vom Empfänger an den Sender, Verzögern einer zweiten negativen Bestätigung vom Empfänger für einen Antwortzeitraum, wobei der Antwortzeitraum mit der Zeitverzögerung in Beziehung steht, die zwischen dem Senden der ersten negativen Bestätigung und dem erwarteten Empfang eines erneut gesendeten Frames erwartet wird, und ein dynamisch bestimmter Zeitraum ist, der anhand gemessener Übertragungszeiträume bestimmt wird, und einmaliges erneutes Senden des fehlenden früheren Frames für jede empfangene negative Bestätigung.
Verfahren nach Anspruch 1, das ferner dadurch gekennzeichnet ist, dass: der möglicherweise unzuverlässige Kanal ein Teil eines Netzwerks ist, das mehrere Sender und mehrere Empfänger miteinander verbindet, eine Quellenkennung und eine Zielkennung in jedem von einem Quellensender gesendeten Frame enthalten sind, und eine selektive Verarbeitung dieser Frames, die eine den Zielempfänger bestimmende Zielkennung aufweisen, an einem Zielempfänger stattfindet.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch die Angabe des fehlenden früheren Frames, die eine Frame-Kennung eines ersten fehlenden Frames und mehrerer auf den ersten fehlenden Frame folgender, sequenzieller fehlender Frames umfasst.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch das Speichern der Inhalte des Frames über einen Pufferzeitraum und das Verfolgen des Pufferzeitraums für jeden Frame.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch die Speicherbeschränkung, die entweder eine zeitliche Beschränkung ist, bei der Frames nach einem Pufferzeitraum freigegeben werden, oder eine Speicherbeschränkung, bei der der älteste Frame freigegeben wird, wenn ein neuer Frame im Frame-Puffer gespeichert werden soll und der Frame-Puffer voll ist.
Verfahren nach Anspruch 1, das ferner dadurch gekennzeichnet ist, dass das Initialisieren eines neuen Kanals zur Übertragung von Daten-Frames vom Sender über den neuen Kanal auf eine erste Weise durchgeführt wird, wenn bekannt ist, dass alle Stationen des Netzwerks LARQ ausführen, wobei der Sender eine Startsequenznummer auswählt, die Art des logischen Kanals in der Kanaltabelle auf eine Marke setzt, die den Kanal als LARQ kennzeichnet, und den LARQ-Header dem Frame hinzufügt.
Verfahren nach Anspruch 1, das ferner gekennzeichnet ist durch das Initialisieren eines neuen Kanals zur Übertragung von Daten-Frames vom Sender über den neuen Kanal auf eine zweite Weise, wenn dem Sender nicht bekannt ist, ob der Empfänger LARQ ausführt, wobei der Sender den neuen Kanal mit einer Startsequenznummer und einer Marke einrichtet, die den neuen Kanal nicht als LARQ kennzeichnet, das Senden des Daten-Frames, der keinen LARQ-Header umfasst, und das Senden eines LARQ-Erinnerungs-Frames an den Empfänger unter Verwendung der Ziel-MAC-Adresse und Priorität des Daten-Frames.
Frame-Switched-Netzwerkvorrichtung zum Senden von Frames, die an einem Sender gebildet wurden und vom Sender an einen Empfänger über einen möglicherweise unzuverlässigen Kanal zu sendende Daten enthalten, wobei die Frame-Switched-Netzwerkvorrichtung umfasst: den Sender, der eine Sendersteuerlogik umfasst, die das Senden vom Sender an den Empfänger über den möglicherweise unzuverlässigen Kanal steuert, und zwar unabhängig von der Verfügbarkeit des Empfängers an dem unzuverlässigen Kanal, wobei ein gesendeter Frame an einen Empfänger zu sendende Daten enthält und der Frame ferner eine aus einem Satz von Frame-Kennungen ausgewählte Frame-Kennung umfasst, und die Sendersteuerlogiksteuerung dafür konfiguriert ist, eine Kopie des Frames am Sender zurückzuhalten, den Empfänger, der einen LARQ-Handler (100) zum Handhaben (handling) eines LARQ-Protokolls umfasst, wobei der LARQ-Handler (100) in der Sicherungsschicht des ISO-Modells angeordnet ist und wobei der LARQ-Handler (100) den Empfang des Frames am Empfänger steuert, die Frame-Kennung für den empfangenen Frame bestimmt, anhand der Frame-Kennung ermittelt, ob ein früherer Frame in der physikalischen Schicht des ISO-Modells gefehlt hat, das Senden einer negativen Bestätigung vom Empfänger an den Sender steuert, wenn ein fehlender früherer Frame ermittelt wird, wobei die negative Bestätigung eine Angabe des fehlenden früheren Frames umfasst, und die Sendersteuerlogik, die einen LARQ-Handler (100) zum Handhaben eines LARQ-Protokolls umfasst, wobei der LARQ-Handler (100) in der Sicherungsschicht des ISO-Modells angeordnet ist und wobei der LARQ-Handler (100) bei Erhalt einer negativen Bestätigung am Sender die Frame-Kennung des fehlenden früheren Frames bestimmt und wobei der Sender den fehlenden früheren Frame erneut sendet, wenn eine Kopie des fehlenden früheren Frames noch immer am Sender zurückgehalten wird, und die zurückgehaltene Kopie des gesendeten Frames freigegeben wird, und zwar unabhängig von einer Bestätigung eines erfolgreichen Empfangs des gesendeten Frames durch den Empfänger, wenn eine Speicherbeschränkung erreicht wird.