DE60309527T2

DE60309527T2 - System und Verfahren zur Identifikation von Grenzen von Nachrichten höherer Schichten

Info

Publication number: DE60309527T2
Application number: DE60309527T
Authority: DE
Inventors: Uri 92606 Irvine Elzur
Original assignee: Broadcom Corp
Current assignee: Broadcom Corp
Priority date: 2002-03-08
Filing date: 2003-03-07
Publication date: 2007-09-13
Anticipated expiration: 2023-03-08
Also published as: US20080025315A1; US20100220729A1; EP1345382A3; US8345689B2; EP1345382B1; US20100223540A1; DE60309527D1; US20030172342A1; US8958440B2; US8451863B2; US20130262607A1; US8135016B2; EP1345382A2; US7295555B2

Description

HINTERGRUND DER ERFINDUNG
Das Transmission Control Protocol/Internet Protocol (TCP/IP) ist ein Protokoll, das bei der Nachrichtenübermittlung weit verbreitet ist. Das Empfangen, Zwischenspeichern, Verarbeiten und Speichern der in TCP Segmenten kommunizierten Daten kann jedoch ein beträchtliches Ausmaß von Host-Verarbeitungsleistung und Speicherbandbreite beim Empfänger verbrauchen. In einem typischen System umfasst der Empfang die Verarbeitung in mehreren Kommunikationsschichten, bevor die Daten schließlich an ihr Endziel, einen Anwendungspuffer, kopiert werden. Eine typische Netzwerkkarte (Network Interface Card; NIC) verarbeitet die Schicht 2 (Layer 2) Header (z.B. Ethernet Header) und kopiert dann die verbleibenden Header (z.B. Schicht 3 (Layer 3) und höhere Header) und/oder die Upper Layer Protocol (ULP) Nutzlast (payload) in einen Transport-Puffer (z.B. einen TCP Puffer) zur Vernetzungs- und Transportschicht-Verarbeitung. Die Transport- und Vernetzungs-Verarbeitung (z.B. TCP/IP, wenn TCP das Transportschicht-Protokoll ist) entfernt die Schicht 3 und Schicht 4 Header und kopiert die verbleibenden Header und die ULP Nutzlast in einen anderen Puffer. Dieser Vorgang wiederholt sich auf der nächsten Ebene, bis der letzte Header entfernt ist und die ULP Nutzlast in den von der Anwendung zugeordneten Puffer kopiert ist. Die meisten Bytes in den Frames sind Nutzlast (z.B. Daten), aber sie werden immer wieder kopiert, während der Steuerabschnitt der Frames (z.B. die Header) schichtweise verarbeitet werden. Die Host-CPU, die einen großen Overhead von Verarbeitung und Kopieren übernimmt, einschließlich z.B. der Handhabung vieler Unterbrechungen und Kontextwechsel, führt dies durch. Somit sind zur Anwendungsverarbeitung, der gewünschten Verwendung einer Servervorrichtung, sehr wenige Takte verfügbar. Für Hochgeschwindigkeits-Vernetzung (z.B. 10 Gigabit pro Sekunde) belastet das zusätzliche Kopieren das Speicher-Untersystem des Computers. Für durchschnittlich drei Datenkopien wird das Speicher-Untersystem der meisten im Handel erhältlichen Servercomputer zum Engpass, wodurch verhindert wird, dass das System 10 Gigabit Netzwerk-Verkehr unterstützt. Da TCP/IP das vorherrschende Transport-Protokoll ist, das von den meisten heutigen Anwendungen verwendet wird, wäre es daher von Nutzen, die Belastung dieser Verarbeitung zu verringern, um beispielsweise eine skalierbare geringe CPU-Verwendung zu erreichen, wenn mit einer gleichrangigen Maschine kommuniziert wird.
Zur Reduzierung des Overheads ist es nötig sicherzustellen, dass Daten ein Mal von der Leitung in den Anwendungspuffer kopiert werden. Ein Problem ist, dass die NIC nicht weiß, welcher Teil eines empfangenen Frames beispielsweise ULP Daten sind, und welcher Teil ULP-Steuerung ist. Es ist erforderlich, dass der Sender die Frames so aufbaut, dass es für die Empfänger-NIC einfach ist, diese Unterscheidung zu treffen. Jedes ULP-Protokoll kann jedoch eine eigene Art des Mischens von Daten und Steuerung aufweisen, wodurch es sehr schwierig wird, eine NIC zu konstruieren, die alle unterstützt.
Ein weiteres Problem ist, dass das TCP einen Bytestrom-Dienst für das ULP anbietet. Es ist nicht immer möglich, den Anfang einer ULP Nachricht (z.B. die Protokolldateneinheit; Protocol Data Unit (PDU)) innerhalb dieses Endlosstroms von Bytes (z.B. der TCP Daten) zu bestimmen. Unter der Annahme, dass die Frames ohne Resegmentierung beim Empfänger (z.B. einem Server) ankommen, kann der Empfänger den Frame mittels TCP entpacken und könnte den ULP Header lokalisieren. Der ULP Header kann beispielsweise Steuerinformationen enthalten, die eine Stelle in dem Anwendungspuffer identifizieren können, an die die ULPDU (Upper Layer Protocol Data Unit; Protokolldateneinheit höherer Schichten) direkt platziert werden kann. Doch auch wenn ein Sender so ausgestaltet werden könnte, dass er in jedem TCP Segment eine TCP Schicht verwendet, die ULP Steuerinformationen beginnend in dem ersten Nutzlast-Byte des TCP Segments platzieren kann, könnte dies nicht ausreichend sein. Dies deshalb, weil Resegmentierung in TCP-/IP-Kommunikationen nicht ungewöhnlich ist. Es gibt keine Garantie, dass die TCP Segmente am anderen Ende der Leitung so ankommen, wie sie vom Sender aufgebaut worden sind, weil es beispielsweise zwischen dem Sender und dem Empfänger Netzwerk-Architektur-Strukturen geben kann. Eine Zwischenbox oder Mittelbox (z.B. eine Firewall) kann beispielsweise die TCP Verbindung mit dem Sender beenden und, ohne dass der Sender oder der Empfänger dies merkt, eine andere TCP Verbindung mit dem Empfänger aufbauen. Die Zwischenbox kann die ankommenden Frames resegmentieren (z.B. kleinere TCP Nutzlasten verwenden). Somit kann ein einzelner Frame in die Zwischenbox eintreten, aber eine Vielzahl kleinerer Frames, jeder mit eigenem TCP Header, aus der Zwischenbox austreten. Dieses Verhalten der Zwischenbox kann in der richtigen Reihenfolge platzierten Steuer- und Datenabschnitte durcheinander bringen.
Im Fall der Resegmentierung kann sich der Empfänger einer Reihe von Herausforderungen gegenüber sehen. Es ist beispielsweise möglich, dass der Empfänger nichts von dem Vorhandensein von Zwischenboxen zwischen dem Sender und dem Empfänger weiß. Außerdem kann es sein, dass das von dem Sender verwendete Anfangs-Segmentierschema nicht das von dem Empfänger empfangene Segmentier-Schema ist. Somit ist es möglich, dass, obwohl der Empfänger die kleineren Frames ordnen kann, er beispielsweise den ULP Header und die ULPDU nicht lokalisieren kann. Demgemäß ist es möglich, dass der Empfänger die Steuer- und Grenzinformationen, die gegebenenfalls erforderlich sind, um die ULPDU an der richtigen Stelle z.B. des Anwendungspuffers des Empfängers zu platzieren, nicht ermitteln kann.
Ein weiteres Problem ist, dass TCP/IP Netzwerke Segmente außer der Reihe liefern können. Es ist möglich, dass das ULP eine PDU aufweist, die länger ist, als ein TCP Segment, das auf 1460 Byte beschränkt sein kann, wenn es mit Ethernet verwendet wird, und die ULPDU kann zwischen einer Vielzahl von TCP Segmenten aufgesplittet sein. Daher können einige TCP Segmente beispielsweise nur Daten und keine Steuer-Informationen enthalten, die die empfangende NIC instruieren, wohin die Daten zu platzieren sind. Der Empfänger steht vor der Wahl, entweder die Segmente außer der Reihe fallen zu lassen und eine neue Übertragung anzufordern, was hinsichtlich Verzögerung und Leistungsverlust teuer ist, oder die Segmente außer der Reihe zwischenzuspeichern, bis alle fehlenden Segmente empfangen worden sind. In einigen Implementierungen kann das Ansammeln aller defekten Segmente gewählt werden, um auf den Empfang der fehlenden TCP Segmente zu warten und sie dann in der richtigen Reihenfolge zu platzieren. Die empfangende NIC kann dann den ganzen Satz TCP Segmente verarbeiten, während sie den Steuerabschnitt verwendet, um Datenplatzierungs-Informationen zu erhalten. Durch dieses Vorgehen entstehen zusätzliche Kosten für den temporären Puffer, und es werden eine Hochleistungs-CPU und ein breiterer Datenpfad, als sonst benötigt, verwendet. Die empfangende NIC verarbeitet alle angesammelten TCP Segmente parallel zur Verarbeitung anderer TCP Segmente mit Leitungsgeschwindigkeit, da der Verkehr auf dem Link die ganze Zeit anhält. Die Segmente außer der Reihe können für den Empfänger eine „Verarbeitungs-Blase" entstehen lassen.
Ein Lösungsvorschlag zur Lokalisierung des ULP Headers ist die Verwendung des TCP ULP Framing (TUF)-Protokolls. Gemäß dem TUF-Protokoll platziert ein Sender einen bestimmten Wert (z.B. einen Schlüssel) in dem TCP Segment als erstes Byte, das dem TCP Header folgt, wie in 1 gezeigt ist. Der Schlüssel kann ein eindeutiger Wert sein (z.B. ein bestimmter 48 Bit Wert), nach dem der Empfänger suchen kann. Demgemäß hat der Empfänger, wenn er den Schlüssel fin det, beispielsweise auch den ULP Header oder den Beginn der Steuerinformationen (z.B. das erste Byte des DDP/RDMA Headers; Direct Data Placement/Remote Direct Memory Access Header) gefunden. Das TUF-Protokoll ist jedoch von wahrscheinlichkeitstheoretischer Natur. Der eindeutige Wert kann beispielsweise zufällig in der ULPDU auftauchen. Des Weiteren kann der Empfänger angesichts beispielsweise der Resegmentierung oder TCP Neuübertragung (z.B. von einem ungeeigneten TCP Sender) den Beginn der Steuerinformationen falsch identifizieren, was aufgrund der Platzierung an der falschen Stelle des Host-Speichers zu einer stillen Korruption der Daten führt. Obwohl die Länge des eindeutigen Werts vergrößert werden kann, um den Fall einer solchen Falschidentifizierung zu verringern, besteht die Wahrscheinlichkeit immer. Der Schlüssel kann auch ein Sicherheitsrisiko darstellen, wenn ein unberechtigter Empfänger den eindeutigen Wert erhalten kann, der es ihm ermöglicht, auf die ULP Nutzlast zuzugreifen.
Eine weitere Lösung zum Lokalisieren eines bestimmten Headers ist es, ein Fixed Interval Markers (FIM)-Protokoll zu verwenden. Das FIM-Protokoll verwendet nur vorwärts zeigende Marker und ist auf internet Small Computer System Interface (iSCSI)-Anwendungen beschränkt. Bei dem FIM-Protokoll wird ein vorwärts zeigender Marker an einer bekannten Stelle in dem TCP-Bytestrom platziert. Dies ermöglicht es dem Empfänger, ihn in dem endlosen TCP-Bytestrom möglicherweise zu lokalisieren. Der FIM Marker zeigt nach vorne zum Beginn des iSCSI Headers, wie in 2 gezeigt ist. Der Marker wird standardmäßig alle 8192 Bytes gesetzt, obwohl dies verhandelbar ist. Das FIM-Protokoll kann jedoch einen Nachteil haben, weil der Marker nur sparsam, alle 8192 Bytes, gesetzt wird. Demgemäß ist es möglich, dass viele Frames zwischengespeichert werden müssen, bevor oder wenn der iSCSI Header zu identifizieren ist. Es kann sein, dass auf andere iSCSI Header kein FIM Marker zeigt, so dass der Empfänger die TCP Segmente verarbeiten muss, um die iSCSI Daten platzieren zu können. Das FIM-Protokoll liefert auch keine Garantie, dass der iSCSI Header nach dem TCP Header angeordnet wird, oder dass der iSCSI Header überhaupt vollständig in einem TCP Segment platziert wird. Um das FIM-Protokoll zu verwenden, muss der Empfänger die Stelle der TCP Sequenz, auf die dieser FIM zeigt, lokal speichern. Er verwendet diese, wenn das TCP Segment mit dieser Stelle empfangen wird (d.h. zusätzliche Zustandsinformationen werden für jeden empfangenen FIM gespeichert, bis das entsprechende TCP Segment mit dem iSCSI-Header empfangen ist). Das FIM-Protokoll macht keinen Vorschlag und gibt keine Lehre hinsichtlich der Verarbeitung defekter TCP Segmente, wenn die außer der Reihe empfangenen TCP Segmente kleiner sind, als der FIM-Abstand (z.B. 8192 Bytes beim Standard). Das FIM-Protokoll ist ebenfalls auf iSCSI-Anwendungen beschränkt und kann für das Framing-Problem, das sich allen Anwendungen stellen kann, die das Hochgeschwindigkeits-TCP/IP-Protokoll verwenden, keine generische Lösung liefern. Ein Protokoll, das Fixed Interval Markers verwendet, ist in draft-iets-ips-iSCSI-10 offenbart.
Weitere Einschränkungen und Nachteile herkömmlicher und traditioneller Ansätze werden für den Fachmann aus einem Vergleich derartiger Systeme mit einigen Aspekten der vorliegenden Erfindung, die im Rest der vorliegenden Anmeldung unter Bezug auf die Zeichnungen dargelegt sind, offensichtlich.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung ist durch den Gegenstand des unabhängigen Anspruchs 1 definiert.
Ein Beispiel stellt ein Verfahren bereit, das einen Marker Header in einem empfangenen TCP Frame lokalisiert. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Lokalisieren eines nach hinten zeigenden Markers; und Verwenden von Informationen, die in dem nach hinten zeigenden Marker gespeichert sind, um den Frame Header zu lokalisieren.
Ein Beispiel stellt ein Verfahren bereit, das die Resegmentierung eines TCP Segments ermittelt. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Lokalisieren eines nach hinten zeigenden Markers in dem TCP Segment; Bestimmen einer Stelle eines Frame Headers unter Verwendung von Informationen, die in dem nach hinten zeigenden Marker gespeichert sind; und Bestimmen, dass eine Resegmentierung des TCP Segments stattgefunden hat, wenn sich der Frame Header nicht vorne in dem TCP Segment nach einem TCP Header des TCP Segments befindet.
Ein Beispiel stellt ein Verfahren bereit, das eine Resegmentierung eines TCP Segments ermittelt. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Lokalisieren eines nach hinten zeigenden Markers in dem TCP Segment; Bestimmen einer Stelle eines Frame Headers unter Verwendung von Informationen, die in dem nach hinten zeigenden Marker gespeichert sind; und Bestimmen, dass eine Resegmentierung des TCP Segments stattgefunden hat, wenn der nach hinten zeigende Marker auf eine Stelle außerhalb des TCP Segments zeigt.
Ein Beispiel stellt ein Verfahren bereit, das eine Resegmentierung eines TCP Segments ermittelt. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Lokalisieren eines nach hinten zeigenden Markers in dem TCP Segment; Bestimmen einer Stelle eines Frame Headers unter Verwendung von Informationen, die in dem nach hinten zeigenden Marker gespeichert sind; und Bestimmen, dass eine Resegmentierung des TCP Frames stattgefunden hat, wenn die Anzahl von Nutzlast-Bytes in dem TCP Segment nicht gleich der Anzahl ist, die von einem Frame Header Längenfeld plus einem Pad und einem CRC Feld angegeben wird.
Ein Beispiel stellt ein Verfahren bereit, das eine Resegmentierung eines TCP Segments ermittelt. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Lokalisieren eines nach hinten zeigenden Markers in dem TCP Segment; Bestimmen einer Stelle eines Frame Headers unter Verwendung von Informationen, die in dem nach hinten zeigenden Marker gespeichert sind; und Bestimmen, dass eine Resegmentierung des TCP Frames stattgefunden hat, wenn die Anzahl von Nutzlast-Bytes in dem TCP Segment nicht gleich der Summe aller Werte eines Frame Header Längenfelds plus Pads und CRC Feldern für mehrere Frame PDUs ist, die in einem TCP Segment platziert sind.
Ein Beispiel stellt ein Verfahren bereit, das einen potentiellen Fehler in einem Bytestrom-Transportprotokoll-Segment ermittelt durch Vergleichen eines empfangenen Fehlerermittlungscodes mit einem berechneten Fehlerermittlungscode über eine Frame PDU. Das Verfahren kann einen oder mehrere der folgenden Schritte umfassen: Wenn der Vergleich vor der Verarbeitung des Bytestrom-Transportprotokolls stattfindet, Verwerfen des empfangenen Segments und Berufen auf das Bytestrom-Transport-Wiederherstellungs-Protokoll ohne Notwendigkeit einer spezifischen Frameschicht-Wiederherstellung; wenn der Vergleich nach der Verarbeitung des Bytestrom-Transportprotokolls stattfindet, Abbrechen der Verbindung; und Zulassen zusätzlichen Schutzes über das Bytestrom-Transport-Prüfsummen-Protokoll hinaus.
Ein Beispiel stellt ein Verfahren bereit, bei dem von einem TCP Segment keine Informationen gespeichert werden, um die Verarbeitung eines anderen TCP Segments zu ermöglichen.
Ein Beispiel stellt ein Verfahren bereit, das zusätzlichen Schutz eines Markers bereitstellt durch Anhängen von 16 Bits eines Fehlerermittlungscodes, beispielsweise Cyclical Redundancy Checking (CRC) (zyklische Redundanzprüfung), z.B. CRC16, an den Marker.
Ein Beispiel stellt ein Verfahren bereit, das ermöglicht, dass zusätzliche Informationen in den reservierten Bits (z.B. 16 reservierte Bits) des Markers getragen werden. Dies kann beispielsweise ein weiterer Marker für einen ULP-spezifischen Zweck oder beliebige andere nützliche Daten sein, die in einer Sequenz dieser 16 Bit Einheiten getragen werden können. Das reservierte Feld kann beispielsweise zum Signalisieren zwischen 2 ULPs verwendet werden.
Bei einigen Ausführungsformen kann die vorliegende Erfindung ein Frame Protokoll definieren, das es dem Empfänger ermöglicht, den Beginn von ULP-Steuer- und -Datenabschnitten, die in dem TCP/IP Bytestrom eingebettet sind, zu identifizieren. Jedes TCP Segment kann selbstbeschreibend sein, um eine Datenplatzierung zu ermöglichen, wenn es in der richtigen Reihenfolge oder außer der Reihe empfangen wird. Auf dem Frame Protokoll geschichtet kann sich beispielsweise ein Direct Data Placement/Remote Direct Memory Access (DDP/RDMA) Protokoll Header befinden. Der DDP/RDMA Header kann die Informationen hinsichtlich des zu verwendenden Puffers und der Offsets in diesen Puffer tragen. Sobald der Empfänger das DDP/RDMA Feld findet, kann er die Steuer- und Datenabschnitte einzeln benennen und die ULP Daten ohne Verarbeitung der protokollspezifischen Steuerinformationen platzieren. Die obere Schicht (Upper Layer (UL)) kann ein ULP Paket bilden, indem ULP Steuerinformationen oder eine ULP Dateneinheit (ULP Data Unit (ULPDU)) als Nutzlast für das Lower Layer Protocol (Protokoll niedrigerer Schicht) (z.B. RDMA/DDP) platziert werden. Die RDMA/DDP PDU kann in eine Frame PDU platziert werden. Die TCP Schicht kann ein TCP Segment bilden, indem ein TCP Header an das ULP/RDMA/DDP Frame-Paket angehängt wird. Die Pakete können durch andere Schichten des Protokollstapels (z.B. die Ethernet-Schicht) laufen, bevor sie auf einem Datenlink (z.B. einer Leitung) als Frames durch den Sender (z.B. einen Client) platziert werden.
Diese und weitere Merkmale und Vorteile der vorliegenden Erfindung werden aus einer Durchsicht der folgenden detaillierten Beschreibung der vorliegenden Erfindung zusammen mit den beigefügten Zeichnungen ersichtlich, in denen gleiche Bezugszeichen durchwegs gleiche Teile bezeichnen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Beispiel des TUF-Protokolls.
2 zeigt ein Beispiel des FIM-Protokolls zur Verwendung mit iSCSI.
3 zeigt eine Ausführungsform eines Systems, das Frame-Markierung gemäß der vorliegenden Erfindung bereitstellen kann.
4 zeigt eine Ausführungsform eines TCP Frames gemäß der vorliegenden Erfindung.
5 zeigt eine Ausführungsform eines TCP Frames gemäß der vorliegenden Erfindung.
6 zeigt eine Ausführungsform eines TCP Frames gemäß der vorliegenden Erfindung.
7 zeigt eine Ausführungsform eines Marker Header- und Trailer-Formats gemäß der vorliegenden Erfindung.
8 zeigt eine Ausführungsform eines Markerformats gemäß der vorliegenden Erfindung.
9A–B zeigen ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Markieren von Frames gemäß der vorliegenden Erfindung.
10A–D zeigen ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Empfangen von TCP Frames gemäß der vorliegenden Erfindung.
11 zeigt ein Beispiel der Resegmentierung eines TCP Frames.
12A–D zeigen Ausführungsformen spezieller Marker-Stellen gemäß der vorliegenden Erfindung.
13 zeigt ein Beispiel eines Verfahrens, das resegmentierte TCP Segmente ermittelt.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
3 zeigt eine Ausführungsform eines Systems, das ein Verfahren zur Identifizierung von Upper Layer Protocol (ULP)-Nachrichtengrenzen bereitstellt. Das Verfahren kann beispielsweise ULP-Nachrichtengrenzen in einem Bytestrom-Transportprotokoll (z.B. einem Frame-Protokoll) identifizieren. Ein Sender 10 (z.B. ein Client) kann über ein Netzwerk 20, z.B. das Internet, an einen Empfänger 30 (z.B. einen Server) gekoppelt sein. Das Netzwerk 20 kann optional eine Zwischenbox 40 aufweisen. Eine TCP-Verbindung kann zwischen dem Sender 10 und dem Empfänger 30 hergestellt werden. Die Zwischenbox 40 (z.B. eine Firewall) kann die TCP-Verbindung des Senders 10 beenden und eine andere TCP-Verbindung mit dem Empfänger 30 herstellen. Die Zwischenbox 40 kann einen ersten Satz TCP Frames von dem Sender 10 empfangen und den ersten Satz TCP Frames zu einem zweiten Satz TCP Frames resegmentieren. Die Resegmentierung des ersten Satzes TCP Frames kann beispielsweise zu kleineren TCP Frames führen. In einem solchen Fall ist es möglich, dass das von dem Sender 10 gesendete Frame-Schema nicht das von dem Empfänger 30 empfangene Frame-Schema ist.
4 und 5 zeigen Ausführungsformen von TCP Frames gemäß der vorliegenden Erfindung. Der TCP Frame 50 kann beispielsweise einen TCP Header 60, einen Frame Header 70, einen oder mehrere Marker 80, einen Frame Trailer 90, der gegebenenfalls beispielsweise ein Pad oder Cyclical Redundancy Checking (CRC) enthält, und Nutzlast 100, die beispielsweise ULP Daten enthalten kann, aufweisen. 4 zeigt eine Ausführungsform, bei der sich ein Marker 80 in dem TCP Frame 50 befindet, und 5 zeigt eine Ausführungsform, bei der sich zwei Marker 80 in dem TCP Frame 50 befinden. Obwohl einer oder zwei Marker 80 in dem TCP Frame 50 gezeigt sind, können sich in dem TCP Frame 50 null, drei oder mehr Marker befinden. Der TCP Header 60 kann ein herkömmlicher TCP Header 60 sein und bei spielsweise Stelleninformationen innerhalb des TCP Sequenznummernraums bereitstellen. Das CRC 90 kann optional für Fehlerermittlung verwendet werden. Das CRC 90 kann beispielsweise den Frame Header 70, den einen oder die mehreren Marker 80, die Nutzlast 100 und, wenn vorhanden, das Pad 100 abdecken. Andere Arten von Fehlerermittlung oder Fehlerkorrektur können ebenfalls anstelle oder zusätzlich zu dem CRC 90 verwendet werden. Das CRC kann beispielsweise CRC-32c verwenden.
Der Frame Header 70 (z.B. ein Marker Header) kann nach dem TCP Header 60 angeordnet sein. Der Frame Header 70 folgt unmittelbar nach dem letzten Byte des TCP Headers 60, der beliebige potentielle TCP Optionen enthalten kann, in dem TCP Frame 50. Der Sender 10 kann garantieren, dass alle TCP Segmente (einschließlich Neuübertragungen) als erstes Byte, das unmittelbar auf den TCP Header (plus Optionen, wenn verwendet) folgt, den Frame Header 70 aufweisen. Der Frame Header 70 kann Informationen wie beispielsweise Dateninformationen oder Steuerinformationen (z.B. ULP Steuerinformationen) enthalten. Der Frame Header 70 kann auch Informationen hinsichtlich Grenzen der Nutzlast 100 bereitstellen, die dem Frame Header 70 entsprechen. Außerdem kann der ULP Header 110 spezifische Informationen darüber enthalten, in welchem Speicher (z.B. einem Anwendungspuffer) und insbesondere wo in dem Speicher des Empfängers 10 die Nutzlast 100 platziert (z.B. gespeichert) werden sollte. Der ULP Header 110 kann beispielsweise einen DDP/RDMA Header/Trailer oder andere Arten von ULP Headern/Trailern enthalten. 6 zeigt eine Ausführungsform eines TCP Frames 50, der den Frame Header 70 und einen separaten DDP/RDMA Header 110 aufweist.
7 zeigt eine Ausführungsform eines Marker Header-Formats gemäß der vorliegenden Erfindung. Eine Nutzlast-Länge kann die Länge in Bytes der in dem TCP Segment enthaltenen ULPDU angeben. Es kann sein, dass sie die Länge des Frame Headers selbst, des Pads, des CRCs oder eines beliebigen Markers, der in der Frame PDU vorhanden sein kann, nicht enthält. Die ULPDU kann beispielsweise die ULP Daten (oder die ULP Steuerung) sein. Das Pad kann beispielsweise bis zu drei Bytes bereitstellen, um die Länge des Frames zu einem Modulo 4 Byte zu machen. Das CRC kann beispielsweise ein CRC-32c sein. Bei einem Beispiel kann die Gesamtlänge in Bytes der ULPDU und der Frame Header und des Trailers in dem TCP Paket die Nutzlast-Länge plus die Länge des CRCs (z.B. 4 Bytes für CRC-32c) plus die Anzahl von Pad-Bytes sein.
In einem TCP Segment können sich mehrere Frame PDUs befinden. Jede von ihnen kann unabhängig von dem Empfänger 30 verarbeitet werden.
Der Marker 80 ist ein nach hinten zeigender Marker. Der Marker 80 kann nach hinten zu dem Beginn des Frame Headers 70 zeigen, wodurch er den Frame Header 70 identifiziert. Wenn in dem TCP Frame 50 mehr als ein Marker 80 vorhanden ist, kann/können, wie in 5 gezeigt ist, ein oder mehrere Marker nach hinten auf denselben Frame Header 70 zeigen. Bei einer Ausführungsform zeigen alle Marker 80 in dem TCP Frame 50 auf den Frame Header 70. Somit ist, anders als beim TUF-Protokoll, die Identifizierung der ULP Nachrichtengrenze (z.B. der Beginn des Frame Headers) vollkommen deterministisch und keinem wahrscheinlichkeitstheoretischen Fehlschlag unterworfen. Somit kann, anders als beim FIM-Protokoll, ein Zwischenspeichern minimiert werden, da jedes TCP Segment, das einen Marker 80 trägt, selbstbeschreibend ist und es dem Empfänger 30 ermöglicht, die Puffer-Platzierungs-Informationen, die in diesem Segment, beispielsweise in dem ULP Header 110, getragen werden, zu lokalisieren. Der Marker 80 kann verwendet werden, um von den beispielsweise in dem ULP Header platzierten Puffer-Platzierungs-Informationen abzuleiten, ob das TCP Segment in der richtigen Reihenfolge oder außer der Reihe empfangen worden ist. Ein TCP Segment kann beispielsweise in der richtigen Reihenfolge empfangen werden, wenn alle vorhergehenden TCP Segmente mit niedrigeren TCP Sequenznummern, die legal empfangen werden können, innerhalb des TCP „Windows" liegen. Auch ein TCP Segment, das außer der Reihe empfangen worden ist, jedoch einen Marker 80 trägt, kann verarbeitet werden, um die ULP Daten, die es enthält, zu platzieren, da der Marker 80 auf den Frame Header 70 zeigt. Aus dem Frame Header 70 kann der Empfänger 30 den ULP Header 110 ermitteln, der die Pufferinformationen enthalten kann. Der TCP Header kann gemäß dem TCP-Protokoll separat verarbeitet werden.
Der Marker 80 kann von dem Sender 10 in einem vorgegebenen Intervall in dem TCP Strom platziert werden. Der Marker 80 kann beispielsweise alle 512 Bytes in dem TCP Strom platziert werden. Wenn das vorgegebene Intervall genügend klein ist (z.B. kleiner als das kleinste Transportsegment), dann kann in fast jedem TCP Segment 50 oder in jedem TCP Segment 50 ein Marker vorhanden sein. Wenn das TCP Segment 50 kürzer als das vorgegebene Intervall ist, dann gibt es keine Garantie, dass ein Marker in dem TCP Segment vorhanden ist. Wenn ein Marker 80 noch in dem kurzen TCP Frame 50 vorhanden ist (z.B. einem TCP Segment, das kürzer ist, als das vorgegebene Intervall), dann kann der Frame Header 70 lokalisiert und das TCP Segment 50 wie oben beschrieben verarbeitet werden (z.B. kann die Nutzlast 100 direkt an der geeigneten Stelle in dem Anwendungspuffer platziert werden). Wenn andererseits kein Marker 80 vorhanden ist, kann der Empfänger 30 die Nutzlast 100 immer noch gemäß Informationen, die in dem ULP Header 110 vorhanden sein können, platzieren, wenn das TCP Segment in der richtigen Reihenfolge empfangen worden ist (z.B. alle vorhergehenden TCP Segmente mit niedrigerer TCP Sequenznummer, die legal empfangen werden können, innerhalb des TCP Windows liegen). In diesem Fall kann dieses Segment immer noch verarbeitet werden, auch wenn eine Zwischenbox vorhanden ist und sie den TCP Bytestrom resegmentiert hat. Dies beruht auf der Tatsache, dass die vorhergehenden Segmente verarbeitet wurden, und wenn kein Fehler aufgetreten ist, dann ist bekannt, dass das nächste Byte, das von dem Sender in dem TCP Bytestrom platziert worden ist, das erste Byte des Frame Headers 70 ist. Ein anderer Fall tritt ein, wenn das TCP Segment außer der Reihe ohne Marker empfangen wird. In diesem Fall platziert der Empfänger das TCP Segment, das er empfangen hat, in einem temporären Puffer (oder lässt das TCP Segment fallen und verarbeitet nur solche in der richtigen Reihenfolge), wodurch ein Bedarf an einem Puffer mit geringer Leistungsverschlechterung ausgeschlossen wird. Die Puffergröße kann klein sein und annähernd berechnet werden als beispielsweise das vorgegebene Intervall multipliziert mit der Anzahl von TCP Löchern, die der Empfänger pro TCP Verbindung unterstützen möchte. Im Gegensatz dazu benötigt das FIM-Protokoll eine Puffergröße des FIM-Intervalls plus eine maximale Übertragungseinheit (Maximum Transmission Unit (MTU)) multipliziert mit der Anzahl von TCP Löchern und den in dem Marker enthaltenen Daten für jeden Marker, multipliziert mit der Anzahl von TCP Verbindungen. Der Empfänger kann statistisch weniger Ressourcen vorsehen, da nicht alle Verbindungen gleichzeitig TCP Segmente außer der Reihe zu erwarten haben. Wenn der Empfänger keinen Puffer mehr für TCP Segmente außer der Reihe zur Verfügung hat, kann er alle nachfolgend außer der Reihe empfangenen TCP Segmente fallen lassen, bis ein Puffer beispielsweise aufgrund des Stopfens von Löchern in dem TCP Strom frei geworden ist.
Die TCP Frames 50 können selbstbeschreibend sein. Außerdem braucht, anders als beim FIM-Protokoll, der Empfänger 30 nicht unbedingt Zustandsinformationen von einem Frame zu einem anderen Frame zu tragen. Da fast jeder TCP Frame 50 einen Marker 80 enthalten kann, kann fast jeder TCP Frame 50 unabhängig verarbeitet werden. Das unabhängige Verarbeiten der TCP Frames 50 kann die Pufferer fordernisse wesentlich reduzieren, insbesondere in einer TCP Umgebung, in der TCP Frames 50 bei Eintreffen bei dem Empfänger 30 außer der Reihe sein können.
Das Platzieren des Markers 80 an einem vorgegebenen Intervall kann dem Empfänger 30 auch bekannte Stellen in dem TCP Strom zur Verfügung stellen, an denen er den Marker 80 finden kann. Somit kann die relative Stelle des Markers 80 in Bezug auf den TCP Header 60 von TCP Frame 50 zu TCP Frame 50 variieren. Der Empfänger 30 kann innerhalb des TCP Sequenznummern-Raums von den TCP Headern 60 Stelleninformationen bestimmen. Bei einem Beispiel, bei dem der Marker 80 alle 512 Bytes in dem TCP Strom platziert wird, kann der Empfänger 30 eine Modulo 512 Operation durchführen, um den Marker 80 zu lokalisieren. Da der TCP Sequenzraum bei einem Nicht-Null-Wert beginnen kann, der von TCP Verbindung zu TCP Verbindung variieren kann, kann das vorgegebene Intervall durch Subtrahieren des Anfangs-Nicht-Null-Werts von der TCP Sequenznummer, die in dem TCP Header getragen wird, berechnet werden, und durch Durchführen eines Modulo 512 für das Ergebnis. Anders als beim FIM-Protokoll beseitigt die Fähigkeit, die Verwendung des Frame Protokolls ohne Verhandlung zu beginnen, alle zusätzlichen Wartezeiten, indem die beiden Maschinen mit den Vorteilen eines Frame Protokolls miteinander in Kommunikation gebracht werden. Auch der zusätzliche Code, der geschrieben und auf der NIC gespeichert werden muss, um die Verhandlung durchzuführen, kann gespart werden.
Die vorliegende Erfindung sieht auch vor, dass anstelle des vorgegebenen Intervalls der Sender 10 und der Empfänger 30 ein Intervall aushandeln können. Des Weiteren können Band-externe Kommunikationen verwendet werden, um das Markerintervall einzustellen. Der Wert des Markerintervalls kann jederzeit nach Initialisierung durch das ULP eingestellt werden. Dies kann einen Ausgleich zwischen dem Wire Protocol Overhead und der empfängerseitigen Resegmentierungs-Puffergröße pro Verbindung ermöglichen.
8 zeigt eine Ausführungsform eines Markerformats gemäß der vorliegenden Erfindung. Bei einer Ausführungsform ist der Marker 32 Bit lang. Die ersten 16 Bits (MSB) können den Abstand zum Beginn des Frame Headers 70 angeben. Der 16-Bit Marker kann als 16-Bit vorzeichenlose ganze Zahl interpretiert werden, die die Anzahl von Bytes in dem TCP Sequenzraum von dem ersten Byte des Frame Headers 70 zu dem Marker 80 trägt. Wenn beispielsweise der Anfangs-TCP-Se quenzraum bei Byte 12 beginnt und bei dem aktuellen TCP Segment das erste Nutzlast-Byte bei Byte 112 in dem TCP Sequenzraum angeordnet ist. Der nächste Marker kann in dem TCP Sequenzraum an dem 32-Bit Feld angeordnet werden, das in dem Byte 524 angeordnet ist, wenn ein Marker Intervall von 512 Bytes angenommen wird. Der Marker kann den Wert 412 haben (d.h. 112 von 524 subtrahiert). Bei einer Ausführungsform sind, da die Felder des zum Framen formatierten TCP Segments 4-Byte-ausgerichtet sind, die letzten 2 Bits des Markers Nullen. Die nächsten 16 Bits (LSB) können für weiteres Framen (z.B. NFS) oder eine andere Signalisierungsfunktion reserviert werden. Bei einer Ausführungsform können die nächsten 16 Bits (LSB) eine Wiederholung der ersten 16 Bits sein. Bei einer weiteren Ausführungsform können die nächsten 16 Bits (LSB) Fehlerkorrektur- oder Fehlerermittlungs-Code (z.B. CRC-16) tragen, um den Inhalt des Markers zu schützen. Bei einer weiteren Ausführungsform können die nächsten 16 Bits (LSB) ULP-spezifische Informationen tragen und einen Kommunikationskanal zwischen den ULPs bedienen oder verwendet werden, um auf ein ULP-spezifisches Feld zu zeigen (z.B. ein zweiter Marker, der beispielsweise auf einen NFS Header zeigt). Bei einer anderen Ausführungsform können die 16-Bit Felder geswappt werden. Anders als beim FIM-Protokoll kann der Overhead des Markers nur 32 Bit betragen. Das FIM-Protokoll hat 2 Kopien desselben Markers, die jeweils 32 Bits belegen, da das Intervall zwischen Markern lang sein kann und eine Mittelbox in der Mitte eines Markers resegmentieren kann. Eine Ausführungsform der vorliegenden Erfindung kann beispielsweise nur eine Kopie des Markers benötigen.
Im Betrieb kann der Sender 10 einen Protokollstapel verwenden, der obere Schichten (Upper Layers; ULs) sowie beispielsweise TCP/IP Schichten bei der Bildung der TCP Frames 50 umfasst. 9A–B zeigen ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Markieren von Frames gemäß der vorliegenden Erfindung. In Schritt 120 kann eine TCP Verbindung beispielsweise zwischen dem Sender 10 und dem Empfänger 30 hergestellt werden. In Schritt 130 kann der Sender 10 den Frame Header 70 in dem TCP Segment unmittelbar dem TCP Header folgend platzieren. In Schritt 140 kann ein DDP/RDMA Header in dem TCP Segment unmittelbar dem Frame Header 70 folgend platziert werden. Bei einem Beispiel kann der Sender 10 einen DDP/RDMA Header/Trailer 110 anhängen, bevor er den Frame Header 70 anhängt. In Schritt 150 kann der Sender 10 die ULPDU-Länge erhalten und sie so segmentieren, dass sie in ein TCP Segment passt. Als nächstes kann der Sender 10 die Stelle und den Inhalt des einen oder mehrerer Marker berechnen. In Schritt 160 kann der Sender 10 die Stelle des nächsten Markers berechnen, indem er beispielsweise das vorgegebene Intervall zu der Stelle des letzten Markers addiert. In Schritt 170 kann der Sender 10 prüfen, ob der nächste Marker innerhalb der Grenzen des TCP Segments liegt. Dieser Schritt kann beispielsweise die maximale Übertragungseinheit für das TCP Segment und die Menge von zu übertragenden ULPDU Daten in Betracht ziehen. Wenn der nächste Marker außerhalb der Grenzen des TCP Segments liegt, dann kann in Schritt 210 der Sender 10 die ULPDU Daten unmittelbar nach dem Frame Header 70 und dem DDP/RDMA Header 110, wenn vorhanden, beginnend platzieren (und den einen oder mehrere Marker überspringen). Wenn der nächste Marker innerhalb das TCP Segment fällt, kann der Sender 10 in Schritt 180 prüfen, ob der nächste Marker unmittelbar nach dem TCP Header fällt. Wenn der nächste Marker unmittelbar nach dem TCP Header fällt, wird er unmittelbar nach dem TCP Header und vor dem Frame Header 70 platziert. In Schritt 190 wird der Markerwert auf 0 gesetzt (d.h. der Frame Header folgt unmittelbar auf diesen Marker). Dann kann der Sender 10 in Schritt 160 sehen, ob mehr Marker zu platzieren sind. In Schritt 180, wenn der nächste Marker nicht unmittelbar nach dem TCP Header kommt, kann in Schritt 200 der Sender 10 ermitteln, ob der nächste Marker in das nächste Byte nach der Stelle des CRC Felds fällt. Wenn der nächste Marker in das nächste Byte nach der Stelle des CRC Felds fällt, dann wird in Schritt 220 der Marker nicht platziert. In Schritt 210 kann, da der letzte Marker platziert worden ist, die ULPDU platziert werden und das CRC kann berechnet und platziert werden. Wenn der Marker 80 nicht unmittelbar nach dem CRC Feld fällt, dann fällt er in das TCP Segment. In Schritt 230 wird der Marker 80 berechnet und platziert, und das Verfahren geht zurück zu Schritt 160, um die Stelle des nächsten Markers 80 in dem TCP Segment zu finden. Nachdem alle Marker 80 durch den Sender 10 platziert worden sind, kann Schritt 170 zu Schritt 210 weitergehen. In Schritt 210 kann, da der letzte Marker platziert worden ist, die ULPDU um die Marker herum platziert werden und das CRC kann berechnet und platziert werden. Das CRC kann die komplette Frame PDU von dem ersten Byte, das dem TCP Header unmittelbar folgt, bis zu dem letzten Byte des Pads, wenn vorhanden, oder der ULPDU Daten abdecken. Die CRC Berechnung kann am Ende des Frames angehängt werden, um den TCP Frame 50 zu bilden. Obwohl in einer bestimmten Reihenfolge beschrieben, können die Schritte in anderer Reihenfolge angeordnet werden, und einige Schritte können gleichzeitig stattfinden oder weggelassen werden. Der Marker 80 kann beispielsweise vor oder gleichzeitig mit dem Anhängen des TCP Headers 60 eingesetzt werden. Anders als beim FIM-Protokoll deckt das CRC die Marker ab, was beispielsweise einen sehr einfachen Empfänger ermöglicht, bei dem die komplette TCP Nutzlast außer den letzten 4 Bytes (von denen angenommen wird, dass sie das CRC sind) der CRC Berechnung unterliegt. Der FIM-Protokoll-Mechanismus erfordert das Lokalisieren der Marker und ihren Ausschluss von der CRC Berechnung, was eine mühsamere und aufwendige Operation ist.
Der Sender 10 kann die PMTU (Path Maximum Transmission Unit) kennen und wissen, wie sie sich verändern kann. Die TCP-Schicht-variable maximale Segmentgröße kann von der PMTU beeinflusst werden. Bei der Neuübertragung kann der Sender 10, je nach TCP Erfordernissen, den Bytestrom auf dieselbe Weise segmentieren, in der die ursprüngliche Frame PDU segmentiert worden ist (z.B. folgt das erste Byte des Frame Headers dem TCP Header, die Länge des TCP Segments kann eine komplette Frame PDU oder mehrere komplette Frame PDUs umfassen). Die PMTU kann sich zwischen der ersten Übertragung und der Neuübertragung ändern. Der Sender 10 kann nochmals das TCP Segment erzeugen, das er beim ersten Mal erzeugte. Wenn die PMTU kleiner geworden ist, kann die ursprüngliche Segmentgröße die erlaubte PMTU übersteigen. Ein Mechanismus mit niedrigeren Schichten, z.B. IP Fragmentierung, kann verwendet werden.
Bei einem Netzwerk, bei dem die PMTU zu klein ist, um eine geeignete Operation zu ermöglichen, kann der Sender 10 einem „Notfall-Modus" folgen, wie er in dem TUF-Protokoll dargestellt ist. Das TUF-Protokoll wird beispielsweise beschrieben in „TCP ULP Framing Protocol (TUF): draft-ietf-tsvwg-tcp-ulp-frame-01" von Bailey et al.
Der Sender 10 kann dann den TCP Frame 50 senden. 10A–D zeigen ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Empfangen der TCP Frames 50 gemäß der vorliegenden Erfindung. In Schritt 240 kann der TCP Frame 50 von dem Empfänger 30 empfangen werden. Das TCP Segment kann in der richtigen Reihenfolge sein (z.B. das nächste erwartete Segment in dem TCP Sequenznummernraum) oder außer der Reihe (z.B. ein TCP Segment, das sich an der rechten oder linken Kante des TCP Windows befindet). In Schritt 250 kann der Empfänger 30 den Marker 80 in dem TCP Frame 50 lokalisieren. Der Empfänger 30 kann TCP Sequenznummerninformationen von dem TCP Header für den TCP Frame 50 erhalten. Außerdem kann der Empfänger, um den Marker 80 zu lokalisieren, den Anfangs-Nicht-Null-Wert der TCP Sequenznummer für das erste TCP Nutzlastbyte in diesem bestimmten TCP Strom subtrahieren. Der Empfänger 30 kann dann eine Modulo-Operation für die TCP Sequenznummern unter Verwendung des vorgegebenen Intervalls durchführen, an dem der Marker 80 angeordnet ist. Der Empfänger 30 muss nicht alle Marker lokalisieren, wenn mehr als einer vorhanden ist, da die Verwendung des einen Markers ausreichend sein kann. In Schritt 260 kann der Empfänger ermitteln, ob ein Marker innerhalb des TCP Segments 50 vorhanden ist. Wenn vorhanden, kann der Empfänger in Schritt 270 den Frame Header 70 unter Verwendung der in dem Marker 80 gespeicherten Informationen lokalisieren. Bei einem Beispiel kann der Marker 80 ein nach hinten zeigender Zeiger sein, wobei ein Deltawert in dem Marker 80 gespeichert ist. Der Deltawert kann die Stelle des Frame Headers 70 durch Angeben der Anzahl von Bytes nach hinten von der TCP Sequenznummer des Markers 80 zu der TCP Sequenznummer des Beginns des ULP Headers 70 angeben. In Schritt 280 kann der Empfänger 30 die Frame PDU Länge von dem Längenfeld innerhalb des Frame Headers 70 erhalten. In Schritt 290 kann der Empfänger 30 das CRC über die komplette Frame PDU berechnen und mit dem in dem CRC Feld dieser Frame PDU erhaltenen Wert vergleichen. In Schritt 300 kann der Empfänger 30 ermitteln, ob das CRC gültig ist. Wenn das CRC stimmt, kann der Empfänger 30 in Schritt 310 Steuerinformationen und/oder Dateninformationen von dem Frame Header 70 und/oder dem DDP/RDMA Header 110 erhalten. In Schritt 320 kann der Empfänger 30 die gemäß den Steuerinformationen und/oder Dateninformationen geforderte Operation durchführen. Der DDP/RDMA Header 110 kann beispielsweise ULP Steuerinformationen enthalten. Bei einem anderen Beispiel kann der DDP/RDMA Header 110 Grenzinformationen über die ULP Nutzlast enthalten. Bei einem weiteren Beispiel kann der DDP/RDMA Header 110 angeben, in welchem Speicher (z.B. einem bestimmten Anwendungspuffer) und an welcher Stelle innerhalb des Speichers die ULPDU Daten direkt platziert werden sollten. Der Empfänger 30 kann das Frame Header Längenfeld verwenden, um beispielsweise zu sehen, ob ein Pad vorhanden ist (d.h., ob die Länge kein ganzzahliges Vielfaches von 4 Bytes ist). Der Empfänger 30 kann die ULPDU Daten an dieser Speicherstelle platzieren, ohne die Pad-Bytes (z.B. 0–3 Bytes) zu platzieren. In Schritt 300, wenn das CRC nach der durch den Empfänger 30 durchgeführten Prüfung nicht stimmt, kann der Empfänger 30 in Schritt 360 ermitteln, ob die TCP Schichtverarbeitung für das bestimmte Segment durchgeführt worden ist, was für Schichtimplementierung ohne Veränderung an dem TCP der Fall sein kann. Wenn die TCP Verarbeitung für dieses TCP Segment 50 durchgeführt wurde, dann kann der Empfänger 30 in Schritt 370 die TCP Verbindung abbrechen. Es gibt keinen Weg, diesen Fehler wieder gut zu ma chen, der von der stärkeren CRC erkannt worden ist, die von der Frame Schicht verwendet wird, der aber durch den weniger rigorosen Test der TCP Prüfsumme durchgeschlüpft sein kann. In Schritt 360, wenn die Frame Schicht CRC Prüfung vor der TCP Schichtverarbeitung stattfindet (z.B. eine NIC, die Ethernet und IP und TCP und Framen implementiert, wo lokale Optimierung ohne Bruch der Übereinstimmung mit IETF RFCs durchgeführt werden kann), kann dann in Schritt 380 der Empfänger 30 das TCP Segment ruhig fallen lassen und es dem TCP Schicht Wiederherstellungsmechanismus ermöglichen, es neu zu übertragen. Dies kann das Erfordernis verringern oder beseitigen, Fehlerbehebungsmechanismen in der Frame Schicht hinzuzufügen (anders als die komplexen Fehlerbehebungsmechanismen, die von iSCSI verwendet werden), während es der Frame Schicht erlaubt, die erhöhte Integrität von Nutzlast, die durch CRC geschützt ist, zu genießen.
Wenn die TCP Frames 50 kürzer sind, als das vorgegebene Markerintervall von beispielsweise 512 Bytes, dann ist es möglich, dass der TCP Frame 50 den Marker 80 nicht enthält. In Schritt 260 kann der Empfänger ermitteln, ob der Marker in dem TCP Segment vorhanden ist. Wenn kein Marker vorhanden ist, kann der Empfänger 30 in Schritt 330 ermitteln, ob dieses TCP Segment 50 in der richtigen Reihenfolge empfangen worden ist. Wenn die TCP Segmente in der richtigen Reihenfolge empfangen worden sind, gibt es keine Notwendigkeit zum Zwischenspeichern und sie können direkt verarbeitet werden. In Schritt 340 kann der Empfänger 30 beispielsweise annehmen, dass der Frame Header an dem ersten Byte, das dem TCP Header unmittelbar folgt, beginnt. Das Verfahren kann dann zu Schritt 280 zurückgehen. In Schritt 330, wenn die TCP Segmente außer der Reihe empfangen worden sind, kann der Empfänger in Schritt 350 begrenztes Zwischenspeichern von ca. 512 Bytes verwenden, da es beispielsweise für jedes Loch in der TCP Sequenz nicht mehr als 512 Byte TCP Segmente gibt, die keinen Marker tragen. Sobald das TCP „Loch" gestopft ist und alle vorhergehenden TCP Segmente verarbeitet und als fehlerfrei gefunden worden sind, kann der Empfänger in Schritt 340 fortfahren. Wenn die TCP Frames 50 außer der Reihe empfangen worden sind und wenn der Empfänger 30 wünscht, mehr als ein „Loch" in dem TCP Sequenznummernraum zu unterstützen, kann zusätzliches Zwischenspeichern verwendet werden (z.B. 512 Bytes für jedes „Loch").
Der Marker 80 kann auch verwendet werden, um Resegmentierung der TCP Frames 50 zu ermitteln. 11 zeigt ein Beispiel der Resegmentierung des TCP Frames 50 in zwei TCP Frames 50A, 50B gemäß der vorliegenden Erfindung. Bei diesem Beispiel kann sich der Frame Header 70 in dem ersten TCP Frame 50A und der Marker 80 in dem zweiten TCP Frame 50B befinden. Wenn der Empfänger 30 den Marker 80 lokalisiert, kann er die Stelle des Frame Headers 70 ermitteln. Wenn jedoch die Stelle des Frame Headers 70 nicht in dem TCP Frame 50B ist, kann der Empfänger 30 feststellen, dass eine Resegmentierung stattgefunden hat. Eine Zwischenbox 40 kann beispielsweise die TCP Frames 50 von dem Sender 10 resegmentiert haben. Wenn die Stelle des Frame Headers 70 in dem TCP Frame 50B ist, jedoch nicht am Beginn des TCP Frames 50B (d.h. der Frame Header 70 befand sich nicht unmittelbar nach dem TCP Header 60), dann kann der Empfänger 30 feststellen, dass eine Resegmentierung stattgefunden hat. Bei einer Ausführungsform kann, wenn eine Resegmentierung stattgefunden hat, der Empfänger 30 die beschleunigten Express-Dienste wie beispielsweise direkte Datenplatzierung (Direct Data Placement) nicht anbieten. Bei einer anderen Ausführungsform kann der Empfänger 30 den Marker 80 verwenden, um die ursprünglich von dem Sender 10 übertragenen TCP Segmente zu rekonstruieren (d.h. ihren Frame Header zu finden und die in ihm und in dem DDP/RDMA eingebetteten Informationen zu verwenden, um die von dem ULP platzierten Informationen zu finden) und alle Dienste wie für normalen Empfang durchzuführen. Wie in 13 gezeigt ist, ist ein anderes Verfahren, das der Empfänger 30 verwenden kann, um Resegmentierung festzustellen, dass ein Marker 80 nicht vollständig in dem empfangenen TCP Segment vorhanden ist. Wie in 13 gezeigt ist, kann das Längenfeld des Frame Headers 70 auch von dem Empfänger 30 verwendet werden, um zu ermitteln, dass das TCP Segment eine (oder mehrere) komplette Frame PDUs enthält. Der Empfänger 30 kann eine Resegmentierung identifizieren, indem er herausfindet, dass der Frame Header 70 dem TCP Header 60 nicht unmittelbar folgt, oder falls das TCP Segment mehr oder weniger Bytes enthält, als von dem Längenfeld des Frame Headers angegeben sind (siehe z.B. 7). Wenn mehr Bytes gefunden werden, kann der Empfänger 30 die Bytes, die der CRC unmittelbar folgen, als Frame Header der nächsten Frame PDU behandeln (d.h., mehr als eine Frame PDU ist in ein TCP Segment gepackt worden). Wenn das letzte Byte der letzten Frame PDU (z.B. das CRC Feld) nicht das letzte Byte der TCP Segment Nutzlast ist, hat eine Resegmentierung stattgefunden.
12A–D zeigen Ausführungsformen besonderer Markerstellen gemäß der vorliegenden Erfindung. 12A zeigt ein Beispiel eines TCP Frames 50, in dem der Marker 80, wenn an dem vorgegebenen Interval platziert, sich unmittelbar nach der CRC 90 befinden würde. Bei einer Ausführungsform kann der Marker 80 Teil des aktuellen Frames sein und nach hinten zu dem Frame Header 70 des aktuellen Frames zeigen. 12B zeigt eine andere Lösung des Problems, dass der Marker 80 unmittelbar nach der CRC 90, wie in 12A gezeigt, platziert wird. In diesem Beispiel kann der Marker 80 an die Vorderseite des nächsten TCP Frames zwischen dem TCP Header 60 und dem Frame Header 70 bewegt werden. Der Marker 80 kann dann nach vorne zu dem Frame Header 70 zeigen (und einen Wert 0 haben). 12C zeigt ein Beispiel, in dem der Marker 80 in der Mitte des ULP Headers (z.B. des DDP/RDMA Headers 110) platziert ist. Dieser Fall bereitet keine besonderen Probleme, weil der Marker noch wirksam auf den Beginn des Frame Headers 70 zeigen kann. 12D zeigt ein Beispiel, bei dem der Marker 80 in der Mitte des CRC 90 platziert ist. Da sowohl der Marker 80 als auch das CRC 90 beispielsweise vier ausgerichtete Bytes umfassen können, kann dieses Beispiel nicht erlaubt sein.

Claims

Verfahren zum Identifizieren von Protokollnachrichten höherer Schichten in einem Bytestrom-Transportprotokoll, das die folgenden Schritte umfasst: Anfügen eines Frame Headers (70), der einen Protokoll Header (110) höherer Schichten eines Frames aufweist, an eine Protokolldateneinheit (100) höherer Schichten, wobei der Frame Header (70) unmittelbar nach dem Bytestrom-Transportprotokoll-Header platziert wird, wobei der Frame Header (70) ein Längenfeld aufweist, das die Länge der Protokolldateneinheit (100) höherer Schichten umfasst; und Einfügen eines Markers (80) in den Bytestrom, wobei der Marker (80) nach hinten zu dem Frame Header (70) zeigt und zu einem vorgegebenen Intervall eingefügt wird.
Verfahren nach Anspruch 1, wobei der Frame Header (70) wenigstens eine von Steuerinformationen und Dateninformationen aufweist.
Verfahren nach Anspruch 1, wobei der Marker (80) einen Deltawert aufweist, der eine Anzahl von Bytes vor einer Marker-Stelle bis zu einer bestimmten Stelle in dem Frame Header (70) angibt.
Verfahren nach Anspruch 1, wobei der Marker (80) einen Deltawert aufweist, der eine Anzahl von Bytes vor einer Marker-Stelle bis zu einer Anfangsstelle des Frame Headers (70) angibt.
Verfahren nach Anspruch 1, wobei der Marker (80) in dem Frame Header (70) angeordnet ist.