DE60009884T2 - Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle - Google Patents

Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle Download PDF

Info

Publication number
DE60009884T2
DE60009884T2 DE60009884T DE60009884T DE60009884T2 DE 60009884 T2 DE60009884 T2 DE 60009884T2 DE 60009884 T DE60009884 T DE 60009884T DE 60009884 T DE60009884 T DE 60009884T DE 60009884 T2 DE60009884 T2 DE 60009884T2
Authority
DE
Germany
Prior art keywords
packet
flow
header
data
package
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60009884T
Other languages
English (en)
Other versions
DE60009884D1 (de
Inventor
Shimon Muller
Denton Gentry
John Watkins
Linda Cheng
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60009884D1 publication Critical patent/DE60009884D1/de
Publication of DE60009884T2 publication Critical patent/DE60009884T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9063—Intermediate storage in different physical parts of a node or terminal
    • H04L49/9068—Intermediate storage in different physical parts of a node or terminal in the network interface card

Description

  • HINTERGRUND
  • Diese Erfindung bezieht sich auf die Gebiete der Computersysteme und der Computer-Netze. Insbesondere bezieht sich die vorliegende Erfindung auf eine Netzschnittstellenschaltung (NIC), um zwischen einem Computer-Netz und einem Host-Computersystem ausgetauschte Kommunikationspakete zu verarbeiten.
  • Die Schnittstelle zwischen einem Computer und einem Netz ist oft ein Engpass für die Kommunikationen, die zwischen dem Computer und dem Netz erfolgen. Während die Computer-Leistung (z. B. die Prozessorgeschwindigkeit) während der Jahre exponentiell zugenommen hat und die Übertragungsgeschwindigkeiten der Computer-Netze ähnliche Steigerungen erlebt haben, sind die Ineffizienzen in der Art, in der die Netzschnittstellenschaltungen die Kommunikationen abwickeln, immer offensichtlicher geworden. Mit jeder inkrementellen Zunahme der Computer- oder Netzgeschwindigkeit wird es immer offensichtlicher, dass die Schnittstelle zwischen dem Computer und dem Netz nicht Schritt halten kann. Diese Ineffizienzen umfassen einige Grundprobleme in der Art, in der die Kommunikationen zwischen einem Netz und einem Computer abgewickelt werden.
  • Die heutigen populärsten Formen der Netze sind tendenziell paketgestützt. Diese Netztypen, einschließlich des Internets und vieler lokaler Netze, übertragen die Informationen in der Form von Paketen. Jedes Paket wird durch eine Ursprungs-Endstelle separat erzeugt und übertragen und durch eine Ziel-Endstelle separat empfangen und verarbeitet. Außerdem kann jedes Paket, z. B. in einem Netz mit Bustopologie, durch zahlreiche Stationen empfangen und verarbeitet werden, die sich zwischen den Ursprungs- und Ziel-Endstellen befinden.
  • Ein Grundproblem bei Paketnetzen ist, dass jedes Paket durch mehrere Protokolle oder Protokollebenen (die zusammen als ein "Protokollstapel" bekannt sind) sowohl in den Ursprungs-Endstellen als auch in den Ziel-Endstellen verarbeitet werden muss. Wenn die zwischen den Stationen übertragenen Daten länger als eine bestimmte minimale Länge sind, werden die Daten in mehrere Abschnitte geteilt, wobei jeder Abschnitt durch ein separates Paket übertragen wird. Die Datenmenge, die ein Paket übertragen kann, ist im Allgemeinen durch das Netz eingeschränkt, das das Paket befördert, wobei sie oft als eine maximale Übertragungseinheit (MTU) ausgedrückt wird. Die ursprüngliche Ansammlung der Daten ist manchmal als ein "Datagramm" bekannt, wobei jedes Paket, das einen Teil eines einzelnen Datagramms überträgt, sehr ähnlich zu den anderen Paketen des Datagramms verarbeitet wird.
  • Die Kommunikationspakete werden im Allgemeinen wie folgt verarbeitet. In der Ursprungs-Endstelle wird jeder separate Datenabschnitt eines Datagramms durch einen Protokollstapel verarbeitet. Während dieser Verarbeitung werden mehrere Protokollköpfe (z. B. TCP, IP, Ethernet) zum Datenabschnitt hinzugefügt, um ein Paket zu bilden, das über das Netz übertragen werden kann. Das Paket wird durch eine Netzschnittstellenschaltung empfangen, die das Paket zur Ziel-Endstelle oder zu einem Host-Computer, der die Ziel-Endstelle bedient, überträgt. In der Ziel-Endstelle wird das Paket durch den Protokollstapel in der entgegengesetzten Richtung wie in der Ursprungs-Endstelle verarbeitet. Während dieser Verarbeitung werden die Protokollköpfe in der entgegengesetzten Reihenfolge entfernt, in der sie angebracht worden sind. Der Datenabschnitt wird auf diese Weise wiedergewonnen und kann einem Anwender, einem Anwendungsprogramm usw. verfügbar gemacht werden.
  • Mehrere in Beziehung stehende Pakete (z. B. Pakete, die die Daten von einem Datagramm übertragen) erleben folglich im Wesentlichen denselben Prozess in einer seriellen Weise (d. h. ein Paket auf einmal). Je mehr Daten übertragen werden müssen, desto mehr Pakete müssen gesendet werden, wobei jedes durch den Protokollstapel in jeder Richtung separat abgewickelt und verarbeitet wird. Natürlich ist der dem Prozessor der Endstelle auferlegte Bedarf desto größer, je mehr Pakete verarbeitet werden müssen. Die Anzahl der Pakete, die verarbeitet werden muss, wird durch andere Faktoren als nur der in einem Datagramm gesendeten Datenmenge beeinflusst. Wenn z. B. die Datenmenge, die in einem Paket eingekapselt sein kann, zunimmt, müssen weniger Pakete gesendet werden. Wie oben dargelegt worden ist, kann ein Paket jedoch eine maximal zulässige Größe besitzen, abhängig vom verwendeten Netztyp (z. B. beträgt die maximale Übertragungseinheit für Standard-Ethernet-Verkehr etwa 1.500 Bytes). Die Geschwindigkeit des Netzes beeinflusst außerdem die Anzahl der Pakete, die eine NIC in einer gegebenen Zeitperiode abwickeln kann. Ein Gigabit-Ethernet-Netz, das mit der Spitzenkapazität arbeitet, kann z. B. erfordern, dass eine NIC etwa 1,48 Million Pakete pro Sekunde empfängt. Folglich kann die durch einen Protokollstapel zu verarbeitende Anzahl der Pakete dem Prozessor eines Computers eine signifikante Belastung auferlegen. Die Situation wird durch die Not wendigkeit, jedes Paket separat zu verarbeiten, verschlimmert, selbst wenn jedes in einer im Wesentlichen ähnlichen Weise verarbeitet wird.
  • Ein zur unzusammenhängenden Verarbeitung der Pakete in Beziehung stehendes Problem ist die Weise, in der die Daten zwischen dem "Anwenderraum" (z. B. dem Datenspeicher eines Anwendungsprogramms) und dem "Systemraum" (z. B. dem Systemspeicher) während der Übertragung und des Empfangs der Daten bewegt werden. Gegenwärtig werden die Daten einfach von einem Bereich des Speichers, der einem Anwender- oder Anwendungsprogramm zugeordnet ist, in einen anderen Bereich des Speichers, der für die Verwendung durch den Prozessor reserviert ist, kopiert. Weil jeder Abschnitt eines Datagramms, der in einem Paket übertragen wird, separat kopiert werden kann (z. B. ein Byte auf einmal), ist eine nichttriviale Menge der Prozessorzeit erforderlich, wobei häufige Übertragungen eine große Menge der Bandbreite des Speicherbusses verbrauchen können. Beispielhaft kann für die über das Netz übertragenen Daten jedes Byte der Daten in einem vom Netz empfangenen Paket aus dem Systemraum gelesen und in einer separaten Kopieroperation in den Anwenderraum geschrieben werden und umgekehrt. Obwohl der Systemraum im Allgemeinen einen geschützten Speicherbereich vorsieht (z. B. vor Manipulation durch Anwenderprogramme geschützt), tut die Kopieroperation nichts von Wert, wenn sie vom Standpunkt einer Netzschnittstellenschaltung betrachtet wird. Stattdessen riskiert sie die Überlastung des Host-Prozessors und verzögert seine Fähigkeit, zusätzlichen Netzverkehr von der NIC schnell anzunehmen. Das separate Kopieren der Daten jedes Pakets kann deshalb sehr ineffizient sein, insbesondere in der Umgebung eines Hochgeschwindigkeitsnetzes.
  • Außer der ineffizienten Datenübertragung (z. B. die Daten eines Pakets auf einmal) ist die Verarbeitung der Köpfe der von einem Netz empfangenen Pakete außerdem ineffizient. Jedes Paket, das einen Teil eines einzelnen Datagramms überträgt, besitzt im Allgemeinen die gleichen Protokollköpfe (z. B. Ethernet, IP und TCP), obwohl es für ein spezielles Protokoll irgendeine Variation in den Werten innerhalb der Köpfe der Pakete geben kann. Jedes Paket wird jedoch einzeln durch denselben Protokollstapel verarbeitet, wobei folglich mehrere Wiederholungen völlig gleicher Operationen für in Beziehung stehende Pakete erforderlich sind. Die aufeinander folgende Verarbeitung nicht in Beziehung stehender Pakete durch verschiedene Protokollstapel ist wahrscheinlich viel weniger effizient als die fortlaufende Verarbeitung einer Anzahl in Beziehung ste hender Pakete durch einen Protokollstapel auf einmal.
  • Ein weiteres Grundproblem, das die Wechselwirkung zwischen gegenwärtigen Netzschnittstellenschaltungen und Host-Computersystemen betrifft, ist, dass die Kombination oft misslingt, um die vergrößerten Prozessorbetriebsmittel zu nutzen, die in Mehrprozessor-Computersystemen verfügbar sind. Mit anderen Worten, gegenwärtige Versuche, die Verarbeitung der Netzpakete (z. B. durch einen Protokollstapel) zwischen einer Anzahl von Protokollen in einer effizienten Weise zu verteilen, sind im Allgemeinen ineffektiv. Insbesondere kommt die Leistung der gegenwärtigen NICs nicht nah an die erwarteten oder gewünschten linearen Leistungsgewinne heran, deren Verwirklichung aus der Verfügbarkeit mehrerer Prozessoren erwartet werden kann. In einigen Mehrprozessorsystemen wird z. B. eine kleine Verbesserung der Verarbeitung des Netzverkehrs aus der Verwendung von mehr als 4–6 Prozessoren verwirklicht.
  • Außerdem kann es misslingen, dass die Rate, mit der die Pakete von einer Netzschnittstellenschaltung zu einem Host-Computer oder einer anderen Kommunikationsvorrichtung übertragen werden, mit der Rate der Paketankunft and der Schnittstelle Schritt hält. Ein Element oder ein anderes des Host-Computers (z. B. ein Speicherbus, ein Prozessor) können überlastet oder anderweitig nicht in der Lage sein, um Pakete mit ausreichender Munterkeit anzunehmen. In diesem Fall können ein oder mehrere Pakete fallen gelassen oder verworfen werden. Das Fallenlassen von Paketen kann verursachen, dass eine Netzentität einigen Verkehr erneut überträgt, wobei, falls zu viele Pakete fallen gelassen werden, eine Netzverbindung eine erneute Initialisierung erfordern kann. Ferner kann das Fallenlassen eines Pakets oder eines Pakettyps anstatt eines anderen einen signifikanten Unterschied im gesamten Netzverkehr ausmachen. Falls z. B. ein Steuerpaket fallen gelassen wird, kann die entsprechende Netzverbindung stark beeinflusst werden und infolge der typischerweise kleinen Größe eines Steuerpakets wenig tun, um die Paketsättigung der Netzschnittstellenschaltung zu lindern. Deshalb kann der Netzverkehr mehr als notwendig verschlechtert werden, es sei denn, das Fallenlassen der Pakete wird in einer Weise ausgeführt, die die Wirkung zwischen vielen Netzverbindungen verteilt oder die bestimmte Pakettypen berücksichtigt.
  • Folglich misslingt es gegenwärtigen NICs, eine angemessene Leistung bereitzustellen, um heutige Computersysteme der oberen Preisklasse und Hochgeschwin digkeitsnetze miteinander zu verbinden. Außerdem kann eine Netzschnittstellenschaltung, die einen überlasteten Host-Computer nicht berücksichtigten kann, die Leistung des Computers verschlechtern.
  • US-A-5 684 954 offenbart Verfahren und Vorrichtung für die Verarbeitung von Feldern eines Protokollkopfes, der einem Datenstrom vorangeht, um eine Verbindungskennung für die Verarbeitung des Datenstroms zu erzeugen. Die Protokollinformationen eines ersten Protokolls werden extrahiert, wobei die Informationen hinsichtlich der auf dem ersten Protokoll aufgebauten Protokolle dann gelesen werden. Die Protokoll- und Protokolltyp-Informationen werden verwendet, um die Verbindungskennung zu erzeugen.
  • ZUSAMMENFASSUNG
  • In einer Ausführungsform der Erfindung werden ein System und ein Verfahren zum Analysieren oder Parsen eines von einem Netz empfangenen Kommunikationspakets geschaffen. Ein Kommunikationsfluss oder eine Kommunikationsverbindung, der bzw. die das Paket umfasst, wird aus den im Paket enthaltenen Informationen identifiziert, wobei ein Schlüssel erzeugt wird, um den Fluss zu klassifizieren oder zu identifizieren.
  • In dieser Ausführungsform wird ein von einer Ursprungsentität über ein Netz zu einer Zielentität gesendetes Paket durch eine Kommunikationsvorrichtung, wie z. B. eine Netzschnittstelle, empfangen. Ein Kopfabschnitt des Pakets, der die Abschnitte von einem oder mehreren Köpfen des Pakets umfasst, wird in einen Speicher kopiert. Jeder Kopfbereich stellt eine andere Schicht innerhalb einer Folge von Protokollen (z. B. einem Protokollstapel) zum Verarbeiten der Kommunikationen zwischen den Entitäten dar. Ein Kopf-Parser-Modul parst den Kopfabschnitt, um die Werte in einem oder mehreren Kopffeldern wiederzugewinnen und möglicherweise bestimmte Bereiche des Pakets, wie z. B. den Anfang eines Datenabschnitts, zu identifizieren. Die Parsprozedur kann abgebrochen werden, falls bestimmt wird, dass die zum Konstruieren des Pakets verwendeten Protokolle nicht mit im Voraus ausgewählten Protokollen übereinstimmen.
  • Der Kopf-Parser kann in Übereinstimmung mit einem oder mehreren im Voraus ausgewählten Protokollen konfiguriert sein, die mit dem Netz kompatibel sind, das das Paket befördert hat. Folglich kann in einer Ausführungsform der Erfindung, in der das Netz das Internet ist, der Kopf-Parser für das Internetprotokoll (IP) und das Transportsteuerprotokoll (TCP) optimiert sein. In anderen Ausführungsformen der Erfindung können jedoch Pakete, die praktisch jedes anderes Protokoll einhalten, unterstützt und geparst werden.
  • Wenn ein Paket geparst wird, werden die Werte von einem oder mehreren Adressenfeldern in einem oder mehreren Protokollköpfen wiedergewonnen und verkettet, um einen Flussschlüssel zu bilden, um den Kommunikationsfluss oder die Kommunikationsverbindung zwischen den kommunizierenden Entitäten zu identifizieren. Der Flussschlüssel kann aus den Kennungen der Ursprungs- und Zielentität und bestehen, die aus den Protokollköpfen sowohl der Schicht drei als auch der Schicht vier des Pakets entnommen worden sind. Folglich werden in einer Ausführungsform der Erfindung die IP-Ursprungs- und -Ziel-Adressen und die Werte des TCP-Ursprungs- und -Ziel-Ports verkettet. In einer weiteren Ausführungsform der Erfindung können jedoch die Ursprungs- und Zieladressen der Schicht zwei (z. B. Ethernet) verwendet werden, um einen Flussschlüssel zusammenzufügen.
  • Außer dem Identifizieren eines Kommunikationsflusses können andere Status- oder Steuerinformationen außerdem aus dem Kopfabschnitt des Pakets wiedergewonnen werden. Es können z. B. verschiedene Kopffelder gesammelt werden, um zu bestimmen, ob das Paket Daten enthält, um zu bestimmen, ob die Nutzinformationen des Pakets größer als eine bestimmte Größe sind, um zu bestimmen, ob das Paket ein Steuerpaket ist, um die Sequenznummer des Pakets zu identifizieren, um den Wert bestimmter Kopfmerker zu bestimmen usw.
  • Die aus den Köpfen der Pakete abgeleiteten Informationen, einschließlich des Flussschlüssels und der Steuerinformationen, können für verschiedene Funktionen durch andere Abschnitte der Netzschnittstelle und/oder ein Host-Computersystem verwendet werden. Die Informationen können verwendet werden, um die von der Ursprungsentität zur Zielentität übertragenen Daten erneut zusammenzufügen oder um die gemeinsame Verarbeitung der Pakete von einem Kommunikationsfluss zu ermöglichen. Die Informationen können außerdem verwendet werden, um die Verarbeitung des Netzverkehrs unter mehreren Prozessoren in einem Mehrprozessor-Host-Computersystem zu verteilen oder zu teilen, um die Integrität des Pakets (z. B. durch eine Prüfsumme) zu verifizieren oder um irgendeine andere Handlung auszuführen, um die effiziente Abwicklung des Netzver kehrs zu verbessern.
  • KURZBESCHREIBUNG DER FIGUREN
  • 1A ist ein Blockschaltplan, der eine Netzschnittstellenschaltung (NIC) darstellt, um ein Paket von einem Netz in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zu empfangen.
  • 1B ist ein Ablaufplan, der ein Verfahren des Betreibens der NIC nach 1A demonstriert, um ein von einem Netz empfangenes Paket gemäß einer Ausführungsform der Erfindung zu einem Host-Computer zu übertragen.
  • 2 ist eine graphische Darstellung eines über ein Netz übertragenen und an einer Netzschnittstellenschaltung empfangenen Pakets in einer Ausführungsform der Erfindung.
  • 3 ist ein Blockschaltplan, der einen Kopf-Parser einer Netzschnittstellenschaltung darstellt, um ein Paket gemäß einer Ausführungsform der Erfindung zu parsen.
  • 4A–4B umfassen einen Ablaufplan, der ein Verfahren des Parsens eines von einem Netz an einer Netzschnittstellenschaltung empfangenen Pakets gemäß einer Ausführungsform der vorliegenden Erfindung demonstriert.
  • 5 ist ein Blockschaltplan, der eine Netzschnittstellenschaltungs-Flussdatenbank gemäß einer Ausführungsform der Erfindung darstellt.
  • 6A–6E umfassen einen Ablaufplan, der ein Verfahren zum Managen einer Netzschnittstellenschaltungs-Flussdatenbank gemäß einer Ausführungsform der Erfindung veranschaulicht.
  • 7 stellt einen Satz dynamische Befehle dar, um ein Paket gemäß einer Ausführungsform der Erfindung zu parsen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgende Beschreibung wird vorgelegt, um jedem Fachmann auf dem Gebiet zu ermöglichen, die Erfindung auszuführen und zu verwenden, wobei sie im Kontext spezieller Anwendungen der Erfindung und ihrer Anforderungen bereitgestellt ist. Für die Fachleute auf dem Gebiet werden verschiedene Modifikationen an den offenbarten Ausführungsformen leicht ersichtlich sein, wobei die hierin definierten allgemeinen Prinzipien auf andere Ausführungsformen und Anwendungen angewendet werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Folglich ist nicht beabsichtigt, dass die vorliegende Erfindung auf die gezeigten Ausführungsformen eingeschränkt wird, sondern dass sie mit dem weitesten Umfang übereinstimmt, der mit den hierin offenbarten Prinzipien und Merkmalen konsistent ist.
  • Insbesondere sind die Ausführungsformen der Erfindung im Folgenden in Form einer Netzschnittstellenschaltung (NIC) beschrieben, die Kommunikationspakete empfängt, die in Übereinstimmung mit bestimmten Kommunikationsprotokollen, die mit dem Internet kompatibel sind, formatiert sind. Ein Fachmann auf dem Gebiet wird jedoch erkennen, dass die vorliegende Erfindung nicht auf mit dem Internet kompatible Kommunikationsprotokolle eingeschränkt ist, wobei sie leicht für die Verwendung mit anderen Protokollen und in anderen Kommunikationsvorrichtungen als einer NIC leicht angepasst werden kann.
  • Die Programmumgebung, in der eine vorliegende Ausführungsform der Erfindung beispielhaft ausgeführt wird, umfasst einen Universal-Computer oder eine Spezialvorrichtung, wie z. B. einen Handheld-Computer. Die Einzelheiten derartiger Vorrichtungen (z. B. Prozessor, Speicher, Datenspeicher, Eingabe/Ausgabe-Ports und Anzeige) sind wohl bekannt und um der Klarheit willen weggelassen.
  • Es sollte außerdem selbstverständlich sein, dass die Techniken der vorliegenden Erfindung unter Verwendung einer Vielzahl von Technologien implementiert sein könnten. Die hierin beschriebenen Verfahren können z. B. in Software, die auf einem programmierbaren Mikroprozessor abläuft, implementiert sein, oder sie können unter Verwendung entweder einer Kombination von Mikroprozessoren oder anderer spezifisch konstruierter anwendungsspezifischer integrierter Schaltungen, programmierbaren Logikvorrichtungen oder verschiedener Kombinationen daraus in Hardware implementiert sein. Insbesondere können die hierin beschriebenen Verfahren durch eine Folge computerausführbarer Befehle implementiert sein, die in einem Speichermedium, wie z. B. einer Trägerwelle, einem Plattenlaufwerk oder einem anderen computerlesbaren Medium, gespeichert sind.
  • Einführung
  • In einer Ausführungsform der vorliegenden Erfindung ist eine Netzschnittstellenschaltung (NIC) konfiguriert, um Kommunikationspakete, die zwischen einem Host-Computersystem und einem Netz, wie z. B. dem Internet, ausgetauscht werden, zu empfangen und zu verarbeiten. Insbesondere ist die NIC konfiguriert, um Pakete zu empfangen und zu manipulieren, die in Übereinstimmung mit einem Protokollstapel (z. B. einer Kombination von Kommunikationsprotokollen) formatiert sind, der durch ein an die NIC gekoppeltes Netz unterstützt wird.
  • Ein Protokollstapel kann unter Bezugnahme auf die siebenschichtige ISO-OSI-Modell-Grundstruktur (Grundstruktur des Modells der internationalen Organisation für Standardisierung – der Kommunikation offener Systeme) beschrieben werden. Folglich enthält ein beispielhafter Protokollstapel das Transportsteuerprotokoll (TCP) in der Schicht vier, das Internetprotokoll (IP) in der Schicht drei und das Ethernet in der Schicht zwei. Für die Zwecke der Erörterung kann der Begriff "Ethernet" hierin verwendet werden, um gemeinsam sowohl auf die standardisierte 802.3-Spezifikation des IEEE (Institut der Elektro- und Elektronikingenieure) als auch auf die Version zwei der nicht standardisierten Form des Protokolls Bezug zu nehmen. Wo verschiedene Formen des Protokolls unterschieden werden müssen, kann die Standardform identifiziert werden, indem die Bezeichnung "802.3" einbezogen wird.
  • Andere Ausführungsformen der Erfindung sind konfiguriert, um mit Kommunikationen zu arbeiten, die andere Protokolle einhalten, sowohl bekannte (z. B. Apple-Talk, IPX (netzüberschreitende Paketvermittlung) usw.) als auch zum gegenwärtigen Zeitpunkt unbekannte. Ein Fachmann auf dem Gebiet erkennt, dass die durch diese Erfindung geschaffenen Verfahren leicht an neue Kommunikationsprotokolle anpassbar sind.
  • Außerdem kann die Verarbeitung der im Folgenden beschriebenen Pakete in anderen Kommunikationsvorrichtungen als einer NIC ausgeführt werden. Ein Modem, eine Vermittlung, ein Router oder ein anderer Kommunikations-Port oder eine andere Kommunikationsvorrichtung (z. B. seriell, parallel, USB, SCSI) können z. B. ähnlich konfiguriert sein und ähnlich betrieben werden.
  • In im Folgenden beschriebenen Ausführungsformen der Erfindung empfängt eine NIC ein Paket von einem Netz für einen Host-Computersystem oder eine andere Kommunikationsvorrichtung. Die NIC analysiert das Paket (z. B. durch Wiedergewinnen bestimmter Felder aus einem oder mehreren seiner Protokollköpfe) und unternimmt Handlungen, um die Effizienz zu vergrößern, mit der das Paket übertragen oder seiner Zielentität bereitgestellt wird. Die im Folgenden erörterte Ausrüstung und die im Folgenden erörterten Verfahren, um die Effizienz der Verarbeitung oder der Übertragung der von einem Netz empfangenen Pakete zu vergrößern, können außerdem für Pakete verwendet werden, die sich in der entgegengesetzten Richtung bewegen (d. h. von der NIC zum Netz).
  • Eine Technik, die auf den ankommenden Netzverkehr angewendet werden kann, umfasst das Untersuchen oder Parsen eines Kopfbereichs oder mehrerer Kopfbereiche eines ankommenden Pakets (z. B. der Kopfbereiche für die Protokolle der Schichten zwei, drei und vier), um die Ursprungs- und Zielentitäten des Pakets zu identifizieren und möglicherweise bestimmte andere Informationen wiederzugewinnen. Unter Verwendung der Kennungen der kommunizierenden Entitäten als einen Schlüssel können die Daten von mehreren Paketen angesammelt oder erneut zusammengefügt werden. Typischerweise wird ein von einer Ursprungsentität zu einer Zielentität gesendetes Datagramm über mehrere Pakete übertragen. Das Ansammeln der Daten aus mehreren in Beziehung stehenden Paketen (z. B. Paketen, die Daten vom selben Datagramm übertragen) erlaubt folglich, dass ein Datagramm erneut zusammengefügt und vereint zu einem Host-Computer übertragen wird. Das Datagramm kann dann der Zielentität in einer im hohen Grade effizienten Weise bereitgestellt werden. Es kann z. B. eine "Seitenumdreh"-Operation ausgeführt werden, anstatt die Daten von einem Paket auf einmal (und ein Byte auf einmal) in separaten "Kopier"-Operationen bereitzustellen. Beim Umdrehen einer Seite kann eine ganze Speicherseite der Daten der Zielentität bereitgestellt werden, möglicherweise im Austausch für eine leere oder unbenutzte Seite.
  • In einer weiteren Technik werden die von einem Netz empfangenen Pakete in einer Warteschlange angeordnet, um die Übertragung zu einem Host-Computer zu erwarten. Während die Übertragung erwartet wird, können mehrere in Beziehung stehende Pakete für den Host-Computer identifiziert werden. Nachdem sie übertragen worden sind, können sie durch einen Host-Prozessor als eine Gruppe verarbeitet werden, anstatt dass die seriell (z. B. eines auf einmal) verarbeitet werden.
  • Eine noch weitere Technik umfasst das Senden einer Anzahl in Beziehung stehender Pakete an einen einzelnen Prozessor eines Mehrprozessor-Host-Computersystems. Durch das Verteilen der zwischen verschiedenen Paaren von Ursprungs- und Zielentitäten beförderten Paketen zwischen verschiedenen Prozessoren kann die Verarbeitung der Pakete durch ihre jeweiligen Protokollstapel verteilt werden, während die Pakete trotzdem in ihrer richtigen Reihenfolge aufrechterhalten werden.
  • Die oben erörterten Techniken, um die Effizienz vergrößern, mit der die Pakete verarbeitet werden, können eine Kombination aus Hardware- und Software-Modulen umfassen, die sich in einer Netzschnittstelle und/oder einem Host-Computersystem befinden. In einer speziellen Ausführungsform parst ein Parsmodul in einer NIC eines Host-Computers die Kopfabschnitte der Pakete. Beispielhaft umfasst das Parsmodul eine Mikro-Ablaufsteuerung, die entsprechend einem Satz ersetzbarer Befehle arbeitet, die als Mikrocode gespeichert sind. Unter Verwendung der aus den Paketen extrahierten Informationen können mehrere Pakete von einer Ursprungsentität für eine Zielentität identifiziert werden. Ein Hardware-Modul für das erneute Zusammenfügen in der NIC kann dann die Daten von mehreren Paketen sammeln. Ein weiteres Hardware-Modul in der NIC ist konfiguriert, um in Beziehung stehende Pakete zu erkennen, die die Übertragung zum Host-Computer erwarten, sodass sie anstatt seriell gemeinsam durch einen geeigneten Protokollstapel verarbeitet werden können. Die erneut zusammengefügten Daten und die Köpfe der Pakete können dann dem Host-Computer bereitgestellt werden, sodass eine geeignete Software (z. B. ein Vorrichtungstreiber für die NIC) die Köpfe verarbeiten und die Daten zur Zielentität liefern kann.
  • Wenn der Host-Computer mehrere Prozessoren enthält, kann eine Last-Verteilungseinrichtung (die außerdem in Hardware in der NIC implementiert sein kann) einen Prozessor auswählen, um die Köpfe der mehreren Pakete durch einen Protokollstapel zu verarbeiten.
  • In einer weiteren Ausführungsform der Erfindung ist ein System vorgesehen, um ein Paket von einer NIC zufällig zu verwerfen, wenn die NIC mit Paketen, die die Übertragung zu einem Host-Computer erwarten, gesättigt oder beinah gesättigt ist.
  • Eine Ausführungsform einer Hochleistungs-Netzschnittstellenschaltung
  • 1A stellt eine NIC 100 dar, die gemäß einer beispielhaften Ausführungsform der Erfindung konfiguriert ist. Es folgt eine kurze Beschreibung der Operation und der Wechselwirkung der verschiedenen Module der NIC 100 in dieser Ausführungsform.
  • Ein Kommunikationspaket kann in der NIC 100 vom Netz 102 durch ein (in 1A nicht gezeigtes) Endgerät-Anschlusssteuerungs-Modul (MAC-Modul) empfangen werden. Das MAC-Modul führt die Verarbeitung auf niedriger Ebene des Pakets aus, wie z. B. das Lesen des Pakets aus dem Netz, das Ausführen irgendeiner Fehlerüberprüfung, das Erfassen von Paketfragmenten, das Erfassen von überdimensionierten Paketen, das Entfernen der Präambel der Schicht eins usw.
  • Dann empfängt das Eingangs-Port-Verarbeitungsmodul (IPP-Modul) 104 das Paket. Das IPP-Modul speichert das ganze Paket, wie es vom MAC-Modul oder dem Netz empfangen worden ist, in der Paketwarteschlange 116, wobei ein Abschnitt des Pakets in den Kopf-Parser 106 kopiert wird. In einer Ausführungsform der Erfindung kann das IPP-Modul 104 als eine Koordinationseinrichtung der Sorten wirken, um das Paket für die Übertragung zu einem Host-Computersystem vorzubereiten. In einer derartigen Rolle kann das IPP-Modul 104 Informationen, die ein Paket betreffen, von verschiedenen Modulen der NIC 100 empfangen und derartige Informationen zu anderen Modulen abfertigen.
  • Der Kopf-Parser 106 parst einen Kopfabschnitt des Pakets, um verschiedene Stücke der Informationen wiederzugewinnen, die verwendet werden, um in Beziehung stehende Pakete zu identifizieren (z. B. mehrere Pakete von derselben Ursprungsentität für eine Zielentität) und die die anschließende Verarbeitung der Pakete beeinflussen. In der veranschaulichten Ausführungsform kommuniziert der Kopf-Parser 106 mit dem Flussdatenbankmanager (FDBM) 108, der die Flussdatenbank (FDB) 110 managt. Insbesondere sendet der Kopf-Parser 106 eine Abfrage an den FDBM 108, um zu bestimmen, ob ein (im Folgenden beschriebener) gültiger Kommunikationsfluss zwischen der Ursprungsentität, die ein Paket sendet, und der Zielentität vorhanden ist. Die Zielentität kann ein Anwendungsprogramm, ein Kommunikationsmodul oder irgendein anderes Element eines Host-Computersystems umfassen, das das Paket empfangen soll.
  • Inder veranschaulichten Ausführungsform der Erfindung umfasst ein Kommunikationsfluss eines oder mehrere Datagramm-Pakete von einer Ursprungsentität zu einer Zielentität. Ein Fluss kann durch einen Flussschlüssel identifiziert werden, der aus den durch den Kopf-Parser 106 vom Paket wiedergewonnenen Ursprungs- und Zielkennungen zusammengefügt ist. In einer Ausführungsform der Erfindung umfasst ein Flussschlüssel die Adressen- und/oder Port-Informationen für die Ursprungs- und Zielentitäten aus den Protokollköpfen der Schicht drei (z. B. IP) und/oder der Schicht vier (z. B. TCP) des Pakets.
  • Für die Zwecke der veranschaulichten Ausführungsform der Erfindung ist ein Kommunikationsfluss ähnlich zu einer TCP-Gesamtverbindung, er besitzt aber im Allgemeinen eine kürzere Dauer. Insbesondere kann in dieser Ausführungsform die Dauer eines Flusses auf die Zeit eingeschränkt sein, die erforderlich ist, um alle Pakete zu empfangen, die einem einzelnen Datagramm zugeordnet sind, das von der Ursprungsentität zur Zielentität geleitet wird.
  • Folglich leitet für die Zwecke des Flussmanagements der Kopf-Parser 106 den Flussschlüssel des Pakets zum Flussdatenbankmanager 108. Der Kopf-Parser kann außerdem den Flussdatenbankmanager mit anderen Informationen, die das Paket betreffen, versehen, die aus dem Paket wiedergewonnenen worden sind (z. B. die Länge des Pakets).
  • Der Flussdatenbankmanager 108 durchsucht die FDB 110 in Reaktion auf eine vom Kopf-Parser 106 empfangene Abfrage. Beispielhaft speichert die Flussdatenbank 110 Informationen, die jeden gültigen Kommunikationsfluss betreffen, der eine durch die NIC 100 bediente Zielentität umfasst. Folglich aktualisiert der FDBM 108 die FDB 110, wie es notwendig ist, abhängig von den vom Kopf-Parser 106 empfangenen Informationen. Außerdem ordnet in dieser Ausführungsform der Erfindung der FDBM 108 einen Operations- oder Aktionscode dem empfangenen Paket zu. Ein Operationscode kann verwendet werden, um zu identifizieren, ob ein Paket ein Teil eines neuen oder vorhandenen Flusses ist, ob das Paket Daten oder nur Steuerinformationen enthält, um die Menge der Daten innerhalb des Pakets zu identifizieren, um zu identifizieren, ob die Paketdaten mit in Beziehung stehenden Daten erneut zusammengefügt werden können (z. B. andere Daten in einem von der Ursprungsentität zur Zielentität gesendeten Datagramm) usw. Der FDBM 108 kann die vom Paket wiedergewonnenen und durch den Kopf-Parser 106 bereitgestellten Informationen verwenden, um einen geeigneten Operationscode auszuwählen. Der Operationscode des Pakets wird dann zusammen mit einem Index des Flusses des Pakets innerhalb der FDB 110 zurück zum Kopf-Parser geleitet.
  • In einer Ausführungsform der Erfindung kann die Kombination aus dem Kopf-Parser 106, dem FDBM 108 und der FDB 110 oder eine Teilmenge dieser Module, zurückzuführen auf ihre Rolle beim Klassifizieren oder Identifizieren des an der NIC 100 empfangenen Netzverkehrs, als eine Verkehrsklassifizierungseinrichtung bekannt sein.
  • In der veranschaulichten Ausführungsform leitet der Kopf-Parser 106 außerdem den Flussschlüssel des Pakets zu einer Lastverteilungseinrichtung 112. In einem Host-Computersystem mit mehreren Prozessoren kann die Lastverteilungseinrichtung 112 bestimmen, zu welchem Prozessor ein ankommendes Paket für die Verarbeitung durch den geeigneten Protokollstapel zu leiten ist. Die Lastverteilungseinrichtung 112 kann z. B. sichern, dass in Beziehung stehende Pakete zu einem einzelnen Prozessor geleitet werden. Durch das Senden aller Pakete in einem Kommunikationsfluss oder einer Gesamtverbindung zu einem einzelnen Prozessor kann die richtige Ordnung der Pakete erzwungen werden. Die Lastverteilungseinrichtung 112 kann in einer alternativen Ausführungsform der Erfindung weggelassen sein. In einer alternativen Ausführungsform kann der Kopf-Parser 106 außerdem direkt mit anderen Modulen der NIC 100 außer der Lastverteilungseinrichtung und dem Flussdatenbankmanager kommunizieren.
  • Folglich ändert oder aktualisiert der FDBM 108 die FDB 110, nachdem der Kopf-Parser 106 ein Paket geparst hat, während die Lastverteilungseinrichtung 112 einen Prozessor im Host-Computersystem identifiziert, um das Paket zu verarbeiten. Nach diesen Handlungen leitet der Kopf-Parser verschiedene Informationen zurück zum IPP-Modul 104. Beispielhaft können diese Informationen den Flussschlüssel des Pakets, einen Index des Flusses des Pakets innerhalb der Flussdatenbank 110, eine Kennung eines Prozessors im Host-Computersystem und verschiedene andere Daten, die das Paket betreffen (z. B. seine Länge, eine Länge eines Paketkopfes), enthalten.
  • Nun kann das Paket in der Paketwarteschlange 116 gespeichert werden, die die Pakete für die Manipulation durch die DMA-Maschine (Direktspeicherzugriff- Maschine) 120 und die Übertragung zu einem Host-Computer hält. Außer dem Speichern des Pakets in einer Paketwarteschlange wird ein entsprechender Eintrag für das Paket in einer Steuerwarteschlange 118 hergestellt, wobei die den Fluss des Pakets betreffenden Informationen außerdem zu einem dynamischen Paketstapelmodul 122 geleitet werden können. Die Steuerwarteschlange 118 enthält die in Beziehung stehenden Steuerinformationen für jedes Paket in der Paketwarteschlange 116.
  • Das Paketstapelmodul 122 entnimmt die Informationen, die die Pakete in der Paketwarteschlange 116 betreffen, um die Stapelverarbeitung (d. h. die gemeinsame Verarbeitung) der Köpfe von mehreren in Beziehung stehenden Paketen zu ermöglichen. In einer Ausführungsform der Erfindung signalisiert das Paketstapelmodul 122 dem Host-Computer die Verfügbarkeit der Köpfe von in Beziehung stehenden Paketen, sodass sie zusammen verarbeitet werden können.
  • Obwohl in einer Ausführungsform der Erfindung die Verarbeitung der Protokollköpfe eines Pakets durch einen Prozessor in einem Host-Computersystem ausgeführt wird, können in einer weiteren Ausführungsform die Protokollköpfe durch einen Prozessor verarbeitet werden, der sich in der NIC 100 befindet. In der ersteren Ausführungsform kann die Software im Host-Computer (z. B. ein Vorrichtungstreiber für die NIC 100) die Vorteile des zusätzlichen Speichers und eines austauschbaren oder aufrüstbaren Prozessors (z. B. kann der Speicher ergänzt und der Prozessor durch ein schnelleres Modell ersetzt werden) ernten.
  • Während der Speicherung eines Pakets in der Paketwarteschlange 116 kann ein Prüfsummengenerator 114 eine Prüfsummenoperation ausführen. Die Prüfsumme kann zur Paketwarteschlange als ein Nachsatz für das Paket hinzugefügt werden. Beispielhaft erzeugt der Prüfsummengenerator 114 eine Prüfsumme aus einem Abschnitt des vom Netz 102 empfangenen Pakets. In einer Ausführungsform der Erfindung wird eine Prüfsumme aus dem TCP-Abschnitt eines Pakets (z. B. dem TCP-Kopf und den TCP-Daten) erzeugt. Falls ein Paket nicht entsprechend dem TCP-Protokoll formatiert ist, kann eine Prüfsumme an einem anderen Abschnitt des Pakets erzeugt werden, wobei das Ergebnis in der späteren Verarbeitung eingestellt werden kann, wie es notwendig ist. Falls z. B. die durch den Prüfsummengenerator 114 berechnete Prüfsumme nicht im richtigen Abschnitt des Pakets berechnet worden ist, kann die Prüfsumme eingestellt werden, um den richtigen Abschnitt zu erfassen. Diese Einstellung kann durch Software, die in einem Host- Computersystem arbeitet, (z. B. einen Vorrichtungstreiber) ausgeführt werden. Der Prüfsummengenerator 114 kann in einer alternativen Ausführungsform der Erfindung weggelassen oder mit einem anderen Modul der NIC 100 verschmolzen sein.
  • Aus den vom Kopf-Parser 106 erhaltenen Informationen und den vom Flussdatenbankmanager 108 gemanagten Flussinformationen kann das durch die NIC 100 bediente Host-Computersystem in der veranschaulichten Ausführungsform den Netzverkehr sehr effizient verarbeiten. Die Datenabschnitte der in Beziehung stehenden Pakete können z. B. durch die DMA-Maschine 120 erneut zusammengefügt werden, um Ansammlungen zu bilden, die effizienter manipuliert werden können. Durch das Zusammenfügen der Daten in Puffern mit der Größe einer Speicherseite können die Daten durch das "Seitenumdrehen", bei dem eine durch die DMA-Maschine 120 gefüllte ganze Speicherseite auf einmal bereitgestellt wird, effizienter zu einer Zielentität übertragen werden. Ein Seitenumdrehen kann folglich den Platz von mehreren Kopieroperationen einnehmen. Unterdessen können die Kopfabschnitte der erneut zusammengefügten Pakete ähnlich als eine Gruppe durch ihren geeigneten Protokollstapel verarbeitet werden.
  • Wie bereits beschrieben worden ist, kann in einer weiteren Ausführungsform der Erfindung die Verarbeitung des Netzverkehrs durch die geeigneten Protokollstapel effizient in einem Mehrprozessor-Host-Computersystem verteilt werden. In dieser Ausführungsform ordnet die Lastverteilungseinrichtung 112 in Beziehung stehende Pakete (z. B. Pakete im selben Kommunikationsfluss) dem selben Prozessor zu oder verteilt sie zu ihm. Insbesondere können Pakete, die in ihren Protokollköpfen der Schicht drei (z. B. dem IP) dieselben Ursprungs- und Zieladressen und/oder in ihren Protokollköpfen der Schicht vier (z. B. dem TCP) dieselben Ursprungs- und Ziel-Ports besitzen, zu einem einzelnen Prozessor geschickt werden.
  • In der in 1A veranschaulichten NIC sind die oben erörterten Verarbeitungsverbesserungen (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung der Paketköpfe, das Verteilen der Protokollstapelverarbeitung) für vom Netz 102 empfangene Pakete möglich, die entsprechend einem oder mehreren im Voraus gewählten bzw. gewählter Protokollstapel formatiert sind. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet, wobei die NIC 100 deshalb konfiguriert ist, um die Pakete unter Verwendung eines von mehreren Protokollstapeln zu verarbeiten, die mit dem Internet kompatibel sind. Die nicht entsprechend den im Voraus ausgewählten Protokollen konfigurierten Pakete werden ebenfalls verarbeitet, sie können aber nicht die Vorteile des vollen Satzes der Verarbeitungseffizienzen erhalten, die für Pakete bereitgestellt werden, die die im Voraus ausgewählten Protokolle erfüllen.
  • Die Pakete, die nicht einem der im Voraus ausgewählten Protokollstapel entsprechen, können für die Verarbeitung in einem Mehrprozessorsystem auf der Grundlage der Ursprungs- und Zieladressen der Schicht zwei (z. B. der Endgerät-Anschlusssteuerung) des Pakets anstatt der Adressen ihrer Schicht drei oder Schicht vier verteilt werden. Die Verwendung der Kennungen der Schicht zwei stellt weniger Granularität für die Lastverteilungsprozedur bereit, wobei folglich die Verarbeitung der Pakete möglicherweise weniger gleichmäßig verteilt wird, als wenn die Kennungen der Schicht drei/vier verwendet würden.
  • 1B stellt ein Verfahren der Verwendung der NIC 100 nach 1A dar, um ein Paket vom Netz 102 zu empfangen und es zu einem Host-Computer zu übertragen. Der Zustand 130 ist ein Anfangszustand, der möglicherweise durch die Initialisierung oder das Zurücksetzen der NIC 100 gekennzeichnet ist.
  • Im Zustand 132 wird ein Paket durch die NIC 100 vom Netz 102 empfangen. Wie bereits beschrieben worden ist, kann das Paket entsprechend einer Vielzahl von Kommunikationsprotokollen formatiert sein. Das Paket kann durch ein MAC-Modul empfangen und anfangs manipuliert werden, bevor es zu einem IPP-Modul geleitet wird.
  • In einem Zustand 134 wird ein Abschnitt des Pakets kopiert und zum Kopf-Parser 106 geleitet. Dann parst der Kopf-Parser 106 das Paket, um die Werte von einem oder mehreren seiner Kopfbereiche und/oder seiner Daten zu extrahieren. Aus einigen der wiedergewonnenen Informationen wird ein Flussschlüssel erzeugt, um den Kommunikationsfluss zu identifizieren, der das Paket enthält. Der Grad oder das Ausmaß, in dem das Paket geparst wird, kann insofern von seinen Protokollen abhängen, als der Kopf-Parser konfiguriert sein kann, um die Köpfe verschiedener Protokolle in verschiedene Tiefen zu parsen. Insbesondere kann der Kopf-Parser 106 für eine spezifische Menge von Protokollen oder Protokollstapeln optimiert (z. B. seine Betriebsbefehle konfiguriert) sein. Falls das Paket einem oder mehreren der spezifizierten Protokolle entspricht, kann es vollständiger als ein Paket, das keines der Protokolle einhält, geparst werden.
  • Im Zustand 136 werden die aus den Kopfbereichen der Pakete extrahierten Informationen zum Flussdatenbankmanager 108 und/oder zur Lastverteilungseinrichtung 112 weitergeleitet. Der FDBM verwendet die Informationen, um einen Fluss in der Flussdatenbank 110 aufzubauen, falls für diesen Kommunikationsfluss nicht bereits einer vorhanden ist. Wenn für den Fluss des Pakets bereits ein Eintrag vorhanden ist, kann er aktualisiert werden, um den Empfang eines neuen Flusspakets widerzuspiegeln. Ferner erzeugt der FDBM 108 einen Operationscode, um eine oder mehrere Eigenschaften oder einen oder mehrere Zustände des Pakets zusammenzufassen. Der Operationscode kann durch andere Module der NIC 100 verwendet werden, um das Paket in einer geeigneten Weise abzuwickeln, wie in anschließenden Abschnitten beschrieben ist. Der Operationscode wird zum Kopf-Parser zusammen mit einem Index (z. B. einer Flussnummer) des Flusses des Pakets in der Flussdatenbank zurückgeschickt.
  • Im Zustand 138 weist die Lastverteilungseinrichtung 112 dem Paket eine Prozessornummer zu, falls der Host-Computer mehrere Prozessoren enthält, wobei sie die Prozessornummer zum Kopfprozessor zurückschickt. Beispielhaft identifiziert die Prozessornummer, welcher Prozessor das Paket durch seinen Protokollstapel im Host-Computer führen soll. Der Zustand 138 kann in einer alternativen Ausführungsform der Erfindung weggelassen sein, insbesondere wenn der Host-Computer nur einen einzelnen Prozessor umfasst.
  • Im Zustand 140 wird das Paket in der Paketwarteschlange 116 gespeichert. Wenn die Inhalte des Pakets in die Paketwarteschlange gelegt sind, kann der Prüfsummengenerator 114 eine Prüfsumme berechnen. Der Prüfsummengenerator kann durch das IPP-Modul 104 informiert werden, mit welchem Abschnitt des Pakets die Prüfsumme zu berechnen ist. Die berechnete Prüfsumme wird zur Paketwarteschlange als ein Nachsatz zum Paket hinzugefügt. In einer Ausführungsform der Erfindung wird das Paket im Wesentlichen zum gleichen Zeitpunkt in der Paketwarteschlange gespeichert, zu dem eine Kopie eines Kopfabschnitts des Pakets dem Kopf-Parser 106 bereitgestellt wird.
  • Im Zustand 140 werden außerdem die Steuerinformationen für das Paket in der Steuerwarteschlange 118 gespeichert, wobei die Informationen, die den Fluss des Pakets (z. B. die Flussnummer, den Flussschlüssel) betreffen, dem dynamischen Paketstapelmodul 122 bereitgestellt werden können.
  • Im Zustand 142 bestimmt die NIC 100, ob das Paket bereit ist, um zum Speicher des Host-Computers übertragen zu werden. Bis es bereit ist, übertragen zu werden, wartet die veranschaulichte Prozedur.
  • Wenn das Paket bereit ist, übertragen zu werden (z. B. das Paket befindet sich im Kopf der Paketwarteschlange oder der Host-Computer empfängt das Paket vor diesem Paket in der Paketwarteschlange), bestimmt im Zustand 144 das dynamische Paketstapelmodul 122, ob ein in Beziehung stehendes Paket bald übertragen wird. Wenn ja, dann wird, wenn das gegenwärtige Paket zum Host-Speicher übertragen wird, dem Host-Computer signalisiert, dass ein in Beziehung stehendes Paket bald folgen wird. Der Host-Computer kann dann die Pakete (z. B. durch ihren Protokollstapel) als eine Gruppe verarbeiten.
  • Im Zustand 146 wird das Paket (z. B. über eine Direktspeicherzugriffsoperation) zum Speicher des Host-Computers übertragen. Im Zustand 148 wird der Host-Computer benachrichtigt, dass das Paket übertragen worden ist. Die veranschaulichte Prozedur endet dann im Zustand 150.
  • Ein Fachmann auf dem Gebiet der Computersysteme und der Netze erkennt, dass die obenbeschriebene Prozedur nur ein Verfahren ist, um die Module der NIC 100 zu verwenden, um ein einzelnes Paket von einem Netz zu empfangen und es zu einem Host-Computersystem zu übertragen. Innerhalb des Umfangs der Erfindung werden außerdem andere geeignete Verfahren für möglich gehalten.
  • Ein beispielhaftes Paket
  • 2 ist eine graphische Darstellung eines durch die NIC 100 vom Netz 102 empfangenen beispielhaften Pakets. Das Paket 200 umfasst einen Datenabschnitt 202 und einen Kopfabschnitt 204, wobei es außerdem einen Nachsatzabschnitt 206 enthalten kann. Abhängig von der vom Paket 200 durchquerten Netzumgebung kann seine maximale Größe (z. B. seine maximale Übertragungseinheit oder MTU) eingeschränkt sein.
  • In der veranschaulichten Ausführungsform umfasst der Datenabschnitt 202 die Daten, die einer Ziel- oder Empfangsentität innerhalb eines Computersystems (z. B. einem Anwender-, einem Anwendungsprogramm, einem Betriebssystem) oder einem Kommunikationsuntersystem des Computers bereitgestellt werden. Der Kopfabschnitt 204 umfasst einen oder mehrere Kopfbereiche, die dem Datenabschnitt durch die Ursprungs- oder Quellentität oder einem Computersystem, das die Ursprungsentität umfasst, vorangesetzt worden sind. Jeder Kopfbereich entspricht normalerweise einem anderen Kommunikationsprotokoll.
  • In einer typischen Netzumgebung, wie z. B. dem Internet, sind einzelne Kopfbereiche innerhalb des Kopfabschnitts 204 angebracht (z. B. vorher angehängt), wie das Paket durch verschiedene Schichten eines Protokollstapels (z. B. einer Menge von Protokollen für die Kommunikation zwischen den Entitäten) im sendenden Computersystem verarbeitet wird. 2 stellt z. B. die Protokollköpfe 210, 212, 214 und 216 dar, die in dieser Reihenfolge den Schichten eins bis vier eines geeigneten Protokollstapels entsprechen. Jeder Protokollkopf enthält die durch das empfangende Computersystem zu verwendenden Informationen, wenn das Paket empfangen und durch den Protokollstapel verarbeitet wird. Schließlich wird jeder Protokollkopf beseitigt und der Datenabschnitt 202 wiedergewonnen.
  • In einer Ausführungsform der Erfindung werden ein System und ein Verfahren geschaffen, um das Paket 200 zu parsen, um verschiedene Bits der Informationen wiederzugewinnen. In dieser Ausführungsform wird das Paket 200 geparst, um den Anfang des Datenabschnitts 202 identifizieren und um einen oder mehrere Werte für die Felder innerhalb des Kopfabschnitts 204 wiederzugewinnen. Beispielhaft entspricht jedoch der Protokollkopf oder die Präambel 210 der Schicht eins einer Spezifikation auf Hardware-Ebene, die mit der Codierung der einzelnen Bits in Beziehung steht. Die Protokolle der Schicht eins werden im Allgemeinen nur für den physikalischen Prozess des Sendens oder Empfangens des Pakets über einen Leiter benötigt. Folglich wird in dieser Ausführungsform der Erfindung die. Präambel 210 der Schicht eins vom Paket 200 eliminiert, kurz nachdem es durch die NIC 100 empfangen worden ist, wobei sie deshalb nicht geparst wird.
  • Das Ausmaß, in dem der Kopfabschnitt 204 geparst wird, kann davon abhängen, wie viele, wenn überhaupt eines, der im Kopfabschnitt dargestellten Protokolle mit einer Menge im Voraus ausgewählter Protokolle übereinstimmen. Die Parsprozedur kann z. B. abgekürzt oder abgebrochen werden, sobald bestimmt wird, dass einer der Kopfbereiche des Pakets einem nicht unterstützten Protokoll entspricht.
  • Insbesondere ist in einer Ausführungsform der Erfindung die NIC 100 hauptsächlich für den Internetverkehr konfiguriert. Folglich wird in dieser Ausführungsform das Paket 200 nur umfassend geparst, wenn das Protokoll der Schicht zwei das Ethernet ist (entweder das herkömmliche Ethernet oder das 802.3-Ethernet, mit oder ohne Kennzeichnung für virtuelle lokale Netze), das Protokoll der Schicht drei das IP (Internetprotokoll) ist und das Protokoll der Schicht vier das TCP (Transportsteuerprotokoll) ist. Die Pakete, die andere Protokolle einhalten, können in irgendeinem (z. B. geringeren) Ausmaß geparst werden. Die NIC 100 kann jedoch konfiguriert sein, um praktisch jeden Kopfbereich eines Kommunikationsprotokolls zu unterstützen und zu parsen. Beispielhaft sind die Protokollköpfe, die geparst werden, und das Ausmaß, in dem sie geparst werden, durch die Konfiguration eines Befehlssatzes zum Betreiben des Kopf-Parsers 106 bestimmt.
  • Wie oben beschrieben worden ist, hängen die Protokolle, die den Kopfbereichen 212, 214 und 216 entsprechen, von der Netzumgebung ab, in der ein Paket gesendet wird. Die Protokolle hängen außerdem von den kommunizierenden Entitäten ab. Ein von einer Netzschnittstelle empfangenes Paket kann z. B. ein zwischen den Endgerät-Anschlusssteuerungen für die Ursprungs- und Ziel-Computersysteme ausgetauschtes Steuerpaket sein. In diesem Fall würde das Paket wahrscheinlich minimale oder keine Daten enthalten, wobei es den Protokollkopf 214 der Schicht drei oder den Protokollkopf 216 der Schicht vier nicht enthalten kann. Die Steuerpakete werden typischerweise für verschiedene Zwecke verwendet, die mit dem Management der einzelnen Verbindungen in Beziehung stehen.
  • Ein weiterer Kommunikationsfluss oder eine weitere Kommunikationsverbindung könnte zwei Anwendungsprogramme umfassen. In diesem Fall kann ein Paket die Kopfbereiche 212, 214 und 216 enthalten, wie in 2 gezeigt ist, wobei es außerdem zusätzliche Kopfbereiche enthalten kann, die mit den höheren Schichten eines Protokollstapels (z. B. Sitzungs-, Darstellungs- und Anwendungsschichten im ISO-OSI-Modell) in Beziehung stehen. Außerdem können einige Anwendungen Kopfbereiche oder kopfähnliche Informationen innerhalb des Datenabschnitts 202 enthalten. Für eine Netzdateisystem-Anwendung (NFS-Anwendung) kann z. B. der Datenabschnitt 202 NFS-Kopfbereiche enthalten, die mit einzelnen NFS-Datagrammen in Beziehung stehen. Ein Datagramm kann als eine Sammlung von von einer Entität zu einer anderen gesendeten Daten definiert sein, wobei es in mehreren Paketen übertragene Daten umfassen kann. Mit anderen Worten, die Datenmenge, die ein Datagramm bildet, kann größer als die Datenmenge sein, die in einem Paket enthalten sein kann.
  • Eine Ausführungsform eines Kopf-Parsers
  • 3 stellt den Kopf-Parser 106 nach 1A gemäß einer vorliegenden Ausführungsform der Erfindung dar. Beispielhaft umfasst der Kopf-Parsers 106 den Kopfspeicher 302 und den Parser 304, wobei der Parser 304 den Befehlsspeicher 306 umfasst. In einer alternativen Ausführungsform der Erfindung sind der Kopfspeicher 302 und der Befehlsspeicher 306 zusammenhängend, obwohl sie in 3 als getrennte Module dargestellt sind. Vorteilhaft sind die hierin beschriebenen Verfahren zum Parsen eines Pakets leicht für Pakete anpassbar, die in Übereinstimmung mit praktisch jedem Kommunikationsprotokoll formatiert sind.
  • In der veranschaulichten Ausführungsform parst der Parser 304 einen im Kopfspeicher 302 gespeicherten Kopf entsprechend den im Befehlsspeicher 306 gespeicherten Befehlen. Die Befehle sind für das Parsen spezieller Protokolle oder eines speziellen Protokollstapels konstruiert, wie oben erörtert worden ist. In einer Ausführungsform der Erfindung ist der Befehlsspeicher 306 modifizierbar (der Speicher ist z. B. als RAM, EPROM, EEPROM oder dergleichen implementiert), sodass neue oder modifizierte Parsbefehle heruntergeladen oder anderweitig installiert werden können. Die Befehle zum Parsen eines Pakets sind im folgenden Abschnitt weiter erörtert.
  • In 3 wird ein Kopfabschnitt eines im (in 1A gezeigten) IPP-Modul 104 gespeicherten Pakets in den Kopfspeicher 302 kopiert. Beispielhaft wird eine spezifische Anzahl von Bytes (z. B. 114) am Anfang des Pakets kopiert. In einer alternativen Ausführungsform der Erfindung kann der Abschnitt eines Pakets, der kopiert wird, eine andere Größe aufweisen. Die spezielle Menge eines in den Kopfspeicher 302 kopierten Paketes sollte ausreichend sein, um einen oder mehrere Protokollköpfe oder wenigstens ausreichend Informationen (z. B. ob sie in einem Kopf- oder Datenabschnitt des Pakets enthalten sind), um die im Folgenden beschriebenen Informationen wiederzugewinnen, zu erfassen. Der im Kopfspeicher 302 gespeicherte Kopfabschnitt enthält vielleicht nicht den Kopfbereich der Schicht eins, der vor der oder im Zusammenhang mit der Verarbeitung des Pakets durch das IPP-Modul 104 entfernt werden kann.
  • Nachdem ein Kopfabschnitt des Pakets im Kopfspeicher 302 gespeichert worden ist, parst der Parser 304 den Kopfabschnitt entsprechend den im Befehlsspeicher 306 gespeicherten Befehlen. Die Befehle zum Betreiben des Parsers 304 in der gegenwärtig beschriebenen Ausführungsform wenden die Formate der ausgewählten Protokolle an, um die Inhalte des Kopfspeichers 302 zu durchlaufen und spezifische Informationen wiederzugewinnen. Insbesondere sind die Spezifikationen der Kommunikationsprotokolle wohl bekannt und allgemein verfügbar. Folglich kann ein Protokollkopf byteweise oder in irgendeiner anderen Weise durchlaufen werden, indem auf die Protokollspezifikationen Bezug genommen wird. Folglich ist in einer vorliegenden Ausführungsform der Erfindung der Parsalgorithmus dynamisch, wobei die von einem Feld eines Kopfes wiedergewonnenen Informationen oft die Art ändern, in der ein weiterer Teil geparst wird.
  • Es ist z. B. bekannt, dass das Typfeld eines Pakets, das die herkömmliche Form des Ethernets (z. B. Version zwei) einhält, am dreizehnten Byte des Kopfbereichs (der Schicht zwei) beginnt. Zum Vergleich beginnt das Typfeld eines Pakets, das der IEEE-802.3-Version des Ethernets folgt, am einundzwanzigsten Byte des Kopfbereichs. Das Typfeld befindet sich an noch anderen Orten, falls das Paket einen Teil einer Kommunikation über ein virtuelles lokales Netz (VLAN) bildet (das beispielhaft die Kennzeichnung oder Einkapselung eines Ethernet-Kopfes umfasst). Folglich werden in einer vorliegenden Ausführungsform der Erfindung die Werte in bestimmten Feldern wiedergewonnenen und geprüft, um zu sichern, dass die von einem Kopfbereich benötigten Informationen vom richtigen Abschnitt des Kopfbereichs entnommen werden. Die Einzelheiten, die die Form eines VLAN-Pakets betreffen, sind in den Spezifikationen für die IEEE-802.3p- und IEEE-802.3q-Formen des Ethernet-Protokolls zu finden.
  • Die Operation des Kopf-Parsers 106 hängt außerdem von den Unterschieden zwischen den Protokollen ab, wie z. B. ob das Paket die Version vier oder die Version sechs des Internetprotokolls usw. verwendet. Die Spezifikationen der Versionen vier und sechs des IP sind in den RFCs (Kommentaranforderungen) 791 bzw. 2460 der IETF (Internettechnik-Projektgruppe) zu finden.
  • Je mehr Protokolle dem Parser 304 "bekannt" sind, nach desto mehr Protokollen kann ein Paket überprrüft werden, und desto komplizierter kann das Parsen eines Kopfabschnitts eines Pakets werden. Ein Fachmann auf dem Gebiet erkennt, dass die Protokolle, die durch den Parser 304 geparst werden können, nur durch die Befehle eingeschränkt sind, entsprechend denen er arbeitet. Folglich können durch Vergrößerung oder Ersetzung der im Befehlsspeicher 306 gespeicherten Parsbefehle praktisch alle bekannten Protokolle durch den Kopf-Parser 106 abgewickelt werden, wobei praktisch alle Informationen aus den Kopfbereichen eines Pakets wiedergewonnen werden können.
  • Falls ein Paketkopf einem erwarteten oder vermuteten Protokoll nicht entspricht, kann selbstverständlich die Parsoperation beendet werden. In diesem Fall kann das Paket für eine oder mehrere der durch die NIC 100 angebotenen Effizienzverbesserungen (z. B. das erneute Zusammenfügen der Daten, die Paketstapelung, die Lastverteilung) nicht geeignet sein.
  • Beispielhaft werden die von den Kopfbereichen eines Pakets wiedergewonnenen Informationen durch andere Abschnitte der NIC 100 verwendet, wenn dieses Paket verarbeitet wird. Im Ergebnis des durch den Parser 304 ausgeführten Parsens des Pakets wird z. B. ein Flussschlüssel erzeugt, um den Kommunikationsfluss oder die Kommunikationsverbindung zu identifizieren, der bzw. die das Paket umfasst. Beispielhaft wird der Flussschlüssel zusammengefügt, indem eine oder mehrere Adressen verkettet werden, die einer oder mehreren der kommunizierenden Entitäten entsprechen. In einer vorliegenden Ausführungsform wird ein Flussschlüssel aus einer Kombination der aus dem IP-Kopf entnommenen Ursprungs- und Zieladressen und den vom TCP-Kopf genommenen Ursprungs- und Ziel-Ports gebildet. Andere Indizien der kommunizierenden Entitäten können verwendet werden, wie z. B. die (aus dem Kopfbereich der Schicht zwei entnommenen) Ethernet-Ursprungs- und -Zieladressen, die NFS-Dateikennziffern oder die vom Datenabschnitt des Pakets entnommenen Ursprungs- und Zielkennungen für andere Anwendungsdatagramme.
  • Ein Fachmann auf dem Gebiet erkennt, dass die kommunizierenden Entitäten unter Verwendung der von den höheren Schichten des einem Paket zugeordneten Protokollstapels entnommenen Indizien mit einer größeren Auflösung identifiziert werden können. Folglich kann eine Kombination der IP- und TCP-Indizien die Entitäten mit einer größeren Genauigkeit als die Informationen der Schicht zwei identifizieren.
  • Außer einem Flussschlüssel erzeugt der Parser 304 außerdem einen Steuer- oder Statusindikator, um zusätzliche Informationen zusammenzufassen, die das Paket betreffen. In einer Ausführungsform der Erfindung enthält ein Steuerindikator eine Sequenznummer (z. B. die von einem TCP-Kopf entnommene TCP-Sequenznummer), um die richtige Ordnung der Pakete zu sichern, wenn ihre Daten erneut zusammengefügt werden. Der Steuerindikator kann außerdem enthüllen, ob bestimmte Merker in den Kopfbereichen des Pakets gesetzt oder gelöscht sind, ob das Paket irgendwelche Daten enthält und, falls das Paket Daten enthält, ob die Daten eine bestimmte Größe überschreiten. Andere Daten sind außerdem für die Aufnahme in den Steuerindikator geeignet, eingeschränkt nur durch die Informationen, die in dem Abschnitt des durch den Parser 304 geparsten Pakets verfügbar sind.
  • In einer Ausführungsform der Erfindung stellt der Kopf-Parser 106 einen Flussschlüssel und den ganzen Steuerindikator oder einen Abschnitt des Steuerindikators dem Flussdatenbankmanager 108 bereit. Wie in einem folgenden Abschnitt erörtert ist, managt der FDBM 108 eine Datenbank oder eine andere Datenstruktur, die die für die durch die NIC 100 gehenden Kommunikationsflüsse relevanten Informationen enthält.
  • In anderen Ausführungsformen der Erfindung erzeugt der Parser 304 vom Kopfbereich eines Pakets abgeleitete zusätzliche Informationen für die Verwendung durch andere Module der NIC 100. Der Kopf-Parser 106 kann z. B. den Versatz vom Anfang des Pakets oder von irgendeinem anderen Punkt des Daten- oder Nutzinformationenabschnitts eines von einem Netz empfangenen Pakets melden. Wie oben beschrieben worden ist, folgt der Datenabschnitt eines Pakets typischerweise dem Kopfabschnitt, wobei ihm ein Nachsatzabschnitt folgen kann. Andere Daten, die der Kopf-Parser 106 melden kann, enthaften den Ort im Paket, an dem eine Prüfsummenoperation beginnen sollte, den Ort im Paket, an dem die Kopfbereiche der Schicht drei und/oder der Schicht vier beginnen, diagnostische Daten, Nutzinformationeninformationen usw. Der Begriff "Nutzinformationen" wird oft verwendet, um auf den Datenabschnitt eines Pakets Bezug zu nehmen. Insbesondere stellt in einer Ausführungsform der Erfindung der Kopf-Parser 106 einen Nutzinformationenversatz und eine Nutzinformationengröße der Steuerwarteschlange 118 bereit.
  • Unter geeigneten Umständen kann der Kopf-Parser 106 außerdem (z. B. dem IPP-Modul 104 und/oder der Steuerwarteschlange 118) melden, dass das Paket nicht in Übereinstimmung mit den Protokollen formatiert ist, für deren Manipulation der Parser 304 konfiguriert ist. Diese Meldung kann die Form eines Signals (z. B. des im Folgenden beschriebenen No_Assist-Signals), einer Signalisierung, eines Merkers oder eines anderen Indikators annehmen. Das Signal kann erzeugt oder ausgegeben werden, wann immer festgestellt wird, dass das Paket ein anderes Protokoll als die im Voraus ausgewählten Protokolle widerspiegelt, die mit den obenbeschriebenen Verarbeitungsverbesserungen (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung der Paketköpfe, die Lastverteilung) kompatibel sind. In einer Ausführungsform der Erfindung kann z. B. der Parser 304 konfiguriert sein, um die Pakete unter Verwendung des TCP in der Schicht vier, des IP in der Schicht drei und des Ethernets in der Schicht zwei zu parsen und effizient zu verarbeiten. In dieser Ausführungsform würde ein IPX-Paket (Paket einer netzüberschreitenden Paketvermittlung) nicht als kompatibel betrachtet, wobei die IPX-Pakete deshalb für das erneute Zusammenfügen der Daten und die Stapelverarbeitung nicht gesammelt werden würden.
  • Beim Abschluss des Parsens werden in einer Ausführungsform der Erfindung die obenbeschriebenen verschiedenen Stücke der Informationen an die geeigneten Module der NIC 100 verbreitet. Danach (und wie in einem folgenden Abschnitt beschrieben ist) bestimmt der Flussdatenbankmanager 108, ob ein aktiver Fluss dem aus dem Paket abgeleiteten Flussschlüssel zugeordnet ist, wobei er einen in der anschließenden Verarbeitung zu verwendenden Operationscode festlegt. Außerdem überträgt das IPP-Modul 104 das Paket zur Paketwarteschlange 116. Das IPP-Modul 104 kann außerdem einige der durch den Kopf-Parser 106 extrahierten Informationen empfangen und sie zu einem weiteren Modul der NIC 100 weiterleiten.
  • In der in 3 dargestellten Ausführungsform der Erfindung wird ein ganzer Kopfabschnitt eines zu parsenden empfangenen Pakets kopiert und dann in einem Ablauf geparst, nach dem der Kopf-Parser seine Aufmerksamkeit einem weiteren Paket zuwendet. In einer alternativen Ausführungsform können jedoch mehrere Kopier- und/oder Parsoperationen an einem einzelnen Paket ausgeführt werden. Insbesondere kann ein anfänglicher Kopfabschnitt des Pakets in einem ersten Ablauf in den Kopf-Parser 106 kopiert und durch den Kopf-Parser 106 geparst werden, nach dem ein weiterer Kopfabschnitt in einem zweiten Ablauf in den Kopf-Parser 106 kopiert und geparst werden kann. Ein Kopfabschnitt in einem Ablauf kann teilweise oder vollständig den Kopfabschnitt eines weiteren Ablaufs überlappen. In dieser Weise können ausgedehnte Kopfbereiche geparst werden, selbst wenn der Kopfspeicher 302 eine eingeschränkte Größe aufweist. Es kann ähnlich mehr als eine Operation erfordern, um einen vollen Befehlssatz für das Parsen eines Pakets in den Befehlspeicher 306 zu laden. Beispielhaft kann ein erster Abschnitt der Befehle geladen und ausgeführt werden, wobei danach andere Befehle geladen werden.
  • Unter Bezugnahme auf die 4A–4B wird nun ein Ablaufplan dargestellt, um ein Verfahren zu veranschaulichen, mit dem ein Kopf-Parser einen Kopfabschnitt eines an einer Netzschnittstellenschaltung von einem Netz empfangenen Paketes parsen kann. In dieser Implementierung ist der Kopf-Parser konfiguriert oder optimiert, um Pakete zu parsen, die einer Menge im Voraus ausgewählter Protokolle (oder Protokollstapel) entsprechen. Für Pakete, die diese Kriterien erfüllen, werden verschiedene Informationen aus dem Kopfabschnitt wiedergewonnen, um das erneute Zusammenfügen der Datenabschnitte in Beziehung stehender Pakete (z. B. der Pakete, die die Daten von einem einzelnen Datagramm umfassen) zu unterstützen. Andere verbesserte Merkmale der Netzschnittstellenschaltung können außerdem ermöglicht sein.
  • Die durch den Kopf-Parser erzeugten Informationen enthalten insbesondere einen Flussschlüssel, mit dem der Kommunikationsfluss oder die Kommunikationsverbindung zu identifizieren ist, der bzw. die das empfangene Paket umfasst. In einer Ausführungsform der Erfindung können die Daten aus den Paketen, die den gleichen Flussschlüssel besitzen, identifiziert und erneut zusammengefügt werden, um ein Datagramm zu bilden. Außerdem können die Köpfe der Pakete, die den gleichen Flussschlüssel besitzen, gemeinsam durch ihren Protokollstapel (z. B. anstatt seriell) verarbeitet werden.
  • In einer weiteren Ausführungsform der Erfindung werden die durch den Kopf-Parser wiedergewonnenen Informationen außerdem verwendet, um die Verarbeitung des von einem Netz empfangenen Netzverkehrs zu verteilen. Mehrere Pakete, die den gleichen Flussschlüssel besitzen, können z. B. zu einem einzelnen Prozessor eines Mehrprozessor-Host-Computersystems gesendet werden.
  • In dem in den 4A–4B veranschaulichten Verfahren entspricht die Menge der im Voraus ausgewählten Protokolle den häufig über das Internet übertragenen Kommunikationsprotokollen. Insbesondere enthält die Menge der Protokolle, die in diesem Verfahren umfassend geparst werden können, das Folgende. In der Schicht zwei: das Ethernet (die herkömmliche Version), das 802.3-Ethernet, das Ethernet-VLAN (Ethernet für virtuelle lokale Netze) und das 802.3-Ethernet-VLAN. In der Schicht drei: das IPv4 (ohne Optionen) und das IPv6 (ohne Optionen). Schließlich werden in der Schicht vier nur die TCP-Protokollköpfe (mit oder ohne Optionen) im veranschaulichen Verfahren geparst. Die Kopf-Parser in alternativen Ausführungsformen der Erfindung parsen die durch andere Protokollstapel formatierten Pakete. Insbesondere kann eine NIC in Übereinstimmung mit den häufigsten Protokollstapeln, die in einem gegebenen Netz verwendet werden, konfiguriert sein, die Protokolle enthalten oder nicht enthalten können, die mit dem in den 4A–4B veranschaulichten Verfahren für den Kopf-Parser kompatibel sind.
  • Wie oben beschrieben worden ist, kann ein empfangenes Paket, das den durch ein gegebenes Verfahren geparsten Protokollen nicht entspricht, mit einem Merker gekennzeichnet und der Parsalgorithmus für dieses Paket beendet werden. Weil die Protokolle, nach denen ein Paket formatiert worden ist, im vorliegenden Verfahren nur bestimmt werden können, indem die Werte von bestimmten Kopffeldern untersucht werden, kann die Bestimmung, dass ein Paket einer ausgewählten Menge von Protokollen nicht entspricht, zu praktisch jedem Zeitpunkt während der Prozedur ausgeführt werden. Folglich besitzt das veranschaulichte Parsverfahren als ein Ziel die Identifizierung von Paketen, die die Formatierungskritetien für das erneute Zusammenfügen der Daten nicht erfüllen.
  • Verschiedene Felder des Protokollkopfes, die in den Kopfbereichen für die ausgewählten Protokolle erscheinen, sind im Folgenden erörtert. Die Kommunikationsprotokolle, die mit einer Ausführungsform der vorliegenden Erfindung kompatibel sein können (z. B. die Protokolle, die durch einen Kopf-Parser geparst werden können), sind den Fachleuten auf dem Gebiet wohl bekannt, wobei sie in einer Anzahl von Literaturstellen in großer Ausführlichkeit beschrieben sind. Sie müssen deshalb hierin nicht in den kleinsten Einzelheiten erörtert werden. Außerdem ist das veranschaulichte Verfahren zum Parsen eines Kopfabschnitts eines Pakets für die ausgewählten Protokolle lediglich ein Verfahren zum Sammeln der im Folgenden beschriebenen Informationen. Andere Parsprozeduren, die dies ausführen können, sind gleichermaßen geeignet.
  • In einer vorliegenden Ausführungsform der Erfindung ist die veranschaulichte Prozedur als eine Kombination aus Hardware und Software implementiert. Aktualisierbare Mikrocodebefehle zum Ausführen der Prozedur können z. B. durch eine Mikro-Ablaufsteuerung ausgeführt werden. Alternativ können derartige Befehle fest (z. B. in einem Festwertspeicher gespeichert) sein, oder sie können durch einen Prozessor oder einen Mikroprozessor ausgeführt werden.
  • In den 4A–4B ist der Zustand 400 ein Anfangszustand, während dessen ein Paket durch die (in 1A gezeigte) NIC 100 empfangen und die Anfangsverarbeitung ausgeführt wird. Die NIC 100 ist für die Zwecke dieser Prozedur mit dem Internet gekoppelt. Die Anfangsverarbeitung kann die grundlegende Fehlerüberprüfung und die Beseitigung der Präambel der Schicht eins enthalten. Nach der Anfangsverarbeitung wird das Paket durch das (ebenfalls in 1A gezeigte) IPP-Modul 104 gehalten. In einer Ausführungsform der Erfindung umfasst der Zustand 400 eine logische Schleife, in der der Kopf-Parser in einem Ruhe- oder Wartezustand verbleibt, bis ein Paket empfangen wird.
  • Im Zustand 402 wird ein Kopfabschnitt des Pakets in den Speicher (z. B. den Kopfspeicher 302 nach 3) kopiert. In einer vorliegenden Ausführungsform der Erfindung wird eine vorgegebene Anzahl von Bytes am Anfang (z. B. 114 Bytes) des Pakets kopiert. In alternativen Ausführungsformen der Erfindung werden Paketabschnitte mit anderen Größen kopiert, deren Größen durch das Ziel des Kopierens von einer genügenden Menge des Pakets gesteuert wird, um die notwendigen Kopfinformationen zu erfassen und/oder zu identifizieren. Beispielhaft wird das volle Paket durch das IPP-Modul 104 beibehalten, während die folgenden Parsoperationen ausgeführt werden, obwohl das Paket alternativ vor dem Abschluss des Parsens in der Paketwarteschlange 116 gespeichert sein kann.
  • Im Zustand 402 kann außerdem ein Zeiger initialisiert werden, der beim Parsen des Pakets zu verwenden ist. Weil die Präambel der Schicht eins entfernt worden ist, sollte der in den Speicher kopierte Kopfabschnitt mit dem Protokollkopf der Schicht zwei beginnen. Beispielhaft wird deshalb der Zeiger anfangs eingestellt, dass er auf das zwölfte Byte des Protokollkopfes der Schicht zwei zeigt, wobei der Zwei-Byte-Werte an der Zeigerposition gelesen wird. Wie ein Fachmann auf dem Gebiet erkennt, können diese zwei Bytes Teil einer Anzahl verschiedener Felder sein, abhängig davon, welches Protokoll die Schicht zwei des Protokollstapels des Pakets bildet. Diese zwei Bytes können z. B. das Typfeld eines herkömmlichen Ethernet-Kopfes, das Längenfeld eines 802.3-Ethernet-Kopfes oder das TPID-Feld (Feld der Kennungsprotokoll-Kennzeichnung) eines VLAN-gekennzeichneten Kopfbereichs sein.
  • Im Zustand 404 wird eine erste Untersuchung des Kopfbereichs der Schicht zwei ausgeführt, um zu bestimmen, ob sie einen VLAN-gekennzeichneten Protokollkopf der Schicht zwei umfasst. Beispielhaft hängt diese Bestimmung davon ab, ob die zwei Bytes an der Zeigerposition den hexadezimalen Wert 8100 speichern. Wenn ja, befindet sich der Zeiger wahrscheinlich im TPID-Feld VLAN-gekennzeichneten Kopfbereichs. Falls es kein VLAN-Kopf ist, geht die Prozedur zum Zustand 408 weiter.
  • Falls jedoch der Kopfbereich der Schicht zwei ein VLAN-gekennzeichneter Kopfbereich ist, wird im Zustand 406 das CFI-Bit (Bit des kanonischen Formatindikators) untersucht, Falls das CFI-Bit gesetzt ist (z. B. gleich eins ist), springt die veranschaulichte Prozedur zum Zustand 430, nach dem sie endet. In dieser Ausführungsform der Erfindung gibt das CFI-Bit, wenn es gesetzt ist, an, dass das Format des Pakets nicht mit den im Voraus ausgewählten Protokollen kompatibel ist (d. h., ihnen nicht entspricht), (das Protokoll der Schicht zwei ist z. B. nicht das Ethernet oder 802.3-Ethernet). Falls das CFI-Bit gelöscht ist (z. B. gleich null ist), wird der Zeiger inkrementiert (z. B. um vier Bytes), um ihn auf dem nächsten Feld zu positionieren, das untersucht werden muss.
  • Im Zustand 408 wird der Kopfbereich der Schicht zwei weiter geprüft. Obwohl es nicht bekannt ist, ob dies ein VLAN-gekennzeichneter Kopfbereich ist oder nicht, kann abhängig davon, ob der Zustand 408 durch den Zustand 406 oder direkt vom Zustand 404 erreicht worden ist, der Kopfbereich entweder das herkömmliche Ethernet-Format oder das 802.3-Ethernet-Format widerspiegeln. Am Anfang des Zustands 408 befindet sich der Zeiger entweder auf dem zwölften oder sechzehnten Byte des Kopfbereichs, von denen irgendeines einem Längenfeld oder einem Typfeld entsprechen kann. Wenn insbesondere der Zwei-Byte-Wert an der durch den Zeiger identifizierten Position kleiner als 0600 (hexadezimal) ist, dann entspricht das Paket dem 802.3-Ethernet, wobei aufgefasst wird, dass der Zeiger ein Längenfeld identifiziert. Andernfalls ist das Paket ein herkömmliches Ethernet-Paket (z. B. der Version zwei), wobei der Zeiger ein Typfeld identifiziert.
  • Falls das Protokoll der Schicht zwei das 802.3-Ethernet ist, wird die Prozedur im Zustand 410 fortgesetzt. Falls das Protokoll der Schicht zwei das herkömmliche Ethernet ist, wird das Typfeld nach den hexadezimalen Werten 0800 und 08DD überprüft. Wenn das geprüfte Feld einen dieser Werte besitzt, dann ist außerdem bestimmt worden, dass das Protokoll der Schicht drei des Pakets das Internetprotokoll ist. In diesem Fall wird die veranschaulichte Prozedur im Zustand 412 fortgesetzt. Wenn schließlich das Feld ein Typfeld ist, das einen anderen Wert als 0800 oder 86DD (hexadezimal) besitzt, dann entspricht das Protokoll der Schicht drei des Pakets nicht den im Voraus ausgewählten Protokollen, entsprechend denen der Kopf-Parser konfiguriert worden ist. Deshalb wird die Prozedur im Zustand 430 fortgesetzt, wobei sie dann endet.
  • In einer Ausführungsform der Erfindung wird das Paket im Zustand 408 untersucht, um zu bestimmen, ob es ein riesiger Ethernet-Rahmen ist. Diese Bestimmung würde wahrscheinlich ausgeführt werden, bevor entschieden wird, ob der Kopfbereich der Schicht zwei dem Ethernet oder dem 802.3-Ethernet entspricht. Beispielhaft kann die Bestimmung des riesigen Rahmens anhand der Größe des Pakets ausgeführt werden, die durch das IPP-Modul 104 oder ein MAC-Modul gemeldet werden kann. Falls das Paket ein riesiger Rahmen ist, kann die Prozedur im Zustand 410 fortgesetzt werden; andernfalls kann sie im Zustand 412 wieder aufgenommen werden.
  • Im Zustand 410 verifiziert die Prozedur, dass das Protokoll der Schicht zwei das 802.3-Ethernet mit einer LLC-SNAP-Einkapselung ist. Insbesondere wird der Zeiger fortgeschaltet (z. B. um zwei Bytes), wobei der dem Längenfeld im Kopfbereich der Schicht zwei folgende Sechs-Byte-Wert wiedergewonnen und untersucht wird. Falls der Kopfbereich ein 802.3-Ethernet-Kopf ist, ist das Feld das LLC_SNAP-Feld, wobei es einen Wert von AAAA03000000 (hexadezimal) besitzen sollte. Die ursprüngliche Spezifikation für einen LLC-SNAP-Kopfbereich ist in der Spezifikation für das IEEE 802.2 zu finden. Falls der Wert im LLC_SNAP-Feld des Pakets dem erwarteten Wert entspricht, wird der Zeiger um weitere sechs Bytes inkrementiert, das Zwei-Byte-802.3-Ethernet-Typfeld wird gelesen und die Prozedur wird im Zustand 412 fortgesetzt. Wenn die Werte nicht übereinstimmen, dann entspricht das Paket nicht den spezifizierten Protokollen, wobei die Prozedur in den Zustand 430 eintritt und dann endet.
  • Im Zustand 412 wird der Zeiger fortgeschaltet (z. B. um weitere zwei Bytes), um den Anfang des Protokollkopfes der Schicht drei zu lokalisieren. Diese Position kann für die spätere Verwendung beim schnellen Identifizieren des Anfangs dieses Kopfbereichs gesichert werden. Nun ist bekannt, dass das Paket einem akzeptierten Protokoll der Schicht zwei (z. B. dem herkömmlichen Ethernet, dem Ethernet mit LAN-Kennzeichnung oder dem 802.3-Ethernet mit LLC SNAP) entspricht, wobei es nun überprüft wird, um zu sichern, dass das Protokoll der Schicht drei des Pakets das IP ist. Wie oben erörtert worden ist, werden in der veranschaulichten Ausführungsform nur Pakete, die dem IP-Protokoll entsprechen, durch den Kopf-Parser umfassend verarbeitet.
  • Falls beispielhaft der Wert des Typfeldes im Kopfbereich der Schicht zwei (der im Zustand 402 oder im Zustand 410 wiedergewonnen wird) 0800 (hexadezimal) ist, wird erwartet, dass das Protokoll der Schicht drei das IP, Version vier, ist. Wenn der Wert 86DD (hexadezimal) ist, wird erwartet, dass das Protokoll der Schicht drei das IP, Version sechs, ist. Folglich wird das Typfeld im Zustand 412 überprüft, wobei die Prozedur im Zustand 414 oder im Zustand 418 fortgesetzt wird, abhängig davon, ob der hexadezimale Wert 0800 oder 86DD ist.
  • Im Zustand 414 wird die Übereinstimmung des Kopfbereichs der Schicht drei mit der Version vier des IP verifiziert. In einer Ausführungsform der Erfindung wird das Versionsfeld des Kopfbereichs der Schicht drei überprüft, um zu sichern, dass es den hexadezimalen Wert 4 enthält, der der Version vier des IP spricht. Wenn im Zustand 414 bestätigt wird, dass der Kopfbereich der Schicht drei das IP, Version vier, ist, wird die Prozedur im Zustand 416 fortgesetzt; andernfalls geht die Prozedur zum Zustand 430 weiter und endet dann im Zustand 432.
  • Im Zustand 416 werden verschiedene Stücke der Informationen vom IP-Kopf gesichert. Diese Informationen können das IHL- (IP-Kopflängen-), das Gesamtlängen-, das Protokoll- und/oder das Fragmentversatz-Feld enthalten. Die IP-Ursprungsadresse und die IP-Zieladresse können außerdem gespeichert sein. Die Werte der Ursprungs- und Zieladressen sind in der Version vier des IP jede vier Bytes lang. Diese Adressen werden verwendet, wie oben beschrieben worden ist, um einen Flussschlüssel zu erzeugen, der den Kommunikationsfluss identifiziert, in dem dieses Paket gesendet worden ist. Das Gesamtlängenfeld speichert die Größe des IP-Segments dieses Pakets, das beispielhaft den IP-Kopf, den TCP-Kopf und den Datenabschnitt des Pakets umfasst. Die TCP-Segmentgröße des Pakets (z. B. die Größe des TCP-Kopfes plus die Größe des Datenabschnitts des Pakets) kann berechnet werden, indem zwanzig Bytes (die Größe des Kopfbereichs der IP-Version vier) vom Gesamtlängenwert abgezogen werden. Nach dem Zustand 416 rückt die veranschaulichte Prozedur zum Zustand 422 vor.
  • Im Zustand 418 wird die Übereinstimmung des Kopfbereichs der Schicht drei mit der Version sechs des IP verifiziert, indem das Versionsfeld auf den hexadezimalen Wert 6 überprüft wird. Wenn das Versionsfeld diesen Wert nicht enthält, geht die veranschaulichte Prozedur zum Zustand 430 weiter.
  • Im Zustand 420 werden die Werte der Nutzinformationenlänge (z. B. die Größe des TCP-Segments) und das Feld für den nächsten Kopf plus die IP-Ursprungs- und -Zieladressen gesichert. Die Ursprungs- und Zieladressen sind in der Version sechs des IP jede sechzehn Bytes lang.
  • Im Zustand 422 der veranschaulichten Prozedur wird bestimmt, ob der IP-Kopf (entweder die Version vier oder die Version sechs) angibt, dass der Kopfbereich der Schicht vier das TCP ist. Beispielhaft wird das Protokollfeld des IP-Kopfes der Version vier überprüft, während das Feld für den nächsten Kopf eines Kopfbereichs der Version sechs überprüft wird. In beiden Fällen sollte der Wert 6 (hexadezimal) sein. Der Zeiger wird dann inkrementiert, wie es notwendig ist (z. B. zwanzig Bytes für die IP-Version vier, vierzig Bytes für die IP-Version sechs), um den Anfang des TCP-Kopfes zu erreichen. Wenn im Zustand 422 bestimmt wird, dass der Kopfbereich der Schicht vier nicht das TCP ist, rückt die Prozedur zum Zustand 430 vor, wobei sie im Endzustand 432 endet.
  • In einer Ausführungsform der Erfindung können andere Felder eines Kopfbereichs des IP, Version 4, im Zustand 422 überprüft werden, um zu sichern, dass das Paket die Kriterien für die verbesserte Verarbeitung durch die NIC 100 erfüllt. Ein Wert des IHL-Feldes, der von 5 (hexadezimal) verschieden ist, gibt z. B. an, dass für dieses Paket die IP-Optionen gesetzt sind, wobei in diesem Fall die Parsoperation abgebrochen wird. Ein Wert des Fragmentierungsfeldes, der von null verschieden ist, gibt an, dass das IP-Segment des Pakets ein Fragment ist, wobei in diesem Fall das Parsen ebenfalls abgebrochen wird. In beiden Fällen springt die Prozedur zum Zustand 430, wobei sie dann im Endzustand 432 endet.
  • Im Zustand 424 wird der TCP-Kopf des Pakets geparst, wobei aus ihm verschiedene Daten gesammelt werden. Insbesondere werden die Werte des TCP-Ursprungs-Ports und des TCP-Ziel-Ports gesichert. Die TCP-Sequenznummer, die verwendet wird, um das richtige erneute Zusammenfügen der Daten aus mehreren Paketen zu sichern, wird außerdem gesichert. Ferner werden die Werte einiger Komponenten des Merkerfeldes – beispielsweise die Bits URG (dringend), PSH (Schieben), RST (Zurücksetzen), SYN (Synchronisieren) und FIN (Ende) – gesichert. In einer Ausführungsform der Erfindung signalisieren diese Merker verschiedene auszuführende Handlungen oder bei der Abwicklung des Pakets zu berücksichtigende Status.
  • Andere Signale oder Status können im Zustand 424 erzeugt werden, um die aus dem TCP-Kopf wiedergewonnenen Informationen widerzuspiegeln. Der Punkt, an dem eine Prüfsummenoperation zu beginnen ist, kann z. B. gesichert werden (beispielhaft der Anfang des TCP-Kopfes); der Endpunkt einer Prüfsummenoperation kann außerdem gesichert werden (beispielsweise das Ende des Datenabschnitts des Pakets). Ein Versatz des Datenabschnitts des Pakets kann identifiziert werden, indem der Wert des Kopflängenfeldes des TCP-Kopfes mit vier multipliziert wird. Die Größe des Datenabschnitts kann dann berechnet werden, indem der Versatz zum Datenabschnitt von der Größe des ganzen TCP-Segments abgezogen wird.
  • Im Zustand 426 wird ein Flussschlüssel zusammengefügt, indem die IP-Ursprungs- und -Zieladressen und die TCP-Ursprungs- und -Ziel-Ports verkettet werden. Wie bereits beschrieben worden ist, kann der Flussschlüssel verwendet werden, um einen Kommunikationsfluss oder eine Kommunikationsverbindung zu identifizieren, wobei er durch andere Module der NIC 100 verwendet werden kann, um den Netzverkehr effizienter zu verarbeiten. Obwohl sich die Größen der Ursprungs- und Zieladressen zwischen den IP-Versionen vier und sechs unterscheiden (z. B. jeweils vier Bytes gegen jeweils sechzehn Bytes), besitzen in der gegenwärtig beschriebenen Ausführungsform der Erfindung alle Flussschlüssel eine einheitliche Größe. Insbesondere sind sie in dieser Ausführungsform sechsunddreißig Bytes lang, einschließlich des Zwei-Byte-TCP-Ursprungs-Ports und des Zwei-Byte-TCP-Ziel-Ports. Die aus den Paketköpfen des IP, Version vier, erzeugten Flussschlüssel werden aufgefüllt, wie es notwendig ist (z. B. mit vierundzwanzig leeren Bytes), um den zugeteilten Raum des Flussschlüssels zu füllen.
  • Im Zustand 428 wird ein Steuer- oder Statusindikator zusammengefügt, um verschiedene Informationen einem Modul oder mehreren Modulen der NIC 100 bereitzustellen. In einer Ausführungsform der Erfindung enthält ein Steuerindikator die TCP-Sequenznummer des Pakets, einen Merker oder eine Kennzeichnung (z. B. ein oder mehrere Bits), der bzw. die angibt, ob das Paket Daten enthält (z. B. ob die Größe der TCP-Nutzinformationen größer als null ist), einen Merker, der angibt, ob der Datenabschnitt des Pakets eine vorgegebene Größe überschreitet, und einen Merker, der angibt, ob bestimmte Einträge im TCP-Merkerfeld zu vorgegebenen Werten äquivalent sind. Der letztere Merker kann z. B. verwendet werden, um ein anderes Modul der NIC 100 zu informieren, dass die Komponenten des Merkerfeldes eine besondere Konfiguration besitzen oder nicht. Nach dem Zustand 428 endet die veranschaulichte Prozedur mit dem Zustand 432.
  • In den Zustand 430 kann an einigen verschiedenen Punkten der veranschaulichten Prozedur eingetreten werden. In diesen Zustand wird z. B. eingetreten, wenn bestimmt wird, dass ein Kopfabschnitt, der durch einen Kopf-Parser geparst wird, den oben identifizierten im Voraus ausgewählten Protokollstapeln nicht entspricht. Im Ergebnis werden viele der obenbeschriebenen Informationen nicht wiedergewonnen. Eine praktische Folge der Unfähigkeit, diese Informationen wiederzugewinnen, ist, dass sie dann den andern Modulen der NIC 100 nicht bereitgestellt werden können, wobei die hierin beschriebene verbesserte Verarbeitung für dieses Paket nicht ausgeführt werden kann. Insbesondere, und wie vorausgehend erörtert worden ist, können in einer vorliegenden Ausführungsform der Erfindung eine oder mehrere verbesserte Operationen an den geparsten Paketen ausgeführt werden, um die Effizienz zu vergrößern, mit der sie verarbeitet werden. Beispielhafte Operationen, die angewendet werden können, enthalten das erneute Zusammenfügen der Daten aus in Beziehung stehenden Paketen (z. B. Paketen, die die Daten von einem einzelnen Datagramm enthalten), die Stapelverarbeitung der Paketköpfe durch einen Protokollstapel, die Lastverteilung oder die Lastteilung der Verarbeitung des Protokollstapels, die effiziente Übertragung der Paketdaten zu einer Zielentität usw.
  • In der veranschaulichten Prozedur wird im Schritt 430 ein Merker oder ein Signal (der bzw. das beispielhaft als No_Assist bezeichnet wird), gesetzt oder gelöscht, um anzugeben, dass das gegenwärtig durch das IPP-Modul 104 gehaltene Paket (z. B. das soeben durch den Kopf-Parser verarbeitet worden ist) keinem der im Voraus ausgewählten Protokollstapel entspricht. Auf diesen Merker oder dieses Signal kann sich ein anderes Modul der NIC 100 stützen, wenn es entscheidet, ob eine der verbesserten Operationen ausgeführt wird.
  • Ein weiterer Merker oder ein weiteres Signal kann im Zustand 430 gesetzt oder gelöscht werden, um einen Prüfsummenparameter zu initialisieren, der angibt, dass eine Prüfsummenoperation, falls sie ausgeführt wird, am Anfang des Pakets beginnen sollte (z. B. ohne einen Versatz in das Paket). Beispielhaft können inkompatible Pakete nicht geparst werden, um einen geeigneteren Punkt zu bestimmen, von dem die Prüfsummenoperation zu beginnen ist. Nach dem Zustand 430 endet die Prozedur mit dem Endzustand 432.
  • Nach dem Parsen eines Pakets kann der Kopf-Parser die aus dem Paket erzeugten Informationen an ein Modul oder mehrere Module der NIC 100 verteilen. In einer Ausführungsform der Erfindung wird z. B. der Flussschlüssel dem Flussdatenbankmanager 108, der Lastverteilungseinrichtung 112 und der Steuerwarteschlange 118 und/oder der Paketwarteschlange 116 bereitgestellt. Beispielhaft wird der Steuerindikator dem Flussdatenbankmanager 108 bereitgestellt. Diese und andere Steuerinformationen, wie z. B. die Größe der TCP-Nutzinformationen, der Versatz der TCP-Nutzinformationen und das No_Assist-Signal, können zum IPP-Modul 104 zurückgeschickt und der Steuerwarteschlange 118 bereitgestellt werden. Noch weitere Steuer- und/oder diagnostische Informationen, wie z. B. die Versätze der Kopfbereiche der Schicht drei und/oder der Schicht vier, können dem IPP-Modul 104, der Paketwarteschlange 116 und/oder der Steuerwarteschlange 118 bereitgestellt werden. Die Prüfsummeninformationen (z. B. ein Anfangspunkt und entweder ein Endpunkt oder andere Mittel zum Identifizieren eines Abschnitts des Pakets, von dem eine Prüfsumme zu berechnen ist) können dem Prüfsummengenerator 114 bereitgestellt werden.
  • Nachdem ein empfangenes Paket in der NIC 100 (z. B. durch den Kopf-Parser 106) geparst worden ist, werden die Pakete in der veranschaulichten Ausführungsform der Erfindung immer noch (z. B. durch ihre entsprechenden Protokollstapel) im Host-Computersystem verarbeitet. Nach dem Parsen eines Pakets in einer alternativen Ausführungsform der Erfindung führt jedoch die NIC 100 außerdem einen oder mehrere anschließende Verarbeitungsschritte aus. Die NIC 100 kann z. B. einen oder mehrere Protokollprozessoren enthalten, um einen oder mehrere der Protokollköpfe des Pakets zu verarbeiten.
  • Die dynamischen Kopf-Parsbefehle in einer Ausführungsform der Erfindung
  • In einer Ausführungsform der vorliegenden Erfindung parst der Kopf-Parser 106 ein von einem Netz empfangenes Paket entsprechend einer dynamischen Se quenz von Befehlen. Die Befehle können im Befehlspeicher des Kopf-Parsers (z. B. RAM, SRAM, DRAM, Flash) gespeichert sein, der umprogrammierbar ist oder der anderweitig mit neuen oder zusätzlichen Befehlen aktualisiert werden kann. In einer Ausführungsform der Erfindung kann die in einem Host-Computer (z. B. einem Vorrichtungstreiber) arbeitende Software einen Satz von Parsbefehlen für die Speicherung im Speicher des Kopf-Parsers herunterladen.
  • Die Anzahl und das Format der im Befehlspeicher eines Kopf-Parsers gespeicherten Befehle kann für ein spezifisches Protokoll oder mehrere spezifische Protokolle oder einen spezifischen oder mehrere spezifische Protokollstapel maßgeschneidert sein. Ein für eine Sammlung von Protokollen konfigurierter Befehlssatz oder ein aus diesem Befehlssatz konstruiertes Programm kann deshalb durch einen anderen Befehlssatz oder ein anderes Programm aktualisiert oder ersetzt werden. Für an der Netzschnittstelle empfangene Pakete, die in Übereinstimmung mit den ausgewählten Protokollen formatiert sind (z. B. "kompatible" Pakete), wie es durch das Analysieren oder das Parsen der Pakete bestimmt wird, werden verschiedene Verbesserungen in der Abwicklung des Netzverkehrs möglich, wie hierin beschrieben ist. Insbesondere können die Pakete von einem Datagramm, die entsprechend einem ausgewählten Protokoll konfiguriert sind, für die effiziente Übertragung in einem Host-Computer erneut zusammengefügt werden. Außerdem können die Kopfabschnitte derartiger Pakete gemeinsam anstatt seriell verarbeitet werden. Außerdem kann die Verarbeitung der Pakete aus verschiedenen Datagrammen durch einen Mehrprozessor-Host-Computer zwischen den Prozessoren geteilt oder verteilt werden. Deshalb ist es eine Aufgabe der dynamischen Kopf-Parsoperation, ein Protokoll zu identifizieren, entsprechend dem ein empfangenes Paket formatiert worden ist, oder zu bestimmen, ob ein Paketkopf einem speziellen Protokoll entspricht.
  • 7, die bald ausführlich erörtert wird, stellt eine beispielhafte Folge von Befehlen für das Parsen der Kopfbereiche der Schichten zwei, drei und vier eines Pakets dar, um zu bestimmen, ob sie das Ethernet, das IP bzw. das TCP sind. Die veranschaulichten Befehle umfassen ein mögliches Programm oder einen möglichen Mikrocode zum Ausführen einer Parsoperation. Wie ein Fachmann auf dem Gebiet erkennt, kann eine Anzahl verschiedener Programme zusammengefügt werden, nachdem ein spezieller Satz von Parsbefehlen in einen Parser-Speicher geladen worden ist. 7 stellt folglich lediglich eines von einer Anzahl von Programmen dar, die aus den gespeicherten Befehlen erzeugt werden können.
  • Die in 7 dargestellten Befehle können durch eine Mikro-Ablaufsteuerung, einen Prozessor, einen Mikroprozessor oder ein anderes ähnliches Modul, das sich innerhalb einer Netzschnittstellenschaltung befindet, ausgeführt oder abgearbeitet werden.
  • Insbesondere können andere Befehlssätze und andere Programme für andere Kommunikationsprotokolle abgeleitet werden, wobei sie auf andere Schichten eines Protokollstapels ausgedehnt werden können. Ein Befehlssatz könnte z. B. für das Parsen von NFS-Paketen (Netzdateisystem-Paketen) erzeugt werden. Beispielhaft würden diese Befehle konfiguriert sein, um die Kopfbereiche der Schichten fünf und sechs zu parsen, um zu bestimmen, ob sie ein entfernter Prozeduraufruf (RPC) bzw. eine externe Datendarstellung (XDR) sind. Andere Befehle könnten konfiguriert sein, um einen Abschnitt der Daten des Pakets (die als die Schicht sieben betrachtet werden können) zu parsen. Ein NFS-Kopf kann als ein Teil eines Protokollkopfes der Schicht sechs des Pakets oder ein Teil der Daten des Pakets betrachtet werden.
  • Ein durch eine Mikro-Ablaufsteuerung ausgeführter Befehlstyp kann konstruiert sein, um ein spezielles Feld eines Pakets (z. B. an einem spezifischen Versatz innerhalb des Pakets) zu lokalisieren und den bei diesem Versatz gespeicherten Wert mit einem Wert zu vergleichen, der diesem Feld in einem speziellen Kommunikationsprotokoll zugeordnet ist. Ein Befehl kann z. B. erfordern, dass die Mikro-Ablaufsteuerung einen Wert in einem Paketkopf bei einem Versatz untersucht, der einem Typfeld eines Ethernet-Kopfes entsprechen würde. Durch das Vergleichen des tatsächlich im Paket gespeicherten Wertes mit dem für das Protokoll erwarteten Wert kann die Mikro-Ablaufsteuerung bestimmen, ob es sich herausstellt, dass das Paket dem Ethernet-Protokoll entspricht. Beispielhaft hängt der nächste im Parsprogramm angewendete Befehl davon ab, ob der vorhergehende Vergleich erfolgreich gewesen ist. Folglich hängen die durch die Mikro-Ablaufsteuerung angewendeten speziellen Befehle und die Sequenz, in der sie angewendet werden, davon ab, welche Protokolle durch die Kopfbereiche des Pakets dargestellt werden.
  • Die Mikro-Ablaufsteuerung kann einen oder mehrere Feldwerte innerhalb jedes in einem Paket enthaltenen Kopfbereichs überprüfen. Je mehr Felder überprüft werden und von denen festgestellt wird, dass sie dem Format eines bekannten Protokolls entsprechen, desto größer ist die Bestimmtheit, dass das Paket diesem Protokoll entspricht. Wie ein Fachmann auf dem Gebiet erkennt, kann ein Kommunikationsprotokoll von einem anderen Protokoll ganz verschieden sein, wobei folglich die Untersuchung verschiedener Teile der Paketköpfe für verschiedene Protokolle erforderlich ist. Beispielhaft kann das Parsen eines Pakets im Fall eines Fehlers oder weil bestimmt worden ist, dass das geparste Paket dem Protokoll (den Protokollen), für das (die) die Befehle konstruiert sind, entspricht oder nicht entspricht, enden.
  • Jeder Befehl in 7 kann durch eine Zahl und/oder einen Namen identifiziert werden. Ein spezieller Befehl kann außer dem Vergleichen eines Kopffeldes mit einem erwarteten Wert eine Vielzahl von Aufgaben ausführen. Ein Befehl kann z. B. einen anderen Befehl aufrufen, um einen anderen Abschnitt eines Paketkopfes zu untersuchen, ein Register oder eine andere Datenstruktur zu initialisieren, zu laden oder zu konfigurieren, die Ankunft und das Parsen eines anderen Pakets vorbereiten usw. Insbesondere kann ein Register oder eine andere Speicherstruktur in der Voraussicht einer Operation konfiguriert werden, die in der Netzschnittstelle ausgeführt wird, nachdem das Paket geparst worden ist. Ein Programmbefehl in 7 kann z. B. eine Ausgabeoperation identifizieren, die abhängig vom Erfolg oder Misserfolg des Vergleichs eines aus einem Paket extrahierten Wertes mit einem erwarteten Wert ausgeführt oder nicht ausgeführt werden kann. Eine Ausgabeoperation kann einen Wert in einem Register speichern, ein Register für eine Operation nach dem Parsen konfigurieren (z. B. ein Argument oder einen Operator laden), ein Register löschen, um ein neues Paket zu erwarten, usw.
  • Es kann ein Zeiger verwendet werden, um einen Versatz in ein Paket zu identifizieren, das geparst wird. In einer Ausführungsform befindet sich ein derartiger Zeiger anfangs am Anfang des Protokollkopfes der Schicht zwei. In einer weiteren Ausführungsform befindet sich der Zeiger jedoch an einem spezifischen Ort innerhalb eines speziellen Kopfbereichs (z. B. unmittelbar nach den Ziel- und/oder Ursprungsadressen der Schicht zwei), wenn das Parsen beginnt. Beispielhaft wird der Zeiger durch das Paket inkrementiert, wie die Parsprozedur ausgeführt wird. In einer alternativen Ausführungsform können jedoch die Versätze zu interessierenden Bereichen im Paket aus einem oder mehreren bekannten oder berechneten Orten berechnet werden.
  • Im in 7 dargestellten Parsprogramm wird im Kopfbereich in Inkrementen von zwei Bytes (z. B. Sechzehn-Bit-Wörtern) navigiert (wird z. B. der Zeiger fortgeschaltet). Außerdem werden, wo ein spezielles Feld eines Kopfbereichs mit einem bekannten oder erwarteten Wert verglichen wird, bis zu zwei Bytes auf einmal aus dem Feld extrahiert. Wenn ferner ein Wert oder ein Kopffeld für die Speicherung in einem Register oder einer anderen Datenstruktur kopiert wird, kann die Datenmenge, die in einer Operation kopiert werden kann, in Vielfachen von Zwei-Byte-Einheiten oder in völlig anderen Einheiten (z. B. einzelnen Bytes) ausgedrückt werden. Diese Maßeinheit (z. B. zwei Bytes) kann in einer alternativen Ausführungsform der Erfindung vergrößert oder verkleinert sein. Das Ändern der Maßeinheit kann die Genauigkeit ändern, mit der ein Kopfbereich geparst oder ein Kopfwert extrahiert werden kann.
  • In der in 7 veranschaulichten Ausführungsform der Erfindung umfasst ein in den Befehlsspeicher des Kopf-Parsers geladener Befehlssatz eine Anzahl möglicher Operationen, die auszuführen sind, während ein Paket auf die Kompatibilität mit ausgewählten Protokollen überprüft wird. Das Programm 700 wird aus dem Befehlssatz erzeugt. Das Programm 700 ist folglich lediglich ein mögliches Programm, ein möglicher Mikrocode oder eine mögliche Sequenz von Befehlen, das, der bzw. die aus dem verfügbaren Befehlssatz gebildet werden kann.
  • In dieser Ausführungsform ermöglicht der geladene Befehlssatz die folgenden sechzehn Operationen, die an einem Paket ausgeführt werden können, das geparst wird. Die spezifischen Implementierungen dieser Operationen im Programm 700 sind im Folgenden weiter ausführlich erörtert. Es ist selbstverständlich, dass diese Befehle in ihrem Wesen beispielhaft sind und die Zusammensetzung der Befehlssätze in anderen Ausführungsform der Erfindung nicht einschränken. Außerdem kann jede Teilmenge dieser Operationen in einem speziellen Parsprogramm oder einem speziellen Pars-Mikrocode verwendet werden. Ferner können mehrere Befehle dieselbe Operation verwenden und verschiedene Wirkungen besitzen.
  • Eine CLR_REG-Operation ermöglicht die wahlweise Initialisierung von Registern oder anderen Datenstrukturen, die im Programm 700 verwendet werden, und möglicherweise von Datenstrukturen, die in Funktionen verwendet werden, die ausgeführt werden, nachdem das Paket geparst worden ist. Die Initialisierung kann das Speichern des Wertes null umfassen. Eine Anzahl beispielhafter Register, die durch eine CLR_REG-Operation initialisiert werden können, wird in den verbleibenden Operationen identifiziert.
  • Eine LD_FID-Operation kopiert eine variable Datenmenge von einem speziellen Versatz innerhalb des Pakets in ein Register, das konfiguriert ist, um den Flussschlüssel oder eine andere Flusskennung eines Pakets zu speichern. Dieses Register kann als ein FLOWID-Register bezeichnet werden. Die Wirkung einer LD_FID-Operation ist kumulativ. Mit anderen Worten, jedes Mal, wenn sie für ein Paket aufgerufen wird, werden die erzeugten Daten an die vorausgehend gespeicherten Daten des Flussschlüssels angehängt.
  • Eine LD_SEQ-Operation kopiert eine variable Datenmenge von einem speziellen Versatz innerhalb des Pakets in ein Register, das konfiguriert ist, um die Sequenznummer eines Pakets (z. B. eine TCP-Sequenznummer) zu speichern. Dieses Register kann der Marke SEQNO zugewiesen sein. Diese Operation ist ebenfalls kumulativ – die zweiten und anschließenden Aufrufe dieser Operation für das Paket bewirken, dass die identifizierten Daten an die vorausgehend gespeicherten Daten angehängt werden.
  • Eine LD_CTL-Operation lädt einen Wert von einem spezifizierten Versatz in das Paket in ein CONTROL-Register. Das CONTROL-Register kann einen Steuerindikator umfassen, um zu identifizieren, ob ein Paket für das erneute Zusammenfügen der Daten, die Paketstapelung, die Lastverteilung oder andere verbessere Funktionen der NIC 100 geeignet ist. Insbesondere kann der Steuerindikator angeben, ob ein No_Assist-Merker für das Paket gesetzt werden sollte, ob das Paket irgendwelche Daten enthält, ob die Menge der Paketdaten größer als ein vorgegebener Schwellenwert ist usw. Folglich kann der in einer LD_CTL-Operation in ein CONTROL-Register geladene Wert die Abwicklung des Pakets nach dem Parsen beeinflussen.
  • Eine LD_SAP-Operation lädt einen Wert von einem variablen Versatz innerhalb des Pakets in das CONTROL-Register. Der geladene Wert kann den Ethernet-Typ des Pakets umfassen. In einer Option, die einer LD_SAP-Operation zugeordnet sein kann, kann der Versatz des Kopfbereichs der Schicht drei des Pakets außerdem im CONTROL-Register und anderswo gespeichert werden. Wie ein Fachmann auf dem Gebiet erkennt, kann der Kopfbereich der Schicht drei des Pakets unmittelbar seinem Ethernet-Typ-Feld der Schicht zwei folgen, falls das Paket den Ethernet- und IP-Protokollen entspricht.
  • Eine LD_R1-Operation kann verwendet werden, um einen Wert von einem variablen Versatz innerhalb des Pakets in ein temporäres Register (z. B. namens R1) zu laden. Ein temporäres Register kann für eine Vielzahl von Aufgaben verwendet werden, wie z. B. das Ansammeln von Werten, um die Länge eines Kopfbereichs oder eines anderen Abschnitts des Pakets zu bestimmen. Eine LD_R1-Operation kann außerdem verursachen, dass ein Wert von einem weiteren variablen Versatz in einem zweiten temporären Register (z. B. namens R2) gespeichert wird. Diese in den R1- und/oder R2-Registern während des Parsens eines Pakets gespeicherten Werte können kumulativ sein oder nicht.
  • Eine LD_L3-Operation kann einen Wert vom Paket in ein Register laden, dass konfiguriert ist, um den Ort des Kopfbereichs der Schicht drei des Pakets zu speichern. Dieses Register kann L3OFFSET benannt sein. In einem optionalen Verfahren des Aufrufens dieser Operation kann sie verwendet werden, um einen festen Wert in das L3OFFSET-Register zu laden. Als eine weitere Option kann LD_L3-die Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert hinzufügen, der im L3OFFSET-Register gespeichert ist.
  • Eine LD_SUM-Operation speichert den Anfangspunkt innerhalb des Pakets, von denn eine Prüfsumme berechnet werden sollte. Das Register, in dem dieser Wert gespeichert ist, kann als ein CSUMSTART-Register benannt sein. In einem alternativen Aufruf dieser Operation wird ein fester oder vorgegebener Wert im Register gespeichert. Als eine weitere Option kann die LD_SUM-Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert hinzufügen, der im CSUMSTART-Register gespeichert ist.
  • Eine LD_HDR-Operation lädt einen Wert in ein Register, das konfiguriert ist, um den Ort innerhalb des Pakets zu speichern, an dem der Kopfabschnitt aufgespalten werden kann. Der Wert, der gespeichert ist, kann z. B. während der Übertragung des Pakets zum Host-Computer verwendet werden, um einen Datenabschnitt des Pakets an einem vom Kopfabschnitt separaten Ort zu speichern. Der geladene Wert kann folglich den Anfang der Paketdaten oder den Anfang eines speziellen Kopfbereichs identifizieren. In einem Aufruf einer LD_HDR-Operation kann der gespeicherte Wert aus einer aktuellen Position eines Parszeigers, der oben beschrieben worden ist, berechnet werden. In einem weiteren Aufruf kann ein fester oder vorgegebener Wert gespeichert werden. Als eine noch weitere Alternative kann ein in einem temporären Register (z. B. R1) gespeicherter Wert und/oder eine Konstante zum geladenen Wert hinzugefügt werden.
  • Eine LD_LEN-Operation speichert die Länge der Nutzinformationen des Pakets in einem Register (z. B. einem PAYLOADLEN-Register).
  • Eine IM_FID-Operation hängt einen festen oder vorgegebenen Wert an die vorhandenen Inhalte des obenbeschriebenen FLOWID-Registers an oder fügt einen festen oder vorgegebenen Wert zu den vorhandenen Inhalten des obenbeschriebenen FLOWID-Registers hinzu.
  • Ein IM_SEQ-Operation hängt einen festen oder vorgegebenen Wert an die vorhandenen Inhalte des obenbeschriebenen SEQNO-Registers an oder fügt einen festen oder vorgegebenen Wert zu den vorhandenen Inhalten des obenbeschriebenen SEQNO-Registers hinzu.
  • Eine IM_SAP-Operation lädt oder speichert einen festen oder vorgegebenen Wert in das obenbeschriebene bzw. im obenbeschriebenen CSUMSTART-Register.
  • Eine IM_R1-Operation kann einen vorgegebenen Wert zu einem oder mehreren temporären Registern (z. B. R1, R2) hinzufügen oder in ein temporäres oder mehrere temporäre Register (z. B. R1, R2) laden.
  • Eine IM_CTL-Operation lädt oder speichert einen festen oder vorgegebenen Wert in das obenbeschriebene bzw. im obenbeschriebenen CONTROL-Register.
  • Eine ST_FLAG-Operation lädt einen Wert von einem spezifizierten Versatz im Paket in ein FLAGS-Register. Der geladene Wert kann ein oder mehrere Felder oder einen oder mehrere Merker von einem Paketkopf umfassen.
  • Ein Fachmann auf dem Gebiet erkennt, dass die den Operationen und Registern, die oben und anderswo in diesem Abschnitt beschrieben worden sind, zugewiesenen Marken in ihrem Wesen lediglich beispielhaft sind und die Operationen und Parsbefehle in keiner Weise einschränken, die in anderen Ausführungsform der Erfindung verwendet werden können.
  • Die Befehle im Programm 700 umfassen das Befehlsnummerfeld 702, das eine Nummer eines Befehls innerhalb des Programms enthält, und ein Befehlsnamensfeld 704, das einen Namen eines Befehls enthält. In einer alternativen Ausführungsform der Erfindung können die Befehlsnummer- und Befehlsnamenfelder verschmolzen sein, oder eines von ihnen kann weggelassen sein.
  • Das Befehlsinhaltefeld 706 enthält mehrere Abschnitte zum Ausführen eines Befehls. Ein "Extraktionsmasken"-Abschnitt eines Befehls ist eine Zwei-Byte-Maske in hexadezimaler Schreibweise. Eine Extraktionsmaske identifiziert einen Abschnitt eines Paketkopfes, der zu kopieren oder extrahieren ist, beginnend vom momentanen Paketversatz (z. B. der momentanen Position des Parszeigers). Beispielhaft wird jedes Bit im Kopfbereich des Pakets, das einer eins im hexadezimalen Wert entspricht, für den Vergleich mit einem Vergleichs- oder Prüfwert kopiert. Ein Wert von 0xFF00 im Extraktionsmaskenabschnitt eines Befehls bedeutet z. B., dass das ganze erste Byte beim momentanen Paketversatz kopiert wird, und dass die Inhalte des zweiten Bytes irrelevant sind. Ähnlich bedeutet eine Extraktionsmaske von 0x3FFF, dass alle außer den zwei höchstwertigen Bits des ersten Bytes zu kopieren sind. Aus den extrahierten Inhalten wird unter Verwendung dessen, was auch immer aus dem Paket kopiert worden ist, ein Zwei-Byte-Wert konstruiert. Beispielhaft wird der Rest des Wertes mit Nullen aufgefüllt. Ein Fachmann auf dem Gebiet erkennt, dass das Format einer Extraktionsmaske (oder einer im Folgenden beschriebenen Ausgabemaske) eingestellt werden kann, wie es notwendig ist, um die Little-Endian- oder Big-Endian-Darstellungen widerzuspiegeln.
  • Ein oder mehrere Befehle in einem Parsprogramm erfordern vielleicht keine an der Zeigerstelle aus dem Paket extrahierten Daten, damit sie ihre Ausgabeoperation ausführen können. Diese Befehle können einen Extraktionsmaskenwert von 0x0000 besitzen, um anzugeben, dass jedes Bit des Wertes maskiert wird, obwohl trotzdem ein Zwei-Byte-Wert von der Zeigerposition wiedergewonnen wird. Eine derartige Extraktionsmaske liefert folglich einen definierten Wert von null. Dieser Befehlstyp kann verwendet werden, wenn z. B. eine Ausgabeoperation ausgeführt werden muss, bevor ein weiterer wesentlicher Abschnitt der Kopfdaten mit einer anderen Extraktionsmaske als 0x0000 extrahiert wird.
  • Ein "Vergleichswert"-Abschnitt eines Befehls ist ein hexadezimaler Zwei-Byte-Wert, mit dem die extrahierten Paketinhalte zu vergleichen sind. Der Vergleichswert kann ein Wert sein, von dem bekannt ist, dass er in einem speziellen Feld ei nes spezifischen Protokollkopfes gespeichert ist. Der Vergleichswert kann einen Wert umfassen, mit dem der extrahierte Abschnitt des Kopfbereichs übereinstimmen oder eine spezifizierte Beziehung besitzen sollte, damit das Paket als kompatibel mit den im Voraus ausgewählten Protokollen betrachtet wird.
  • Ein "Operator"-Abschnitt eines Befehls identifiziert einen Operator, der bedeutet, wie die extrahierten Werte und die Vergleichswerte zu vergleichen sind. Beispielhaft bedeutet EQ, dass sie auf Gleichheit geprüft werden, NE bedeutet, dass sie auf Ungleichheit geprüft werden, LT bedeutet, dass der extrahierte Wert kleiner als der Vergleichswert sein muss, damit der Vergleich erfolgreich ist, GE bedeutet, dass der extrahierte Wert größer als der oder gleich dem Vergleichswert sein muss usw. Ein Befehl, der die Ankunft eines neuen zu parsenden Pakets erwartet, kann eine Operation von NP verwenden. Andere Operatoren für andere Funktionen können hinzugefügt werden, wobei den vorhandenen Operatoren andere Namen zugewiesen werden können.
  • Ein "Erfolgsversatz"-Abschnitt eines Befehls gibt die Anzahl der Zwei-Byte-Einheiten an, die der Zeiger fortgeschaltet werden muss, falls der Vergleich zwischen dem extrahierten Wert und dem Prüfwert erfolgreich ist. Ein "Erfolgsbefehls"-Abschnitt eines Befehls identifiziert den nächsten Befehl im Programm 700, der auszuführen ist, falls der Vergleich erfolgreich ist.
  • Ähnlich geben die "Misserfolgsversatz"- und "Misserfolgsbefehls"-Abschnitte die Anzahl der Zwei-Byte-Einheiten, die der Zeiger fortzuschalten ist, bzw. den nächsten auszuführenden Befehl an, falls der Vergleich misslingt. Obwohl in dieser Ausführungsform der Erfindung die Versätze in Einheiten von zwei Bytes ausgedrückt sind (z. B. Sechzehn-Bit-Wörter), können sie in einer alternativen Ausführungsform der Erfindung kleinere oder größere Einheiten sein. Außerdem kann, wie oben erwähnt worden ist, ein Befehl durch eine Nummer oder einen Namen identifiziert werden.
  • Nicht alle Befehle in einem Programm werden notwendigerweise für jedes Paket verwendet, das geparst wird. Ein Programm kann z. B. Befehle enthalten, um auf mehr als einen Typ oder mehr als eine Version eines Protokolls in einer speziellen Schicht zu prüfen. Insbesondere prüft das Programm 700 nach irgendeiner Version vier oder sechs des IP-Protokolls in der Schicht drei. Diese Befehle, die für ein gegebenes Paket tatsächlich ausgeführt werden, hängen folglich vom Format des Pakets ab. Sobald ein Paket so viel wie möglich mit einem gegebenen Programm geparst worden ist oder bestimmt worden ist, dass das Paket einem ausgewählten Protokoll entspricht oder nicht, kann das Parsen beendet oder ein Befehl zum Anhalten der Parsprozedur ausgeführt werden. Beispielhaft gibt ein nächster Befehlsabschnitt eines Befehls (z. B. des "Erfolgsbefehls" oder des "Misserfolgsbefehls") mit dem Wert "DONE den Abschluss des Parsens eines Pakets an. Ein DONE- oder ähnlicher Befehl kann ein Leerbefehl sein. Mit anderen Worten, "DONE" kann einfach bedeuten, dass für das aktuelle Paket des Parsen zu beenden ist. Oder, wie der Befehl achtzehn des Programms 700, kann ein DONE-Befehl irgendeine Handlung ausführen, um ein neues Paket zu erwarten (z. B. durch das Initialisieren eines Registers).
  • Die verbleibenden Abschnitte des Befehlsinhaltefelds 706 werden verwendet, um eine Ausgabeoperation oder eine andere Datenspeicherungsoperation zu spezifizieren und abzuschließen. Insbesondere entspricht in dieser Ausführungsform ein "Ausgabeoperations"-Abschnitt eines Befehls den Operationen, die im geladenen Befehlssatz enthalten sind. Folglich identifiziert für das Programm 700 der Ausgabeoperationsabschnitt eines Befehls eine der obenbeschriebenen sechzehn Operationen. Die im Programm 700 verwendeten Ausgabeoperationen sind im Folgenden im Zusammenhang mit den einzelnen Befehlen weiter beschrieben.
  • Ein "Operationsargument"-Abschnitt eines Befehls umfasst ein oder mehrere Argumente oder Felder, die zu speichern, zu laden oder anderweitig im Zusammenhang mit der Ausgabeoperation des Befehls zu verwenden sind. Beispielhaft nimmt der Operationsargumentabschnitt die Form eines hexadezimalen Mehrbitwertes an. Für das Programm 700 besitzen die Operationsargumente eine Größe von elf Bits. Ein Argument oder ein Abschnitt eines Arguments kann abhängig von der Ausgabeoperation verschiedene Bedeutungen besitzen. Ein Operationsargument kann z. B. einen oder mehrere numerische Werte, die in einem Register zu speichern sind oder die zu verwenden sind, um einen Abschnitt eines Kopfbereichs zu lokalisieren oder abzugrenzen, umfassen. Ein Argumentbit kann alternativ einen Merker umfassen, um eine Handlung oder einen Status zu signalisieren. Insbesondere kann ein Argumentbit spezifizieren, dass ein spezielles Register zurückzusetzen ist; ein Satz von Argumentbits kann einen Versatz in einen Paketkopf zu einem in einem Register zu speichernden Wert umfassen usw. Beispielhaft wird der durch ein Operationsargument spezifizierte Versatz auf den Ort der Position des Parszeigers angewendet, bevor der Zeiger fortgeschaltet wird, wie durch den anwendbaren Erfolgsversatz oder Misserfolgsversatz spezifiziert ist. Die im Programm 700 verwendeten Operationsargumente sind im Folgenden weiter ausführlich erklärt.
  • Ein "Operationsfreigabeeinrichtungs"-Abschnitt eines Befehlsinhaltefelds spezifiziert, ob oder wann die Ausgabeoperation eines Befehls auszuführen ist. Insbesondere kann in der veranschaulichten Ausführungsform der Erfindung die Ausgabeoperation eines Befehls abhängig vom Ergebnis des Vergleichs zwischen einem aus einem Kopfbereich extrahierten Wert und dem Vergleichswert ausgeführt werden oder nicht. Eine Ausgabefreigabeeinrichtung kann z. B. auf einen ersten Wert (z. B. null) gesetzt sein, falls die Ausgabeoperation niemals auszuführen ist. Sie kann andere Werte annehmen, falls sie nur auszuführen ist, wenn der Vergleich dem Operator entspricht oder nicht (z. B. eins bzw. zwei). Eine Operationsfreigabeeinrichtung kann einen noch weiteren Wert (z. B. drei) annehmen, falls sie immer auszuführen ist.
  • Ein "Verschiebungs"-Abschnitt eines Befehls umfasst einen Wert, der angibt, wie ein Ausgabewert zu verschieben ist. Eine Verschiebung kann notwendig sein, weil verschiedene Protokolle manchmal erfordern, dass Werte verschieden formatiert werden. Außerdem kann ein Wert, der eine Länge oder einen Ort eines Kopfbereichs oder eines Kopffeldes angibt, eine Verschiebung erfordern, um die durch den Wert dargestellte geeignete Größe widerzuspiegeln. Weil das Programm 700 konstruiert ist, um Zwei-Byte-Einheiten zu verwenden, kann ein Wert verschoben werden müssen, falls andere Einheiten (z. B. Bytes) widerzuspiegeln sind. Ein Verschiebungswert in einer vorliegenden Ausführungsform gibt die Anzahl von Positionen (z. B. Bits) an, die ein Ausgabewert nach rechts zu verschieben ist. In einer weiteren Ausführungsform der Erfindung kann ein Verschiebungswert einen anderen Verschiebungstyp oder eine andere Verschiebungsrichtung darstellen.
  • Schließlich spezifiziert eine "Ausgabemaske", wie ein in einem Register oder einer anderen Datenstruktur gespeicherter Wert zu formatieren ist. Wie oben dargelegt worden ist, kann eine Ausgabeoperation erfordern, dass ein extrahierter, berechneter oder zusammengefügter Wert zu speichern ist. Ähnlich zur Extraktionsmaske ist die Ausgabemaske ein hexadezimaler Zwei-Byte-Wert. Für jede Position in der Ausgabemaske, die eine Eins enthält, ist in dieser Ausführungsform der Erfindung das entsprechende Bit im durch die Ausgabeoperation und/oder das Operationsargument identifizierten Zwei-Byte-Wert zu speichern. Ein Wert von 0xFFFF gibt z. B. an, dass der spezifizierte Zwei-Byte-Wert zu speichern ist, wie er ist. Beispielhaft wird für jede Position in der Ausgabemaske, die eine Null enthält, eine Null gespeichert. Folglich gibt ein Wert von 0xF000 an, dass die vier höchstwertigen Bits des ersten Bytes zu speichern sind, aber der Rest des gespeicherten Wertes irrelevant ist und mit Nullen aufgefüllt werden kann.
  • Eine Ausgabeoperation von "NONE" kann verwendet werden, um anzugeben, dass es keine auszuführende oder zu speichernde Ausgabeoperation gibt, wobei in diesem Fall andere zur Ausgabe gehörende Befehlsabschnitte ignoriert werden oder spezifizierte Werte (z. B. alles Nullen) enthalten können. In dem in 7 dargestellten Programm kann jedoch eine CLR_REG-Ausgabeoperation, die die wahlweise Neuinitialisierung der Register erlaubt, mit einem Operationsargument von null verwendet werden, um effektiv keine Ausgabe auszuführen. Insbesondere gibt ein Operationsargument von null für die CLR_REG-Operation an, dass keine Register zurückzusetzen sind. In einer alternativen Ausführungsform der Erfindung könnte der Operationsfreigabeeinrichtungs-Abschnitt eines Befehls auf einen Wert (z. B. null) gesetzt sein, der angibt, dass die Ausgabeoperation niemals auszuführen ist.
  • Es ist selbstverständlich, dass das Format und die Sequenz der Befehle in 7 nur hin Verfahren zum Parsen eines Pakets darstellen, um zu bestimmen, ob es einem speziellen Kommunikationsprotokoll entspricht. Insbesondere sind die Befehle konstruiert, um einen oder mehrere Abschnitte von einem oder mehreren Paketköpfen für den Vergleich mit bekannten oder erwarteten Werten zu untersuchen und ein Register oder eine andere Speicherstelle zu konfigurieren oder zu laden, wie es notwendig ist. Wie ein Fachmann auf dem Gebiet erkennt, können die Befehle zum Parsen eines Pakets irgendeine aus einer Anzahl von Formen annehmen und können in einer Vielzahl von Sequenzen ausgeführt werden, ohne den Umfang der Erfindung zu überschreiten.
  • Unter Bezugnahme auf 7 können die Befehle im Programm 700 nun ausführlich beschrieben werden. Vor der Ausführung des in 7 dargestellten Programms befindet sich ein Parszeiger am Anfang des Kopfbereichs der Schicht zwei eines Pakets. Die Position des Parszeigers kann für die leichte Bezugnahme und Aktualisierung während der Parsprozedur in einem Register gespeichert sein. Insbesondere kann die Position des Parszeigers als ein Versatz (z. B. vom Anfang des Kopfbereichs der Schicht zwei) beim Berechnen der Position einer speziellen Position innerhalb eines Kopfbereichs verwendet werden.
  • Das Programm 700 beginnt mit einem WAIT-Befehl (z. B. dem Befehl null), der auf ein neues Paket wartet (z. B. angegeben durch den Operator NP), wobei er, wenn eines empfangen wird, einen Parszeiger auf das zwölfte Byte des Kopfbereichs der Schicht zwei setzt. Dieser Versatz zum zwölften Byte wird durch den Erfolgsversatz-Abschnitt des Befehls angegeben. Bis ein Paket empfangen wird, durchläuft der WAIT-Befehl eine Schleife zu sich selbst. Außerdem wird eine CLR_REG-Operation ausgeführt, aber die Einstellung der Operationsfreigabeeinrichtung gibt an, dass sie nur ausgeführt wird, wenn der Vergleich erfolgreich ist (z. B. wenn ein neues Paket empfangen wird).
  • Die spezifizierte CLR_REG-Operation arbeitet entsprechend dem Operationsargument des WAIT-Befehls (d. h. 0x3FF). In dieser Ausführungsform entspricht jedes Bit des Arguments einem Register oder einer anderen Datenstruktur. Die in dieser Operation initialisieren Register können die Folgenden enthalten: ADDR (z. B. um die Adresse oder den Ort des Parszeigers zu speichern), FLOWID (z. B. um den Flussschlüssel des Pakets zu speichern), SEQNO (z. B. um eine TCP-Sequenznummer zu speichern), SAP (z. B. den Ethernet-Typ des Pakets) und PAYLOADLEN (z. B. die Nutzinformationenlänge). Die folgenden Register, die konfiguriert sind, um bestimmte Versätze zu speichern, können außerdem zurückgesetzt werden: FLOWOFF (z. B. der Versatz innerhalb des FLOWID-Registers), SEQOFF (z. B. der Versatz innerhalb des SEQNO-Registers), L3OFFSET (z. B. der Versatz des Kopfbereichs der Schicht drei des Pakets), HDRSPLIT (z. B. der Ort, um das Paket aufzuspalten) und CSUMSTART (z. B. der Anfangsort, um eine Prüfsumme zu berechnen). Außerdem können einer oder mehrere Status- oder Steuerindikatoren (z. B. das CONTROL- oder FLAGS-Register), um den Status von einem oder mehreren Merkern eines Paketkopfes zu melden, zurückgesetzt werden. Außerdem können ein temporäres oder mehrere temporäre Register (z. B. R1, R2) oder andere Datenstrukturen ebenfalls initialisiert werden. Diese Register sind für die Datenstrukturen, die in einer Ausführungsform der Erfindung verwendet werden können, lediglich beispielhaft. In anderen Ausführungsformen können für die gleichen oder andere Ausgabeoperationen andere Datenstrukturen verwendet werden.
  • Die temporären Register, wie z. B. R1 und/oder R2, können im Programm 700 verwendet werden, um verschiedene Kopfbereiche und Kopffelder zu verfolgen.
  • Ein Fachmann auf dem Gebiet erkennt die Anzahl der möglichen Kombinationen der Kommunikationsprotokolle und die Wirkung dieser verschiedenen Kombinationen auf die Struktur und das Format der Kopfbereiche eines Pakets. Aus einem Paket, das einem Protokoll und einer Menge von Protokollen entspricht, können mehr Informationen als von einem Paket, das einem anderen Protokoll oder einer anderen Menge von Protokollen entspricht, untersucht oder gesammelt werden müssen. Falls innerhalb eines Internetprotokoll-Kopfes die Erweiterungs-Kopfbereiche verwendet werden, können z. B. die Werte aus diesen Erweiterungs-Kopfbereichen und/oder ihre Längen gespeichert werden müssen, wobei diese Werte nicht benötigt werden, falls die Erweiterungs-Kopfbereiche nicht verwendet werden. Wenn ein spezieller Versatz berechnet wird, wie z. B. ein Versatz zum Anfang des Datenabschnitts eines Pakets, können mehrere Register aufrechterhalten und ihre Werte kombiniert oder addiert werden müssen. In diesem Beispiel kann ein Register oder ein temporäres Register die Größe oder das Format eines Erweiterungs-Kopfbereichs verfolgen, während ein weiteres Register den Basis-IP-Kopf verfolgt.
  • Der Befehl VLAN (z. B. der Befehl eins) untersucht das Zwei-Byte-Feld an der Position des Parszeigers (möglicherweise ein Typ-, Längen- oder TPID-Feld) nach einem Wert, der einen VLAN-gekennzeichneten Kopfbereich (z. B. 8100 hexadezimal) angibt. Falls der Kopfbereich VLAN-gekennzeichnet ist, wird der Zeiger um ein paar Bytes inkrementiert (z. B. eine Zwei-Byte-Einheit), wobei die Ausführung mit dem Befehl CFI fortgesetzt wird; andernfalls wird die Ausführung mit dem Befehl 802.3 fortgesetzt. In beiden Fällen gibt die Operationsfreigabeeinrichtung des Befehls an, dass immer eine IM_CTL-Operation auszuführen ist.
  • Wie oben beschrieben worden ist, bewirkt eine IM_CTL-Operation, dass ein Steuerregister oder eine andere Datenstruktur mit einem Merker oder mehreren Merkern bevölkert wird, um den Status oder den Zustand eines Pakets zu melden. Ein Steuerindikator kann angeben, ob ein Paket für die verbesserte Verarbeitung geeignet ist (z. B. ob ein No_Assist-Signal für das Paket erzeugt werden sollte), ob ein Paket irgendwelche Daten enthält und, wenn ja, ob Größe des Datenabschnitts einen spezifizierten Schwellenwert überschreitet. Das Operationsargument 0x00A für den Befehl VLAN umfasst den im Steuerregister zu speichernden Wert, wobei einzelne Bits des Arguments speziellen Merkern entsprechen. Beispielhaft können die den soeben beschriebenen Zuständen zugeordneten Merker in dieser IM_CTL-Operation auf eins oder wahr gesetzt werden.
  • Der Befehl CFI (z. B. der Befehl zwei) untersucht das CFI-Bit oder den CFI-Merker in einem Kopfbereich der Schicht zwei. Wenn das CFI-Bit gesetzt ist, dann ist das Paket für die Verarbeitungsverbesserungen einer vorliegenden Ausführungsform der Erfindung nicht geeignet, wobei die Parsprozedur durch das Aufrufen des Befehls DONE (z. B. des Befehls achtzehn) endet. Wenn das CFI-Bit nicht gesetzt ist, dann wird der Zeiger um eine andere Anzahl von Bytes inkrementiert, wobei die Ausführung mit dem Befehl 802.3 fortgesetzt wird. Wie oben erklärt worden ist, gibt eine Nullausgabeoperation (z. B. "NONE") an, dass keine Ausgabeoperation ausgeführt wird. Außerdem sichert ein Wert der Ausgabefreigabeeinrichtung (z. B. null) ferner, dass keine Ausgabeoperation ausgeführt wird.
  • Im Befehl 802.3 (z. B. dem Befehl drei) wird ein Typ- oder Längenfeld (abhängig vom Ort des Zeigers und dem Format des Pakets) untersucht, um zu bestimmen, ob das Format der Schicht zwei des Pakets das herkömmliche Ethernet oder das 802.3-Ethernet ist. Falls sich herausstellt, dass der Wert im Kopffeld das 802.3-Ethernet angibt (z. B. einen hexadezimalen Wert enthält, der kleiner als 0600 ist), wird der Zeiger um zwei Bytes inkrementiert (zu dem, was ein LLC-SNAP-Feld sein sollte), wobei die Ausführung mit dem Befehl LLC_1 fortgesetzt wird. Andernfalls kann das Protokoll der Schicht zwei als das herkömmliche Ethernet betrachtet werden, wobei die Ausführung mit dem Befehl IPV4_1 fortgesetzt wird. Der Befehl 802.3 enthält in dieser Ausführungsform der Erfindung keine Ausgabeoperation.
  • In den Befehlen LLC_1 und LLC_2 (z. B. den Befehlen vier und fünf) wird ein vermutetes LLC-SNAP-Feld der Schicht zwei untersucht, um zu sichern, dass das Paket dem 802.3-Ethernet-Protokoll entspricht. Im Befehl LLC_1 wird ein erster Teil des Feldes überprüft, wobei, wenn dies erfolgreich ist, der Zeiger um zwei Bytes inkrementiert wird, wobei dann in einem Befehl LLC_2 ein zweiter Teil überprüft wird. Falls der Befehl LLC_2 erfolgreich ist, wird der Parszeiger vier Bytes fortgeschaltet, um das zu erreichen, was ein Typfeld sein sollte, wobei die Ausführung mit dem Befehl IPV4_1 fortgesetzt wird. Wenn beide Prüfungen misslingen, endet jedoch die Parsprozedur. In der veranschaulichten Ausführungsform der Erfindung wird keine Ausgabeoperation ausgeführt, während das LLC-SNAP-Feld überprüft wird.
  • Im Befehl IPV4_1 (z. B. dem Befehl sechs) sollte sich der Parszeiger in einem Ethernet-Typfeld befinden. Dieses Feld wird untersucht, um zu bestimmen, ob sich herausstellt, dass das Protokoll der Schicht drei der Version vier des Internetprotokolls entspricht. Falls diese Prüfung erfolgreich ist (z. B. das Typfeld einen hexadezimalen Wert von 0800 enthält), wird der Zeiger um zwei Bytes zum Anfang des Kopfbereichs der Schicht drei fortgeschaltet, wobei die Ausführung des Programms 700 mit dem Befehl IPV4_2 fortgesetzt wird. Wenn die Prüfung erfolglos ist, dann wird die Ausführung mit dem Befehl IPV6_1 fortgesetzt. Ungeachtet der Prüfergebnisse gibt der Wert der Operationsfreigabeeinrichtung (z. B. drei) an, dass die spezifizierte LD_SAP-Ausgabeoperation immer ausgeführt wird.
  • Wie vorausgehend beschrieben worden ist, wird in einer LD_SAP-Operation der Ethernet-Typ eines Pakets (oder ein Datenzugriffspunkt) in einem Register gespeichert. Ein Teil des Operationsarguments von 0x100, insbesondere die sechs Bits am weitesten rechts (z. B. null), bilden einen Versatz zu einem Zwei-Byte-Wert, der den Ethernet-Typ umfasst. Der Versatz in diesem Beispiel ist null, weil sich im vorliegenden Kontext der Parszeiger bereits auf dem Typfeld befindet, das den Ethernet-Typ enthält. In der gegenwärtig beschriebenen Ausführungsform bildet der Rest des Operationsarguments einen Merker, der spezifiziert, dass die Anfangsposition des Kopfbereichs der Schicht drei (z. B. ein Versatz vom Anfang des Pakets) außerdem zu sichern ist (z. B. im L3OFFSET-Register). Insbesondere ist bekannt, dass sich der Anfang des Kopfbereichs der Schicht drei unmittelbar nach dem Zwei-Byte-Typfeld befindet.
  • Der Befehl IPV4_2 (z. B. der Befehl sieben) prüft ein vermutetes Versionsfeld der Schicht drei, um zu sichern, dass das Protokoll der Schicht drei die Version vier des IP ist. Insbesondere spezifiziert eine Spezifikation für die Version vier des IP, dass die ersten vier Bits des Kopfbereichs der Schicht drei einen Wert von 0x4 enthalten. Falls die Prüfung misslingt, endet die Parsprozedur mit dem Befehl DONE. Falls die Prüfung erfolgreich ist, wird der Zeiger sechs Bytes fortgeschaltet, wobei der Befehl IPV4_3 aufgerufen wird.
  • Die spezifizierte LD_SUM-Operation, die nur ausgeführt wird, falls der Vergleich im Befehl IPV4_2 erfolgreich ist, gibt an, dass ein Versatz zum Anfang eines Punktes gespeichert werden sollte, von dem eine Prüfsumme berechnet werden kann. Insbesondere sollte in der gegenwärtig beschriebenen Ausführungsform der Erfindung eine Prüfsumme vom Anfang des TCP-Kopfes berechnet werden (vorausgesetzt, dass der Kopfbereich der Schicht vier das TCP ist). Der Wert des Operationsarguments (z. B. 0x00A) gibt an, dass sich die Prüfsumme zwanzig Bytes (z. B. zehn Zwei-Byte-Inkremente) vom momentanen Zeiger befindet. Folglich wird ein Wert von zwanzig Bytes zur Position des Parszeigers hinzugefügt, wobei das Ergebnis in einem Register oder einer anderen Datenstruktur (z. B. im CSUMSTART-Register) gespeichert wird.
  • Der Befehl IPV4_3 (z. B. der Befehl acht) ist konstruiert, um zu bestimmen, ob der IP-Kopf des Pakets eine IP-Fragmentierung angibt. Wenn der aus dem Kopfbereich in Übereinstimmung mit der Extraktionsmaske extrahierte Wert nicht gleich dem Vergleichswert ist, dann gibt das Paket eine Fragmentierung an. Wenn eine Fragmentierung erfasst wird, wird das Paket als für die hierin erörterten Verarbeitungsverbesserungen ungeeignet betrachtet, wobei die Prozedur endet (z. B. durch den Befehl DONE). Andernfalls wird der Zeiger um zwei Bytes inkrementiert, wobei der Befehl IPV4_4 nach der Ausführung einer LD_LEN-Operation aufgerufen wird.
  • In Übereinstimmung mit der LD_LEN-Operation wird die Länge des IP-Segments gesichert. Das veranschaulichte Operationsargument (z. B. 0x03E) umfasst einen Versatz zum Gesamtlängenfeld, wo sich der Wert befindet. Insbesondere bilden die sechs niedrigstwertigen Bits den Versatz. Weil der Zeiger bereits über dieses Feld hinaus fortgeschaltet worden ist, umfasst das Operationsargument einen negativen Wert. Ein Fachmann auf dem Gebiet erkennt, dass dieser binäre Wert (z. B. 111110) verwendet werden kann, um den Dezimalwert der negativen Zwei darzustellen. Folglich wird der gegenwärtige Versatz des Zeigers minus vier Bytes (z. B. zwei Zwei-Byte-Einheiten) in einem Register oder einer anderen Datenstruktur (z. B. dem PAYLOADLEN-Register) gesichert. Jedes andere geeignete Verfahren, um einen negativen Versatz darzustellen, kann verwendet werden. Alternativ kann die IP-Segmentlänge gesichert werden, während sich der Zeiger an einem Ort befindet, der dem Gesamtlängenfeld vorangeht (z. B. während eines vorhergehenden Befehls).
  • Im Befehl IPV4_4 (z. B. dem Befehl neun) wird ein Ein-Byte-Protokollfeld untersucht, um zu bestimmen, ob sich herausstellt, das das Protokoll der Schicht vier das TCP ist. Wenn ja, wird der Zeiger vierzehn Bytes fortgeschaltet, wobei die Ausführung mit dem Befehl TCP_1 fortgesetzt wird; andernfalls endet die Prozedur.
  • Die spezifizierte LD_FID-Operation, die nur ausgeführt wird, wenn der Vergleich im Befehl IPV4_4 erfolgreich ist, umfasst das Wiedergewinnen des Flussschlüssels des Pakets und seine Speicherung in einem Register oder an einem anderen Ort (z. B. dem FLOWID-Register). Ein Fachmann auf dem Gebiet erkennt, dass die Kopfbereiche der Schichten drei und vier des Pakets dem IP (Version vier) bzw. dem TCP entsprechen müssen, damit der Vergleich im Befehl IPV4_4 erfolgreich ist. Wenn ja, dann wird der ganze Flussschlüssel (z. B. die IP-Ursprungs- und -Zieladressen plus die TCP-Ursprungs- und -Ziel-Port-Nummern) zusammenhängend im Kopfabschnitt des Pakets gespeichert. Insbesondere umfasst der Flussschlüssel den letzten Abschnitt des IP-Kopfes und den Anfangsabschnitt des TCP-Kopfes, wobei er in einer Operation extrahiert werden kann. Das Operationsargument (z. B. 0x182) umfasst folglich zwei Werte, die notwendig sind, um den Flussschlüssel zu lokalisieren und abzugrenzen. Beispielhaft identifizieren die sechs Bits am weitesten rechts des Arguments (z. B. 0x02) einen Versatz von der Zeigerposition in Zwei-Byte-Einheiten zum Anfang des Flussschlüssels. Die anderen fünf Bits des Arguments (z. B. 0x06) identifizieren die Größe des zu speichernden Flussschlüssels in Zwei-Byte-Einheiten.
  • Im Befehl IPV6_1 (z. B. dem Befehl zehn), der dem Misserfolg des durch den Befehl IPV4_1 ausgeführten Vergleichs folgt, sollte sich der Parszeiger auf einem Typfeld der Schicht zwei befinden. Falls der Test erfolgreich ist (z. B. das Typfeld einen hexadezimalen Wert von 86DD enthält), wird der Befehl IPV6_2 ausgeführt, nachdem eine LD_SUM-Operation ausgeführt worden ist und der Zeiger zwei Bytes zum Anfang des Protokolls der Schicht drei inkrementiert worden ist. Falls die Prüfung erfolglos ist, endet die Prozedur.
  • Die angegebene LD_SUM-Operation im Befehl IPV6_1 ist zu einer im Befehl IPV4_2 ausgeführten Operation ähnlich, verwendet aber ein anderes Argument. Abermals ist die Prüfsumme vom Anfang des TCP-Kopfes zu berechnen (vorausgesetzt, der Kopfbereich der Schicht vier ist das TCP). Das spezifizierte Operationsargument (z. B. 0x015) umfasst folglich einen Versatz zum Anfang des TCP-Kopfes – einundzwanzig Zwei-Byte=Schritte voraus. Der angegebene Versatz wird zur aktuellen Zeigerposition hinzugefügt und in einem Register oder einer anderen Datenstruktur (z. B. dem CSUMSTART-Register) gesichert.
  • Der Befehl IPV6_2 (z. B. der Befehl elf) überprüft ein vermutetes Versionsfeld der Schicht drei, um weiter zu sichern, dass das Protokoll der Schicht drei die Version sechs des IP ist. Falls der Vergleich misslingt, endet die Parsprozedur mit dem Aufruf des Befehls DONE. Falls er erfolgreich ist, wird der Befehl IPV6_3 aufgerufen. Die Operation IM_R1, die nur ausgeführt wird, wenn der Vergleich in dieser Ausführungsform erfolgreich ist, sichert die Länge des IP-Kopfes aus dem Nutzinformationen-Längenfeld. Wie ein Fachmann auf dem Gebiet erkennt, enthält das Gesamtlängenfeld (z. B. die IP-Segmentgröße) eines IP-Kopfes, Version vier, die Größe des Kopfbereichs der Version vier. Das Nutzinformationen-Längenfeld (z. B. die IP-Segmentgröße) eines IP-Kopfes, Version sechs, enthält jedoch die Größe des Kopfbereichs der Version sechs nicht. Folglich wird die Größe des Kopfbereichs der Version sechs, die durch die acht Bits am weitesten rechts des Ausgabearguments (z. B. 0x14, was zwanzig Zwei-Byte-Einheiten angibt) identifiziert wird, gesichert. Beispielhaft identifiziert der Rest des Arguments die Datenstruktur, in der die Kopflänge zu speichern ist (z. B. das temporäre Register R1). Infolge der Variation in der Größe der Kopfbereiche der Schicht drei zwischen den Protokollen wird in einer Ausführungsform der Erfindung die Kopfgröße in anderen Einheiten angegeben, um eine größere Genauigkeit zu erlauben. Insbesondere wird in einer Ausführungsform der Erfindung die Größe des Kopfbereichs im Befehl IPV6_2 in Bytes spezifiziert, wobei in diesem Fall das Ausgabeargument 0x128 sein könnte.
  • Der Befehl IPV6_3 (z. B. der Befehl zwölf) in dieser Ausführungsform untersucht keinen Wert eines Kopfbereichs. In dieser Ausführungsform gibt die Kombination einer Extraktionsmaske von 0x0000 mit einem Vergleichswert von 0x0000 an, dass eine Ausgabeoperation vor der nächsten Untersuchung eines Abschnitts eines Kopfbereichs erwünscht ist. Nachdem die LD_FID-Operation ausgeführt worden ist, wird der Parszeiger sechs Bytes zu einem Feld für den nächsten Kopf des IP-Kopfes der Version sechs fortgeschaltet. Weil die Extraktionsmaske und die Vergleichswerte beide 0x0000 sind, sollte der Vergleich niemals misslingen, wobei der Misserfolgszweig des Befehls niemals aufgerufen werden sollte.
  • Wie vorausgehend beschrieben worden ist, speichert eine LD_FID-Operation einen Flussschlüssel in einem geeigneten Register oder einer anderen Datenstruktur (z. B. dem FLOWID-Register). Beispielhaft umfasst das Operationsargument von 0x484 zwei Werte zum Identifizieren und Abgrenzen des Flussschlüssels. Insbesondere geben die sechs Bits am weitesten rechts (z. B. 0x04) an, dass sich der Abschnitt des Flussschlüssels bei einem Versatz von acht Bytes (z. B. vier Zwei-Byte-Inkrementen) von der momentanen Zeigerposition befindet. Der Rest des Operationsarguments (z. B. 0x12) gibt an, dass sechsunddreißig Bytes (z. B. das dezimale Äquivalent von 0x12 Zwei-Byte-Einheiten) vom berechneten Versatz zu kopieren sind. In der veranschaulichten Ausführungsform der Erfindung wird der ganze Flussschlüssel intakt kopiert, einschließlich der Ursprungs- und Zieladressen der Schicht drei und der Ursprungs- und Ziel-Ports der Schicht vier.
  • Im Befehl IPV6_4 (z. B. dem Befehl dreizehn) wird ein vermutetes Feld für den nächsten Kopf untersucht, um zu bestimmen, ob sich herausstellt, dass das Protokoll der Schicht vier des Protokollstapels des Pakets das TCP ist. Wenn ja, wird die Prozedur sechsunddreißig Bytes (z. B. achtzehn Zwei-Byte-Einheiten) fortgeschaltet und der Befehl TCP_1 aufgerufen; andernfalls endet die Prozedur (z. B. durch den Befehl DONE). Die Operation LD_LEN wird ausgeführt, falls der Wert des Feldes für den nächsten Kopf 0x06 ist. Wie oben beschrieben worden ist, speichert diese Operation die IP-Segmentgröße. Abermals umfasst das Argument (z. B. 0x03F) einen negativen Versatz, in diesem Fall die negative Eins. Dieser Versatz gibt an, dass sich das gewünschte Nutzinformationen-Längenfeld zwei Bytes vor der aktuellen Position des Zeigers befindet. Folglich wird der negative Versatz zum aktuellen Zeigerversatz hinzugefügt und das Ergebnis in einem geeigneten Register oder einer anderen Datenstruktur (z. B. dem PAYLOADLEN-Register) gesichert.
  • In den Befehlen TCP_1, TCP_2, TCP_3 und TCP_4 (z. B. den Befehlen vierzehn bis siebzehn) werden keine Werte der Kopfbereiche – außer bestimmten Merkern, die in den Ausgabeoperationen der Befehle spezifiziert sind – untersucht, es werden aber verschiedene Daten aus dem TCP-Kopf des Pakets gesichert. In der veranschaulichten Ausführungsform enthalten die Daten, die gesichert werden, eine TCP-Sequenznummer, eine TCP-Kopflänge und einen oder mehrere Merker. Für jeden Befehl wird die spezifizierte Operation ausgeführt, wobei der nächste Befehl aufgerufen wird. Wie oben beschrieben worden ist, misslingt ein Vergleich zwischen dem Vergleichswert 0x0000 und einem Null-Extraktionswert, wie er in jedem dieser Befehle verwendet wird, niemals. Nach dem Befehl TCP_4 kehrt die Parsprozedur zum Befehl WAIT zurück, um ein neues Paket zu erwarten.
  • Für die Operation LD_SEQ im Befehl TCP_1 umfasst das Operationsargument (z. B. 0x081) zwei Werte, um eine TCP-Sequenznummer zu identifizieren und zu extrahieren. Die sechs Bits am weitesten rechts (z. B. 0x01) geben an, dass sich die Sequenznummer zwei Bytes von der momentanen Position des Zeigers befindet. Der Rest des Arguments (z. B. 0x2) gibt die Anzahl der Zwei-Byte-Einheiten an, die von dieser Position kopiert werden müssen, um die Sequenznummer zu erfassen. Beispielhaft wird die Sequenznummer im SEQNO-Register gespeichert.
  • Für die Operation ST_FLAG im Befehl TCP_2 wird das Operationsargument (z. B. 0x145) verwendet, um ein Register (z. B. das FLAGS-Register) mit den Merkern zu konfigurieren, die in einer Aufgabe nach dem Parsen zu verwenden sind. Die sechs Bits am weitesten rechts (z. B. 0x05) bilden einen Versatz in Zwei-Byte-Einheiten zu einem Zwei-Byte-Abschnitt des TCP-Kopfes, der die Merker enthält, die beeinflussen können, ob das Paket für die Verbesserungen nach dem Parsen der vorliegenden Erfindung geeignet ist. An der Versatzposition können sich z. B. die URG-, PSH-, RST-, SYN- und FIN-Merker befinden, wobei sie verwendet werden können, um das Register zu konfigurieren. Die Ausgabemaske (z. B. 0x002F) gibt an, dass nur spezielle Positionen (z. B. Bits) des Merkerfelds des TCP-Kopfes gespeichert sind.
  • Die Operation LD_R1 des Befehls TCP_3 ist zu der im Befehl IPV6_2 ausgeführten Operation ähnlich. Hier enthält ein Operationsargument von 0x205 einen Wert (z. B. die sechs niedrigstwertigen Bits), die einen Versatz von fünf Zwei-Byte-Einheiten von der momentanen Zeigerposition identifizieren. Dieser Ort sollte ein Kopflängenfeld enthalten, das in einer Datenstruktur, die durch den Rest des Arguments identifiziert ist, (z. B. dem temporären Register R1) zu speichern ist. Die Ausgabemaske (z. B. 0xF000) gibt an, dass nur die ersten vier Bits gesichert werden (z. B. besitzt das Kopflängenfeld nur eine Größe von vier Bits).
  • Wie ein Fachmann auf dem Gebiet erkennt, kann der aus dem Kopflängenfeld extrahierte Wert eingestellt werden müssen, um in der veranschaulichten Ausführungsform die Verwendung der Zwei-Byte-Einheiten (z. B. der Sechzehn-Bit-Wörter) widerzuspiegeln. Deshalb wird in Übereinstimmung mit dem Verschiebungsabschnitt des Befehls TCP_3 der aus dem Feld extrahierte und durch die Ausgabemaske (z. B. 0xF000) konfigurierte Wert elf Positionen nach rechts verschoben, wenn er gespeichert wird, um die Berechnungen zu vereinfachen.
  • Die Operation LD_HDR des Befehls TCP_4 verursacht das Laden eines Versatzes zum ersten Byte der Paketdaten, die dem TCP-Kopf folgen. Beispielhaft können Pakete, die mit einem im Voraus ausgewählten Protokollstapel kompatibel sind, an irgendeinem Punkt in die Kopf- und Datenabschnitte getrennt werden. Das Sichern eines Versatzes zum Datenabschnitt macht es nun leichter, das Paket später aufzuspalten. Beispielhaft umfassen die sieben Bits am weitesten rechts des 0x0FF-Operationsarguments ein erstes Element des Versatzes zu den Daten. Ein Fachmann auf dem Gebiet erkennt, dass das Bitmuster (z. B. 1111111) gleich einer negativen Eins ist. Folglich wird ein Versatzwert, der gleich dem momentanen Parszeiger (z. B. der Wert im ADDR-Register) minus zwei Byte ist – der den Anfang des TCP-Kopfes lokalisiert – gesichert. Der Rest des Arguments bedeutet, dass der Wert einer temporären Datenstruktur (z. B. des temporären Registers R1) zu diesem Versatz hinzuzufügen ist. In diesem speziellen Kontext wird der im vorhergehenden Befehl gesicherte Wert (z. B. die Länge des TCP-Kopfes) hinzugefügt. Diese zwei Werte werden kombiniert, um einen Versatz zum Anfang der Paketdaten zu bilden, der in einem geeigneten Register oder einer anderen Datenstruktur (z. B. dem HDRSPLIT-Register) gespeichert wird.
  • Schließlich, und wie oben erwähnt worden ist, gibt der Befehl DONE (z. B. der Befehl achtzehn) das Ende des Parsens eines Pakets an, wenn bestimmt wird, dass das Paket nicht einem oder mehreren der Protokolle entspricht, die den veranschaulichten Befehlen zugeordnet sind. Dieser kann als ein "Aufräum"-Befehl betrachtet werden. Insbesondere gibt die Ausgabeoperation LD_CTL mit einem Operationsargument von 0x001 an, dass ein No_Assist-Merker in dem oben im Zusammenhang mit dem Befehl VLAN beschriebenen Steuerregister zu setzen ist (z. B. auf eins). Der No_Assist-Merker, wie er anderswo beschrieben ist, kann verwendet werden, um die anderen Module der Netzschnittstelle zu informieren, dass das aktuelle Paket für eine oder mehrere der anderswo beschriebenen Verarbeitungsverbesserungen ungeeignet ist.
  • Das veranschaulichte Programm oder der veranschaulichte Mikrocode stellen lediglich ein Verfahren zum Parsen eines Pakets bereit. Andere Programme, die die gleichen Befehle in einer anderen Sequenz oder völlig andere Befehle mit ähnlichen oder unähnlichen Formaten umfassen, können verwendet werden, um die Abschnitte der Kopfbereiche zu untersuchen und zu speichern und um die Register und anderen Datenstrukturen zu konfigurieren.
  • Die aus der Anwendung der verbesserten Verarbeitung einer vorliegenden Ausführungsform der Erfindung zu verwirklichenden Effizienzgewinne gleichen die Zeit, die erforderlich ist, um ein Paket mit dem veranschaulichten Programm zu parsen, mehr als aus. Selbst wenn in einer aktuellen Ausführungsform ein Kopf-Parser ein Paket in einer NIC parst, kann das Paket ferner immer noch durch seinen Protokollstapel durch einen Prozessor in einem Host-Computer verarbeitet werden müssen (z. B. um die Protokollköpfe zu beseitigen). Indem dies getan wird, wird die Belastung der Kommunikationsvorrichtung (z. B. der Netzschnittstelle) mit einer derartigen Aufgabe vermieden.
  • Eine Ausführungsform einer Flussdatenbank
  • 5 stellt die Flussdatenbank (FDB) 110 gemäß einer Ausführungsform der Erfindung dar. Beispielhaft ist die FDB 110 als ein CAM (inhaltsadressierbarer Speicher) unter Verwendung wiederbeschreibbarer Speicherkomponenten (z. B. RAM, SRAM, DRAM) implementiert. In dieser Ausführungsform umfasst die FDB 110 einen Assoziativabschnitt 502 und einen assoziierten Abschnitt 504, wobei sie durch die Flussnummer 506 indexiert werden kann.
  • Der Umfang der Erfindung schränkt die Form oder die Struktur der Flussdatenbank 110 nicht ein. In alternativen Ausführungsformen der Erfindung kann praktisch jede Form der Datenstruktur verwendet werden (z. B. Datenbank, Tabelle, Warteschlange, Liste, Feld), entweder monolithisch oder segmentiert, wobei sie in Hardware oder Software implementiert sein kann. Die veranschaulichte Form der FDB 110 ist lediglich eine Weise, um die nützlichen Informationen aufrechtzuerhalten, die die Kommunikationsflüsse durch die NIC 100 betreffen. Wie ein Fachmann auf dem Gebiet erkennt, erlaubt die Struktur einer CAM ein im hohen Grade effizientes und schnelles assoziatives Suchen.
  • In der veranschaulichten Ausführungsform der Erfindung erlauben die in der FDB 110 gespeicherten Informationen und die Operation des (im Folgenden beschriebenen) Flussdatenbankmanagers (FDBM) 108 Funktionen, wie z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung der Paketköpfe und andere Verbesserungen. Diese Funktionen können wie folgt kurz beschrieben werden.
  • Eine Form des erneuten Zusammenfügens der Daten umfasst das erneute Zusammenfügen oder die Kombination der Daten aus mehreren in Beziehung stehenden Paketen (z. B. Paketen aus einem einzelnen Kommunikationsfluss oder einem einzelnen Datagramm). Ein Verfahren für die Stapelverarbeitung der Paketköpfe erfordert die gemeinsame Verarbeitung der Protokollköpfe von mehreren in Beziehung stehenden Paketen durch einen Protokollstapel anstatt der Verarbeitung von einem Paket auf einmal. Eine weitere beispielhafte Funktion der NIC 100 umfasst die Verteilung oder Teilung einer derartigen Verarbeitung des Protokollstapels (und/oder anderer Funktionen) zwischen den Prozessoren in einem Mehrprozessor-Host-Computersystem. Eine noch weitere mögliche Funktion der NIC 100 ist, die Übertragung der erneut zusammengefügten Daten zu einer Zielentität (z. B. einem Anwendungsprogramm) in einer effizienten Ansammlung (z. B. einer Speicherseite) zu ermöglichen und dadurch die stückchenweisen und im hohen Grade ineffizienten Übertragungen der Daten eines Pakets auf einmal zu vermeiden. Folglich ist in dieser Ausführungsform der Erfindung ein Zweck der FDB 110 und des FDBM 108, die Informationen für die Verwendung der NIC 100 und/oder eines Host-Computersystems beim Freigeben, Sperren oder Ausführen einer oder mehrerer dieser Funktionen zu erzeugen.
  • Der Assoziativabschnitt 502 der FDB 110 in 5 speichert den Flussschlüssel jedes gültigen Flusses, der zu einer durch die NIC 100 bedienten Entität unterwegs ist. Folglich enthält in einer Ausführungsform der Erfindung der Assoziativabschnitt 502 die IP-Ursprungsadresse 510, die IP-Zieladresse 512, den TCP-Ursprungs-Port 514 und den TCP-Ziel-Port 516. Wie in einem früheren Abschnitt beschrieben worden ist, können diese Felder aus einem Paket extrahiert und durch den Kopf-Parser 106 dem FDBM 108 bereitgestellt werden.
  • Obwohl jede durch die NIC 100 bediente Zielentität an mehreren Kommunikationsflüssen oder TCP-Gesamtverbindungen beteiligt sein kann, ist nur ein Fluss auf einmal zwischen einer speziellen Ursprungsentität und einer speziellen Zielentität vorhanden. Deshalb sollte jeder Flussschlüssel im Assoziativabschnitt 502, der einem gültigen Fluss entspricht, aus allen anderen gültigen Flüssen eindeutig sein. In alternativen Ausführungsformen der Erfindung besteht der Assoziativabschnitt 502 aus verschiedenen Feldern, die alternative Flussschlüsselformen widerspiegeln, die durch die durch den Kopf-Parser geparsten Protokolle und die zum Identifizieren der Kommunikationsflüsse verwendeten Informationen bestimmt sein können.
  • Der assoziierte Abschnitt 504 in der veranschaulichten Ausführungsform umfasst den Flussgültigkeitsindikator 520, die Flusssequenznummer 522 und den Flussaktivitätsindikator 524. Diese Felder stellen die Informationen bereit, die den durch den im entsprechenden Eintrag im Assoziativabschnitt 502 gespeicherten Fluss schlüssel identifizierten Fluss betreffen. Die Felder des assoziierten Abschnitts 504 können durch den FDBM 108 wiedergewonnen und/oder aktualisiert werden, wie im folgenden Abschnitt beschrieben ist.
  • Der Flussgültigkeitsindikator 520 gibt in dieser Ausführungsform an, ob der zugeordnete Fluss gültig oder ungültig ist. Beispielhaft ist der Flussgültigkeitsindikator gesetzt, um einen gültigen Fluss anzugeben, wenn das erste Paket der Daten in einem Fluss empfangen wird, wobei er zurückgesetzt werden kann, um die Gültigkeit eines Flusses jedes Mal erneut festzustellen, wenn ein Abschnitt eines Datagramms des Flusses (z. B. ein Paket) richtig empfangen wird.
  • Der Flussgültigkeitsindikator 520 kann als ungültig markiert werden, nachdem das letzte Paket der Daten in einem Fluss empfangen worden ist. Der Flussgültigkeitsindikator kann außerdem gesetzt werden, um einen ungültigen Fluss anzugeben, wann immer ein Fluss aus irgendeinem Grund außer dem Empfang eines letzten Datenpakets abzubauen ist (z. B. zu beenden oder abzubrechen ist). Ein Paket kann z. B. außerhalb der Reihenfolge von anderen Paketen eines Datagramms empfangen werden, es kann ein Steuerpaket, das angibt, dass eine Datenübertragung oder ein Fluss abgebrochen wird, empfangen werden, es kann ein Versuch unternommen werden, um einen Fluss neu aufzubauen oder neu zu synchronisieren (wobei in diesem Fall der ursprüngliche Fluss beendet wird) usw. In einer Ausführungsform der Erfindung ist der Flussgültigkeitsindikator 520 ein einzelnes Bit, ein einzelner Merker oder ein einzelner Wert.
  • Die Flusssequenznummer 522 umfasst in der veranschaulichten Ausführungsform eine Sequenznummer des nächsten Abschnitts der Daten, der im zugeordneten Fluss erwartet wird. Weil das in einem Fluss gesendete Datagramm typischerweise über mehrere Pakete empfangen wird, stellt die Flusssequenznummer einen Mechanismus bereit, um zu sichern, dass die Pakete in der richtigen Reihenfolge empfangen werden. In einer Ausführungsform der Erfindung fügt z. B. die NIC 100 die Daten von mehreren Paketen eines Datagramms erneut zusammen. Um dieses erneute Zusammenfügen in der effizientesten Weise auszuführen, müssen die Pakete der Reihe nach empfangen werden. Folglich speichert die Flusssequenznummer 522 eine Kennzeichnung, um das nächste Paket oder den nächsten Abschnitt der Daten zu identifizieren, das bzw. der empfangen werden sollte.
  • In einer Ausführungsform der Erfindung entspricht die Flusssequenznummer 522 dem in den TCP-Protokollköpfen gefundenen TCP-Sequenznummernfeld. Wie ein Fachmann auf dem Gebiet erkennt, identifiziert die TCP-Sequenznummer eines Pakets die Position der Daten des Pakets bezüglich der anderen Daten, die in einem Datagramm gesendet werden. Für Paket und Flüsse, die andere Protokolle als das TCP umfassen, kann ein alternatives Verfahren verwendet werden, um den Empfang der Daten in der richtigen Reihenfolge zu verifizieren oder zu sichern.
  • Der Flussaktivitätsindikator 524 spiegelt in der veranschaulichten Ausführungsform die Neuheit der Aktivität eines Flusses oder, mit anderen Worten, das Alter eines Flusses wieder. In dieser Ausführungsform der Erfindung ist der Flussaktivitätsindikator 524 einem Zähler zugeordnet, wie z. B. einem (in 5 nicht dargestellten) Flussaktivitätszähler. Der Flussaktivitätszähler wird jedes Mal aktualisiert (z. B. inkrementiert), wenn ein Paket als ein Teil eines Flusses empfangen wird, der bereits in der Flussdatenbank 110 gespeichert ist. Der aktualisierte Zählerwert wird dann im Flussaktivitätsindikator-Feld des Flusses des Pakets gespeichert. Der Flussaktivitätszähler kann außerdem jedes Mal inkrementiert werden, wenn ein erstes Paket eines neuen Flusses, der zur Datenbank hinzugefügt wird, empfangen wird. In einer alternativen Ausführungsform wird ein Flussaktivitätszähler nur für Daten enthaltende Pakete aktualisiert (er wird z. B. für Steuerpakete nicht aktualisiert). In einer noch weiteren alternativen Ausführungsform werden mehrere Zähler verwendet, um die Flussaktivitätsindikatoren verschiedener Flüsse zu aktualisieren.
  • Weil nicht immer bestimmt werden kann, wann ein Kommunikationsfluss beendet ist (z. B. kann das letzte Paket verloren worden sein), kann der Flussaktivitätsindikator, verwendet werden, um Flüsse zu identifizieren, die veraltet sind oder die aus irgendeinem anderen Grund abgebaut werden sollten. Falls sich z. B. herausstellt, dass die Flussdatenbank 110 vollständig bevölkert ist (z. B. der Flussgültigkeitsindikator 520 ist für jede Flussnummer gesetzt), wenn das erste Paket eines neuen Flusses empfangen wird, kann der Fluss mit dem niedrigsten Flussaktivitätsindikator durch den neuen Fluss ersetzt werden.
  • In der veranschaulichten Ausführungsform der Erfindung kann sich die Größe der Felder in der FDB 110 von einem Eintrag zum anderen unterscheiden. In der Version vier des Protokolls sind z. B. die IP-Ursprungs- und -Zieladressen vier Bytes groß, sie sind aber in der Version sechs sechzehn Bytes groß. In einer alternativen Ausführungsform der Erfindung können die Einträge für ein spezielles Feld eine einheitliche Größe besitzen, wobei kleinere Einträge aufgefüllt werden, wie es notwendig ist.
  • In einer weiteren alternativen Ausführungsform der Erfindung können die Felder innerhalb der FDB 110 verschmolzen sein. Insbesondere kann der Flussschlüssel eines Flusses als eine einzelne Entität oder ein einzelnes Feld gespeichert sein, anstatt dass er als eine Anzahl separater Felder gespeichert ist, wie in 5 gezeigt ist. Ähnlich sind der Flussgültigkeitsindikator 520, die Flusssequenznummer 522 und der Flussaktivitätsindikator 524 in 5 als separate Einträge dargestellt. In einer alternativen Ausführungsform der Erfindung können jedoch einer oder mehrere dieser Einträge kombiniert sein. Insbesondere umfassen in einer alternativen Ausführungsform der Flussgültigkeitsindikator 520 und der Flussaktivitätsindikator 524 einen einzelnen Eintrag, der einen ersten Wert (z. B. null) besitzt, wenn der zugeordnete Fluss des Eintrags ungültig ist. Solange wie der Fluss gültig ist, wird jedoch der kombinierte Eintrag inkrementiert, wie Pakete empfangen werden, wobei er beim Abschluss des Flusses auf den ersten Wert zurückgesetzt wird.
  • In einer Ausführungsform der Erfindung enthält die FDB 110 maximal vierundsechzig Einträge, die durch die Flussnummer 506 indexiert sind, wobei folglich die Datenbank erlaubt, vierundsechzig gültige Flüsse auf einmal zu verfolgen. In alternativen Ausführungsformen der Erfindung können abhängig von der Größe des der Flussdatenbank 110 zugewiesenen Speichers mehr oder weniger Einträge erlaubt sein. Außer durch die Flussnummer 506 kann ein Fluss durch seinen Flussschlüssel (der im Assoziativabschnitt 502 gespeichert ist) identifizierbar sein.
  • In der veranschaulichten Ausführungsform der Erfindung ist die Flussdatenbank 110 leer (z. B. alle Felder sind mit Nullen gefüllt, wenn die NIC 100 initialisiert wird. Wenn das erste Paket eines Flusses empfangen wird, parst der Kopf-Parser 106 einen Kopfabschnitt des Pakets. Wie in einem vorhergehenden Abschnitt beschrieben worden ist, fügt der Kopf-Parser einen Flussschlüssel zusammen, um den Fluss zu identifizieren, wobei er andere Informationen extrahiert, die das Paket und/oder den Fluss betreffen. Der Flussschlüssel und andere Informationen werden zum Flussdatenbankmanager 108 geleitet. Dann durchsucht der FDBM 108 die FDB 110 nach einem aktiven Fluss, der dem Flussschlüssel zugeordnet ist. Weil die Datenbank leer ist, gibt es keine Übereinstimmung.
  • Deshalb wird in diesem Beispiel der Flussschlüssel gespeichert (z. B. als eine Flussnummer null), indem die IP-Ursprungsadresse, die IP-Zieladresse, der TCP-Ursprungs-Port und der TCP-Ziel-Port in die entsprechenden Felder kopiert werden. Dann wird der Flussgültigkeitsindikator 520 gesetzt, um einen gültigen Fluss anzugeben, die Flusssequenznummer 522 wird aus der TCP-Sequenznummer abgeleitet (die beispielsweise durch den Kopf-Parser bereitgestellt wird) und der Flussaktivitätsindikator 524 wird auf einen Anfangswert gesetzt (z. B. eins), der von einem Zähler abgeleitet werden kann. Ein Verfahren zum Erzeugen einer geeigneten Flusssequenznummer, die verwendet werden kann, um zu verifizieren, dass der für den Fluss empfangene nächste Abschnitt der Daten der Reihe nach empfangen wird, ist, die TCP-Sequenznummer und die Größe der Daten des Pakets zu addieren. Abhängig von der Konfiguration des Pakets (z. B. ob das SYN-Bit in einem Merkerfeld des TCP-Kopfes des Pakets gesetzt ist) kann jedoch die Summe eingestellt werden müssen (z. B. durch das Addieren von eins), um den nächsten erwarteten Abschnitt der Daten richtig zu identifizieren.
  • Wie oben beschrieben worden ist, ist ein Verfahren zum Erzeugen eines geeigneten Anfangswertes für einen Flussaktivitätsindikator, einen Zählerwert zu kopieren, der für jedes als ein Teil eines Flusses empfangene Paket inkrementiert wird. Für das erste empfangene Paket nach der Initialisierung der NIC 100 kann z. B. ein Flussaktivitätszähler auf den Wert von eins inkrementiert werden. Dieser Wert kann dann im Flussaktivitätsindikator 524 für den zugeordneten Fluss gespeichert werden. Das nächste als ein Teil des gleichen (oder eines neuen) Flusses empfangene Paket verursacht, dass der Zähler auf zwei inkrementiert wird, wobei dieser Wert im Flussaktivitätsindikator für den zugeordneten Fluss gespeichert wird. In diesem Beispiel sollten keine zwei Flüsse mit Ausnahme bei der Initialisierung, wenn sie alle gleich null oder irgendeinem anderen vorgegebenen Wert sein können, den gleichen Flussaktivitätsindikator besitzen.
  • Beim Empfang und beim Parsen eines an der NIC 100 empfangenen späteren Pakets wird die Flussdatenbank nach einem gültigen Fluss durchsucht, der mit dem Flussschlüssel des Pakets übereinstimmt. Beispielhaft werden nur die Flussschlüssel der aktiven Flüsse (z. B. derjenigen Flüsse, für die der Flussgültigkeitsindikator 520 gesetzt ist) durchsucht. Alternativ können alle Flussschlüssel (z. B. alle Einträge im Assoziativabschnitt 502) durchsucht werden, es wird aber nur eine Übereinstimmung gemeldet, falls ihr Flussgültigkeitsindikator einen gültigen Fluss angibt. Bei einem CAM, wie z. B. der FDB 110 in 5, können die Flussschlüssel und die Flussgültigkeitsindikatoren parallel durchsucht werden.
  • Falls ein späteres Paket den nächsten Abschnitt der Daten für einen vorhergehenden Fluss (z. B. der Fluss Nummer null) enthält, wird dieser Fluss geeignet aktualisiert. In einer Ausführungsform der Erfindung erfordert dies das Aktualisieren der Flusssequenznummer 522 und das Inkrementieren des Flussaktivitätsindikators 524, um seine jüngste Aktivität widerzuspiegeln. Der Flussgültigkeitsindikator 520 kann außerdem gesetzt werden, um die Gültigkeit des Flusses anzugeben, obwohl er bereits angeben sollte, dass der Fluss gültig ist.
  • Wenn neue Flüsse identifiziert werden, werden sie in einer zum ersten Fluss ähnlichen Weise zur FDB 110 hinzugefügt. Wenn ein Fluss beendet oder abgebaut wird, wird der zugeordnete Eintrag in der FDB 110 ungültig gemacht. In einer Ausführungsform der Erfindung wird der Flussgültigkeitsindikator 520 für den beendeten Fluss lediglich gelöscht (z. B. auf null gesetzt). In einer weiteren Ausführungsform werden ein Feld oder mehrere Felder eines beendeten Flusses gelöscht oder auf einen beliebigen oder einen vorgegebenen Wert gesetzt. Infolge der gebündelten Art des Netzpaketverkehrs werden alle oder die meisten Daten von einem Datagramm im Allgemeinen in einer kurzen Zeitperiode empfangen. Folglich muss jeder gültige Fluss in der FDB 110 normalerweise nur während einer kurzen Zeitperiode aufrechterhalten werden, wobei sein Eintrag dann verwendet werden kann, um einen anderen Fluss zu speichern.
  • Zurückzuführen auf die in einer Ausführungsform der Erfindung für die Flussdatenbank 110 verfügbare begrenzte Menge des Speichers kann die Größe jedes Feldes begrenzt sein. In dieser Ausführungsform sind sechzehn Bytes für die IP-Ursprungsadresse 510 und sechzehn Bytes für die IP-Zieladresse 512 zugewiesen. Für IP-Adressen, deren Länge kürzer als sechzehn Bytes ist, kann der zusätzliche Raum mit Nullen aufgefüllt sein. Ferner sind sowohl dem TCP-Ursprungs-Port 514 als auch dem TCP-Ziel-Port 516 zwei Bytes zugewiesen. Außerdem umfasst in dieser Ausführungsform der Flussgültigkeitsindikator 520 ein Bit, sind der Flusssequenznummer 522 vier Bytes zugewiesen und sind dem Flussaktivitätsindikator 524 ebenfalls vier Bytes zugewiesen.
  • Wie ein Fachmann auf dem Gebiet aus den obenbeschriebenen Ausführungsfor men erkennt, ist ein Fluss einer TCP-Gesamtverbindung ähnlich, aber nicht völlig gleich. Eine TCP-Verbindung kann für eine relativ ausgedehnte Zeitperiode vorhanden sein, die ausreichend ist, um mehrere Datagramme von einer Ursprungsentität zu einer Zielentität zu übertragen. Ein Fluss kann jedoch nur für ein Datagramm vorhanden sein. Folglich können während einer TCP-Gesamtverbindung mehrere Flüsse aufgebaut und abgebaut werden (z. B. einer für jedes Datagramm). Wie oben beschrieben worden ist, kann ein Fluss aufgebaut (z. B. zur FDB 110 hinzugefügt und als gültig markiert) werden, wenn die NIC 100 den ersten Abschnitt der Daten in einem Datagramm erfasst, während er abgebaut (z. B. in der FDB 110 als ungültig markiert) werden kann, wenn der letzte Abschnitt der Daten empfangen wird. Beispielhaft besitzt jeder während einer einzelnen TCP-Gesamtverbindung aufgebaute Fluss den gleichen Flussschlüssel, weil die Adressen und die Port-Kennzeichnungen der Schicht drei und der Schicht vier, die verwendet werden, um den Flussschlüssel zu bilden, die gleichen bleiben.
  • In der veranschaulichten Ausführungsform bestimmt die Größe der Flussdatenbank 110 (z. B. die Anzahl der Flusseinträge) die maximale Anzahl der Flüsse, die auf einmal verschachtelt (z. B. gleichzeitig aktiv) sein können, während die Funktionen des erneuten Zusammenfügens der Daten und der Stapelverarbeitung der Protokollköpfe ermöglicht sind. Mit anderen Worten, in der in 5 dargestellten Ausführungsform kann die NIC 100 vierundsechzig Flüsse aufbauen und Pakete von bis zu vierundsechzig verschiedenen Datagrammen empfangen (d. h., es können vierundsechzig Flüsse aktiv sein), ohne einen Fluss abzubauen. Falls eine maximale Anzahl der Flüsse durch die NIC 100 bekannt wäre, könnte die Flussdatenbank 110 die entsprechende Anzahl der Einträge begrenzt sein.
  • Die Flussdatenbank kann klein gehalten werden, weil ein Fluss in der gegenwärtig beschriebenen Ausführungsform nur ein Datagramm dauert, wobei infolge der gebündelten Art des Paketverkehrs die Pakete des Datagramms im Allgemeinen in einer kurzen Zeitperiode empfangen werden. Die kurze Dauer eines Flusses kompensiert die begrenzte Anzahl der Einträge in der Flussdatenbank. In einer Ausführungsform der Erfindung wird, falls die FDB 110 mit aktiven Flüssen gefüllt ist und ein neuer Fluss begonnen wird (d. h. ein erster Abschnitt der Daten in einem neuen Datagramm), der älteste (d. h. der am weitesten zurückliegend aktive) Fluss durch den neuen ersetzt.
  • In einer alternativen Ausführungsform der Erfindung können die Flüsse für irgendeine Anzahl von Datagrammen (oder ein anderes Maß des Netzverkehrs) oder für eine spezifizierte Dauer oder einen spezifizierten Bereich in der Zeit aktiv gehalten werden. Wenn z. B. ein Datagramm endet, kann sein Fluss in der FDB 110 "offen"-gehalten (d. h. nicht abgebaut) werden, falls die Datenbank nicht voll ist (z. B. der Eintrag des Flusses nicht für einen anderen Fluss benötigt wird). Dieses Schema kann die effiziente Operation der NIC 100 weiter verbessern, falls ein weiteres Datagramm mit dem gleichen Flussschlüssel empfangen wird. Insbesondere wird der Zusatzaufwand, den das Aufbauen eines weiteren Flusses mit sich bringt, vermieden, wobei mehr erneutes Zusammenfügen der Daten und mehr Paketstapelung (wie im Folgenden beschrieben ist) ausgeführt werden können. Vorteilhaft kann ein Fluss in der Flussdatenbank 110 offen gehalten werden, bis die TCP-Gesamtverbindung, die den Fluss umfasst, endet.
  • Eine Ausführungsform eines Flussdatenbankmanagers
  • 6A–6E stellen ein Verfahren zum Betreiben eines Flussdatenbankmanagers (FDBM), wie z. B. des Flussdatenbankmanagers 108 nach 1A, dar, um die Flussdatenbank (FDB) 110 zu managen. Beispielhaft speichert und aktualisiert der FDB 108 die in der Flussdatenbank 110 gespeicherten Flussinformationen und erzeugt für ein durch die NIC 100 empfangenes Paket einen Operationscode. Der FDBM 108 baut außerdem einen Fluss ab (z. B. ersetzt oder beseitigt einen Eintrag in der FDB 110 oder macht ihn anderweitig ungültig), wenn der Fluss beendet oder abgebrochen wird.
  • In einer Ausführungsform der Erfindung spiegelt der Operationscode eines Pakets die Kompatibilität des Pakets mit vorgegebenen Kriterien wieder, um eine oder mehrere Funktionen der NIC 100 (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung der Paketköpfe, die Lastverteilung) auszuführen. Mit anderen Worten, abhängig vom Operationscode eines Pakets können andere Module der NIC 100 eine dieser Funktionen ausführen oder nicht.
  • In einer weiteren Ausführungsform der Erfindung gibt ein Operationscode einen Paketstatus an. Ein Operationscode kann z. B. angeben, dass ein Paket: keine Daten enthält, ein Steuerpaket ist, mehr als eine spezifizierte Datenmenge enthält, das erste Paket eines neuen Flusses ist, das letzte Paket eines vorhandenen Flusses ist, sich außerhalb der Reihenfolge befindet, einen bestimmten Merker enthält (z. B. in einem Protokollkopf), der keinen erwarteten Wert besitzt (und folglich möglicherweise einen Ausnahmezustand angibt) usw.
  • Die Operation des Flussdatenbankmanagers 108 hängt von den durch den Kopf-Parser 106 bereitgestellten Paketinformationen und den aus der Flussdatenbank 110 entnommenen Daten ab. Nachdem der FDBM 108 die Paketinformationen und/oder die Daten verarbeitet hat, werden die Steuerinformationen (z. B. der Operationscode des Pakets) in der Steuerwarteschlange 118 gespeichert, wobei die FDB 110 geändert werden kann (z. B. ein neuer Fluss eingegeben oder ein vorhandener Fluss aktualisiert oder abgebaut werden kann).
  • Unter Bezugnahme auf die 6A–6E ist nun der Zustand 600 ein Anfangszustand, in dem der FDBM 108 die aus einem durch die NIC 100 vom Netz 102 empfangenen Paket entnommenen Informationen erwartet. Im Zustand 602 benachrichtigt der Kopf-Parser 106 oder ein anderes Modul der NIC 100 den FDBM 108 über ein neues Paket, indem er den Flussschlüssel des Pakets und einige Steuerinformationen bereitstellt. Der Empfang dieser Daten kann als eine Anforderung interpretiert werden, um die FDB 110 zu durchsuchen, um zu bestimmen, ob ein Fluss mit diesem Flussschlüssel bereits vorhanden ist.
  • In einer Ausführungsform der Erfindung enthalten die zum FDBM 108 geleiteten Steuerinformationen eine aus dem Paketkopf entnommene Sequenznummer (z. B. eine TCP-Sequenznummer). Die Steuerinformationen können außerdem den Status bestimmter Merker in den Kopfbereichen des Pakets, ob das Paket Daten enthält und, wenn ja, ob die Datenmenge eine bestimmte Größe überschreitet, angeben. In dieser Ausführungsform empfängt der FDBM 108 außerdem ein No_Assist-Signal für ein Paket, falls der Kopf-Parser bestimmt, dass das Paket nicht entsprechend einem der im Voraus ausgewählten Protokollstapel formatiert ist (d. h., dass das Paket nicht "kompatibel" ist), wie in einem vorhergehenden Abschnitt erörtert worden ist. Beispielhaft gibt das No_Assist-Signal an, dass eine oder mehrere Funktionen der NIC 100 (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung, der Lastausgleich) für das Paket nicht bereitgestellt werden können.
  • Im Zustand 604 bestimmt der FDBM 108, ob ein No_Assist-Signal für das Paket gesetzt worden ist. Wenn ja, geht die Prozedur zum Zustand 668 weiter (6E). Anderenfalls durchsucht der FDBM 108 im Zustand 606 die FDB 110 nach dem Flussschlüssel des Pakets: In einer Ausführungsform der Erfindung werden nur gültige Flusseinträge in der Flussdatenbank durchsucht. Wie oben erörtert worden ist, kann die Gültigkeit eines Flusses durch einen Gültigkeitsindikator, wie z. B. den (in 5 gezeigten) Flussgültigkeitsindikator 520, widergespiegelt werden. Falls im Zustand 608 bestimmt wird, dass der Flussschlüssel des Pakets in der Datenbank nicht gefunden worden ist, oder dass eine Übereinstimmung gefunden worden ist, aber der zugeordnete Fluss nicht gültig ist, geht die Prozedur zum Zustand 646 weiter (6D).
  • Falls eine gültige Übereinstimmung in der Flussdatenbank gefunden wird, wird im Zustand 610 die Flussnummer (z. B. der Index der Flussdatenbank für den übereinstimmenden Eintrag) des übereinstimmenden Flusses vermerkt und werden die in der FDB 110 gespeicherten Flussinformationen gelesen. Beispielhaft enthalten diese Informationen den Flussgültigkeitsindikator 520, die Flusssequenznummer 522 und den Flussaktivitätsindikator 524 (die in 5 gezeigt sind).
  • Im Zustand 612 bestimmt der FDBM 108 aus den vom Kopf-Parser 106 empfangenen Informationen, ob das Paket TCP-Nutzinformationendaten enthält. Wenn nicht, geht die veranschaulichte Prozedur zum Zustand 638 weiter (6C); andernfalls wird die Prozedur im Zustand 614 fortgesetzt.
  • Im Zustand 614 bestimmt der Flussdatenbankmanager, ob das Paket einen Versuch bildet, eine Kommunikationsverbindung oder einen Kommunikationsfluss zurückzusetzen. Beispielhaft kann dies bestimmt werden, indem der Zustand eines SYN-Bits in einem der Protokollköpfe des Pakets (z. B. einem TCP-Kopf) untersucht wird. In einer Ausführungsform der Erfindung wird der Wert von einem oder mehreren Steuer- oder Merkerbits (wie z. B. dem SYN-Bit) durch den Kopf-Parser dem FDBM bereitgestellt. Wie ein Fachmann auf dem Gebiet erkennt, kann eine TCP-Entität versuchen, einen Kommunikationsfluss oder eine Kommunikationsverbindung mit einer weiteren Entität zurückzusetzen (z. B. infolge eines Problems in einem der Host-Computer der Entität) und einen ersten Abschnitt der Daten zusammen mit einer Anforderung für eine erneute Verbindung zu senden. Dies ist die Situation, die der Flussdatenbankmanager im Zustand 614 zu erkennen versucht. Falls das Paket Teil eines Versuchs ist, einen Fluss oder eine Verbindung erneut zu verbinden oder zurückzusetzen, wird die Prozedur im Zustand 630 fortgesetzt (6C).
  • Im Zustand 616 vergleicht der Flussdatenbankmanager 108 eine aus einem Paketkopf extrahierte Sequenznummer (z. B. eine TCP-Sequenznummer) mit einer Sequenznummer (z. B. der Flusssequenznummer 522 nach 5) des nächsten erwarteten Abschnitts der Daten für diesen Fluss. Beispielhaft sollten diese Sequenznummern übereinstimmen, falls das Paket den nächsten Abschnitt der Daten des Flusses enthält. Falls die Sequenznummern nicht übereinstimmen, wird die Prozedur im Zustand 628 fortgesetzt.
  • Im Zustand 618 bestimmt der FDBM 108, ob bestimmte aus einem oder mehreren der Protokollköpfe des Pakets extrahierte Merker mit erwarteten Werten übereinstimmen. In einer Ausführungsform der Erfindung wird z. B. erwartet, dass die URG-, PSH-, RST- und FIN-Merker des TCP-Kopfes des Pakets gelöscht (d. h. gleich null) sind. Falls irgendeiner dieser Merker gesetzt ist (z. B. gleich eins ist), kann ein Ausnahmezustand vorhanden sein, der es folglich möglich macht, dass eine oder mehrere der durch die NIC 100 angebotenen Funktionen (z. B. das erneute Zusammensetzen der Daten, die Stapelverarbeitung, die Lastverteilung) für dieses Paket nicht ausgeführt werden sollten. Solange wie die Merker gelöscht sind, wird die Prozedur im Zustand 620 fortgesetzt; andernfalls wird die Prozedur im Zustand 626 fortgesetzt.
  • Im Zustand 620 bestimmt der Flussdatenbankmanager, ob während dieses Flusses weitere Daten erwartet werden. Wie oben erörtert worden ist, kann die Dauer eines Flusses auf ein einzelnes Datagramm begrenzt sein. Deshalb bestimmt im Zustand 620 der FDBM, ob sich herausstellt, dass dieses Paket der letzte Abschnitt der Daten für das Datagramm dieses Flusses ist. Beispielhaft wird diese Bestimmung auf der Grundlage der innerhalb des aktuellen Pakets enthaltenen Datenmenge ausgeführt. Wie ein Fachmann auf dem Gebiet erkennt, wird ein Datagramm, das mehr Daten umfasst, als in einem Paket übertragen werden können, über mehrere Paket gesendet. Die typische Weise der Verbreitung eines Datagramms zwischen mehreren Paketen ist, so viel Daten wie möglich in jedes Paket zu legen. Folglich ist die Größe jedes Pakets mit Ausnahme des Letzten normalerweise gleich oder fast gleich der maximalen Übertragungseinheit (MTU), die für das Netz erlaubt ist, über das die Pakete gesendet werden. Das letzte Paket enthält den Rest, dies verursacht normalerweise, dass es kleiner als die MTU ist.
  • Deshalb ist eine Art des Identifizierens des letzten Abschnitts der Daten in einem Datagramm eines Flusses, die Größe jedes Pakets zu untersuchen und sie mit einer Zahl (z. B. der MTU) zu vergleichen, deren Überschreitung durch ein Paket erwartet wird, mit Ausnahme, wenn der letzte Datenabschnitt übertragen wird. Es ist oben beschrieben worden, dass die Steuerinformationen vom Kopf-Parser 106 durch den FDBM 108 empfangen werden. In diesen Informationen kann eine Angabe der Größe der durch ein Paket übertragenen Daten enthalten sein. Insbesondere ist der Kopf-Parser 106 in einer Ausführungsform der Erfindung konfiguriert, um die Größe des Datenabschnitts jedes Pakets mit einem im Voraus ausgewählten Wert zu vergleichen. In einer Ausführungsform der Erfindung ist dieser Wert programmierbar. In der veranschaulichten Ausführungsform der Erfindung ist dieser Wert auf die maximale Datenmenge gesetzt, die ein Paket übertragen kann, ohne die MTU zu überschreiten. In einer alternativen Ausführungsform ist der Wert auf eine Menge gesetzt, die ein wenig kleiner als die maximale Datenmenge ist, die übertragen werden kann.
  • Folglich bestimmt im Zustand 620 der Flussdatenbankmanager 108, ob sich herausstellt, dass das empfangene Paket den letzten Abschnitt der Daten für das Datagramm des Flusses überträgt. Falls nicht, wird die Prozedur im Zustand 626 fortgesetzt.
  • Im Zustand 622 ist festgestellt worden, dass das Paket mit den im Voraus ausgewählten Protokollen kompatibel ist, und dass es für eine oder mehrere der durch die NIC 100 angebotenen Funktionen geeignet ist. Insbesondere ist das Paket für eine oder mehrere der oben erörterten Funktionen geeignet formatiert worden. Der FDBM 108 hat bestimmt, dass das empfangene Paket Teil eines vorhandenen Flusses ist, dass es mit den im Voraus ausgewählten Protokollen kompatibel ist, und dass es den nächsten Abschnitt der Daten für den Fluss (aber nicht den letzten Abschnitt) enthält. Ferner ist das Paket nicht Teil eines Versuchs, einen Fluss/eine Verbindung zurückzusetzen, wobei wichtige Merker ihre erwarteten Werte besitzen. Folglich kann die Flussdatenbank 110 wie folgt aktualisiert werden.
  • Der Aktivitätsindikator (z. B. der Flussaktivitätsindikator 524 nach 5) für diesen Fluss wird modifiziert, um die jüngste Flussaktivität widerzuspiegeln. In einer Ausführungsform der Erfindung ist der Flussaktivitätsindikator 524 als ein Zähler implementiert oder einem Zähler zugeordnet, der jedes Mal inkrementiert wird, wenn Daten für einen Fluss empfangen werden. In einer weiteren Ausführungsform der Erfindung wird ein Aktivitätsindikator oder Zähler jedes Mal aktualisiert, wenn ein Paket empfangen wird, das einen Flussschlüssel besitzt, der mit einem gültigen Fluss übereinstimmt (z. B. ob das Paket Daten enthält oder nicht).
  • In der veranschaulichten Ausführungsform wird, nachdem ein Flussaktivitätsindikator oder -zähler inkrementiert worden ist, er untersucht, um zu bestimmen, ob er auf null "übergelaufen" ist (d. h., ob er über seinen maximalen Wert inkrementiert worden ist). Wenn ja, werden der Zähler und/oder die Flussaktivitätsindikatoren für jeden Eintrag in der Flussdatenbank 110 auf null gesetzt, wobei der Aktivitätsindikator des momentanen Flusses noch einmal inkrementiert wird. Folglich verursacht in einer Ausführungsform der Erfindung das Überlaufen eines Flussaktivitätszählers oder -indikators die erneute Initialisierung des Flussaktivitätsmechanismus für die Flussdatenbank 110. Danach wird der Zähler inkrementiert und die Flussaktivitätsindikatoren abermals aktualisiert, die vorausgehend beschrieben worden ist. Ein Fachmann auf dem Gebiet erkennt, dass es viele andere geeignete Verfahren gibt, die in einer Ausführungsform der vorliegenden Erfindung angewendet werden können, um anzugeben, dass ein Fluss weniger zurückliegend aktiv gewesen ist als es ein anderer gewesen ist.
  • Außerdem wird im Zustand 622 die Flusssequenznummer 522 aktualisiert. Beispielhaft wird die neue Flusssequenznummer bestimmt, indem die Größe der neu empfangenen Daten zur vorhandenen Flusssequenznummer addiert wird. Abhängig von der Konfiguration des Pakets (z. B. den Werten in seinen Kopfbereichen) kann diese Summe eingestellt werden müssen. Diese Summe kann z. B. einfach die für das Datagramm des Flusses bis jetzt empfangene Gesamtdatenmenge angeben. Deshalb kann ein Wert (z. B. ein Byte) addiert werden müssen, um eine Sequenznummer des nächsten Bytes der Daten für das Datagramm anzugeben. Wie ein Fachmann auf dem Gebiet erkennt, können andere geeignete Verfahren zum Sichern, dass die Daten der Reihe nach empfangen werden, anstelle des hierin beschriebenen Schemas verwendet werden.
  • Schließlich wird im Zustand 622 in einer Ausführungsform der Erfindung der Flussgültigkeitsindikator 520 gesetzt oder zurückgesetzt, um die Gültigkeit des Flusses anzugeben.
  • Dann wird im Zustand 624 dem Paket an Operationscode zugeordnet. In der veranschaulichten Ausführungsform der Erfindung umfassen die Operationscodes die durch den Flussdatenbankmanager 108 erzeugten und in der Steuerwarte schlange 118 gespeicherten Codes. In dieser Ausführungsform besitzt ein Operationscode eine Größe von drei Bits, wobei folglich acht Operationscodes erlaubt sind. Die Operationscodes können in alternativen Ausführungsformen eine Vielzahl anderer Formen und Bereiche besitzen. Für die veranschaulichte Ausführungsform der Erfindung beschreibt die TABELLE 1 jeden Operationscode hinsichtlich der Kriterien, die zur Auswahl jedes Codes geführt haben, und die Verzweigungen dieser Auswahl. Für die Zwecke der TABELLE 1 umfasst das Aufbauen eines Flusses das Einfügen eines Flusses in die Flussdatenbank 110. Das Abbauen eines Flusses umfasst die Beseitigung oder das Ungültigmachen eines Flusses in der Flussdatenbank 110. Das erneute Zusammenfügen der Daten kann durch die DMA-Maschine 120 ausgeführt werden.
  • In der veranschaulichten Ausführungsform der Erfindung wird im Zustand 624 der Operationscode von 4 für Pakete im aktuellen Kontext der Prozedur ausgewählt (z. B. kompatible Pakete, die den nächsten, aber nicht den letzten Datenabschnitt eines Flusses übertragen). Folglich wird der vorhandene Fluss nicht abgebaut, wobei es keine Notwendigkeit gibt, einen neuen Fluss aufzubauen. Wie oben beschrieben worden ist, ist in dieser Ausführungsform ein kompatibles Paket ein Paket, das einem oder mehreren der im Voraus ausgewählten Protokolle entspricht. Durch das Ändern oder Vermehren der im Voraus ausgewählten Protokolle kann in einer alternativen Ausführungsform der Erfindung praktisch jedes Paket kompatibel sein.
  • In den 6A–6E endet nach dem Zustand 624 die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 626 (der vom Zustand 618 oder vom Zustand 620 erreicht wird) wird der Operationscode 3 für das Paket ausgewählt. Beispielhaft gibt der Operationscode 3 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt (z. B. der Flussschlüssel des Pakets stimmt mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 überein). Der Operationscode 3 kann außerdem bedeuten, dass das Paket Daten enthält, keinen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung neu zu synchronisieren oder zurückzusetzen, und dass die Sequenznummer des Pakets mit der erwarteten Sequenznummer (aus der Flussdatenbank 110) übereinstimmt. Es ist jedoch entweder ein wichtiger Merker (z. B. einer der TCP-Merker URG, PSH, RST oder FIN) gesetzt (was im Zustand 618 bestimmt wird) oder die Daten des Pakets sind kleiner als der obenbeschriebene Schwellenwert (im Zustand 620), wobei dies folglich angibt, dass in diesem Fluss diesem Paket wahrscheinlich keine weiteren Daten folgen. Deshalb wird der vorhandene Fluss abgebaut, es wird aber kein neuer Fluss erzeugt. Beispielhaft kann der Fluss abgebaut werden, indem der Gültigkeitsindikator des Flusses gelöscht wird (er z. B. auf null gesetzt wird). Nach dem Zustand 626 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 628 (der vom Zustand 616 erreicht wird) wird für das Paket der Operationscode 2 ausgewählt. Im vorliegenden Kontext kann der Operationscode 2 angeben, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt (z. B. der Flussschlüssel des Pakets stimmt mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 überein), Daten enthält und keinen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung neu zu synchronisieren oder zurückzusetzen. Die (im Zustand 616) aus dem Paket extrahierte Sequenznummer stimmt jedoch nicht mit der erwarteten Sequenznummer aus der Flussdatenbank 110 überein. Dies kann z. B. auftreten, wenn ein Paket außerhalb der Reihenfolge empfangen wird. Folglich wird der vorhandene Fluss abgebaut, es wird aber kein neuer Fluss aufgebaut. Beispielhaft kann der Fluss abgebaut werden, indem der Gültigkeitsindikator des Flusses gelöscht wird (er z. B. auf null gesetzt wird). Nach dem Zustand 628 endet die veranschaulichte Prozedur im Zustand 670.
  • In den Zustand 630 wird vom Zustand 614 eingetreten, wenn bestimmt wird, dass das empfangene Paket einen Versuch bildet, einen Kommunikationsfluss oder eine Kommunikationsverbindung zurückzusetzen (z. B. das TCP-SYN-Bit gesetzt ist). Im Zustand 630 bestimmt der Flussdatenbankmanager 108, ob erwartet wird, dass weitere Daten folgen. Wie im Zusammenhang mit dem Zustand 620 erklärt worden ist, kann diese Bestimmung auf der Grundlage der vom Kopf-Parser durch den Flussdatenbankmanager empfangenen Steuerinformationen ausgeführt werden. Falls weitere Daten erwartet werden (z. B. die Datenmenge im Paket ist gleich einem oder überschreitet einen Schwellenwert), wird die Prozedur im Zustand 634 fortgesetzt.
  • Im Zustand 632 wird der Operationscode 2 für das Paket ausgewählt. Der Operationscode 2 ist ebenfalls im Zustand 628 in einem anderen Kontext ausgewählt worden. Im vorliegenden Kontext kann der Operationscode 2 angeben, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält.
  • Der Operationscode 2 kann in diesem Kontext außerdem bedeuten, dass das Paket einen Versuch bildet, einen Kommunikationsfluss oder eine Kommunikationsverbindung neu zu synchronisieren oder zurückzusetzen, dass aber keine weiteren Daten erwartet werden, sobald der Fluss/die Verbindung zurückgesetzt worden ist. Deshalb wird der vorhandene Fluss abgebaut und kein neuer Fluss aufgebaut. Beispielhaft kann der Fluss abgebaut werden, indem der Gültigkeitsindikator des Flusses gelöscht wird (er z. B. auf null gesetzt wird). Nach dem Zustand 632 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 634 antwortet der Flussdatenbankmanager 108 auf einen Versuch, einen Kommunikationsfluss/eine Kommunikationsverbindung zurückzusetzen oder neu zu synchronisieren, wodurch zusätzliche Daten erwartet werden. Folglich wird der vorhandene Fluss wie folgt abgebaut und ersetzt. Der vorhandene Fluss kann durch die im Zustand 610 wiedergewonnene Flussnummer oder durch den Flussschlüssel des Pakets identifiziert werden. Die Sequenznummer des Flusses (z. B. die Flusssequenznummer 522 in 5) wird auf den nächsten erwarteten Wert gesetzt. Beispielhaft hängt dieser Wert von der (z. B. durch den Kopf-Parser 106) aus dem Paket wiedergewonnenen Sequenznummer (z. B. der TCP-Sequenznummer) und der im Paket enthaltenen Datenmenge ab. In einer Ausführungsform der Erfindung werden diese zwei Werte addiert, um eine neue Flusssequenznummer zu bestimmen. Wie vorausgehend erörtert worden ist, kann diese Summe eingestellt werden müssen (z. B. durch das Hinzufügen von eins). Außerdem wird im Zustand 634 der Flussaktivitätsindikator aktualisiert (z. B. inkrementiert). Wie im Zusammenhang mit dem Zustand 622 erklärt worden ist, werden die Aktivitätsindikatoren für alle Flüsse in der Datenbank auf null gesetzt und der aktuelle Fluss abermals inkrementiert, falls der Flussaktivitätsindikator überläuft. Schließlich wird der Flussgültigkeitsindikator gesetzt, um anzuzeigen, dass der Fluss gültig ist.
  • Im Zustand 636 wird der Operationscode 7 für das Paket ausgewählt. Im aktuellen Kontext gibt der Operationscode 7 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält. Der Operationscode 7 kann in diesem Kontext ferner bedeuten, dass das Paket einen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung neu zu synchronisieren oder zurückzusetzen, und dass zusätzliche Daten erwartet werden, sobald der Fluss/die Verbindung zurückgesetzt worden ist. Tatsächlich wird deshalb der vorhandene Fluss abgebaut und ein neuer (mit dem gleichen Flussschlüssel) an seiner Stelle gespeichert. Nach dem Zustand 636 endet die veranschaulichte Prozedur im Endzustand 670.
  • Nach dem Zustand 612 wird in den Zustand 638 eingetreten, wenn bestimmt wird, dass das empfangene Paket keine Daten enthält. Dies gibt oft an, dass das Paket ein Steuerpaket ist. Im Zustand 638 bestimmt der Flussdatenbankmanager 108, ob einer oder mehrere durch den Kopf-Parser aus dem Paket extrahierte Merker mit erwarteten oder erwünschten Werten übereinstimmen. In einer Ausführungsform der Erfindung müssen z. B. die TCP-Merker URG, PSH, RST und FIN gelöscht sein, damit die DMA-Maschine 120 die Daten aus mehreren in Beziehung stehenden Paketen (z. B. Paketen, die einen völlig gleichen Flussschlüssel besitzen) erneut zusammenfügt. Wie oben erörtert worden ist, kann das TCP-SYN-Bit außerdem untersucht werden. Im aktuellen Kontext (z. B. ein Paket ohne Daten) wird außerdem erwartet, dass das SYN-Bit gelöscht ist (z. B. einen Wert von null speichert). Falls die Merker (und das SYN-Bit) ihre erwarteten Werte besitzen, wird die Prozedur im Zustand 642 fortgesetzt. Falls jedoch irgendeiner dieser Merker gesetzt ist, kann ein Ausnahmezustand vorhanden sein und es folglich möglich machen, dass eine oder mehrere der durch die NIC 100 angebotenen Funktionen (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung, die Lastverteilung) für dieses Paket ungeeignet sind, wobei in diesem Fall die Prozedur zum Zustand 640 weitergeht.
  • Im Zustand 640 wird der Operationscode 1 für das Paket ausgewählt. Beispielhaft gibt der Operationscode 1 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt, es aber keine Daten enthält und ein wichtiger Merker oder ein wichtiges Bit oder mehrere wichtige Merker oder Bits im Kopfbereich (in den Kopfbereichen) des Pakets gesetzt ist bzw. sind. Folglich wird der vorhandene Fluss abgebaut, wobei kein neuer Fluss aufgebaut wird. Beispielhaft kann der Fluss abgebaut werden, indem der Gültigkeitsindikator des Flusses gelöscht wird (er z. B. auf null gesetzt wird). Nach dem Zustand 640 endet die veranschaulichte Prozedur im Endzustand 670.
  • Im Zustand 642 wird der Aktivitätsindikator des Flusses aktualisiert (z. B. inkrementiert), selbst wenn das Paket keine Daten enthält. Wie oben im Zusammenhang mit dem Zustand 622 beschrieben worden ist, werden in der vorliegenden Ausführungsform der Erfindung, falls der Aktivitätsindikator überläuft, alle Flussaktivitätsindikation in der Datenbank auf null gesetzt, wobei der momentane Fluss abermals inkrementiert wird. Außerdem können sowohl der Gültigkeitsindikator des Flusses als auch die Sequenznummer des Flusses zurückgesetzt werden.
  • Im Zustand 644 wird der Operationscode 0 für das Paket ausgewählt. Beispielhaft gibt der Operationscode 0 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt, und dass das Paket keine Daten enthält. Das Paket kann z. B. ein Steuerpaket sein. Der Operationscode 0 gibt ferner an, dass keiner der durch den Kopf-Parser 106 überprüften und obenbeschriebenen Merker (z. B. URG, PSH, RST und FIN) gesetzt ist. Folglich wird der vorhandene Fluss nicht abgebaut und kein neuer Fluss aufgebaut. Nach dem Zustand 644 endet die veranschaulichte Prozedur im Endzustand 670.
  • In den Zustand 646 wird vom Zustand 608 eingetreten, falls der Flussschlüssel des Pakets mit keinem der Flussschlüssel der gültigen Flüsse in der Flussdatenbank übereinstimmt. Im Zustand 646 bestimmt der FDBM 108, ob die Flussdatenbank 110 voll ist, wobei er irgendeine Angabe sichern kann, ob die Datenbank voll ist. In einer Ausführungsform der Erfindung wird die Flussdatenbank als voll betrachtet, wenn der Gültigkeitsindikator (z. B. der Flussgültigkeitsindikator 520 nach 5) für jede Flussnummer (z. B. für jeden Fluss in der Datenbank) gesetzt ist. Falls die Datenbank voll ist, wird die Prozedur im Zustand 650 fortgesetzt, andernfalls wird sie im Zustand 648 fortgesetzt.
  • Im Zustand 648 wird die niedrigste Flussnummer eines ungültigen Flusses (z. B. ein Fluss, für den der zugeordnete Flussgültigkeitsindikator gleich null ist) bestimmt. Beispielhaft befindet sich diese Flussnummer dort, wo ein neuer Fluss gespeichert wird, falls das empfangene Paket die Erzeugung eines neuen Flusses rechtfertigt. Nach dem Zustand 648 wird die Prozedur im Zustand 652 fortgesetzt.
  • Im Zustand 650 wird die Flussnummer des am weitesten zurückliegend aktiven Flusses bestimmt. Wie oben erörtert worden ist, wird in der veranschaulichten Ausführungsform der Erfindung der Aktivitätsindikator eines Flusses (z. B. der Flussaktivitätsindikator 524 nach 5) jedes Mal aktualisiert (z. B. inkrementiert), wenn für einen Fluss Daten empfangen werden. Deshalb kann in dieser Ausführungsform der am weitesten zurückliegend aktive Fluss als der Fluss identifiziert werden, der den am weitesten zurückliegend aktualisierten (z. B. niedrigsten) Flussaktivitätsindikator besitzt. Beispielhaft kann, falls mehrere Flüsse Flussaktivitätsindikatoren besitzen, die auf einen gemeinsamen Wert (z. B. null) gesetzt sind, eine Flussnummer von ihnen zufällig oder durch irgendein anderes Kriterium ausgewählt werden. Nach dem Zustand 650 wird die Prozedur im Zustand 652 fortgesetzt.
  • Im Zustand 652 bestimmt der Flussdatenbankmanager 108, ob das Paket Daten enthält. Beispielhaft geben die durch den Kopf-Parser dem FDBM 108 bereitgestellten Steuerinformationen an, ob das Paket Daten besitzt. Falls das Paket keine Daten enthält (z. B. das Paket ein Steuerpaket ist), wird die veranschaulichte Prozedur im Zustand 668 fortgesetzt.
  • Im Zustand 654 bestimmt der Flussdatenbankmanager 108, ob sich herausstellt, dass die mit dem aktuellen Paket empfangen Daten den Endabschnitt der Daten für das zugeordnete Datagramm/den zugeordneten Fluss enthalten. Wie im Zusammenhang mit dem Zustand 620 beschrieben worden ist, kann diese Bestimmung auf der Grundlage der in dem Paket enthaltenen Datenmenge ausgeführt werden. Wenn die Datenmenge kleiner als ein Schwellenwert (in der veranschaulichten Ausführungsform ein programmierbar Wert) ist, dann werden keine weiteren Daten erwartet, wobei es wahrscheinlich ist, dass sie die einzigen Daten für diesen Fluss sind. In diesem Fall wird die Prozedur im Zustand 668 fortgesetzt. Falls jedoch die Daten dem Schwellenwert entsprechen oder den Schwellenwert überschreiten, wobei in diesem Fall weitere Daten erwartet werden können, geht die Prozedur zum Zustand 656 weiter.
  • Im Zustand 656 werden die Werte bestimmter Merker untersucht. Diese Merker können z. B. die URG-, PSH-, RST-, FIN-Bits eines TCP-Kopfes enthalten. Falls irgendwelche der untersuchten Merker nicht ihre erwarteten oder erwünschten Werte besitzen (z. B. falls irgendwelche der Merker gesetzt sind), kann ein Ausnahmezustand vorhanden sein, der eine oder mehrere Funktionen der NIC 100 (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung, die Lastverteilung) für dieses Paket ungeeignet macht. In diesem Fall wird die Prozedur im Zustand 668 fortgesetzt; ansonsten geht die Prozedur zum Zustand 658 weiter.
  • Im Zustand 658 werden die im Zustand 646 gespeicherten Informationen hinsichtlich dessen, ob die Flussdatenbank 110 voll ist, durch den Flussdatenbankmanager wiedergewonnen. Falls die Datenbank voll ist, wird die Prozedur im Zustand 664 fortgesetzt; andernfalls wird die Prozedur im Zustand 660 fortgesetzt.
  • Im Zustand 660 wird für das aktuelle Paket ein neuer Fluss zur Flussdatenbank 110 hinzugefügt. Beispielhaft wird der neue Fluss bei der im Zustand 648 identifizierten oder wiedergewonnenen Flussnummer gespeichert. Die Ergänzung eines neuen Flusses kann das Setzen einer Sequenznummer (z. B. der Flusssequenznummer 522 aus 5) umfassen. Die Flusssequenznummer 522 kann erzeugt werden, indem eine vom Paket wiedergewonnene Sequenznummer (z. B. die TCP-Sequenznummer) und die im Paket enthaltene Datenmenge addiert werden. Wie oben erörtert worden ist, kann diese Summe eingestellt werden müssen (z. B. durch das Addierern von eins).
  • Das Speichern eines neuen Flusses kann außerdem die Initialisierung eines Aktivitätsindikators (z. B. des Flussaktivitätsindikators 524 nach 5) einschließen. In einer Ausführungsform der Erfindung umfasst diese Initialisierung das Speichern eines von einem Zähler, der jedes Mal inkrementiert wird, wenn Daten für einen Fluss empfangen werden, wiedergewonnenen Wertes. Beispielhaft werden, falls der Zähler oder ein Flussaktivitätsindikator über seinen maximalen speicherbaren Wert inkrementiert werden, der Zähler und alle Flussaktivitätsindikatoren gelöscht oder zurückgesetzt. Außerdem wird im Zustand 660 ein Gültigkeitsindikator (z. B. der Flussgültigkeitsindikator 520 nach 5) gesetzt, um anzugeben, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des Pakets außerdem in der Flussdatenbank in dem Eintrag, der der zugeordneten Flussnummer entspricht, gespeichert.
  • Im Zustand 662 wird der Operationscode 6 für das Paket ausgewählt. Beispielhaft gibt der Operationscode 6 an, dass das Paket kompatibel ist, mit keinen gültigen Flüssen übereinstimmt und den ersten Abschnitt der Daten für einen neuen Fluss enthält. Ferner besitzen die Merker des Pakets ihre erwarteten oder notwendigen Werte, werden zusätzliche Daten im Fluss erwartet und ist die Flussdatenbank nicht voll. Folglich gibt der Operationscode 6 an, dass es keinen abzubauenden vorhandenen Fluss gibt, und dass ein neuer Fluss in der Flussdatenbank gespeichert worden ist. Nach dem Zustand 662 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 664 wird ein vorhandener Eintrag in der Flussdatenbank ersetzt, sodass ein durch das aktuelle Paket eingeleiteter neuer Fluss gespeichert werden kann. Deshalb wird die im Zustand 650 identifizierte Flussnummer des am weitesten zurückliegend aktiven Flusses wiedergewonnen. Dieser Fluss kann wie folgt ersetzt werden. Die Sequenznummer des vorhandenen Flusses (z. B. die Flusssequenznummer 522 nach 5) wird durch einen durch das Kombinieren einer aus dem Paket extrahierten Sequenznummer (z. B. der TCP-Sequenznummer) mit der Größe des Datenabschnitts des Pakets abgeleiteten Wert ersetzt. Diese Summe kann eingestellt werden müssen (z. B. durch das Hinzufügen von eins). Dann wird der Aktivitätsindikator des vorhandenen Flusses (z. B. der Flussaktivitätsindikator 524) ersetzt. Der Wert eines Flussaktivitätszählers kann z. B. in den Flussaktivitätsindikator kopiert werden, wie oben erörtert worden ist. Der Gültigkeitsindikator des Flusses (z. B. der Flussgültigkeitsindikator 520 nach 5) wird dann gesetzt, um anzugeben, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des neuen Flusses gespeichert.
  • Im Zustand 666 wird der Operationscode 7 für das Paket ausgewählt. Der Operationscode 7 ist außerdem im Zustand 636 ausgewählt worden. Im aktuellen Kontext kann der Operationscode 7 angeben, dass das Paket kompatibel ist, nicht mit dem Flussschlüssel irgendwelcher gültigen Flüsse übereinstimmt und den ersten Abschnitt der Daten für einen neuen Fluss enthält. Ferner besitzen die Merker des Pakets kompatible Werte und werden zusätzliche Daten im Fluss erwartet. Schließlich gibt jedoch in diesem Kontext der Operationscode 7 an, dass die Flussdatenbank voll ist, deshalb ist ein vorhandener Eintrag abgebaut worden, wobei der neue Eintrag an seiner Stelle gespeichert worden ist. Nach dem Zustand 666 endet die veranschaulichte Prozedur im Endzustand 670.
  • Im Zustand 668 wird der Operationscode 5 für das Paket ausgewählt. In den Zustand 668 wird aus verschiedenen Zuständen eingetreten, wobei der Operationscode 5 folglich eine Vielfalt möglicher Zustände oder Situationen darstellt. Der Operationscode 5 kann z. B. ausgewählt werden, wenn (im Zustand 604) ein No_Assist-Signal für ein Paket erfasst wird. Wie oben erörtert worden ist, kann das No_Assist-Signal angeben, dass das entsprechende Paket mit einer Menge im Voraus ausgewählter Protokolle nicht kompatibel ist. In dieser Ausführungsform der Erfindung sind die inkompatiblen Pakete für eine der verschiedenen Funktionen der NIC 100 (z. B. das erneute Zusammenfügen der Daten, die Stapelverarbeitung, die Lastverteilung) ungeeignet.
  • Es kann außerdem vom Zustand 652 in den Zustand 668 eingetreten und der Operationscode 5 ausgewählt werden, wobei in diesem Fall der Code angeben kann, dass das empfangene Paket nicht mit irgendwelchen gültigen Flussschlüsseln übereinstimmt und ferner keine Daten enthält (es kann z. B. ein Steuerpaket sein).
  • Es kann außerdem vom Zustand 654 in den Zustand 668 eingetreten werden. In diesem Kontext kann der Operationscode 5 angeben, dass das Paket nicht mit irgendwelchen gültigen Flussschlüsseln übereinstimmt. Er kann ferner angeben, dass das Paket Daten enthält, dass aber die Größe des Datenabschnitts kleiner als der im Zusammenhang mit dem Zustand 654 erörterte Schwellenwert ist. In diesem Kontext stellt sich heraus, dass die Daten des Pakets vollständig sind (z. B. alle Daten für ein Datagramm enthalten), dies bedeutet, dass es keine weiteren Daten gibt, die mit den Daten dieses Pakets neu zusammenzufügen sind, wobei es deshalb keinen Grund gibt, einen neuen Eintrag in der Datenbank für diesen Ein-Paket-Fluss herzustellen.
  • Schließlich kann außerdem vom Zustand 656 in den Zustand 668 eingetreten werden. In diesem Kontext kann der Operationscode 5 angeben, dass das Paket nicht mit irgendwelchen gültigen Flussschlüsseln übereinstimmt, Daten enthält und weitere Daten erwartet werden, aber wenigstens ein Merker in einem oder mehreren der Protokollköpfe des Pakets nicht seinen erwarteten Wert besitzt. In einer Ausführungsform der Erfindung wird z. B. erwartet, dass die TCP-Merker URG, PSH, RST und FIN gelöscht sind. Falls irgendwelche dieser Merker gesetzt sind, kann ein Ausnahmezustand vorhandenen sein und es folglich möglich machen, dass eine der durch die NIC 100 angebotenen Funktionen für dieses Paket ungeeignet ist.
  • Wie die TABELLE 1 widerspiegelt, gibt es keinen abzubauenden Fluss und wird kein neuer Fluss aufgebaut, wenn der Operationscode 5 ausgewählt ist. Nach dem Zustand 668 endet die veranschaulichte Prozedur im Zustand 670.
  • Ein Fachmann auf dem Gebiet erkennt, dass die in den 6A–6E veranschaulichte und oben erörterte Prozedur nur eine geeignete Prozedur zum Aufrechterhalten und Aktualisieren einer Flussdatenbank und zum Bestimmen der Eignung eines Pakets für bestimmte Verarbeitungsfunktionen ist. Insbesondere können andere Operationscodes verwendet werden oder in einer anderen Weise implementiert sein, wobei es ein Ziel ist, Informationen für die spätere Verarbeitung des Pakets durch die NIC 100 zu erzeugen.
  • Obwohl in der veranschaulichten Prozedur die Operationscodes für alle Pakete durch einen Flussdatenbankmanager zugeordnet werden, kann in einer alternativen Prozedur ein durch den FDBM zugeordneter Operationscode durch ein anderes Modul der NIC 100 ersetzt oder geändert werden. Dies kann ausgeführt werden, um ein spezielles Verfahren zum Behandeln bestimmter Pakettypen zu sichern. In einer Ausführungsform der Erfindung ordnet z. B. das IPP-Modul 104 einen vorgegebenen Operationscode (z. B. den Operationscode 2 nach TABELLE 1) riesigen Paketen zu (z. B. Paketen, deren Größe größer als die MTU ist), sodass die die DMA-Maschine 120 sie nicht erneut zusammenfügt. Insbesondere kann das IPP-Modul unabhängig bestimmen, dass das Paket ein riesiges Paket ist (z. B. aus den durch ein MAC-Modul bereitgestellten Informationen), und deshalb den vorgegebenen Code zuordnen. Beispielhaft führen der Kopf-Parser 106 und der FDBM 108 ihren normalen Funktionen für ein riesiges Paket aus, wobei das IPP-Modul 104 einen durch den FDBM zugeordneten ersten Operationscode empfängt. Das IPP-Modul ersetzt jedoch diesen Code vor dem Speichern des riesigen Pakets und der das Paket betreffenden Informationen. In einer alternativen Ausführungsform können der Kopf-Parser 106 und/oder der Flussdatenbankmanager 108 konfiguriert sein, um einen speziellen Pakettyp (z. B. riesig) zu erkennen und einen vorgegebenen Operationscode zuzuordnen.
  • Die in der in den 6A–6E veranschaulichten Ausführungsform der Erfindung angewendeten Operationscodes sind in der folgenden TABELLE 1 dargestellt und erklärt. Die TABELLE 1 enthält beispielhafte Kriterien, die verwendet werden, um jeden Operationscode auszuwählen, und beispielhafte Ergebnisse oder Wirkungen jedes Codes.
  • Figure 00830001
  • Figure 00840001
    TABELLE 1
  • Die europäische Patentanmeldung Nr. 00910385.4 (am 8. September 2000 als die PCT-Veröffentlichungsnummer WO 00/52904 veröffentlicht), die der US-Patentanmeldung, Serien Nr. 09/259.765 entspricht, besitzt den Titel "A High Performance Network Interface" und stellt zusätzliche Einzelheiten einer Netzschnittstelle bereit, in der eine Ausführungsform der Erfindung praktiziert werden kann.
  • Sun, Sun Microsystems, SPARC und Solarris sind in den vereinigten Staaten und anderen Ländern Warenzeichen oder eingetragene Warenzeichen von Sun Microsystems, Incorporated.
  • Die vorangehenden Beschreibungen der Ausführungsformen der Erfindung sind nur für die Zwecke der Veranschaulichung und Beschreibung dargestellt worden. Sie sind nicht als erschöpfend oder um die Erfindung auf die offenbarten Formen einzuschränken beabsichtigt. Demzufolge ist nicht beabsichtigt, dass die obige Offenbarung die Erfindung einschränkt; der Umfang der Erfindung ist durch die beigefügten Ansprüche definiert.

Claims (30)

  1. Verfahren zur Identifizierung einer Kommunikationsverbindung zwischen zwei Endentitäten aus einem an einer Netzwerkschnittstelle einer der Entitäten empfangenen Paket, aufweisend: Empfangen (132) eines Pakets an einer Netzwerkschnittstelle, wobei das Paket einen Teil einer Kommunikationsverbindung zwischen einer Ursprungsentität und einer Zielentität gekoppelt an die Netzwerkschnittstelle aufweist; Parsen (134) eines Kopfabschnitts des Pakets, um Folgendes aufzufinden: eine Ursprungskennung, die die Ursprungsidentität identifiziert; eine Zielkennung, die die Zielentität identifiziert; eine Sequenznummer; und einen Nutzinformations-Größenindikator, der ausgebildet ist, anzugeben, ob ein Datenabschnitt des Pakets eine festgelegte Größe übersteigt; Zusammenfügen (426) der Ursprungskennung und der Zielkennung, um einen Schlüssel zur Identifizierung der Kommunikationsverbindung zu bilden; gekennzeichnet durch das Zusammenfügen (428) der Sequenznummer und des Nutzinformations-Größenindikators, um einen Steuerindikator zur Angabe eines Status des Pakets zu bilden.
  2. Verfahren nach Anspruch 1, wobei die festgelegte Größe gleich der maximalen Übertragungseinheit der Netzwerkschnittstelle ist.
  3. Verfahren nach Anspruch 1, wobei die festgelegte Größe Null ist.
  4. Verfahren nach Anspruch 1, wobei der Nutzinformations-Größenindikator eine Datenmenge in dem Paket angibt.
  5. Verfahren nach Anspruch 1, ferner aufweisend Identifizierung eines Beginns eines Abschnitts des Pakets, für welches eine Prüfsumme zu berechnen ist.
  6. Verfahren nach Anspruch 1, ferner aufweisend die Bestimmung, ob das Paket einem aus einer Menge festgelegter Kommunikationsprotokolle entspricht.
  7. Verfahren nach Anspruch 1, ferner aufweisend das Kopieren (402) eines Kopfabschnitts des Pakets in einen ersten Speicher, wobei der Kopfabschnitt einen ersten Kopfbereich entsprechend einem ersten Kommunikationsprotokoll aufweist.
  8. Verfahren nach Anspruch 7, ferner aufweisend die Erzeugung (430) eines Signals, wenn das erste Kommunikationsprotokoll nicht eines der Menge festgelegter Kommunikationsprotokolle ist.
  9. Verfahren nach Anspruch 1, ferner aufweisend Beendigung (430) des Parsens, wenn während des Parsens bestimmt wird, dass das Paket keinem der Menge festgelegter Kommunikationsprotokolle entspricht.
  10. Verfahren nach Anspruch 1, wobei die Ursprungskennung einen Ursprungs-Port und/oder eine Ursprungsadresse enthält.
  11. Verfahren nach Anspruch 1, wobei die Zielkennung einen Ziel-Port und/oder eine Zieladresse enthält.
  12. Verfahren nach Anspruch 1, wobei das Parsen ferner das Auffinden einer Menge von Transportsteuer-Merkern umfasst.
  13. Verfahren nach Anspruch 12, wobei die Transportsteuer-Merker URG, PSH, RST, SYN und FIN umfassen.
  14. Verfahren nach Anspruch 1, wobei das Parsen (134) umfasst: Untersuchung des Kopfabschnitts, um ein erstes Protokoll zu identifizieren, das zur Übertragung des Pakets verwendet wird; und Untersuchung des Kopfabschnitts, um ein zweites Protokoll zu identifizieren, das zur Übertragung des Pakets verwendet wird.
  15. Verfahren nach Anspruch 1, wobei das Zusammenfügen (426) der Ursprungskennung und der Zielkennung das Aneinanderfügen der Ursprungskennung und der Zielkennung umfasst.
  16. Verfahren nach Anspruch 1, ferner aufweisend: Verwendung des Schlüssels, um eine Kommunikationsverbindungsdatenbank bezüglich eines Eintrages entsprechend der Kommunikationsverbindung zu durchsuchen; und wenn der entsprechende Eintrag gefunden wird, Aktualisierung des entsprechenden Eintrags.
  17. Verfahren nach Anspruch 16, wobei die Aktualisierung die Modifizierung des entsprechenden Eintrags umfasst, um anzugeben, dass die Kommunikationsverbindung gültig ist.
  18. Verfahren nach Anspruch 16, ferner aufweisend Eingabe der Kommunikationsverbindung in die Kommunikationsverbindungs-Datenbank, wenn kein entsprechender Eintrag gefunden wird.
  19. Kommunikationsschnittstelle (100) aufweisend: einen ersten Speicher (302), der ausgebildet ist, einen Kopfabschnitt eines von einem Netzwerk empfangenen Pakets zu speichern; und einen Parser (304), ausgebildet, den Kopfabschnitt in Übereinstimmung mit einem Satz Befehlen zu parsen, um Folgendes aufzufinden: eine Ursprungskennung, die einen Ursprung des Pakets identifiziert; eine Zielkennung, die ein Ziel des Pakets identifiziert; eine Sequenznummer; und einen Nutzinformations-Größenindikator, der ausgebildet ist, anzugeben, ob ein Datenabschnitt des Pakets eine festgelegte Größe übersteigt; wobei die Ursprungskennung und die Zielkennung zusammengefügt werden, um einen Schlüssel zur Identifizierung eines Kommunikationsflusses aufweisend das Paket zu bilden; dadurch gekennzeichnet, dass die Sequenznummer und der Nutzinformations-Größenindikator verwendet werden, um einen Steuerindikator zu erzeugen, um einen Status des Pakets anzugeben.
  20. Kommunikationsschnittstelle nach Anspruch 19, ferner aufweisend einen zweiten Speicher (306), der ausgebildet ist, den Befehlssatz zum Parsen des Kopfabschnitts zu speichern.
  21. Kommunikationsschnittstelle nach Anspruch 20, wobei der Parser (304) den zweiten Speicher aufweist.
  22. Kommunikationsschnittstelle nach Anspruch 20, wobei der erste Speicher (302) den zweiten Speicher aufweist.
  23. Kommunikationsschnittstelle nach Anspruch 19, ferner aufweisend einen Signalisierungskanal, wobei der Signalisierungskanal aktiviert wird, wenn der Kopfabschnitt einem anderen Kommunikationsprotokoll als dem Satz festgelegter Kommunikationsprotokolle entspricht.
  24. Kommunikationsschnittstelle nach Anspruch 19, ferner aufweisend eine Kommunikationsfluß-Datenbank (110), die ausgebildet ist, einen Status des Kommunikationsflußes zu speichern.
  25. Kommunikationsschnittstelle nach Anspruch 19, wobei: die Ursprungskennung eine Ursprungsadresse und/oder einen Ursprungs-Port enthält; und die Zielerkennung eine Zieladresse und/oder einen Ziel-Port enthält.
  26. Kommunikationsschnittstelle nach Anspruch 19, wobei die festgelegte Größe gleich der maximalen Übertragungseinheit der Netzwerkschnittstelle ist.
  27. Kommunikationsschnittstelle nach Anspruch 19, wobei die festgelegte Größe Null ist.
  28. Kommunikationsschnittstelle nach Anspruch 19, wobei der Nutzinformations-Größenindikator eine Datenmenge in dem Paket angibt.
  29. Computerprogramm, welches, wenn es auf einem Computer oder einem Computernetzwerk abläuft, ausgebildet ist, das Verfahren nach einem der Ansprüche 1 bis 18 auszuführen.
  30. Computerprogramm nach Anspruch 29, enthalten auf einem maschinenlesbaren Speichermedium.
DE60009884T 1999-03-01 2000-02-29 Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle Expired - Lifetime DE60009884T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US26061899A 1999-03-01 1999-03-01
US260618 1999-03-01
PCT/US2000/005307 WO2000052869A2 (en) 1999-03-01 2000-02-29 Method and apparatus for identifying and classifying network traffic in a high performance network interface

Publications (2)

Publication Number Publication Date
DE60009884D1 DE60009884D1 (de) 2004-05-19
DE60009884T2 true DE60009884T2 (de) 2005-04-07

Family

ID=22989895

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60009884T Expired - Lifetime DE60009884T2 (de) 1999-03-01 2000-02-29 Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle

Country Status (5)

Country Link
EP (1) EP1163777B1 (de)
JP (1) JP2002538721A (de)
AU (1) AU4005100A (de)
DE (1) DE60009884T2 (de)
WO (1) WO2000052869A2 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7860120B1 (en) 2001-07-27 2010-12-28 Hewlett-Packard Company Network interface supporting of virtual paths for quality of service with dynamic buffer allocation
US20040039940A1 (en) * 2002-08-23 2004-02-26 Koninklijke Philips Electronics N.V. Hardware-based packet filtering accelerator
US7724740B1 (en) 2002-08-27 2010-05-25 3Com Corporation Computer system and network interface supporting class of service queues
US7307998B1 (en) 2002-08-27 2007-12-11 3Com Corporation Computer system and network interface supporting dynamically optimized receive buffer queues
US7894480B1 (en) 2002-08-27 2011-02-22 Hewlett-Packard Company Computer system and network interface with hardware based rule checking for embedded firewall
US8296452B2 (en) * 2003-03-06 2012-10-23 Cisco Technology, Inc. Apparatus and method for detecting tiny fragment attacks
US7774506B2 (en) 2003-08-19 2010-08-10 Cisco Technology, Inc. Systems and methods for alleviating client over-subscription in ring networks
GB0404696D0 (en) 2004-03-02 2004-04-07 Level 5 Networks Ltd Dual driver interface
GB0408868D0 (en) * 2004-04-21 2004-05-26 Level 5 Networks Ltd Checking data integrity
GB0420057D0 (en) 2004-09-09 2004-10-13 Level 5 Networks Ltd Dynamic resource allocation
GB0506403D0 (en) 2005-03-30 2005-05-04 Level 5 Networks Ltd Routing tables
EP3217285B1 (de) 2005-03-10 2021-04-28 Xilinx, Inc. Datenübertragung
GB0505300D0 (en) 2005-03-15 2005-04-20 Level 5 Networks Ltd Transmitting data
GB0600417D0 (en) 2006-01-10 2006-02-15 Level 5 Networks Inc Virtualisation support
US20120106555A1 (en) * 2010-11-01 2012-05-03 Indian Institute Of Technology Bombay Low latency carrier class switch-router
US11483245B2 (en) 2018-09-13 2022-10-25 Intel Corporation Technologies for filtering network traffic on ingress
US11159654B2 (en) * 2019-11-13 2021-10-26 Ge Aviation Systems Llc Method and system for data transfer on an avionics bus
CN113890904B (zh) * 2021-09-27 2023-10-27 新华三信息安全技术有限公司 一种报文解析的方法、装置、计算机设备及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2686755A1 (fr) * 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
EP0689748B1 (de) * 1993-03-20 1998-09-16 International Business Machines Corporation Verfahren und vorrichtung zur herausarbeitung der vermittlungsinformation aus dem kopfteil eines protokolls
US5748905A (en) * 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys

Also Published As

Publication number Publication date
AU4005100A (en) 2000-09-21
WO2000052869A3 (en) 2001-01-04
DE60009884D1 (de) 2004-05-19
EP1163777B1 (de) 2004-04-14
WO2000052869A2 (en) 2000-09-08
JP2002538721A (ja) 2002-11-12
EP1163777A2 (de) 2001-12-19

Similar Documents

Publication Publication Date Title
DE60031516T2 (de) Verfahren und gerät für die verwaltung eines netzflusses in einer hochleistungs-netzschnittstelle
DE60009884T2 (de) Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle
DE60016574T2 (de) Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen
DE60019401T2 (de) Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle
DE60021358T2 (de) Eine hoch-leistungs-netzschnittstelle
DE60015186T2 (de) Verfahren und system für rahmen- und protokollklassifikation
DE60305378T2 (de) Verfahren zum Weitergeben von einem Netzwerkstapel
DE60202136T2 (de) Cache-eintrag-auswahlverfahren und -vorrichtung
DE60221030T2 (de) Verfahren, einrichtung und rechnerprogramm für die entkapselung und verkapselung von paketen mit mehreren kopffeldern
DE69434330T2 (de) Übertragungsvorrichtgung und verfahren
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE112008002550B4 (de) Verfahren und System für virtuelle Schnittstellenkommunikation
DE69628512T2 (de) Kompakter, anpassbarer Uberbrückungs-/Leitweglenkungsvermittlungsschalter
DE60026676T2 (de) Paketklassifizierungsautomat
DE60311677T2 (de) Verfahren und vorrichtung zur durchführung von netzwerkverarbeitungsfunktionen
DE69830491T2 (de) Cut-through -durchschaltung und paketfilterung in einem rechnersystem
DE60027404T2 (de) Kreditbasiertes flusskontrollverfahren
DE60305035T2 (de) Anpassen des längsten präfix unter verwendung von baumartigen "bitmap" datenstrukturen
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE60213509T2 (de) Verfahren und Vorrichtung zur Verbesserung der Verfügbarkeit von Wegeleitsystemen mit mehrwege-Kostengleichheit
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE60130367T2 (de) Verfahren zum dynamischen mischen von Paketkopfunterdrückungstechniken
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE60309527T2 (de) System und Verfahren zur Identifikation von Grenzen von Nachrichten höherer Schichten
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition