-
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 |
TsendHold | 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. |
TrcvLost | 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 TsendHold. |
Tremind | 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. |
TminRtx | 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. |
Trequest | 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 TsendHold 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 Tremind 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 TrcvLost 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.