DE60031516T2

DE60031516T2 - Verfahren und gerät für die verwaltung eines netzflusses in einer hochleistungs-netzschnittstelle

Info

Publication number: DE60031516T2
Application number: DE60031516T
Authority: DE
Inventors: Shimon Sunnyvale Muller; Denton Fremont GENTRY
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-03-01
Filing date: 2000-02-29
Publication date: 2007-08-09
Anticipated expiration: 2020-03-01
Also published as: AU3248200A; WO2000052896A3; JP2002538730A; US6650640B1; DE60031516D1; EP1715631A1; EP1166520B1; EP1166520A2; WO2000052896A2

Description

HINTERGRUND
Diese Erfindung bezieht sich auf die Gebiete von Computersystemen und Computernetzen. Insbesondere bezieht sich die vorliegende Erfindung auf eine Netzschnittstellenschaltung (NIC) zum Verarbeiten von Kommunikationspaketen, die zwischen einem Computernetz und einem Host-Computersystem ausgetauscht werden.
Die Schnittstelle zwischen einem Computer und einem Netz ist häufig ein Engpass für Kommunikationen, die zwischen dem Computer und dem Netz laufen. Obwohl die Computerleistung (z. B. Prozessorgeschwindigkeit) über die Jahre exponentiell zugenommen hat und die Computernetz-Übertragungsgeschwindigkeiten ähnliche Steigerungen erfahren haben, wurden Ineffizienzen in der Weise, in der die Netzschnittstellenschaltungen Kommunikationen bearbeiten, immer offensichtlicher. Mit jeder inkrementalen Zunahme der Computer- oder Netzgeschwindigkeit wird es immer ersichtlicher, dass die Schnittstelle zwischen dem Computer und dem Netz nicht Schritt halten kann. Diese Ineffizienzen beinhalten mehrere Basisprobleme in der Weise, in der Kommunikationen zwischen einem Netz und einem Computer bearbeitet werden.
Die heutigen populärsten Formen von Netzen sind gewöhnlich paketbasiert. Diese Arten von Netzen, einschließlich des Internets und vieler lokaler Netze, übertragen Informationen in Form von Paketen. Jedes Paket wird separat durch eine Ursprungsendstation erzeugt und übertragen und wird von einer Zielendstation separat empfangen und verarbeitet. Außerdem kann jedes Paket beispielsweise in einem Bustopologienetz von zahlreichen Stationen empfangen und verarbeitet werden, die sich zwischen der Ursprungs- und der Zielendstation befinden.
Ein Grundproblem bei Paketnetzen besteht darin, dass jedes Paket durch mehrere Protokolle oder Protokollschichten (gemeinsam als "Protokollprofil" bekannt) sowohl an der Ursprungs- als auch Zielendstation verarbeitet werden muss. Wenn zwischen Stationen übertragene Daten länger sind als eine gewisse minimale Länge, werden die Daten in mehrere Abschnitte unterteilt und jeder Abschnitt wird durch ein separates Paket getragen. Die Menge an Daten, die ein Paket tragen kann, ist im Allgemeinen durch das Netz begrenzt, das das Paket befördert, und wird häufig als maximale Übertragungseinheit (MTU) ausgedrückt. Die ursprüngliche Zusammenfassung von Daten ist manchmal als "Datagramm" bekannt, wobei jedes Paket, das einen Teil eines einzelnen Datagramms trägt, sehr ähnlich zu den anderen Paketen des Datagramms verarbeitet wird.
Kommunikationspakete werden im Allgemeinen folgendermaßen verarbeitet. In der Ursprungsendstation wird jeder separate Datenabschnitt eines Datagramms durch ein Protokollprofil 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 von einer Netzschnittstellenschaltung empfangen, die das Paket zur Zielendstation oder zu einem Host-Computer überträgt, der der Zielendstation dient. In der Zielendstation wird das Paket durch das Protokollprofil in der entgegengesetzten Richtung wie in der Ursprungsendstation verarbeitet. Während dieser Verarbeitung werden die Protokollköpfe in der entgegengesetzten Reihenfolge, in der sie angebracht wurden, entfernt. Der Datenabschnitt wird somit wiedergewonnen und kann für einen Benutzer, ein Anwendungsprogramm usw. verfügbar gemacht werden.
Mehrere in Beziehung stehende Pakete (z. B. Pakete, die Daten von einem Datagramm tragen) werden folglich im Wesentlichen demselben Prozess in einer seriellen Weise (d. h. ein Paket auf einmal) unterzogen. Je mehr Daten übertragen werden müssen, desto mehr Pakete müssen gesandt werden, wobei jedes durch das Protokollprofil in jeder Richtung separat gehandhabt und verarbeitet wird. Je mehr Pakete verarbeitet werden müssen, desto größer ist natürlich die dem Prozessor einer Endstation auferlegte Anforderung. Die Anzahl von Paketen, die verarbeitet werden müssen, wird durch andere Faktoren als nur die Menge an gesandten Daten in einem Datagramm beeinflusst. Wenn die Menge an Daten, die in ein Paket eingekapselt werden können, zunimmt, müssen beispielsweise weniger Pakete gesandt werden. Wie vorstehend angegeben, kann jedoch ein Paket eine maximale zulässige Größe in Abhängigkeit von der Art des verwendeten Netzes besitzen (z. B. ist die maximale Übertragungseinheit für Standard-Ethernet-Verkehr ungefähr 1500 Bytes). Die Geschwindigkeit des Netzes beeinflusst auch die Anzahl von Paketen, die eine NIC in einem gegebenen Zeitraum bearbeiten kann. Ein Gigabit-Ethernet-Netz, das mit einer Spitzenkapazität arbeitet, kann beispielsweise erfordern, dass eine NIC ungefähr 1,48 Millionen Pakete pro Sekunde empfängt. Folglich kann die Anzahl von durch ein Protokollprofil zu verarbeitenden Paketen dem Prozessor eines Computers eine signifikante Belastung auferlegen. Die Situation wird durch den Bedarf, jedes Paket separat zu verarbeiten, selbst wenn jedes in einer im Wesentlichen ähnlichen Weise verarbeitet wird, verschlimmert.
Ein zugehöriges Problem zur getrennten Verarbeitung von Paketen ist die Weise, in der Daten zwischen dem "Benutzerraum" (z. B. einem Datenspeicher eines Anwendungsprogramms) und dem "Systemraum" (z. B. Systemspeicher) während der Datenübertragung und des Datenempfangs bewegt werden. Derzeit werden Daten einfach von einem Speicherbereich, der einem Benutzer oder Anwendungsprogramm zugeordnet ist, in einen anderen Speicherbereich, der für die Verwendung des Prozessors zweckgebunden ist, kopiert. Da jeder Abschnitt eines Datagramms, das in einem Paket übertragen wird, separat kopiert werden kann (z. B. ein Byte auf einmal), ist eine nicht geringfügige Menge an Prozessorzeit erforderlich, und häufige Übertragungen können eine große Menge der Speicherbausbandbreite verbrauchen. Erläuternd kann jedes Byte von Daten in einem Paket, das vom Netz empfangen wird, vom Systemraum gelesen werden und in einer separaten Kopieroperation in den Benutzerraum geschrieben werden, und umgekehrt für über das Netz übertragene Daten. Obwohl der Systemraum im Allgemeinen einen geschützten Speicherbereich (z. B. vor Manipulation durch Benutzerprogramme geschützt) bereitstellt, macht die Kopieroperation vom Gesichtspunkt einer Netzschnittstellenschaltung gesehen nichts wertvolles. Statt dessen riskiert sie eine Überlastung des Host-Prozessors und die Verlangsamung seiner Fähigkeit, zusätzlichen Netzverkehr von der NIC schnell anzunehmen. Das separate Kopieren der Daten jedes Pakets kann daher sehr ineffizient sein, insbesondere in einer Hochgeschwindigkeits-Netzumgebung.
Zusätzlich zur ineffizienten Datenübertragung (z. B. Daten eines Pakets auf einmal) ist die Verarbeitung von Köpfen von Paketen, die von einem Netz empfangen werden, auch ineffizient. Jedes Paket, das einen Teil eines einzelnen Datagramms trägt, besitzt im Allgemeinen dieselben Protokollköpfe (z. B. Ethernet, IP und TCP), obwohl eine gewisse Variation in den Werten innerhalb der Köpfe der Pakete für ein spezielles Protokoll bestehen kann. Jedes Paket wird jedoch einzeln durch dasselbe Protokollprofil verarbeitet, was folglich mehrere Wiederholungen von identischen Operationen von in Beziehung stehenden Paketen erfordert. Die aufeinander folgende Verarbeitung von nicht in Beziehung stehenden Paketen durch verschiedene Protokollprofile ist wahrscheinlich viel weniger effizient als die progressive Verarbeitung einer Anzahl von in Beziehung stehenden Paketen durch ein Protokollprofil auf einmal.
Ein weiteres Grundproblem hinsichtlich der Wechselwirkung zwischen derzeitigen Netzschnittstellenschaltungen und Host-Computersystemen besteht darin, dass es der Kombination häufig misslingt, aus den erhöhten Prozessorressourcen, die in Computersystemen mit mehreren Prozessoren zur Verfügung stehen, Kapital zu schlagen. Mit anderen Worten, derzeitige Versuche, die Verarbeitung von Netzpaketen (z. B. durch ein Protokollprofil) unter einer Anzahl von Protokollen in einer effizienten Weise zu verteilen, sind im Allgemeinen unwirksam. Insbesondere kommt die Leistung von derzeitigen NICs nicht nahe an die erwarteten oder gewünschten linearen Leistungsgewinne, deren Verwirklichung durch die Verfügbarkeit von mehreren Prozessoren erwartet werden kann. In einigen Systemen mit mehreren Prozessoren wird eine geringe Verbesserung in der Verarbeitung von Netzverkehr durch die Verwendung von beispielsweise mehr als 4–6 Prozessoren verwirklicht.
Außerdem kann es der Rate, mit der Pakete von einer Netzschnittstellenschaltung zu einem Host-Computer oder einer anderen Kommunikationsvorrichtung übertragen werden, misslingen, mit der Rate der Paketankunft an der Netzschnittstelle Schritt zu halten. Das eine oder andere Element des Host-Computers (z. B. ein Speicherbus, ein Prozessor) kann überlastet oder anderweitig außerstande sein, Pakete mit ausreichender Bereitwilligkeit 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 gewissen Verkehr erneut überträgt, und, wenn zu viele Pakete fallen gelassen werden, kann eine Netzverbindung eine erneute Initialisierung erfordern. Ferner kann das Fallenlassen von einem Paket oder einer Art von Paket anstelle einer anderen einen signifikanten Unterschied im Gesamtnetzverkehr machen. Wenn beispielsweise ein Steuerpaket fallen gelassen wird, kann die entsprechende Netzverbindung stark beeinträchtigt werden und kann aufgrund der typischerweise kleinen Größe eines Steuerpakets wenig tun, um die Paketsättigung der Netzschnittstellenschaltung zu mildern. Wenn nicht das Fallenlassen von Paketen in einer Weise durchgeführt wird, die die Wirkung unter vielen Netzverbindungen verteilt oder die bestimmte Arten von Paketen berücksichtigt, kann der Netzverkehr daher mehr als erforderlich verschlechtert werden.
Folglich misslingt es derzeitigen NICs, eine angemessene Leistung zu schaffen, um heutige Computersysteme des oberen Bereichs und Hochgeschwindigkeitsnetze miteinander zu verbinden. Außerdem kann eine Netzschnittstellenschaltung, die keinen überlasteten Host-Computer berücksichtigen kann, die Leistung des Computers verschlechtern.
"IP Switching and Gigabit Routers", von Peter Newman, et al., IEEE Communications Magazine, Band 35, Nr. 1, 1997, S. 64–69, überprüft Gigabit-Router und IP-Vermittlungsstellen zum Lenken von IP-Verkehr. IP-Vermittlungsstellen lenken Verkehr auf der Basis von Flüssen, deren Handhabung durch das erste Paket im Fluss bestimmt wird.
"IETF Multiprotocol Label Switching (MPLS) Architecture" von Francois Le Faucheur, IEEE International Conference on ATM, 22. Juni 1998, S. 6–15, erörtert die Verwendung der MPLS-Technologie, um ein Protokoll der Ebene 3 über irgendeine Technologie der Ebene 2 zu transportieren. Bei MPLS werden Pakete bezeichnet, um den Kommunikationsstrom, zu dem sie gehören, zu identifizieren. Eine Bezeichnung eines Pakets wird an Vermittlungspunkten verwendet, um den nächsten Hop des Pakets zu bestimmen.
WO 97 28505 A offenbart ein Verfahren und eine Vorrichtung zum dynamischen Verschieben zwischen der Lenkung und Vermittlung von Paketen. Wenn Pakete an einem Stromabwärtsknoten empfangen werden, werden sie klassifiziert, um festzustellen, ob sie zu einem Fluss gehören, der umgelenkt werden sollte. Wenn ja, wird der Stromaufwärtsknoten mit einer freien Bezeichnung versehen, die an Paketen in diesem Fluss angebracht werden soll.
"RFC 1932: IP over ATM: A Framework Document" von R. Cole, et al., IETF Network Working Group, hppt://hlapic.srce.hr/cgi-bin/rfc/rfc1932.txt, April 1996, S. 1–31, erörtert Methoden zum Lenken von IP-Paketen über ATM-Unternetze. In einer verbindungsorientierten Methode werden virtuelle Kanäle aufgebaut, die auf der Basis eines Zeitgebers abgebrochen werden können.
US-A-5 684 954 offenbart ein Verfahren und eine Vorrichtung zur Verarbeitung von Feldern eines Protokollkopfs, der einem Datenstrom vorangeht, um einen Verbindungsidentifizierer zur Verarbeitung des Datenstroms zu erzeugen. Informationen vom Protokolltyp eines ersten Protokolls werden extrahiert und Informationen hinsichtlich Protokollen, die auf dem ersten Protokoll aufgebaut sind, werden dann gelesen. Das Protokoll und die Informationen vom Protokolltyp werden verwendet, um den Verbindungsidentifizierer zu erzeugen.
WO 99 00949 A offenbart ein Netzelement mit mehreren Schichten zum Weiterleiten von Paketen von einem Eingangsanschluss zu einem Ausgangsanschluss mit Dienstqualität. Pakete werden zufällig verworfen, wenn Ausgangswarteschlangen eine festgelegte Schwelle unter ihren Kapazitäten erreichen. Die Priorität eines Flusses, der verursacht, dass eine Warteschlange überläuft, wird verringert.
WO 99 00737 A offenbart ein System und ein Verfahren zum Aktualisieren von Paketköpfen. Ein Eingangsanschlussprozess (IPP) puffert ein Paket und liefert Kopfinformationen zu einer Suchmaschine. Die Suchmaschine versieht den IPP mit Informationen vom Pakettyp, die dann selektiv Felder der Paketköpfe ersetzen.
ZUSAMMENFASSUNG
In einer Ausführungsform der Erfindung werden ein System und ein Verfahren für das Management von Kommunikationsflüssen oder -verbindungen, die an einer Kommunikationsvorrichtung wie z. B. einer Netzschnittstelle empfangen werden, geschaffen. Insbesondere werden Kommunikationsflüsse aufgebaut und abgebrochen, wenn Netzverkehr an einer Netzschnittstelle empfangen wird. Informationen hinsichtlich eines Flusses werden für die Dauer des Flusses aufrechterhalten, um die Bestimmung der Eignung von Flusspaketen für bestimmte verbesserte Verarbeitungsoperationen zu unterstützen. Solche Operationen können beispielsweise für Pakete geeignet sein, die ein oder mehrere vorgewählte Kommunikationsprotokolle einhalten.
In dieser Ausführungsform der Erfindung umfasst eine Hochleistungs-Netzschnittstelle eine Flussdatenbank und ein Flussdatenbank-Managermodul. Eine Flussdatenbank enthält in dieser Ausführungsform einen Eintrag für jeden gültigen oder aktiven Kommunikationsfluss, der von der Netzschnittstelle empfangen wird. Jeder Fluss kann durch einen Flussschlüssel identifiziert werden, der im Datenbankeintrag des Flusses gespeichert ist, und kann durch eine Flussnummer indiziert werden.
Für jeden gültigen Fluss speichert die Flussdatenbank Informationen, die angeben, wie neu ein Paket für den Fluss empfangen wurde, und Folgeinformationen hinsichtlich eines Datagramms (z. B. eine Datensammlung, die über mehrere Pakete gesandt wird), das durch die Quellentität zur Zielentität geleitet wird. Die Folgeinformationen können verwendet werden, um den korrekten Empfang von Daten im Fluss zu überprüfen.
Ein Kommunikationsfluss in dieser Ausführungsform umfasst ein oder mehrere Pakete, die von einer Quellentität zu einer Zielentität gesandt werden, die von der Netzschnittstelle bedient wird. Ein Fluss ist folglich zu einer TCP-Verbindung (Transportsteuerprotokoll-Verbindung) von Ende zu Ende ähnlich, aber nicht identisch. Erläuternd umfasst ein Flussschlüssel eine Kombination von Identifizierern der Quell- und der Zielentität. In einer Ausführungsform der Erfindung ist ein Flussschlüssel eine Kombination von Quell- und Zieladressen, die vom Protokollkopf der Schicht drei des Pakets (z. B. IP oder Internetprotokoll) extrahiert werden, und Quell- und Zielanschlussnummern, die vom Protokollkopf der Schicht vier (z. B. TCP) extrahiert werden.
Wenn ein Flusspaket an der Netzschnittstelle empfangen wird, empfängt ein Flussdatenbank-Manager den Flussschlüssel des Pakets. Der Flussschlüssel kann durch ein Kopf-Parser-Modul zusammengefügt werden, das einen Kopfabschnitt des Pakets syntaktisch analysiert. Der Flussdatenbank-Manager kann auch Steuerinformationen hinsichtlich des Pakets empfangen, wie z. B. eine Angabe der Größe eines Datenabschnitts des Pakets, eine Flussfolgenummer, die verwendet wird, um die Position der Paketdaten innerhalb des Datagramms zu identifizieren, einen Indikator des Status von einem oder mehreren Flags in dem (den) Kopf (Köpfen) des Pakets, usw. Unter Verwendung des Flussschlüssels wird die Flussdatenbank durchsucht und ein Datenbankeintrag wird im Fall eines neuen Flusses hinzugefügt oder aktualisiert, wenn der Fluss bereits existiert.
In einer Ausführungsform der Erfindung ordnet der Flussdatenbank-Manager einen Operationscode dem empfangenen Paket zu, um anzugeben, wie das Paket durch die Netzschnittstelle und/oder einen Host-Computer weiter verarbeitet werden kann. Der spezielle Operationscode, der für ein Paket zugewiesen wird, kann angeben, ob das Paket Daten enthält, die mit anderen im Fluss geleiteten Daten wieder zusammengefügt werden können, ob das Paket ein Steuerpaket ist oder andererseits ohne Daten ist, ob das Paket nicht durch eine spezielle Netzschnittstellenfunktion verarbeitet werden sollte (z. B. aufgrund eines Flag in einem Kopf des Pakets) usw.
Informationen, die vom Paket abgeleitet werden, einschließlich des Flussschlüssels und Steuerinformationen, können von anderen Abschnitten der Netzschnittstelle und/oder eines Host-Computersystems verwendet werden. Erläuternd können die Informationen verwendet werden, um von der Quellentität zur Zielentität gesandte Daten wieder zusammenzufügen, um gemeinsam mehrere Pakete von einem Fluss zu verarbeiten, um die Verarbeitung von Netzverkehr unter mehreren Prozessoren zu verteilen, um die Integrität des Pakets zu überprüfen (z. B. durch eine Prüfsumme) usw.
KURZBESCHREIBUNG DER FIGUREN
1A ist ein Blockdiagramm, das eine Netzschnittstellenschaltung (NIC) zum Empfangen eines Pakets von einem Netz gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
1B ist ein Ablaufplan, der ein Verfahren zum Betreiben der NIC von 1A, um ein von einem Netz empfangenes Paket zu einem Host-Computer zu übertragen, gemäß einer Ausführungsform der Erfindung demonstriert.
2 ist ein Diagramm eines über ein Netz übertragenen und an einer Netzschnittstellenschaltung empfangenen Pakets in einer Ausführungsform der Erfindung.
3 ist ein Blockdiagramm, das einen Kopf-Parser einer Netzschnittstellenschaltung zum syntaktischen Analysieren eines Pakets gemäß einer Ausführungsform der Erfindung darstellt.
4A–4B umfassen einen Ablaufplan, der ein Verfahren zum syntaktischen Analysieren eines von einem Netz empfangenen Pakets an einer Netzschnittstellenschaltung gemäß einer Ausführungsform der vorliegenden Erfindung demonstriert.
5 ist ein Blockdiagramm, das 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 darstellt.
7 ist ein Ablaufplan, der ein Verfahren zum Verteilen der Verarbeitung von Netzpaketen unter mehreren Prozessoren auf einem Host-Computer gemäß einer Ausführungsform der Erfindung demonstriert.
8 ist ein Diagramm einer Paketwarteschlange für eine Netzschnittstellenschaltung gemäß einer Ausführungsform der Erfindung.
9 ist ein Diagramm einer Steuerwarteschlange für eine Netzschnittstellenschaltung gemäß einer Ausführungsform der Erfindung.
10 stellt einen Satz von dynamischen Befehlen zum syntaktischen Analysieren eines Pakets gemäß einer Ausführungsform der Erfindung dar.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung wird dargestellt, um einem beliebigen Fachmann zu ermöglichen, die Erfindung durchzuführen und zu verwenden, und wird im Zusammenhang mit speziellen Anwendungen der Erfindung und ihren Anforderungen bereitgestellt. Verschiedene Modifikationen an den offenbarten Ausführungsformen sind für Fachleute leicht ersichtlich und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen und Anwendungen angewendet werden, ohne vom Gedanken und Schutzbereich der vorliegenden Erfindung abzuweichen. Folglich soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen begrenzt sein, sondern ihr ist der breiteste Schutzbereich zu gewähren, der mit den hierin offenbarten Prinzipien und Merkmalen konsistent ist.
Insbesondere werden Ausführungsformen der Erfindung nachstehend in Form einer Netzschnittstellenschaltung (NIC) beschrieben, die Kommunikationspakete empfängt, die gemäß bestimmten Kommunikationsprotokollen formatiert sind, die mit dem Internet kompatibel sind. Ein Fachmann wird jedoch erkennen, dass die vorliegende Erfindung nicht auf Kommunikationsprotokolle begrenzt ist, die mit dem Internet kompatibel sind, und leicht für die Verwendung mit anderen Protokollen und in anderen Kommunikationsvorrichtungen als einer NIC angepasst werden kann.
Die Programmumgebung, in der eine vorliegende Ausführungsform der Erfindung ausgeführt wird, beinhaltet erläuternd einen Universalcomputer oder eine Spezialvorrichtung wie z. B. einen in der Hand gehaltenen Computer. Details solcher Vorrichtungen (z. B. Prozessor, Speicher, Datenspeicher, Eingangs/Ausgangs-Anschlüsse und Anzeige) sind gut bekannt und werden der Deutlichkeit halber weggelassen.
Es sollte auch selbstverständlich sein, dass die Verfahren der vorliegenden Erfindung unter Verwendung einer Vielzahl von Technologien implementiert werden könnten. Die hierin beschriebenen Verfahren können beispielsweise in einer auf einem programmierbaren Mikroprozessor laufenden Software implementiert werden oder in einer Hardware unter Verwendung von entweder einer Kombination von Mikroprozessoren oder anderen speziell konstruierten anwendungsspezifischen integrierten Schaltungen, programmierbaren Logikvorrichtungen oder verschiedenen Kombinationen davon implementiert werden. Insbesondere können die hierin beschriebenen Verfahren durch eine Reihe von vom Computer ausführbaren Befehlen implementiert werden, die sich auf einem Speichermedium, wie z. B. einer Trägerwelle, einem Plattenlaufwerk oder einem anderen vom Computer lesbaren Medium, befinden.
Einleitung
In einer Ausführungsform der vorliegenden Erfindung ist eine Netzschnittstellenschaltung (NIC) so konfiguriert, dass sie Kommunikationspakete empfängt und verarbeitet, die zwischen einem Host-Computersystem und einem Netz wie z. B. dem Internet ausgetauscht werden. Insbesondere ist die NIC so konfiguriert, dass sie Pakete, die gemäß einem Protokollprofil formatiert sind (z. B. einer Kombination von Kommunikationsprotokollen), das von einem mit der NIC gekoppelten Netz unterstützt wird, empfängt und bearbeitet.
Ein Protokollprofil kann mit Bezug auf das ISO-OSI-Modellrahmenwerk (Modellrahmenwerk der International Standards Organization – Kommunikation offener Systeme) mit sieben Schichten beschrieben werden. Folglich umfasst ein erläuterndes Protokollprofil das Transportsteuerprotokoll (TCP) auf der Schicht vier, das Internetprotokoll (IP) auf der Schicht drei und das Ethernet auf der Schicht zwei. Für Erörterungszwecke kann der Begriff "Ethernet" hierin verwendet werden, um gemeinsam auf die standardisierte Spezifikation IEEE (Institute of Electrical and Electronics Engineers) 802.3 sowie die Version zwei der nicht standardisierten Form des Protokolls Bezug zu nehmen. Wenn verschiedene Formen des Protokolls unterschieden werden müssen, kann die Standardform durch Einschließen der Bezeichnung "802.3" identifiziert werden.
Weitere Ausführungsformen der Erfindung sind so konfiguriert, dass sie mit Kommunikationen arbeiten, die andere Protokollen einhalten, die derzeit sowohl bekannt (z. B. AppleTalk, IPX (Internetwork Packet Exchange) usw.) als auch unbekannt sind. Ein Fachmann wird erkennen, dass die durch diese Erfindung bereitgestellten Verfahren leicht für neue Kommunikationsprotokolle anpassbar sind.
Außerdem kann die nachstehend beschriebene Verarbeitung von Paketen an andren Kommunikationsvorrichtungen als einer NIC durchgeführt werden. Ein Modem, eine Vermittlungsstelle, ein Router oder ein anderer Kommunikationsanschluss oder eine andere Kommunikationsvorrichtung (z. B. seriell, parallel, USB, SCSI) kann beispielsweise ähnlich konfiguriert und betrieben werden.
In nachstehend beschriebenen Ausführungsformen der Erfindung empfängt eine NIC ein Paket von einem Netz zugunsten eines Host-Computersystems oder einer anderen Kommunikationsvorrichtung. Die NIC analysiert das Paket (z. B. durch Wiedergewinnen von bestimmten Feldern von einem oder mehreren seiner Protokollköpfe) und unternimmt eine Handlung, um die Effizienz zu erhöhen, mit der das Paket zu seiner Zielentität übertragen oder geliefert wird. Die Ausrüstung und die Verfahren, die nachstehend erörtert werden, um die Effizienz der Verarbeitung oder Übertragung von Paketen, die von einem Netz empfangen werden, zu erhöhen, können auch für Pakete verwendet werden, die sich in der Rückwärtsrichtung (d. h. von der NIC zum Netz) bewegen.
Ein Verfahren, das auf eingehenden Netzverkehr angewendet werden kann, beinhaltet das Untersuchen oder syntaktische Analysieren von einem oder mehreren Köpfen eines eingehenden Pakets (z. B. Köpfen für die Protokolle der Schicht zwei, drei und vier), um die Quell- und Zielentitäten des Pakets zu identifizieren und möglicherweise gewisse andere Informationen wiederzugewinnen. Unter Verwendung von Identifizierern der Kommunikationsentitäten als Schlüssel können Daten von mehreren Paketen zusammengefasst oder wieder zusammengefügt werden. Typischerweise wird ein zu einer Zielentität von einer Quellentität gesandtes Datagramm über mehrere Pakete übertragen. Das Zusammenfassen von Daten von mehreren in Beziehung stehenden Paketen (z. B. Paketen, die Daten von demselben Datagramm tragen) ermöglicht folglich, dass ein Datagramm wieder zusammengefügt und gemeinsam zu einem Host-Computer übertragen wird. Das Datagramm kann dann zur Zielentität in einer sehr effizienten Weise geliefert werden. Anstatt Daten von einem Paket auf einmal (und einem Byte auf einmal) in separaten "Kopier"-Operationen zu liefern, kann beispielsweise eine "Seitenwechsel"-Operation durchgeführt werden. Bei einem Seitenwechsel kann eine ganze Speicherseite von Daten zur Zielentität geliefert werden, möglicherweise im Austausch gegen eine leere oder unbenutzte Seite.
In einem weiteren Verfahren werden von einem Netz empfangene Pakete in eine Warteschlange gestellt, um auf die Übertragung zu einem Host-Computer zu warten. Während sie auf die Übertragung warten, können mehrere in Beziehung stehende Pakete für den Host-Computer identifiziert werden. Nachdem sie übertragen wurden, können sie vielmehr als Gruppe durch einen Host-Prozessor verarbeitet werden als seriell verarbeitet werden (z. B. eines auf einmal).
Noch ein weiteres Verfahren beinhaltet die Übermittlung einer Anzahl von in Beziehung stehenden Paketen zu einem einzelnen Prozessor eines Host-Computersystems mit mehreren Prozessoren. Durch Verteilen von zwischen verschiedenen Paaren von Quell- und Zielentitäten beförderten Paketen unter verschiedenen Prozessoren kann die Verarbeitung von Paketen durch ihre jeweiligen Protokollprofile verteilt werden, während dennoch Pakete in ihrer korrekten Reihenfolge gehalten werden.
Die vorstehend erörterten Verfahren zum Erhöhen der Effizienz, mit der Pakete verarbeitet werden, können eine Kombination von Hardware- und Softwaremodulen, die sich an einer Netzschnittstelle und/oder an einem Host-Computersystem befinden, beinhalten. In einer speziellen Ausführungsform analysiert ein syntaktisches Analysemodul an der NIC eines Host-Computers syntaktisch Kopfabschnitte von Paketen. Erläuternd umfasst das syntaktische Analysemodul eine Mikroablaufsteuereinheit, die gemäß einem Satz von austauschbaren Befehlen, die als Mikrocode gespeichert sind, arbeitet. Unter Verwendung von Informationen, die von den Paketen extrahiert werden, können mehrere Pakete von einer Quellentität zu einer Zielentität identifiziert werden. Ein Hardwarezusammenfügungsmodul an der NIC kann dann die Daten von den mehreren Paketen sammeln. Ein weiteres Hardwaremodul an der NIC ist dazu konfiguriert, in Beziehung stehende Pakete, die auf die Übertragung zum Host-Computer warten, zu erkennen, so dass sie vielmehr gemeinsam durch ein geeignetes Protokollprofil als seriell verarbeitet werden können. Die wieder zusammengefügten Daten und die Köpfe der Pakete können dann zum Host-Computer geliefert werden, so dass 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 umfasst, kann ein Lastverteiler (der auch in der Hardware an der NIC implementiert werden kann) einen Prozessor auswählen, um die Köpfe der mehreren Pakete durch ein Protokollprofil zu verarbeiten.
In einer weiteren Ausführungsform der Erfindung wird ein System bereitgestellt, um ein Paket von einer NIC zufällig zu verwerfen, wenn die NIC mit Paketen, die auf die Übertragung zu einem Host-Computer warten, gesättigt oder fast gesättigt ist.
Eine Ausführungsform einer Hochleistungs-Netzschnittstellenschaltung
1A stellt eine NIC 100 dar, die gemäß einer erläuternden Ausführungsform der Erfindung konfiguriert ist. Eine kurze Beschreibung des Betriebs und der Wechselwirkung der verschiedenen Module der NIC 100 in dieser Ausführungsform folgt.
Ein Kommunikationspaket kann an der NIC 100 vom Netz 102 durch ein Medienzugriffssteuermodul (MAC-Modul) (in 1A nicht gezeigt) empfangen werden. Das MAC-Modul führt eine Verarbeitung des Pakets niedriger Ebene wie z. B. Lesen des Pakets vom Netz, Durchführen irgendeiner Fehlerprüfung, Erfassen von Paketfragmenten, Erfassen von übergroßen Paketen, Entfernen der Präambel der Schicht eins usw. durch.
Ein Eingangsanschluss-Verarbeitungsmodul (IPP-Modul) 104 empfängt dann das Paket. Das IPP-Modul speichert das ganze Paket in der Paketwarteschlange 116, wie vom MAC-Modul oder Netz empfangen, und ein Abschnitt des Pakets wird in den Kopf-Parser 106 kopiert. In einer Ausführungsform der Erfindung kann das IPP-Modul 104 als Koordinator von Arten wirken, um das Paket auf die Übertragung zu einem Host-Computersystem vorzubereiten. In einer solchen Rolle kann das IPP-Modul 104 Informationen hinsichtlich eines Pakets von verschiedenen Modulen der NIC 100 empfangen und solche Informationen zu anderen Modulen verteilen.
Der Kopf-Parser 106 analysiert einen Kopfabschnitt des Pakets syntaktisch, um verschiedene Informationsstücke wiederzugewinnen, die verwendet werden, um in Beziehung stehende Pakete (z. B. mehrere Pakete von einer gleichen Quellentität für eine Zielentität) zu identifizieren, und die sich auf die anschließende Verarbeitung der Pakete auswirken. In der dargestellten Ausführungsform kommuniziert der Kopf-Parser 106 mit dem Flussdatenbank-Manager (FDBM) 108, der die Flussdatenbank (FDB) 110 managt. Insbesondere übermittelt der Kopf-Parser 106 eine Abfrage zum FDBM 108, um festzustellen, ob ein gültiger Kommunikationsfluss (nachstehend beschrieben) zwischen der Quellentität, die ein Paket gesandt hat, und der Zielentität existiert. Die Zielentität kann ein Anwendungsprogramm, ein Kommunikationsmodul oder irgendein anderes Element eines Host-Computersystems, das das Paket empfangen soll, umfassen.
In der dargestellten Ausführungsform der Erfindung umfasst ein Kommunikationsfluss ein oder mehrere Datagramm-Pakete von einer Quellentität zu einer Zielentität. Ein Fluss kann durch einen Flussschlüssel identifiziert werden, der von Quell- und Zielidentifizierern zusammengefügt wird, die vom Paket durch den Kopf-Parser 106 wiedergewonnen werden. In einer Ausführungsform der Erfindung umfasst ein Flussschlüssel Adressen- und/oder Anschlussinformationen für die Quell- und Zielentitäten von den Protokollköpfen der Schicht drei (z. B. IP) und/oder Schicht vier (z. B. TCP) des Pakets.
Für die Zwecke der dargestellten Ausführungsform der Erfindung ist ein Kommunikationsfluss ähnlich einer TCP-Verbindung von Ende zu Ende, ist jedoch im Allgemeinen in der Dauer kürzer. Insbesondere kann in dieser Ausführungsform die Dauer eines Flusses auf die Zeit begrenzt sein, die erforderlich ist, um alle Pakete zu empfangen, die einem einzelnen Datagramm zugeordnet sind, das von der Quellentität zur Zielentität geleitet wird.
Für die Zwecke des Fluss-Managements leitet folglich der Kopf-Parser 106 den Flussschlüssel des Pakets zum Flussdatenbank-Manager 108. Der Kopf-Parser kann auch den Flussdatenbank-Manager mit anderen Informationen hinsichtlich des Pakets, die vom Paket wiedergewonnen wurden (z. B. Länge des Pakets), versehen.
Der Flussdatenbank-Manager 108 durchsucht die FDB 110 in Reaktion auf eine Abfrage, die vom Kopf-Parser 106 empfangen wird. Erläuternd speichert die Flussdatenbank 110 Informationen hinsichtlich jedes gültigen Informationsflusses, der eine Zielentität beinhaltet, die von der NIC 100 bedient wird. Folglich aktualisiert der FDBM 108 die FDB 110 nach Bedarf in Abhängigkeit von den vom Kopf-Parser 106 empfangenen Informationen. Außerdem ordnet in dieser Ausführungsform der Erfindung der FDBM 108 einen Operations- oder Handlungscode dem empfangenen Paket zu. Ein Operationscode kann verwendet werden, um zu identifizieren, ob ein Paket ein Teil eines neuen oder existierenden Flusses ist, ob das Paket Daten oder nur Steuerinformationen enthält, die Menge an Daten innerhalb des Pakets, ob die Paketdaten mit zugehörigen Daten (z. B. anderen Daten in einem von der Quellentität zur Zielentität gesandten Datagramm) wieder zusammengefügt werden können, usw. Der FDBM 108 kann Informationen verwenden, die vom Paket wiedergewonnen werden und vom Kopf-Parser 106 geliefert werden, um einen geeigneten Operationscode auszuwählen. Der Operationscode des Pakets wird dann zum Kopf-Parser zusammen mit einem Index des Flusses des Pakets innerhalb der FDB 110 zurückgeleitet.
In einer Ausführungsform der Erfindung kann die Kombination des Kopf-Parsers 106, des FDBM 108 und der FDB 110 oder eine Teilmenge dieser Module aufgrund ihrer Rolle beim Klassifizieren oder Identifizieren von Netzverkehr, der an der NIC 100 empfangen wird, als Verkehrsklassifizierer bekannt sein.
In der dargestellten Ausführungsform leitet der Kopf-Parser 106 auch den Flussschlüssel des Pakets zu einem Lastverteiler 112. In einem Host-Computersystem mit mehreren Prozessoren kann der Lastverteiler 112 bestimmen, zu welchem Prozessor ein eingehendes Paket für die Verarbeitung durch das geeignete Protokollprofil gelenkt werden soll. Der Lastverteiler 112 kann beispielsweise sicherstellen, dass in Beziehung stehende Pakete zu einem einzelnen Prozessor gelenkt werden. Durch Senden aller Pakete in einem Kommunikationsfluss oder einer Verbindung von Ende zu Ende zu einem einzelnen Prozessor kann eine korrekte Reihenfolge der Pakete erzwungen werden. Der Lastverteiler 112 kann in einer alternativen Ausführungsform der Erfindung weggelassen werden. In einer alternativen Ausführungsform kann der Kopf-Parser 106 auch direkt mit anderen Modulen der NIC 100 neben dem Lastverteiler und dem Flussdatenbank-Manager kommunizieren.
Nachdem der Kopf-Parser 106 ein Paket syntaktisch analysiert, ändert oder aktualisiert der FDBM 108 folglich die FDB 110 und der Lastverteiler 112 identifiziert einen Prozessor im Host-Computersystem, um das Paket zu verarbeiten. Nach diesen Handlungen leitet der Kopf-Parser verschiedene Informationen zum IPP-Modul 104 zurück. Erläuternd können diese Informationen den Flussschlüssel des Pakets, einen Index des Flusses des Pakets innerhalb der Flussdatenbank 110, einen Identifizierer eines Prozessors im Host-Computersystem und verschiedene andere Daten hinsichtlich des Pakets (z. B. seine Länge, eine Länge eines Paketkopfs) umfassen.
Nun kann das Paket in der Paketwarteschlange 116 gespeichert werden, die Pakete für die Bearbeitung durch die DMA-Maschine (Direktspeicherzugriffs-Maschine) 120 hält und zu einem Host-Computer überträgt. Zusätzlich zum Speichern des Pakets in einer Paketwarteschlange wird ein entsprechender Eintrag für das Paket in der Steuerwarteschlange 118 durchgeführt und Informationen hinsichtlich des Flusses des Pakets können auch zum dynamischen Paketstapelverarbeitungsmodul 122 geleitet werden. Die Steuerwarteschlange 118 enthält in Beziehung stehende Steuerinformationen für jedes Paket in der Paketwarteschlange 116.
Das Paketstapelverarbeitungsmodul 122 entnimmt Informationen hinsichtlich Paketen in der Paketwarteschlange 116, um die Stapelverarbeitung (d. h. gemeinsame Verarbeitung) von Köpfen von mehreren in Beziehung stehenden Paketen zu ermöglichen. In einer Ausführungsform der Erfindung benachrichtigt das Paketstapelverarbeitungsmodul 122 den Host-Computer über die Verfügbarkeit von Köpfen von in Beziehung stehenden Paketen, so dass sie zusammen verarbeitet werden können.
Obwohl die Verarbeitung der Protokollköpfe eines Pakets von einem Prozessor auf einem Host-Computersystem in einer Ausführungsform der Erfindung durchgeführt wird, können in einer anderen Ausführungsform die Protokollköpfe durch einen Prozessor verarbeitet werden, der sich an der NIC 100 befindet. In der ersteren Ausführungsform kann die Software auf dem Host-Computer (z. B. ein Vorrichtungstreiber für die NIC 100) die Vorteile des zusätzlichen Speichers und eines austauschbaren oder aufrüstbaren Prozessors ernten (z. B. kann der Speicher ergänzt werden und der Prozessor kann durch ein schnelleres Modell ersetzt werden).
Während der Speicherung eines Pakets in der Paketwarteschlange 116 kann der Prüfsummengenerator 114 eine Prüfsummenoperation durchführen. Die Prüfsumme kann zur Paketwarteschlange als Nachsatz zum Paket hinzugefügt werden. Erläuternd 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 TCP-Daten) erzeugt. Wenn ein Paket nicht gemäß dem TCP-Protokoll formatiert ist, kann eine Prüfsumme an einem anderen Abschnitt des Pakets erzeugt werden und das Ergebnis kann bei der späteren Verarbeitung nach Bedarf eingestellt werden. Wenn die vom Prüfsummengenerator 114 berechnete Prüfsumme beispielsweise nicht am korrekten Abschnitt des Pakets berechnet wurde, kann die Prüfsumme eingestellt werden, um den korrekten Abschnitt zu erfassen. Diese Einstellung kann durch eine Software durchgeführt werden, die auf einem Host-Computersystem arbeitet (z. B. ein Vorrichtungstreiber). Der Prüfsummengenerator 114 kann in einer alternativen Ausführungsform der Erfindung weggelassen oder mit einem anderen Modul der NIC 100 kombiniert werden.
Aus den vom Kopf-Parser 106 erhaltenen Informationen und den vom Flussdatenbank-Manager 108 gemanagten Flussinformationen kann das durch die NIC 100 in der dargestellten Ausführungsform bediente Host-Computersystem Netzverkehr sehr effizient verarbeiten. Datenabschnitte von in Beziehung stehenden Paketen können beispielsweise durch die DMA-Maschine 120 wieder zusammengefügt werden, um Zusammenfassungen zu bilden, die effizienter bearbeitet werden können. Und durch Zusammenfügen der Daten in Puffern mit der Größe einer Speicherseite können die Daten effizienter zu einer Zielentität durch "Seitenwechsel" übertragen werden, wobei eine ganze Speicherseite, die durch die DMA-Maschine 120 gefüllt wird, auf einmal geliefert wird. Ein Seitenwechsel kann folglich mehrere Kopieroperationen ersetzen. Unterdessen können die Kopfabschnitte der wieder zusammengefügten Pakete ebenso als Gruppe durch ihr geeignetes Protokollprofil verarbeitet werden.
Wie bereits beschrieben, kann in einer anderen Ausführungsform der Erfindung die Verarbeitung von Netzverkehr durch geeignete Protokollprofile effizient in einem Host-Computersystem mit mehreren Prozessoren verteilt werden. In dieser Ausführungsform weist der Lastverteiler 112 in Beziehung stehende Pakete (z. B. Pakete im gleichen Kommunikationsfluss) demselben Prozessor zu oder verteilt sie zu diesem. Insbesondere können Pakete mit denselben Quell- und Zieladressen in ihren Köpfen des Protokolls der Schicht drei (z. B. IP) und/oder mit denselben Quell- und Zielanschlüssen in ihren Köpfen des Protokolls der Schicht vier (z. B. TCP) zu einem einzelnen Prozessor gesandt werden.
In der in 1A dargestellten NIC sind die vorstehend erörterten Verarbeitungsverbesserungen (z. B. erneutes Zusammenfügen von Daten, Stapelverarbeitung von Paketköpfen, Verteilung von Protokollprofilverarbeitung) für Pakete möglich, die vom Netz 102 empfangen werden und die gemäß einem oder mehreren vorgewählten Protokollprofilen formatiert sind. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet und die NIC 100 ist daher dazu konfiguriert, Pakete unter Verwendung von einem von mehreren Protokollprofilen zu verarbeiten, die mit dem Internet kompatibel sind. Pakete, die nicht gemäß den vorgewählten Protokollen konfiguriert sind, werden auch verarbeitet, können jedoch nicht die Vorteile der vollen Folge von Verarbeitungseffizienzen erhalten, die für Pakete vorgesehen sind, die die vorgewählten Protokolle erfüllen.
Pakete, die beispielsweise nicht einem der vorgewählten Protokollprofile entsprechen, können für die Verarbeitung in einem System mit mehreren Prozessoren vielmehr auf der Basis der Quell- und Zieladressen der Schicht zwei der Pakete (z. B. Medienzugriffssteuerung) als ihrer Adressen der Schicht drei oder Schicht vier verteilt werden. Die Verwendung von Identifizierern der Schicht zwei sieht weniger Granularität für die Lastverteilungsprozedur vor, wobei folglich die Verarbeitung von Paketen weniger gleichmäßig verteilt wird, als wenn die Identifizierer der Schicht drei/vier verwendet werden würden.
1B stellt ein Verfahren zur Verwendung der NIC 100 von 1A dar, um ein Paket vom Netz 102 zu empfangen und es zu einem Host-Computer zu übertragen. Der Zustand 130 ist ein Startzustand, 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, kann das Paket gemäß einer Vielzahl von Kommunikationsprotokollen formatiert sein. Das Paket kann durch ein MAC-Modul empfangen und anfänglich bearbeitet werden, bevor es zu einem IPP-Modul weitergeleitet wird.
Im Zustand 134 wird ein Abschnitt des Pakets kopiert und zum Kopf-Parser 106 geleitet. Der Kopf-Parser 106 analysiert dann das Paket syntaktisch, um Werte von einem oder mehreren seiner Köpfe und/oder seiner Daten zu extrahieren. Ein Flussschlüssel wird aus einigen der wiedergewonnenen Informationen erzeugt, um den Kommunikationsfluss, der das Paket umfasst, zu identifizieren. Der Grad oder das Ausmaß, in dem das Paket syntaktisch analysiert wird, kann insofern von seinen Protokollen abhängen, als der Kopf-Parser dazu konfiguriert sein kann, Köpfe von verschiedenen Protokollen in verschiedene Tiefen syntaktisch zu analysieren. Insbesondere kann der Kopf-Parser 106 für einen speziellen Satz von Protokollen oder Protokollprofilen optimiert sein (z. B. seine Operationsbefehle dafür konfiguriert sein). Wenn das Paket einem oder mehreren der festgelegten Protokolle entspricht, kann es vollständiger syntaktisch analysiert werden als ein Paket, das nicht irgendeines der Protokolle einhält.
Im Zustand 136 werden von den Köpfen der Pakete extrahierte Informationen zum Flussdatenbank-Manager 108 und/oder zum Lastverteiler 112 weitergeleitet. Der FDBM verwendet die Informationen, um einen Fluss in der Flussdatenbank 110 aufzubauen, wenn nicht bereits einer für diesen Kommunikationsfluss existiert. Wenn für den Fluss des Pakets bereits ein Eintrag existiert, kann er aktualisiert werden, um den Empfang eines neuen Flusspakets zu reflektieren. Ferner erzeugt der FDBM 108 einen Operationscode, um eine oder mehrere Eigenschaften oder Bedingungen des Pakets zusammenzufassen. Der Operationscode kann von anderen Modulen der NIC 100 verwendet werden, um das Paket in einer geeigneten Weise zu behandeln, wie in nachfolgenden Abschnitten beschrieben. Der Operationscode wird zum Kopf-Parser zusammen mit einem Index (z. B. einer Flussnummer) des Flusses des Pakets in der Flussdatenbank zurückgeführt.
Im Zustand 138 weist der Lastverteiler 112 dem Paket eine Prozessornummer zu, wenn der Host-Computer mehrere Prozessoren umfasst, und führt die Prozessornummer zum Kopfprozessor zurück. Erläuternd identifiziert die Prozessornummer, welcher Prozessor das Paket durch sein Protokollprofil auf dem Host-Computer führen soll. Der Zustand 138 kann in einer alternativen Ausführungsform der Erfindung weggelassen werden, insbesondere wenn der Host-Computer aus nur einem einzelnen Prozessor besteht.
Im Zustand 140 wird das Paket in der Paketwarteschlange 116 gespeichert. Wenn die Inhalte des Pakets in die Paketwarteschlange gestellt werden, kann der Prüfsummengenerator 114 eine Prüfsumme berechnen. Der Prüfsummengenerator kann vom IPP-Modul 104 hinsichtlich dessen informiert werden, an welchem Abschnitt des Pakets die Prüfsumme berechnet werden soll. Die berechnete Prüfsumme wird zur Paketwarteschlange als Nachsatz zum Paket hinzugefügt. In einer Ausführungsform der Erfindung wird das Paket in der Paketwarteschlange zu im Wesentlichen der Zeit gespeichert, zu der eine Kopie eines Kopfabschnitts des Pakets zum Kopf-Parser 106 geliefert wird.
Im Zustand 140 werden auch die Steuerinformationen für das Paket in der Steuerwarteschlange 118 gespeichert und Informationen hinsichtlich des Flusses des Pakets (z. B. Flussnummer, Flussschlüssel) können zum dynamischen Paketstapelverarbeitungsmodul 122 geliefert werden.
Im Zustand 142 stellt die NIC 100 fest, ob das Paket bereit ist, zum Host-Computer-Speicher übertragen zu werden. Bis es zur Übertragung bereit ist, wartet die dargestellte Prozedur.
Wenn das Paket zur Übertragung bereit ist (z. B. befindet sich das Paket am Kopf der Paketwarteschlange oder der Host-Computer empfängt das Paket vor diesem Paket in der Paketwarteschlange), stellt das dynamische Paketstapelverarbeitungsmodul 122 im Zustand 144 fest, ob ein in Beziehung stehendes Paket bald übertragen wird. Wenn ja, wird dann, wenn das vorliegende Paket zum Host-Speicher übertragen wird, der Host-Computer benachrichtigt, dass ein in Beziehung stehendes Paket bald folgen wird. Der Host-Computer kann dann die Pakete (z. B. durch ihr Protokollprofil) als Gruppe verarbeiten.
Im Zustand 146 wird das Paket (z. B. über eine Direktspeicherzugriffsoperation) zum Host-Computer-Speicher übertragen. Und im Zustand 148 wird der Host-Computer benachrichtigt, dass das Paket übertragen wurde. Die dargestellte Prozedur endet dann im Zustand 150.
Ein Fachmann für Computersysteme und -vernetzung wird erkennen, dass die vorstehend beschriebene Prozedur nur ein Verfahren zur Verwendung der Module der NIC 100 zum Empfangen eines einzelnen Pakets von einem Netz und zum Übertragen desselben zu einem Host-Computersystem ist. Andere geeignete Verfahren werden auch innerhalb des Schutzbereichs der Erfindung in Erwägung gezogen.
Ein erläuterndes Paket
2 ist ein Diagramm eines durch die NIC 100 vom Netz 102 empfangenen erläuternden Pakets. Das Paket 200 umfasst einen Datenabschnitt 202 und einen Kopfabschnitt 204 und kann auch einen Nachsatzabschnitt 206 enthalten. In Abhängigkeit von der vom Paket 200 durchquerten Netzumgebung kann seine maximale Größe (z. B. seine maximale Übertragungseinheit oder MTU) begrenzt sein.
In der dargestellten Ausführungsform umfasst der Datenabschnitt 202 Daten, die zu einer Ziel- oder Empfangsentität innerhalb eines Computersystems (z. B. Benutzer, Anwendungsprogramm, Betriebssystem) oder einem Kommunikationsuntersystem des Computers geliefert werden. Der Kopfabschnitt 204 umfasst einen oder mehrere Köpfe, die durch die Quell- oder Ursprungsentität oder ein Computersystem mit der Quellentität dem Datenabschnitt vorangestellt werden. Jeder Kopf entspricht normalerweise einem anderen Kommunikationsprotokoll.
In einer typischen Netzumgebung wie z. B. dem Internet werden einzelne Köpfe innerhalb des Kopfabschnitts 204 angebracht (z. B. vorher angehängt), wenn das Paket durch verschiedene Schichten eines Protokollprofils (z. B. einen Satz von Protokollen für die Kommunikation zwischen Entitäten) auf dem sendenden Computersystem verarbeitet wird. 2 stellt beispielsweise Protokollköpfe 210, 212, 214 und 216 dar, die jeweils den Schichten eins bis vier eines geeigneten Protokollprofils entsprechen. Jeder Protokollkopf enthält vom Empfangscomputersystem zu verwendende Informationen, wenn das Paket empfangen und durch das Protokollprofil verarbeitet wird. Schließlich wird jeder Protokollkopf entfernt und der Datenabschnitt 202 wird wiedergewonnen.
In einer Ausführungsform der Erfindung werden ein System und ein Verfahren zum syntaktischen Analysieren eines Pakets 200, um verschiedene Informationsbits wiederzugewinnen, geschaffen. In dieser Ausführungsform wird das Paket 200 syntaktisch analysiert, um den Beginn des Datenabschnitts 202 zu identifizieren und um einen oder mehrere Werte für Felder innerhalb des Kopfabschnitts 204 wiederzugewinnen. Erläuternd entspricht jedoch der Protokollkopf oder die Präambel 210 der Schicht eins einer Spezifikation auf Hardwareebene, die mit der Codierung einzelner Bits in Beziehung steht. Protokolle der Schicht eins sind im Allgemeinen nur für den physikalischen Prozess des Sendens oder Empfangens des Pakets über einen Leiter erforderlich. Folglich wird in dieser Ausführungsform der Erfindung die Präambel 210 der Schicht eins vom Paket 200 abgelöst, kurz nachdem es von der NIC 100 empfangen wurde, und wird daher nicht syntaktisch analysiert.
Das Ausmaß, in dem der Kopfabschnitt 204 syntaktisch analysiert wird, kann davon abhängen, wie viele, falls überhaupt, der im Kopfabschnitt dargestellten Protokolle einem Satz von vorgewählten Protokollen entsprechen. Die syntaktische Analyseprozedur kann beispielsweise abgekürzt oder abgebrochen werden, sobald festgestellt wird, dass einer der Köpfe des Pakets einem nicht unterstützten Protokoll entspricht.
Insbesondere ist in einer Ausführungsform der Erfindung die NIC 100 hauptsächlich für Internetverkehr konfiguriert. In dieser Ausführungsform wird folglich das Paket 200 nur dann ausgedehnt syntaktisch analysiert, wenn das Protokoll der Schicht zwei das Ethernet (entweder herkömmliches Ethernet oder 802.3-Ethernet mit oder ohne Kennzeichnung für virtuelle lokale Netze) ist, das Protokoll der Schicht drei IP (Internetprotokoll) ist und das Protokoll der Schicht vier TCP (Transportsteuerprotokoll) ist. Pakete, die andere Protokolle einhalten, können in einem gewissen (z. B. geringeren) Ausmaß syntaktisch analysiert werden. Die NIC 100 kann jedoch dazu konfiguriert sein, theoretisch einen Kopf eines beliebigen Kommunikationsprotokolls zu unterstützen und syntaktisch zu analysieren. Erläuternd werden die Protokollköpfe, die syntaktisch analysiert werden, und das Ausmaß, in dem sie syntaktisch analysiert werden, durch die Konfiguration eines Satzes von Befehlen zum Betreiben des Kopf-Parsers 106 festgelegt.
Wie vorstehend beschrieben, hängen die den Köpfen 212, 214 und 216 entsprechenden Protokolle von der Netzumgebung ab, in der ein Paket gesandt wird. Die Protokolle hängen auch von den Kommunikationsentitäten ab. Ein von einer Netzschnittstelle empfangenes Paket kann beispielsweise ein Steuerpaket sein, das zwischen den Medienzugriffssteuereinheiten für die Quell- und Zielcomputersysteme ausgetauscht wird. In diesem Fall würde das Paket wahrscheinlich minimale oder keine Daten enthalten und kann keinen Protokollkopf 214 der Schicht drei oder Protokollkopf 216 der Schicht vier enthalten. Steuerpakete werden typischerweise für verschiedene Zwecke, die mit dem Management von einzelnen Verbindungen in Beziehung stehen, verwendet.
Ein weiterer Kommunikationsfluss oder eine weitere Kommunikationsverbindung könnte zwei Anwendungsprogramme beinhalten. In diesem Fall kann ein Paket Köpfe 212, 214 und 216 umfassen, wie in 2 gezeigt, und kann auch zusätzliche Köpfe umfassen, die mit höheren Schichten eines Protokollprofils (z. B. Sitzungs-, Präsentations- und Anwendungsschichten im ISO-OSI-Modell) in Beziehung stehen. Außerdem können einige Anwendungen Köpfe oder kopfartige Informationen innerhalb des Datenabschnitts 202 umfassen. Für eine Netzdateisystem-Anwendung (NFS-Anwendung) kann der Datenabschnitt 202 beispielsweise NFS-Köpfe umfassen, die mit einzelnen NFS-Datagrammen in Beziehung stehen. Ein Datagramm kann als Sammlung von Daten definiert sein, die von einer Entität zu einer anderen gesandt werden, und kann Daten umfassen, die in mehreren Paketen übertragen werden. Mit anderen Worten, die Menge an Daten, die ein Datagramm bilden, kann größer sein als die Menge an Daten, die in einem Paket enthalten sein können.
Eine Ausführungsform eines Kopf-Parsers
3 stellt einen Kopf-Parser 106 von 1A gemäß einer vorliegenden Ausführungsform der Erfindung dar. Erläuternd umfasst der Kopf-Parser 106 einen Kopfspeicher 302 und einen Parser 304 und der Parser 304 umfasst einen Befehlsspeicher 306. Obwohl sie in 3 als unterschiedliche Module dargestellt sind, sind in einer alternativen Ausführungsform der Erfindung der Kopfspeicher 302 und der Befehlsspeicher 306 zusammenhängend. Vorteilhafterweise sind Verfahren zum syntaktischen Analysieren eines Pakets, die hierin beschrieben werden, leicht für Pakete anpassbar, die gemäß theoretisch einem beliebigen Kommunikationsprotokoll formatiert sind.
In der dargestellten Ausführungsform analysiert der Parser 304 einen im Kopfspeicher 302 gespeicherten Kopf syntaktisch gemäß Befehlen, die im Befehlsspeicher 306 gespeichert sind. Die Befehle sind für die syntaktische Analyse von speziellen Protokollen oder eines speziellen Protokollprofils ausgelegt, wie vorstehend erörtert. In einer Ausführungsform der Erfindung ist der Befehlsspeicher 306 modifizierbar (z. B. ist der Speicher als RAM, EPROM, EEPROM oder dergleichen implementiert), so dass neue oder modifizierte Befehle zur syntaktischen Analyse heruntergeladen oder anderweitig installiert werden können. Befehle zum syntaktischen Analysieren eines Pakets werden im folgenden Abschnitt weiter erörtert.
In 3 wird ein Kopfabschnitt eines Pakets, das im IPP-Modul 104 (in 1A gezeigt) gespeichert ist, in den Kopfspeicher 302 kopiert. Erläuternd werden eine spezielle Anzahl von Bytes (z. B. 114) am Beginn des Pakets kopiert. In einer alternativen Ausführungsform der Erfindung kann der Abschnitt eines Pakets, der kopiert wird, eine andere Größe besitzen. Die spezielle Menge eines in den Kopfspeicher 302 kopierten Pakets sollte genügen, um ein oder mehrere Protokollköpfe oder zumindest genügend Informationen (z. B. ob in einem Kopf- oder Datenabschnitt des Pakets enthalten) zu erfassen, um die nachstehend beschriebenen Informationen wiederzugewinnen. Der im Kopfspeicher 302 gespeicherte Kopfabschnitt kann nicht den Kopf der Schicht eins umfassen, der vor oder in Verbindung damit, dass das Paket vom IPP-Modul 104 verarbeitet wird, entfernt werden kann.
Nachdem ein Kopfabschnitt des Pakets im Kopfspeicher 302 gespeichert ist, analysiert der Parser 304 den Kopfabschnitt syntaktisch gemäß Befehlen, die im Befehlsspeicher 306 gespeichert sind. Befehle zum Betreiben des Parsers 304 in der gerade beschriebenen Ausführungsform wenden die Formate von ausgewählten Protokollen an, um die Inhalte des Kopfspeichers 302 zu durchschreiten und spezielle Informationen wiederzugewinnen. Insbesondere sind Spezifikationen von Kommunikationsprotokollen gut bekannt und stehen umfangreich zur Verfügung. Folglich kann ein Protokollkopf Byte für Byte oder in irgendeiner anderen Weise durchquert werden, indem auf die Protokollspezifikati onen Bezug genommen wird. In einer vorliegenden Ausführungsform der Erfindung ist folglich der Algorithmus zur syntaktischen Analyse dynamisch, wobei Informationen, die von einem Feld eines Kopfs wiedergewonnen werden, häufig die Weise ändern, in der ein anderer Teil syntaktisch analysiert wird.
Es ist beispielsweise bekannt, dass das Typenfeld eines Pakets, das die herkömmliche Form von Ethernet (z. B. Version zwei) einhält, beim dreizehnten Byte des Kopfs (der Schicht zwei) beginnt. Zum Vergleich beginnt das Typenfeld eines Pakets, das der Version IEEE 802.3 des Ethernet folgt, beim einundzwanzigsten Byte des Kopfs. Das Typenfeld befindet sich noch an anderen Stellen, wenn das Paket einen Teil einer Kommunikation eines virtuellen lokalen Netzes (VLAN) (das erläuternd die Kennzeichnung oder Einkapselung eines Ethernet-Kopfs beinhaltet) bildet. In einer vorliegenden Ausführungsform der Erfindung werden folglich die Werte in gewissen Feldern wiedergewonnen und getestet, um sicherzustellen, dass die erforderlichen Informationen von einem Kopf aus dem korrekten Abschnitt des Kopfs entnommen werden. Details hinsichtlich der Form eines VLAN-Pakets sind in Spezifikationen für die Formen IEEE 802.3p und IEEE 802.3q des Ethernet-Protokolls zu finden.
Die Operation des Kopfs-Parsers 106 hängt auch von anderen Unterschieden zwischen Protokollen ab, wie z. B. ob das Paket die Version vier oder Version sechs des Internetprotokolls verwendet, usw. Spezifikationen für die Versionen vier und sechs von IP können in IETF (Internet Engineering Task Force) RFCs (Request for Comment) 791 bzw. 2460, aufgefunden werden.
Je mehr Protokolle dem Parser 304 "bekannt" sind, auf desto mehr Protokolle kann ein Paket getestet werden und desto komplizierter kann die syntaktische Analyse des Kopfabschnitts eines Pakets werden. Ein Fachmann wird erkennen, dass die Protokolle, die vom Parser 304 syntaktisch analysiert werden können, nur durch die Befehle, gemäß denen er arbeitet, begrenzt sind. Durch Steigern oder Austauschen der im Befehlsspeicher 306 gespeicherten Befehle zur syntaktischen Analyse können folglich theoretisch alle bekannten Protokolle vom Kopf-Parser 106 bearbeitet werden und theoretisch jegliche Informationen können von den Köpfen eines Pakets wiedergewonnen werden.
Wenn ein Paketkopf nicht einem erwarteten oder verdächtigten Protokoll entspricht, kann natürlich die syntaktische Analyseoperation beendet werden. In diesem Fall kann das Paket für eine weitere der von der NIC 100 gebotenen Effizienzverbesserungen (z. B. Datenneuzusammenfügung, Paketstapelverarbeitung, Lastverteilung) nicht geeignet sein.
Erläuternd werden die von den Köpfen eines Pakets wiedergewonnenen Informationen von anderen Abschnitten der NIC 100 verwendet, wenn dieses Paket verarbeitet wird. Infolge der syntaktischen Analyse des Pakets, die vom Parser 304 durchgeführt wird, wird beispielsweise ein Flussschlüssel erzeugt, um den Kommunikationsfluss oder die Kommunikationsverbindung, der/die das Paket umfasst, zu identifizieren. Erläuternd wird der Flussschlüssel durch Verketten von einer oder mehreren Adressen, die einer oder mehreren der Kommunikationsentitäten entsprechen, zusammengesetzt. In einer vorliegenden Ausführungsform wird ein Flussschlüssel aus einer Kombination der Quell- und Zieladressen, die aus dem IP-Kopf entnommen werden, und der Quell- und Zielanschlüsse, die aus dem TCP-Kopf entnommen werden, gebildet. Andere Angaben der Kommunikationsentitäten können verwendet werden, wie z. B. die Ethernet-Quell- und -Zieladressen (vom Kopf der Schicht zwei entnommen), NFS-Dateizugriffsnummern oder Quell- und Zielidentifizierer für andere Anwendungsdatagramme, die aus dem Datenabschnitt des Pakets entnommen werden.
Ein Fachmann wird erkennen, dass die Kommunikationsentitäten mit größerer Auflösung identifiziert werden können, indem Angaben verwendet werden, die von den höheren Schichten des einem Paket zugeordneten Protokollprofils entnommen werden. Folglich kann eine Kombination von IP- und TCP-Angaben die Entitäten mit größerer Besonderheit als Informationen der Schicht zwei identifizieren.
Neben einem Flussschlüssel erzeugt der Parser 304 auch einen Steuer- oder Statusindikator, um zusätzliche Informationen hinsichtlich des Pakets zusammenzufassen. In einer Ausführungsform der Erfindung umfasst ein Steuerindikator eine Folgenummer (z. B. TCP-Folgenummer, die aus einem TCP-Kopf entnommen wird), um die korrekte Reihenfolge von Paketen sicherzustellen, wenn ihre Daten wieder zusammengefügt werden. Der Steuerindikator kann auch aufzeigen, ob bestimmte Flags in den Köpfen des Pakets gesetzt oder gelöscht sind, ob das Paket irgendwelche Daten enthält und, wenn das Paket Daten enthält, ob die Daten eine bestimmte Größe überschreiten. Andere Daten sind auch zum Einschluss in den Steuerindikator geeignet, die nur durch die Informationen begrenzt sind, die im Abschnitt des durch den Parser 304 syntaktisch analysierten Pakets verfügbar sind.
In einer Ausführungsform der Erfindung liefert der Kopf-Parser 106 den Flussschlüssel und alles oder einen Abschnitt des Steuerindikators zum Flussdatenbank-Manager 108. Wie in einem folgenden Abschnitt erörtert, managt der FDBM 108 eine Datenbank oder eine andere Datenstruktur, die Informationen enthält, die für die durch die NIC 100 laufenden Kommunikationsflüsse relevant sind.
In weiteren Ausführungsformen der Erfindung erzeugt der Parser 304 zusätzliche Informationen, die vom Kopf eines Pakets zur Verwendung von anderen Modulen der NIC 100 abgeleitet werden. Der Kopf-Parser 106 kann beispielsweise den Versatz vom Beginn des Pakets oder von irgendeinem anderen Punkt der Daten oder des Nutzinformationsabschnitts eines von einem Netz empfangenen Pakets melden. Wie vorstehend beschrieben, folgt der Datenabschnitt eines Pakets typischerweise dem Kopfabschnitt und diesem kann ein Nachsatzabschnitt folgen. Andere Daten, die der Kopf-Parser 106 melden kann, umfassen den Ort im Paket, an dem eine Prüfsummenoperation beginnen sollte, den Ort im Paket, an dem die Köpfe der Schicht drei und/oder Schicht vier beginnen, Diagnosedaten, Nutzinformationen usw. Der Begriff "Nutzinformationen" wird häufig verwendet, um auf den Datenabschnitt eines Pakets Bezug zu nehmen. Insbesondere liefert der Kopf-Parser 106 in einer Ausführungsform der Erfindung einen Nutzinformationsversatz und eine Nutzinformationsgröße zur Steuerwarteschlange 118.
Unter geeigneten Umständen kann der Kopf-Parser 106 auch melden (z. B. an das IPP-Modul 104 und/oder die Steuerwarteschlange 118), dass das Paket nicht gemäß den Protokollen formatiert ist, für deren Bearbeitung der Parser 304 konfiguriert ist. Diese Meldung kann die Form eines Signals (z. B. des nachstehend beschriebenen No_Assist-Signals), einer Warnung, eines Flags oder eines anderen Indikators annehmen. Das Signal kann geschaffen oder ausgegeben werden, sobald festgestellt wird, dass das Paket ein anderes Protokoll als die vorgewählten Protokolle reflektiert, die mit den vorstehend beschriebenen Verarbeitungsverbesserungen (z. B. Datenneuzusammenfügung, Stapelverarbeitung von Paketköpfen, Lastverteilung) kompatibel sind. In einer Ausführungsform der Erfindung kann der Parser 304 beispielsweise dazu konfiguriert sein, Pakete unter Verwendung von TCP auf der Schicht vier, IP auf der Schicht drei und Ethernet auf der Schicht zwei syntaktisch zu analysieren und effizient zu verarbeiten. In dieser Ausführungsform würde ein IPX-Paket (Paket für Internetwork Packet Exchange) nicht als kompatibel betrachtet werden und IPX-Pakete würden daher nicht für die Datenneuzusammenfügung und Stapelverarbeitung gesammelt werden.
Beim Abschluss der syntaktischen Analyse in einer Ausführungsform der Erfindung werden die verschiedenen vorstehend beschriebenen Informationstücke zu geeigneten Modulen der NIC 100 weitergegeben. Danach (und wie in einem folgenden Abschnitt beschrieben) bestimmt der Flussdatenbank-Manager 108, ob ein aktiver Fluss dem vom Paket abgeleiteten Flussschlüssel zugeordnet ist, und legt einen Operationscode fest, der bei der anschließenden Verarbeitung verwendet werden soll. Außerdem überträgt das IPP-Modul 104 das Paket zur Paketwarteschlange 116. Das IPP-Modul 104 kann auch einige der vom Kopf-Parser 106 extrahierten Informationen empfangen und sie zu einem anderen Modul der NIC 100 leiten.
In der Ausführungsform der Erfindung, die in 3 dargestellt ist, wird ein ganzer Kopfabschnitt eines syntaktisch zu analysierenden empfangenen Pakets kopiert und dann in einer Entwicklung syntaktisch analysiert, wonach der Kopf-Parser seine Aufmerksamkeit auf ein anderes Paket richtet. In einer alternativen Ausführungsform können jedoch mehrere Kopier- und/oder syntaktische Analyseoperationen an einem einzelnen Paket durchgeführt werden. Insbesondere kann ein anfänglicher Kopfabschnitt des Pakets in den Kopf-Parser 106 in einer ersten Entwicklung kopiert und durch diesen syntaktisch analysiert werden, wonach ein weiterer Kopfabschnitt in einer zweiten Entwicklung in den Kopf-Parser 106 kopiert und syntaktisch analysiert werden kann. Ein Kopfabschnitt in einer Entwicklung kann teilweise oder vollständig mit dem Kopfabschnitt einer anderen Entwicklung überlappen. In dieser Weise können ausgedehnte Köpfe selbst dann syntaktisch analysiert werden, wenn der Kopfspeicher 302 eine begrenzte Größe aufweist. Ebenso kann es mehr als eine Operation erfordern, um einen vollen Satz von Befehlen zum syntaktischen Analysieren eines Pakets in den Befehlsspeicher 306 zu laden. Erläuternd kann ein erster Abschnitt der Befehle geladen und ausgeführt werden, wonach andere Befehle geladen werden.
Mit Bezug nun auf 4A–4B wird ein Ablaufplan dargestellt, um ein Verfahren zu erläutern, durch das ein Kopf-Parser einen Kopfabschnitt eines an einer Netzschnittstellenschaltung von einem Netz empfangenen Pakets syntaktisch analysieren kann. In dieser Implementierung ist der Kopf-Parser zum syntaktischen Analysieren von Paketen, die einem Satz von vorgewählten Protokollen (oder Protokollprofilen) entsprechen, konfiguriert oder optimiert. Für Pakete, die diese Kriterien erfüllen, werden verschiedene Informationen vom Kopfabschnitt wiedergewonnen, um bei der erneuten Zusammenfügung der Datenabschnitte von in Beziehung stehenden Paketen (z. B. Paketen mit Daten von einem einzelnen Datagramm) zu unterstützen. Andere verbesserte Merkmale der Netzschnittstellenschaltung können auch ermöglicht werden.
Die vom Kopf-Parser erzeugten Informationen umfassen insbesondere einen Flussschlüssel, mit dem der Kommunikationsfluss oder die Kommunikationsverbindung identifiziert werden soll, der/die das empfangene Paket umfasst. In einer Ausführungsform der Erfindung können Daten von Paketen mit demselben Flussschlüssel identifiziert und erneut zusammengefügt werden, um ein Datagramm zu bilden. Außerdem können Köpfe von Paketen mit demselben Flussschlüssel gemeinsam durch ihr Protokollprofil verarbeitet werden (z. B. anstatt seriell).
In einer weiteren Ausführungsform der Erfindung werden Informationen, die vom Kopf-Parser wiedergewonnen werden, auch verwendet, um die Verarbeitung von Netzverkehr, der von einem Netz empfangen wird, zu verteilen. Mehrere Pakete mit demselben Flussschlüssel können beispielsweise zu einem einzelnen Prozessor eines Host-Computersystems mit mehreren Prozessoren übermittelt werden.
In dem in 4A–4B dargestellten Verfahren entspricht der Satz von vorgewählten Protokollen Kommunikationsprotokollen, die häufig über das Internet übertragen werden. Insbesondere umfasst der Satz von Protokollen, die in diesem Verfahren umfangreich syntaktisch analysiert werden können, das Folgende. Auf der Schicht zwei: Ethernet (herkömmliche Version), 802.3 Ethernet, Ethernet VLAN (virtuelles lokales Netz) und 802.3 Ethernet VLAN. Auf der Schicht drei: IPv4 (ohne Optionen) und IPv6 (ohne Optionen). Schließlich werden auf der Schicht vier nur TCP-Protokollköpfe (mit oder ohne Optionen) im dargestellten Verfahren syntaktisch analysiert. Kopf-Parser in alternativen Ausführungsformen der Erfindung analysieren Pakete, die durch andere Protokollprofile formatiert sind, syntaktisch. Insbesondere kann eine NIC gemäß den üblichsten Protokollprofilen, die in einem gegebenen Netz in Gebrauch sind, konfiguriert sein, welche die Protokolle umfassen können oder nicht, die mit dem in 4A–4B dargestellten Kopf-Parser-Verfahren kompatibel sind.
Wie nachstehend beschrieben, kann ein empfangenes Paket, das nicht den Protokollen entspricht, die durch ein gegebenes Verfahren syntaktisch analysiert werden, gekennzeichnet werden und der Algorithmus zur syntaktischen Analyse für dieses Paket beendet werden. Da die Protokolle, unter denen ein Paket formatiert wurde, im vorliegenden Verfahren nur durch Untersuchen gewisser Kopffeldwerte bestimmt werden können, kann die Bestimmung, dass ein Paket nicht dem ausgewählten Satz von Protokollen entspricht, zu theoretisch jedem Zeitpunkt während der Prozedur durchgeführt werden. Folglich besitzt das dargestellte syntaktische Analyseverfahren als ein Ziel die Identifikation von Paketen, die nicht die Formatierungskriterien für die erneute Zusammenfügung von Daten erfüllen.
Verschiedene Protokollkopffelder, die in Köpfen für die ausgewählten Protokolle erscheinen, werden nachstehend erörtert. Kommunikationsprotokolle, die mit einer Ausführungsform der vorliegenden Erfindung kompatibel sein können (z. B. Protokolle, die von einem Kopf-Parser syntaktisch analysiert werden können), sind Fachleuten gut bekannt und sind mit großer Besonderheit in einer Anzahl von Bezugsquellen beschrieben. Sie müssen daher nicht hierin in winzigem Detail besichtigt werden. Außerdem ist das dargestellte Verfahren zum syntaktischen Analysieren eines Kopfabschnitts eines Pakets für die ausgewählten Protokolle nur ein Verfahren zum Sammeln der nachstehend beschriebenen Informationen. Andere Prozeduren zur syntaktischen Analyse, die dies durchführen können, sind gleichermaßen geeignet.
In einer vorliegenden Ausführungsform der Erfindung wird die dargestellte Prozedur als Kombination von Hardware und Software implementiert. Aktualisierbare Mikrocodebefehle zum Durchführen der Prozedur können beispielsweise von einer Mikroablaufsteuereinheit ausgeführt werden. Alternativ können solche Befehle fest sein (z. B. in einem Festwertspeicher gespeichert) oder können von einem Prozessor oder Mikroprozessor ausgeführt werden.
In 4A–4B ist der Zustand 400 ein Startzustand, während dessen ein Paket von der NIC 100 (in 1A gezeigt) empfangen wird und eine anfängliche Verarbeitung durchgeführt wird. Die NIC 100 ist mit dem Internet für Zwecke dieser Prozedur gekoppelt. Die anfängliche Verarbeitung kann eine Basisfehlerprüfung und die Entfernung der Präambel der Schicht eins umfassen. Nach der anfänglichen Verarbeitung wird das Paket vom IPP-Modul 104 (auch in 1A gezeigt) gehalten. In einer Ausführungsform der Erfindung umfasst der Zustand 400 eine logische Schleife, in der der Kopf-Parser in einem Leerlauf- oder Wartezustand bleibt, bis ein Paket empfangen wird.
Im Zustand 402 wird ein Kopfabschnitt des Pakets in den Speicher (z. B. Kopfspeicher 302 von 3) kopiert. In einer vorliegenden Ausführungsform der Erfindung wird eine vorbestimmte Anzahl von Bytes am Beginn (z. B. 114 Bytes) des Pakets kopiert. Paketabschnitte mit verschiedenen Größen werden in alternativen Ausführungsformen der Erfindung kopiert, deren Größen durch das Ziel des Kopierens von genügend des Pakets geführt werden, um die erforderlichen Kopfinformationen zu erfassen und/oder zu identifizieren. Erläuternd wird das volle Paket vom IPP-Modul 104 beibehalten, während die folgenden syntaktischen Analyseoperationen durchgeführt werden, obwohl das Paket alternativ vor der Beendung der syntaktischen Analyse in der Paketwarteschlange 116 gespeichert werden kann.
Im Zustand 402 kann auch ein bei der syntaktischen Analyse des Pakets zu verwendender Zeiger initialisiert werden. Da die Präambel der Schicht eins entfernt wurde, sollte der in den Speicher kopierte Kopfabschnitt mit dem Protokollkopf der Schicht zwei beginnen. Erläuternd wird daher der Zeiger anfänglich so gesetzt, dass er auf das zwölfte Byte des Protokollkopfs der Schicht zwei zeigt und der Zwei-Byte-Wert in der Zeigerposition wird gelesen. Wie ein Fachmann erkennen wird, können diese zwei Bytes ein Teil einer Anzahl von verschiedenen Feldern in Abhängigkeit davon, welches Protokoll die Schicht zwei des Protokollprofils des Pakets bildet, sein. Diese zwei Bytes können beispielsweise das Typenfeld eines herkömmlichen Ethernet-Kopfs, das Längenfeld eines 802.3-Ethernet-Kopfs oder das TPID-Feld (Kennzeichenprotokoll-Identifizierer-Feld) eines mit VLAN gekennzeichneten Kopfs umfassen.
Im Zustand 404 wird eine erste Untersuchung des Kopfs der Schicht zwei durchgeführt, um festzustellen, ob er einen mit VLAN gekennzeichneten Protokollkopf der Schicht zwei umfasst. Erläuternd hängt diese Feststellung davon ab, ob die zwei Bytes in der Zeigerposition den Hexadezimalwert 8100 speichern.
Wenn ja, befindet sich der Zeiger wahrscheinlich am TPID-Feld eines mit VLAN gekennzeichneten Kopfs. Wenn es sich nicht um einen VLAN-Kopf handelt, geht die Prozedur zum Zustand 408 weiter.
Wenn jedoch der Kopf der Schicht zwei ein mit VLAN gekennzeichneter Kopf ist, wird im Zustand 406 das CFI-Bit (Bit des Indikators des kanonischen Formats) untersucht. Wenn das CFI-Bit gesetzt ist (z. B. gleich Eins), springt die dargestellte Prozedur zum Zustand 430, wonach sie austritt. In dieser Ausführungsform der Erfindung gibt das CFI-Bit, wenn es gesetzt ist, an, dass das Format des Pakets nicht mit den vorgewählten Protokollen kompatibel ist (d. h. diesen nicht entspricht) (z. B. ist das Protokoll der Schicht zwei nicht Ethernet oder 802.3-Ethernet). Wenn das CFI-Bit gelöscht ist (z. B. gleich Null), wird der Zeiger inkrementiert (z. B. um vier Bytes), um ihn am nächsten Feld zu positionieren, das untersucht werden muss.
Im Zustand 408 wird der Kopf der Schicht zwei weiter getestet. Obwohl nun bekannt ist, ob dies ein mit VLAN gekennzeichneter Kopf ist oder nicht, in Abhängigkeit davon, ob der Zustand 408 durch den Zustand 406 oder direkt vom Zustand 404 erreicht wurde, kann der Kopf entweder das herkömmliche Ethernet-Format oder das 802.3-Ethernet-Format reflektieren. Am Beginn des Zustandes 408 befindet sich der Zeiger entweder am zwölften oder sechzehnten Byte des Kopfs, die beide einem Längenfeld oder einem Typenfeld entsprechen können. Insbesondere wenn der Zwei-Byte-Wert in der durch den Zeiger identifizierten Position geringer als 0600 (hexadezimal) ist, dann entspricht das Paket dem 802.3 Ethernet und es ist verständlich, dass der Zeiger ein Längenfeld identifiziert. Ansonsten ist das Paket ein herkömmliches Ethernet-Paket (z. B. Version zwei) und der Zeiger identifiziert ein Typenfeld.
Wenn das Protokoll der Schicht zwei 802.3 Ethernet ist, fährt die Prozedur im Zustand 410 fort. Wenn das Protokoll der Schicht zwei das herkömmliche Ethernet ist, wird das Typenfeld auf die Hexadezimalwerte von 0800 und 08DD getestet. Wenn das getestete Feld einen dieser Werte besitzt, dann wurde auch festgestellt, dass das Protokoll der Schicht drei des Pakets das Internetprotokoll ist. In diesem Fall fährt die dargestellte Prozedur im Zustand 412 fort. Wenn das Feld ein Typenfeld mit einem anderen Wert als 0800 oder 86DD (hexadezimal) ist, dann entspricht schließlich das Protokoll der Schicht drei des Pakets nicht den vorgewählten Protokollen, gemäß denen der Kopf-Parser konfiguriert wurde. Daher fährt die Prozedur im Zustand 430 fort und endet dann.
In einer Ausführungsform der Erfindung wird das Paket im Zustand 408 untersucht, um festzustellen, ob es sich um einen Jumbo-Ethernet-Rahmen handelt. Diese Feststellung würde wahrscheinlich vor der Entscheidung, ob der Kopf der Schicht zwei dem Ethernet oder 802.3 Ethernet entspricht, durchgeführt werden. Erläuternd kann die Jumborahmen-Feststellung auf der Basis der Größe des Pakets durchgeführt werden, die durch das IPP-Modul 104 oder ein MAC-Modul gemeldet werden kann. Wenn das Paket ein Jumborahmen ist, kann die Prozedur im Zustand 410 fortfahren; ansonsten kann sie im Zustand 412 fortfahren.
Im Zustand 410 überprüft die Prozedur, dass das Protokoll der Schicht zwei das 802.3 Ethernet mit LLC-SNAP-Einkapselung ist. Insbesondere wird der Zeiger vorgeschoben (z. B. um zwei Bytes) und der Sechs-Byte-Wert, der dem Längenfeld im Kopf der Schicht zwei folgt, wird wiedergewonnen und untersucht. Wenn der Kopf ein 802.3-Ethernet-Kopf ist, ist das Feld das LLC_SNAP-Feld und sollte einen Wert von AAAA03000000 (hexadezimal) aufweisen. Die ursprüngliche Spezifikation für einen LLC-SNAP-Kopf ist in der Spezifikation für IEEE 802.2 zu finden. Wenn der Wert im LLC_SNAP-Feld des Pakets dem erwarteten Wert entspricht, wird der Zeiger um weitere sechs Bytes inkrementiert, das Zwei-Byte-Typenfeld des 802.3 Ethernet wird gelesen und die Prozedur fährt im Zustand 412 fort. Wenn die Werte nicht übereinstimmen, dann entspricht das Paket nicht den festgelegten Protokollen und die Prozedur tritt in den Zustand 430 ein und endet dann.
Im Zustand 412 wird der Zeiger vorgeschoben (z. B. um weitere zwei Bytes), um den Beginn des Protokollkopfs der Schicht drei aufzufinden. Diese Zeigerposition kann für die spätere Verwendung bei der schnellen Identifikation des Beginns dieses Kopfs gespeichert werden. Nun ist bekannt, dass das Paket einem akzeptierten Protokoll der Schicht zwei (z. B. herkömmliches Ethernet, Ethernet mit VLAN-Kennzeichnung oder 802.3 Ethernet mit LLC-SNAP) entspricht, und es wird nun geprüft, um sicherzustellen, dass das Protokoll der Schicht drei des Pakets IP ist. Wie vorstehend erörtert, werden in der dargestellten Ausführungsform nur Pakete, die dem IP-Protokoll entsprechen, vom Kopf-Parser ausgedehnt verarbeitet.
Wenn der Wert des Typenfeldes im Kopf der Schicht zwei (im Zustand 402 oder Zustand 410 wiedergewonnen) 0800 (hexadezimal) ist, wird erläuternd erwartet, dass das Protokoll der Schicht drei IP, Version vier, ist. Wenn der Wert 86DD (hexadezimal) ist, wird erwartet, dass das Protokoll der Schicht drei IP, Version sechs, ist. Folglich wird das Typenfeld im Zustand 412 getestet und die Prozedur fährt im Zustand 414 bzw. Zustand 418 in Abhängigkeit davon, ob der Hexadezimalwert 0800 oder 86DD ist, fort.
Im Zustand 414 wird die Übereinstimmung des Kopfs der Schicht drei mit der Version vier von IP überprüft. In einer Ausführungsform der Erfindung wird das Versionsfeld des Kopfs der Schicht drei getestet, um sicherzustellen, dass es den Hexadezimalwert 4 entsprechend der Version vier von IP enthält. Wenn im Zustand 414 der Kopf der Schicht drei als IP, Version vier, bestätigt wird, fährt die Prozedur im Zustand 416 fort; ansonsten geht die Prozedur zum Zustand 430 weiter und endet dann im Zustand 432.
Im Zustand 416 werden verschiedene Informationsstücke vom IP-Kopf gespeichert. Diese Informationen können die IHL- (IP-Kopflänge), Gesamtlängen-, Protokoll- und/oder Fragmentversatz-Felder umfassen. Die IP-Quelladresse und die IP-Zieladressen können auch gespeichert werden. Die Quell- und Zieladressenwerte sind in der Version vier von IP jeweils vier Bytes lang. Diese Adressen werden, wie vorstehend beschrieben, verwendet, um einen Flussschlüssel zu erzeugen, der den Kommunikationsfluss identifiziert, in dem dieses Paket gesandt wurde. Das Gesamtlängenfeld speichert die Größe des IP-Segments dieses Pakets, die erläuternd 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-Kopfs plus die Größe des Datenabschnitts des Pakets) kann durch Subtrahieren von zwanzig Bytes (die Größe des Kopfs der IP-Version vier) vom Gesamtlängenwert berechnet werden. Nach dem Zustand 416 geht die dargestellte Prozedur zum Zustand 422 weiter.
Im Zustand 418 wird die Übereinstimmung des Kopfs der Schicht drei mit der Version sechs von IP durch Testen des Versionsfeldes auf den Hexadezimalwert 6 überprüft. Wenn das Versionsfeld nicht diesen Wert enthält, geht die dargestellte Prozedur zum Zustand 430 weiter.
Im Zustand 420 werden die Werte der Nutzinformationslänge (z. B. die Größe des TCP-Segments) und des Feldes des nächsten Kopfs, plus die IP-Quell- und -Zieladressen gespeichert. Die Quell- und Zieladressen sind in der Version sechs von IP jeweils sechzehn Bytes lang.
Im Zustand 422 der dargestellten Prozedur wird festgestellt, ob der IP-Kopf (entweder Version vier oder Version sechs) angibt, dass der Kopf der Schicht vier TCP ist. Erläuternd wird das Protokollfeld eines IP-Kopfs der Version vier getestet, während das Feld des nächsten Kopfs eines Kopfs der Version sechs getestet wird. In beiden Fällen sollte der Wert 6 (hexadezimal) sein. Der Zeiger wird dann nach Bedarf inkrementiert (z. B. zwanzig Bytes für die IP-Version vier, vierzig Bytes für die IP-Version sechs), um den Beginn des TCP-Kopfs zu erreichen. Wenn im Zustand 422 festgestellt wird, dass der Kopf der Schicht vier nicht TCP ist, geht die Prozedur zum Zustand 430 weiter und endet im Endzustand 432.
In einer Ausführungsform der Erfindung können andere Felder eines IP-Kopfs der Version vier im Zustand 422 getestet werden, um sicherzustellen, dass das Paket die Kriterien für die verbesserte Verarbeitung durch die NIC 100 erfüllt. Ein anderer IHL-Feld-Wert als 5 (hexadezimal) gibt beispielsweise an, dass die IP-Optionen für dieses Paket festgelegt sind, in welchem Fall die syntaktische Analyseoperation abgebrochen wird. Ein anderer Fragmentierungsfeld-Wert als Null gibt an, dass das IP-Segment des Pakets ein Fragment ist, in welchem Fall die syntaktische Analyse auch abgebrochen wird. In beiden Fällen springt die Prozedur zum Zustand 430 und endet dann im Endzustand 432.
Im Zustand 424 wird der TCP-Kopf des Pakets syntaktisch analysiert und verschiedene Daten werden von ihm gesammelt. Insbesondere werden Die TCP-Quellanschluss- und -Zielanschlusswerte gespeichert. Die TCP-Folgenummer, die verwendet wird, um die korrekte erneute Zusammenfügung von Daten von mehreren Paketen sicherzustellen, wird auch gespeichert. Ferner werden die Werte von verschiedenen Komponenten des Flag-Feldes – erläuternd die URG- (dringend), PSH- (Schub), RST- (Rücksetzen), SYN- (Synchronisation) und FIN- (Ende) Bits – gespeichert. In einer Ausführungsform der Erfindung signalisieren diese Flags verschiedene durchzuführende Handlungen oder Zustände, die bei der Bearbeitung des Pakets berücksichtigt werden sollen.
Andere Signale oder Zustände können im Zustand 424 erzeugt werden, um Informationen zu reflektieren, die vom TCP-Kopf wiedergewonnen werden. Der Punkt, ab dem eine Prüfsummenoperation beginnen soll, kann beispielsweise gespeichert werden (erläuternd der Beginn des TCP-Kopfs); der Endpunkt einer Prüfsummenoperation kann auch gespeichert werden (erläuternd das Ende des Datenabschnitts des Pakets). Ein Versatz zum Datenabschnitt des Pakets kann durch Multiplizieren des Werts des Kopflängenfeldes des TCP-Kopfs mit vier identifiziert werden. Die Größe des Datenabschnitts kann dann durch Subtrahieren des Versatzes zum Datenabschnitt von der Größe des ganzen TCP-Segments berechnet werden.
Im Zustand 426 wird ein Flussschlüssel durch Verketten der IP-Quell- und -Zieladressen und der TCP-Quell- und -Zielanschlüsse zusammengefügt. Wie bereits beschrieben, kann der Flussschlüssel verwendet werden, um einen Kommunikationsfluss oder eine Kommunikationsverbindung zu identifizieren, und kann von anderen Modulen der NIC 100 verwendet werden, um Netzverkehr effizienter zu verarbeiten. Obwohl sich die Größen der Quell- und Zieladressen zwischen den IP-Versionen vier und sechs unterscheiden (z. B. vier Bytes jeweils gegen sechzehn Bytes jeweils), weisen in der gerade beschriebenen Ausführungsform der Erfindung alle Flussschlüssel eine einheitliche Größe auf. Insbesondere sind sie in dieser Ausführungsform sechsunddreißig Bytes lang, einschließlich des Zwei-Byte-TCP-Quellanschlusses und des Zwei-Byte-TCP-Zielanschlusses. Die Flussschlüssel, die von den IP-Paketköpfen der Version vier erzeugt werden, werden nach Bedarf aufgefüllt (z. B. mit vierundzwanzig gelöschten Bytes), um den zugewiesenen Raum des Flussschlüssels zu füllen.
Im Zustand 428 wird ein Steuer- oder Statusindikator zusammengefügt, um verschiedene Informationen zu einem oder mehreren Modulen der NIC 100 zu liefern. In einer Ausführungsform der Erfindung umfasst ein Steuerindikator die TCP-Folgenummer des Pakets, ein Flag oder einen Identifizierer (z. B. ein oder mehrere Bits), das/der angibt, ob das Paket Daten enthält (z. B. ob die TCP-Nutzinformationsgröße größer als Null ist), ein Flag, das angibt, ob der Datenabschnitt des Pakets eine vorbestimmte Größe überschreitet, und ein Flag, das angibt, ob bestimmte Einträge in dem TCP-Flag-Feld zu vorbestimmten Werten äquivalent sind. Das letztere Flag kann beispielsweise verwendet werden, um ein anderes Modul der NIC 100 zu informieren, dass Komponenten des Flag- Feldes eine spezielle Konfiguration aufweisen oder nicht. Nach dem Zustand 428 endet die dargestellte Prozedur mit dem Zustand 432.
In den Zustand 430 kann an mehreren verschiedenen Punkten der dargestellten Prozedur eingetreten werden. In diesen Zustand wird beispielsweise eingetreten, wenn festgestellt wird, dass ein Kopfabschnitt, der von einem Kopf-Parser syntaktisch analysiert wird, nicht den vorstehend identifizierten vorgewählten Protokollprofilen entspricht. Folglich werden viele der vorstehend beschriebenen Informationen nicht wiedergewonnen. Eine praktische Konsequenz der Unfähigkeit, diese Informationen wiederzugewinnen, besteht darin, dass sie dann nicht zu anderen Modulen der NIC 100 geliefert werden können und die hierin beschriebene verbesserte Verarbeitung nicht für dieses Paket durchgeführt werden kann. Insbesondere und wie vorher erörtert, können in einer vorliegenden Ausführungsform der Erfindung eine oder mehrere verbesserte Operationen an syntaktisch analysierten Paketen durchgeführt werden, um die Effizienz zu steigern, mit der sie verarbeitet werden. Erläuternde Operationen, die angewendet werden können, umfassen die erneute Zusammenfügung von Daten aus in Beziehung stehenden Paketen (z. B. Paketen, die Daten von einem einzelnen Datagramm enthalten), die Stapelverarbeitung von Paketköpfen durch ein Protokollprofil, die Lastverteilung oder Lastteilung der Protokollprofilverarbeitung, die effiziente Übertragung von Paketdaten zu einer Zielentität usw.
In der dargestellten Prozedur wird im Zustand 430 ein Flag oder Signal (erläuternd No_Assist genannt) gesetzt oder gelöscht, um anzugeben, dass das vom IPP-Modul 104 gerade gehaltene Paket (z. B. das gerade vom Kopf-Parser verarbeitet wurde) nicht irgendeinem der vorgewählten Protokollprofile entspricht. Auf dieses Flag oder Signal kann sich ein anderes Modul der NIC 100 verlassen, wenn entschieden wird, ob eine der verbesserten Operationen durchgeführt werden soll.
Ein weiteres Flag oder Signal kann im Zustand 430 gesetzt oder gelöscht werden, um einen Prüfsummenparameter zu initialisieren, der angibt, dass eine Prüfsummenoperation, falls durchgeführt, am Beginn des Pakets (z. B. ohne Versatz in das Paket) starten sollte. Erläuternd können inkompatible Pakete nicht syntaktisch analysiert werden, um einen geeigneteren Punkt zu bestimmen, ab dem die Prüfsummenoperation begonnen werden soll. Nach dem Zustand 430 endet die Prozedur mit dem Endzustand 432.
Nach der syntaktischen Analyse eines Pakets kann der Kopf-Parser Informationen, die vom Paket erzeugt werden, zu einem oder mehreren Modulen der NIC 100 verteilen. In einer Ausführungsform der Erfindung wird beispielsweise der Flussschlüssel zum Flussdatenbank-Manager 108, zum Lastverteiler 112 und zu einer oder beiden der Steuerwarteschlange 118 und der Paketwarteschlange 116 geliefert. Erläuternd wird der Steuerindikator zum Flussdatenbank-Manager 108 geliefert. Diese und weitere Steuerinformationen, wie z. B. die TCP-Nutzinformationsgröße, der TCP-Nutzinformationsversatz und das No_Assist-Signal, können zum IPP-Modul 104 zurückgeführt und zur Steuerwarteschlange 118 geliefert werden. Noch zusätzliche Steuer- und/oder Diagnoseinformationen, wie z. B. Versätze zu den Köpfen der Schicht drei und/oder Schicht vier, können zum IPP-Modul 104, zur Paketwarteschlange 116 und/oder zur Steuerwarteschlange 118 geliefert werden. Die Prüfsummeninformationen (z. B. ein Startpunkt und entweder ein Endpunkt oder ein anderes Mittel zum Identifizieren eines Abschnitts des Pakets, aus dem eine Prüfsumme berechnet werden soll), können zum Prüfsummengenerator 114 geliefert werden.
Nachdem ein empfangenes Paket an der NIC 100 (z. B. durch den Kopf-Parser 106) syntaktisch analysiert ist, werden die Pakete noch (z. B. durch ihre jeweiligen Protokollprofile) auf dem Host-Computersystem in der dargestellten Ausführungsform der Erfindung verarbeitet. Nach der syntaktischen Analyse eines Pakets in einer alternativen Ausführungsform der Erfindung führt jedoch die NIC 100 auch einen oder mehrere anschließende Verarbeitungsschritte durch. Die NIC 100 kann beispielsweise ein oder mehrere Protokollprozessoren zum Verarbeiten von einem oder mehreren der Protokollköpfe des Pakets umfassen.
Dynamische Befehle zur syntaktischen Analyse des Kopfes in einer Ausführungsform der Erfindung
In einer Ausführungsform der vorliegenden Erfindung analysiert der Kopf-Parser 106 ein Paket, das von einem Netz empfangen wird, syntaktisch gemäß einer dynamischen Folge von Befehlen. Die Befehle können im Befehlsspeicher des Kopf-Parsers (z. B. RAM, SRAM, DRAM, Flash) gespeichert werden, der umprogrammierbar ist oder der anderweitig mit neuen oder zusätzlichen Befehlen aktualisiert werden kann. In einer Ausführungsform der Erfindung kann eine auf einem Host-Computer arbeitende Software (z. B. ein Vorrichtungstreiber) einen Satz von Befehlen zur syntaktischen Analyse zur Speicherung im Kopf-Parser-Speicher herunterladen.
Die Anzahl und das Format von Befehlen, die im Befehlsspeicher eines Kopf-Parsers gespeichert werden, können auf ein oder mehrere spezielle Protokolle oder Protokollprofile zugeschnitten werden. Ein für eine Sammlung von Protokollen konfigurierter Befehlssatz oder ein aus diesem Befehlssatz konstruiertes Programm kann daher durch einen anderen Befehlssatz oder ein anderes Programm aktualisiert oder ersetzt werden. Für Pakete, die an der Netzschnittstelle empfangen werden und die gemäß den ausgewählten Protokollen formatiert sind (z. B. "kompatible" Pakete), wie durch Analysieren oder syntaktisches Analysieren der Pakete bestimmt, werden verschiedene Verbesserungen bei der Bearbeitung von Netzverkehr möglich, wie hierin beschrieben. Insbesondere können Pakete von einem Datagramm, die gemäß einem ausgewählten Protokoll konfiguriert sind, für eine effiziente Übertragung in einem Host-Computer wieder zusammengefügt werden. Außerdem können Kopfabschnitte solcher Pakete vielmehr gemeinsam als seriell verarbeitet werden. Und die Verarbeitung von Paketen von verschiedenen Datagrammen durch einen Host-Computer mit mehreren Prozessoren kann unter den Prozessoren geteilt oder verteilt werden. Daher besteht ein Ziel einer dynamischen syntaktischen Kopf-Analyseoperation darin, ein Protokoll zu identifizieren, gemäß dem ein empfangenes Paket formatiert wurde, oder zu bestimmen, ob ein Paketkopf einem speziellen Protokoll entspricht.
10, die kurz im Einzelnen erörtert wird, stellt eine erläuternde Reihe von Befehlen zum syntaktisch Analysieren der Köpfe der Schicht zwei, drei und vier eines Pakets dar, um festzustellen, ob sie Ethernet, IP bzw. TCP sind. Die dargestellten Befehle umfassen ein mögliches Programm oder einen möglichen Mikrocode zum Durchführen einer syntaktischen Analyseoperation. Wie ein Fachmann erkennen wird, können, nachdem ein spezieller Satz von Befehlen zur syntaktischen Analyse in einen Parser-Speicher geladen ist, eine Anzahl von verschiedenen Programmen zusammengesetzt werden. 10 stellt somit nur eines von einer Anzahl von Programmen dar, die aus den gespeicherten Befehlen erzeugt werden können. Die in 10 dargestellten Befehle können von einer Mikroablaufsteuereinheit, einem Prozessor, einem Mikroprozessor oder einem anderen ähnlichen Modul, das sich innerhalb der Netzschnittstellenschaltung befindet, durchgeführt oder ausgeführt werden.
Insbesondere können andere Befehlssätze und andere Programme für verschiedene Kommunikationsprotokolle abgeleitet werden und können auf andere Schichten eines Protokollprofils erweitert werden. Ein Satz von Befehlen kann beispielsweise zum syntaktischen Analysieren von NFS-Paketen (Netzdateisystem-Paketen) erzeugt werden. Erläuternd würden diese Befehle konfiguriert werden, um Köpfe der Schicht fünf und sechs syntaktisch zu analysieren, um festzustellen, ob sie entfernter Prozeduraufruf (RPC) bzw. externe Datendarstellung (XDR) sind. Andere Befehle könnten dazu konfiguriert sein, einen Abschnitt der Daten des Pakets (die als Schicht sieben betrachtet werden können) syntaktisch zu analysieren. Ein NFS-Kopf kann als Teil des Protokollkopfs der Schicht sechs eines Pakets oder als Teil der Daten des Pakets betrachtet werden.
Eine Art von Befehl, der von einer Mikroablaufsteuereinheit ausgeführt wird, kann dazu ausgelegt sein, ein spezielles Feld eines Pakets (z. B. in einem speziellen Versatz innerhalb des Pakets) aufzufinden und den in diesem Versatz gespeicherten Wert mit einem Wert zu vergleichen, der diesem Feld in einem speziellen Kommunikationsprotokoll zugeordnet ist. Ein Befehl kann beispielsweise erfordern, dass die Mikroablaufsteuereinheit einen Wert in einem Paketkopf in einem Versatz untersucht, der einem Typenfeld eines Ethernet-Kopfs entsprechen würde. Durch Vergleichen des aktuell im Paket gespeicherten Werts mit dem für das Protokoll erwarteten Wert kann die Mikroablaufsteuereinheit feststellen, ob das Paket dem Ethernet-Protokoll zu entsprechen scheint. Erläuternd hängt der nächste Befehl, der im Programm zur syntaktischen Analyse angewendet wird, davon ab, ob der vorherige Vergleich erfolgreich war. Folglich hängen die speziellen Befehle, die von der Mikroablaufsteuereinheit angewendet werden, und die Folge, in der sie angewendet werden, davon ab, welche Protokolle durch die Köpfe des Pakets dargestellt werden.
Die Mikroablaufsteuereinheit kann einen oder mehrere Feldwerte innerhalb jedes in einem Paket enthaltenen Kopfs testen. Je mehr Felder getestet werden und als dem Format eines bekannten Protokolls entsprechend festgestellt werden, desto größer ist die Sicherheit, dass das Paket diesem Protokoll entspricht. Wie ein Fachmann erkennen wird, kann ein Kommunikationsprotokoll ziemlich anders sein als ein anderes Protokoll, was folglich eine Untersuchung von verschiedenen Teilen der Paketköpfe für verschiedene Protokolle erfordert. Erläuternd kann die syntaktisch Analyse eines Pakets im Fall eines Fehlers enden, oder da festgestellt wurde, dass das syntaktisch analysierte Paket dem (den) Protokoll(en), für das (die) die Befehle ausgelegt sind, entspricht oder nicht.
Jeder Befehl in 10 kann durch eine Zahl und/oder einen Namen identifiziert sein. Ein spezieller Befehl kann eine Vielzahl von anderen Aufgaben als das Vergleichen eines Kopffeldes mit einem erwarteten Wert durchführen. Ein Befehl kann beispielsweise einen anderen Befehl aufrufen, um einen anderen Abschnitt eines Paketkopfs zu untersuchen, ein Register oder eine anderen Datenstruktur initialisieren, laden oder konfigurieren, auf die Ankunft und syntaktische Analyse eines anderen Pakets vorbereiten usw. Insbesondere kann ein Register oder eine andere Speicherstruktur in Erwartung einer Operation konfiguriert sein, die in der Netzschnittstelle durchgeführt wird, nachdem das Paket syntaktisch analysiert ist. Ein Programmbefehl in 10 kann beispielsweise eine Ausgabeoperation identifizieren, die in Abhängigkeit vom Erfolg oder Fehlschlag des Vergleichs eines aus einem Paket extrahierten Werts mit einem erwarteten Wert durchgeführt werden kann oder nicht. Eine Ausgabeoperation kann einen Wert in einem Register speichern, ein Register für eine Operation nach der syntaktischen Analyse konfigurieren (z. B. ein Argument oder einen Operator laden), ein Register löschen, um ein neues Paket zu erwarten, usw.
Ein Zeiger kann verwendet werden, um einen Versatz in ein syntaktisch analysiertes Paket zu identifizieren. In einer Ausführungsform wird ein solcher Zeiger anfänglich am Beginn des Protokollkopfs der Schicht zwei angeordnet. In einer weiteren Ausführungsform befindet sich jedoch der Zeiger an einer speziellen Stelle innerhalb eines speziellen Kopfs (z. B. unmittelbar nach den Ziel- und/oder Quelladressen der Schicht zwei), wenn die syntaktische Analyse beginnt. Erläuternd wird der Zeiger durch das Paket inkrementiert, wenn die Prozedur der syntaktischen Analyse ausgeführt wird. In einer alternativen Ausführungsform können jedoch Versätze zu interessierenden Bereichen im Paket aus einer oder mehreren bekannten oder berechneten Stellen berechnet werden.
In dem in 10 dargestellten Programm zur syntaktischen Analyse wird durch einen Kopf in Inkrementen von zwei Bytes (z. B. Sechzehn-Bit-Worten) navigiert (z. B. wird der Zeiger vorgeschoben). Wenn ein spezielles Feld eines Kopfs mit einem bekannten oder erwarteten Wert verglichen wird, werden außerdem bis zu zwei Bytes auf einmal aus dem Feld extrahiert. Wenn ein Wert- oder Kopffeld für die Speicherung in einem Register oder einer anderen Datenstruktur kopiert wird, kann ferner die Menge an Daten, die in einer Operation kopiert werden können, in Mehrfachen von Zwei-Byte-Einheiten oder vollkommen in anderen Einheiten (z. B. einzelnen Bytes) ausgedrückt werden. Diese Maßeinheit (z. B. zwei Bytes) kann in einer alternativen Ausführungsform der Erfindung erhöht oder verringert werden. Das Ändern der Maßeinheit kann die Genauigkeit ändern, mit der ein Kopf syntaktisch analysiert werden kann oder ein Kopfwert extrahiert werden kann.
In der Ausführungsform der Erfindung, die in 10 dargestellt ist, umfasst ein Satz von Befehlen, die in den Befehlsspeicher des Kopf-Parsers geladen werden, eine Anzahl von möglichen Operationen, die durchgeführt werden sollen, während ein Paket auf Kompatibilität mit ausgewählten Protokollen getestet wird. Das Programm 1000 wird aus dem Befehlssatz erzeugt. Das Programm 1000 ist folglich nur ein mögliches Programm, ein Mikrocode oder eine Folge von Befehlen, die aus dem verfügbaren Befehlssatz gebildet werden können.
In dieser Ausführungsform ermöglicht der geladene Befehlssatz die folgenden sechzehn Operationen, die an einem Paket durchgeführt werden können, das syntaktisch analysiert wird. Spezielle Implementierungen dieser Operationen im Programm 1000 werden nachstehend in zusätzlichem Detail erörtert. Diese Befehle werden als erläuternd in der Art verstanden und begrenzen die Zusammensetzung von Befehlssätzen in anderen Ausführungsformen der Erfindung nicht. Außerdem kann eine beliebige Teilmenge dieser Operationen in einem speziellen Programm oder Mikrocode zur syntaktischen Analyse verwendet werden. Ferner können mehrere Befehle dieselbe Operation verwenden und verschiedene Effekte aufweisen.
Eine CLR_REG-Operation ermöglicht die selektive Initialisierung von Registern oder anderen Datenstrukturen, die im Programm 1000 verwendet werden, und möglicherweise Datenstrukturen, die in Funktionen verwendet werden, die durchgeführt werden, nachdem ein Paket syntaktisch analysiert ist. Die Initialisierung kann das Speichern des Werts Null umfassen. Eine Anzahl von erläuternden Registern, die durch eine CLR_REG-Operation initialisiert werden können, werden in den restlichen Operationen identifiziert.
Eine LD_FID-Operation kopiert eine variable Menge an Daten von einem speziellen Versatz innerhalb des Pakets in ein Register, das dazu konfiguriert ist, den Flussschlüssel oder einen anderen Flussidentifizierer eines Pakets zu speichern. Dieses Register kann als FLOWID-Register bezeichnet werden. Der Effekt 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 vorher gespeicherten Flussschlüsseldaten angehängt.
Eine LD_SEQ-Operation kopiert eine variable Menge an Daten von einem speziellen Versatz innerhalb des Pakets in ein Register, das dazu konfiguriert ist, die Folgenummer eines Pakets (z. B. eine TCP-Folgenummer) zu speichern. Diesem Register kann die Bezeichnung SEQNO zugeordnet werden. Diese Operation ist auch kumulativ – der zweite und die nachfolgenden Aufrufe dieser Operation für das Paket bewirken, dass die identifizierten Daten an vorher gespeicherte Daten angehängt werden.
Eine LD_CTL-Operation lädt einen Wert vom festgelegten Versatz im Paket in ein CONTROL-Register. Das CONTROL-Register kann einen Steuerindikator zum Identifizieren, ob ein Paket für die erneute Datenzusammenfassung, die Paketstapelverarbeitung, die Lastverteilung oder andere verbesserte Funktionen der NIC 100 geeignet ist, umfassen. Insbesondere kann ein Steuerindikator angeben, ob ein No_Assist-Flag für das Paket geschaffen werden sollte, ob das Paket irgendwelche Daten umfasst, ob die Menge von Paketdaten größer ist als eine vorbestimmte Schwelle usw. Folglich kann sich der in ein CONTROL-Register in einer LD_CTL-Operation geladene Wert auf die Bearbeitung des Pakets nach der syntaktischen Analyse auswirken.
Eine LD_SAP-Operation lädt einen Wert in das CONTROL-Register von einem variablen Versatz innerhalb des Pakets. Der geladene Wert kann den Ethertyp des Pakets umfassen. In einer Option, die einer LD_SAP-Operation zugeordnet sein kann, kann der Versatz des Kopfs der Schicht drei des Pakets auch im CONTROL-Register oder anderswo gespeichert werden. Wie ein Fachmann erkennen wird, kann der Kopf der Schicht drei eines Pakets unmittelbar seinem Ethertyp-Feld der Schicht zwei folgen, wenn das Paket dem Ethernet- und dem IP-Protokoll entspricht.
Eine LD_R1-Operation kann verwendet werden, um einen Wert in ein temporäres Register (z. B. R1 genannt) von einem variablen Versatz innerhalb des Pakets zu laden. Ein temporäres Register kann für eine Vielzahl von Aufgaben, wie z. B. Akkumulation von Werten, um die Länge eines Kopfs oder eines anderen Abschnitts des Pakets zu bestimmen, verwendet werden. Eine LD_R1-Operation kann auch bewirken, dass ein Wert von einem anderen variablen Versatz in einem zweiten temporären Register (z. B. R2 genannt) gespeichert wird. Die in den R1- und/oder R2-Registern während der syntaktischen Analyse eines Pakets gespeicherten Werte können kumulativ sein oder nicht.
Eine LD_R3-Operation kann einen Wert vom Paket in ein Register laden, das dazu konfiguriert ist, die Stelle des Kopfs der Schicht drei des Pakets zu speichern. Dieses Register kann L3OFFSET genannt werden. In einem optionalen Verfahren zum Aufrufen dieser Operation kann es verwendet werden, um einen festen Wert in das L3OFFSET-Register zu laden. Als weitere Option kann die LD_L3-Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert, der im L3OFFSET-Register gespeichert wird, addieren.
Eine LD_SUM-Operation speichert den Startpunkt innerhalb des Pakets, ab dem eine Prüfsumme berechnet werden sollte. Das Register, in dem dieser Wert gespeichert wird, kann CSUMSTART-Register genannt werden. Bei einem alternativen Aufruf dieser Operation wird ein fester oder vorbestimmter Wert im Register gespeichert. Als weitere Option kann die LD_SUM-Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert, der im CSUMSTART-Register gespeichert wird, addieren.
Eine LD_HDR-Operation lädt einen Wert in ein Register, das dazu konfiguriert ist, die Stelle innerhalb des Pakets zu speichern, an der der Kopfabschnitt aufgeteilt werden kann. Der Wert, der gespeichert wird, kann beispielsweise während der Übertragung des Pakets zum Host-Computer verwendet werden, um einen Datenabschnitt des Pakets an einer separaten Stelle vom Kopfabschnitt zu speichern. Der geladene Wert kann folglich den Beginn der Paketdaten oder den Beginn eines speziellen Kopfs identifizieren. In einem Aufruf einer LD_HDR-Operation kann der gespeicherte Wert aus einer vorliegenden Position eines vorstehend beschriebenen Zeigers zur syntaktischen Analyse berechnet werden. Bei einem weiteren Aufruf kann ein fester oder vorbestimmter Wert gespeichert werden. Als noch weitere Alternative kann ein in einem temporären Register (z. B. R1) gespeicherter Wert und/oder eine Konstante zum geladenen Wert addiert 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 vorbestimmten Wert an die existierenden Inhalte des vorstehend beschriebenen FLOWID-Registers an oder fügt ihn hinzu.
Eine IM_SEQ-Operation hängt einen festen oder vorbestimmten Wert an die Inhalte des vorstehend beschriebenen SEQNO-Registers an oder fügt ihn hinzu.
Eine IM_SAP-Operation lädt oder speichert einen festen oder vorbestimmten Wert im vorstehend beschriebenen CSUMSTART-Register.
Eine IM_R1-Operation kann einen vorbestimmten Wert in einem oder mehreren temporären Registern (z. B. R1, R2) addieren oder laden.
Eine IM_CTL-Operation lädt oder speichert einen festen oder vorbestimmten Wert im vorstehend beschriebenen CONTROL-Register.
Eine ST_FLAG-Operation lädt einen Wert von einem festgelegten Versatz im Paket in ein FLAGS-Register. Der geladene Wert kann ein oder mehrere Felder oder Flags von einem Paketkopf umfassen.
Ein Fachmann wird erkennen, dass die den vorstehend beschriebenen Operationen und Registern und anderswo in diesem Abschnitt zugewiesenen Bezeichnungen in der Art nur erläuternd sind und in keiner Weise die Operationen und Befehle zur syntaktischen Analyse, die in anderen Ausführungsformen der Erfindung verwendet werden können, begrenzen.
Die Befehle im Programm 1000 umfassen ein Befehlsnummerfeld 1002, das eine Nummer eines Befehls innerhalb des Programms enthält, und ein Befehlsnamenfeld 1004, das einen Namen eines Befehls enthält. In einer alternativen Ausführungsform der Erfindung können die Befehlsnummer- und Befehlsnamenfelder kombiniert werden oder eines von ihnen kann weggelassen werden.
Das Befehlsinhaltsfeld 1006 umfasst mehrere Abschnitte zum Ausführen eines Befehls. Ein "Extraktionsmasken"-Abschnitt eines Befehls ist eine Zwei-Byte- Maske in Hexadezimalschreibweise. Eine Extraktionsmaske identifiziert einen zu kopierenden oder zu extrahierenden Abschnitt eines Paketkopfs, der vom aktuellen Paketversatz (z. B. der aktuellen Position des Zeigers zur syntaktischen Analyse) beginnt. Erläuternd wird jedes Bit im Kopf des Pakets, das einer Eins im Hexadezimalwert entspricht, zum Vergleich mit einem Vergleichs- oder Testwert kopiert. Ein Wert von 0xFF00 im Extraktionsmaskenabschnitt eines Befehls bedeutet beispielsweise, dass das ganze erste Byte am aktuellen Paketversatz kopiert werden soll und dass die Inhalte des zweiten Bytes irrelevant sind. Ebenso bedeutet eine Extraktionsmaske von 0x3FFF, dass alle bis auf die zwei höchstwertigen Bits des ersten Bytes kopiert werden sollen. Ein Zwei-Byte-Wert wird aus den extrahierten Inhalten unter Verwendung dessen, was auch immer aus dem Paket kopiert wird, konstruiert. Erläuternd wird der Rest des Werts mit Nullen aufgefüllt. Ein Fachmann wird erkennen, dass das Format einer Extraktionsmaske (oder einer Ausgabemaske, die nachstehend beschrieben wird) nach Bedarf eingestellt werden kann, um eine Little-Endian- oder Big-Endian-Darstellung zu reflektieren.
Ein oder mehrere Befehle in einem Programm zur syntaktischen Analyse können keine Daten erfordern, die aus dem Paket an der Zeigerstelle extrahiert werden, um seine Ausgabeoperation durchführen zu können. Diese Befehle können einen Extraktionsmaskenwert von 0x0000 aufweisen, um anzugeben, dass, obwohl ein Zwei-Byte-Wert immer noch aus der Zeigerposition wiedergewonnen wird, jedes Bit des Werts maskiert wird. Eine solche Extraktionsmaske ergibt folglich einen endgültigen Wert von Null. Dieser Typ von Befehl kann verwendet werden, wenn beispielsweise eine Ausgabeoperation durchgeführt werden muss, bevor ein weiterer wesentlicher Abschnitt von Kopfdaten mit einer anderen Extraktionsmaske als 0x0000 extrahiert wird.
Ein "Vergleichswert"-Abschnitt eines Befehls ist ein Zwei-Byte-Hexadezimalwert, mit dem die extrahierten Paketinhalte verglichen werden sollen. Der Vergleichswert kann ein bekannter Wert sein, der in einem speziellen Feld eines speziellen Protokollkopfs gespeichert werden soll. Der Vergleichswert kann einen Wert umfassen, dem der extrahierte Abschnitt des Kopfs entsprechen sollte oder zu dem er eine festgelegte Beziehung aufweisen sollte, damit das Paket als mit den vorgewählten Protokollen kompatibel betrachtet wird.
Ein "Operator"-Abschnitt eines Befehls identifiziert einen Operator, der angibt, wie die extrahierten und Vergleichswerte verglichen werden sollen. Erläuternd bedeutet EQ, dass sie auf Gleichheit getestet werden, NE bedeutet, dass sie auf Ungleichheit getestet werden, LT bedeutet, dass der extrahierte Wert geringer sein muss als der Vergleichswert, damit der Vergleich Erfolg hat, GE bedeutet, dass der extrahierte Wert größer als oder gleich dem Vergleichswert sein muss, usw. Ein Befehl, der auf die Ankunft eines syntaktisch zu analysierenden neuen Pakets wartet, kann eine Operation von NP verwenden. Andere Operatoren für andere Funktionen können hinzugefügt werden und die existierenden Operatoren können anderen Monikern zugewiesen werden.
Ein "Erfolgsversatz"-Abschnitt eines Befehls gibt die Anzahl von Zwei-Byte-Einheiten an, die der Zeiger vorzuschieben ist, wenn der Vergleich zwischen dem extrahierten und dem Testwert Erfolg hat. Ein "Erfolgsbefehls"-Abschnitt eines Befehls identifiziert den nächsten auszuführenden Befehl im Programm 1000, wenn der Vergleich erfolgreich ist.
Ebenso geben "Fehlschlagversatz"- und "Fehlschlagbefehls"-Abschnitte die Anzahl von Zwei-Byte-Einheiten zum Vorschieben des Zeigers bzw. den nächsten auszuführenden Befehl an, wenn der Vergleich fehlschlägt. Obwohl Versätze in Einheiten von zwei Bytes (z. B. Sechzehn-Bit-Worten) in dieser Ausführungsform der Erfindung ausgedrückt werden, können sie in einer alternativen Ausführungsform der Erfindung kleinere oder größere Einheiten sein. Wie vorstehend erwähnt, kann ein Befehl ferner durch eine Zahl oder einen Namen identifiziert werden.
Nicht alle der Befehle in einem Programm werden notwendigerweise für jedes Paket, das syntaktisch analysiert wird, verwendet. Ein Programm kann beispielsweise Befehle zum Testen auf mehr als einen Typen oder eine Version eines Protokolls auf einer speziellen Schicht umfassen. Insbesondere testet das Programm 1000 auf entweder die Version vier oder sechs des IP-Protokolls auf der Schicht drei. Die Befehle, die tatsächlich für ein gegebenes Paket ausgeführt werden, hängen folglich vom Format des Pakets ab. Sobald ein Paket so weit wie möglich mit einem gegebenen Programm syntaktisch analysiert wurde oder festgestellt wurde, dass das Paket einem ausgewählten Protokoll entspricht oder nicht, kann die syntaktische Analyse stoppen oder ein Befehl zum Anhalten der Prozedur der syntaktischen Analyse kann ausgeführt werden. Erläuternd gibt ein nächster Befehlsabschnitt eines Befehls (z. B. "Erfolgsbefehl" oder "Fehlschlag befehl") mit dem Wert "DONE" die Beendung der syntaktischen Analyse eines Pakets an. Ein DONE- oder ein ähnlicher Befehl kann ein Scheinbefehl sein. Mit andren Worten, "DONE" kann einfach bedeuten, dass die syntaktische Analyse für das vorliegenden Paket beendet werden soll. Oder wie der Befehl achtzehn des Programms 1000 kann ein DONE-Befehl eine gewisse Handlung unternehmen, um auf ein neues Paket zu warten (z. B. durch Initialisieren eines Registers).
Die restlichen Abschnitte des Befehlsinhaltsfeldes 1006 werden verwendet, um eine Ausgabe- oder andere Datenspeicheroperation festzulegen und zu vollenden. Insbesondere entspricht in dieser Ausführungsform ein "Ausgabeoperations"-Abschnitt eines Befehls den im geladenen Befehlssatz enthaltenen Operationen. Für das Programm 1000 identifiziert folglich der Ausgabeoperationsabschnitt eines Befehls eine der vorstehend beschriebenen sechzehn Operationen. Die im Programm 1000 verwendeten Ausgabeoperationen werden nachstehend in Verbindung mit einzelnen Befehlen weiter beschrieben.
Ein "Operationsargument"-Abschnitt eines Befehls umfasst ein oder mehrere Argumente oder Felder, die in Verbindung mit der Ausgabeoperation des Befehls gespeichert, geladen oder anderweitig verwendet werden sollen. Erläuternd nimmt der Operationsargumentabschnitt die Form eines Hexadezimalwerts mit mehreren Bits an. Für das Programm 1000 sind die Operationsargumente elf Bits groß. Ein Argument oder Abschnitt eines Arguments kann verschiedene Bedeutungen in Abhängigkeit von der Ausgabeoperation aufweisen. Ein Operationsargument kann beispielsweise einen oder mehrere Zahlenwerte umfassen, die in einem Register gespeichert werden sollen oder verwendet werden sollen, um einen Abschnitt eines Kopfs aufzufinden oder zu begrenzen. Oder ein Argumentbit kann ein Flag umfassen, um eine Handlung oder einen Status zu signalisieren. Insbesondere kann ein Argumentbit festlegen, dass ein spezielles Register zurückgesetzt werden soll; ein Satz von Argumentbits kann einen Versatz in einen Paketkopf zu einem in einem Register zu speichernden Wert umfassen, usw. Erläuternd wird der durch ein Operationsargument festgelegte Versatz auf die Stelle der Zeigerposition zur syntaktischen Analyse angewendet, bevor der Zeiger vorgeschoben wird, wie durch den anwendbaren Erfolgsversatz oder Fehlschlagversatz festgelegt. Die im Programm 1000 verwendeten Operationsargumente werden nachstehend genauer erläutert.
Ein "Operationsfreigabe"-Abschnitt eines Befehlsinhaltsfeldes legt fest, ob oder wann eine Ausgabeoperation eines Befehls durchgeführt werden soll. Insbesondere kann in der dargestellten Ausführungsform der Erfindung eine Ausgabeoperation eines Befehls in Abhängigkeit vom Ergebnis des Vergleichs zwischen einem aus einem Kopf extrahierten Wert und dem Vergleichswert durchgeführt werden oder nicht. Eine Ausgabefreigabe kann beispielsweise auf einen festen Wert (z. B. Null) gesetzt werden, wenn die Ausgabeoperation niemals durchgeführt werden soll. Sie kann verschiedene Werte annehmen, wenn sie nur dann durchgeführt werden soll, wenn der Vergleich den Operator (z. B. eins bzw. zwei) erfüllt oder nicht. Eine Operationsfreigabe kann noch einen anderen Wert (z. B. drei) annehmen, wenn sie immer durchgeführt werden soll.
Ein "Verschiebungs"-Abschnitt eines Befehls umfasst einen Wert, der angibt, wie ein Ausgabewert verschoben werden soll. Eine Verschiebung kann erforderlich sein, da verschiedene Protokolle manchmal erfordern, dass Werte unterschiedlich formatiert werden. Außerdem kann ein Wert, der eine Länge oder Stelle eines Kopfs oder Kopffeldes angibt, eine Verschiebung erfordern, um die durch den Wert dargestellte geeignete Größe zu reflektieren. Da das Programm 1000 beispielsweise dazu ausgelegt ist, Zwei-Byte-Einheiten zu verwenden, kann ein Wert verschoben werden müssen, wenn er andere Einheiten (z. B. Bytes) reflektieren soll. Ein Verschiebungswert in einer vorliegenden Ausführungsform gibt die Anzahl von Positionen (z. B. Bits) zur Rechtsverschiebung eines Ausgabewerts an. In einer anderen Ausführungsform der Erfindung kann ein Verschiebungswert eine andere Verschiebungsart oder -richtung darstellen.
Schließlich legt eine "Ausgabemaske" fest, wie ein in einem Register oder einer anderen Datenstruktur gespeicherter Wert formatiert werden soll. Wie vorstehend angegeben, kann eine Ausgabeoperation erfordern, dass ein extrahierter, berechneter oder zusammengesetzter Wert gespeichert wird. Ähnlich der Extraktionsmaske ist die Ausgabemaske ein Zwei-Byte-Hexadezimalwert. Für jede Position in der Ausgabemaske, die eine Eins enthält, soll in dieser Ausführungsform der Erfindung das entsprechende Bit in dem Zwei-Byte-Wert, der durch die Ausgabeoperation und/oder das Operationsargument identifiziert wird, gespeichert werden. Ein Wert von 0xFFFF gibt beispielsweise an, dass der festgelegte Zwei-Byte-Wert so gespeichert werden soll. Erläuternd 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 höchstwertigen vier Bits des ersten Bytes gespeichert werden sollen, aber der Rest des gespeicherten Werts irrelevant ist und mit Nullen aufgefüllt werden kann.
Eine Ausgabeoperation von "NONE" kann verwendet werden, um anzugeben, dass keine Ausgabeoperation durchgeführt oder gespeichert werden soll, in welchem Fall andere Befehlsabschnitte, die die Ausgabe betreffen, ignoriert werden können oder einen festgelegten Wert (z. B. lauter Nullen) umfassen können. In dem in 10 dargestellten Programm kann jedoch eine CLR_REG-Ausgabeoperation, die die selektive erneute Initialisierung von Registern ermöglicht, mit einem Operationsargument von Null verwendet werden, um effektiv keine Ausgabe durchzuführen. Insbesondere gibt ein Operationsargument von Null für die CLR_REG-Operation an, dass keine Register zurückgesetzt werden sollen. In einer alternativen Ausführungsform der Erfindung könnte ein Operationsfreigabeabschnitt eines Befehls auf einen Wert (z. B. Null) gesetzt werden, der angibt, dass die Ausgabeoperation niemals durchgeführt werden soll.
Das Format und die Folge von Befehlen in 10 wird als nur ein Verfahren zum syntaktischen Analysieren eines Pakets darstellend verstanden, um festzustellen, ob es einem speziellen Kommunikationsprotokoll entspricht. Insbesondere sind die Befehle dazu ausgelegt, einen oder mehrere Abschnitte von einem oder mehreren Paketköpfen zum Vergleich mit bekannten oder erwarteten Werten zu untersuchen und ein Register oder eine andere Speicherstelle nach Bedarf zu konfigurieren oder zu laden. Wie ein Fachmann erkennen wird, können Befehle zum syntaktischen Analysieren eines Pakets eine beliebige von einer Anzahl von Formen annehmen und in einer Vielzahl von Folgen durchgeführt werden, ohne den Schutzbereich der Erfindung zu überschreiten.
Mit Bezug nun auf 10 können Befehle im Programm 1000 im Einzelnen beschrieben werden. Vor der Ausführung des in 10 dargestellten Programms befindet sich ein Zeiger zur syntaktischen Analyse am Beginn des Kopfs der Schicht zwei eines Pakets. Die Position des Zeigers zur syntaktischen Analyse kann in einem Register zur leichten Bezugnahme und Aktualisierung während der syntaktischen Analyseprozedur gespeichert werden. Insbesondere kann die Position des Zeigers zur syntaktischen Analyse als Versatz (z. B. vom Beginn des Kopfs der Schicht zwei) beim Berechnen der Position einer speziellen Position innerhalb eines Kopfs verwendet werden.
Das Programm 1000 beginnt mit einem WAIT-Befehl (z. B. Befehl Null), der auf ein neues Paket wartet (z. B. durch den Operator NT angegeben) und, wenn eines empfangen wird, einen Zeiger zur syntaktischen Analyse auf das zwölfte Byte des Kopfs der Schicht zwei setzt. Dieser Versatz zum zwölften Byte wird durch den Erfolgsversatzabschnitt des Befehls angegeben. Bis ein Paket empfangen wird, durchläuft der WAIT-Befehl eine Schleife auf sich. Außerdem wird eine CLR_REG-Operation durchgeführt, aber die Operationsfreigabeeinstellung gibt an, dass sie nur durchgeführt wird, wenn der Vergleich Erfolg hat (z. B. wenn ein neues Paket empfangen wird).
Die festgelegte CLR_REG-Operation arbeitet gemäß dem Operationsargument (d. h. 0x3FF) des WAIT-Befehls. In dieser Ausführungsform entspricht jedes Bit des Arguments einem Register oder einer anderen Datenstruktur. Die in dieser Operation initialisierten Register können die folgenden umfassen: ADDR (z. B. zum Speichern der Adresse oder Stelle des Zeigers zur syntaktischen Analyse), FLOWID (z. B. zum Speichern des Flussschlüssels des Pakets), SEQNO (z. B. zum Speichern einer TCP-Folgenummer), SAP (z. B. der Ethertyp des Pakets) und PAYLOADLEN (z. B. Nutzinformationslänge). Die folgenden Register, die zum Speichern gewisser Versätze konfiguriert sind, können auch zurückgesetzt werden: FLOWOFF (z. B. Versatz innerhalb des FLOWID-Registers), SEQOFF (z. B. Versatz innerhalb des SEQNO-Registers), L3OFFSET (z. B. Versatz des Kopfs der Schicht drei des Pakets), HDRSPLIT (z. B. Stelle zum Aufteilen des Pakets) und CSUMSTART (z. B. Startstelle zum Berechnen einer Prüfsumme). Ein oder mehrere Status- oder Steuerindikatoren (z. B. CONTROL- oder FLAGS-Register) zum Melden des Status von einem oder mehreren Flags eines Paketkopfs können auch zurückgesetzt werden. Außerdem können ein oder mehrere temporäre Register (z. B. R1, R2) oder andere Datenstrukturen auch initialisiert werden. Diese Register erläutern nur die Datenstrukturen, die in einer Ausführungsform der Erfindung verwendet werden können. Andere Datenstrukturen können in anderen Ausführungsformen für dieselben oder andere Ausgabeoperationen verwendet werden.
Temporäre Register wie z. B. R1 und/oder R2 können im Programm 1000 verwendet werden, um verschiedene Köpfe und Kopffelder zu verfolgen. Ein Fachmann wird die Anzahl von möglichen Kombinationen von Kommunikationsprotokollen und die Wirkung dieser verschiedenen Kombinationen auf die Struktur und das Format der Köpfe eines Pakets erkennen. Mehr Informationen können untersucht oder von einem Paket gesammelt werden müssen, das einem Protokoll oder Satz von Protokollen entspricht, als von einem Paket, das einem anderen Protokoll oder Satz von Protokollen entspricht. Wenn beispielsweise Erweiterungsköpfe mit einem Internetprotokoll-Kopf verwendet werden, können Werte von diesen Erweiterungsköpfen und/oder ihre Längen gespeichert werden müssen, wobei die Werte nicht erforderlich sind, wenn Erweiterungsköpfe nicht verwendet werden. Wenn ein spezieller Versatz berechnet wird, wie beispielsweise ein Versatz zum Beginn des Datenabschnitts eines Pakets, können mehrere Register gewartet werden müssen und ihre Werte kombiniert oder addiert werden müssen. In diesem Beispiel kann ein Register oder temporäres Register die Größe oder das Format eines Erweiterungskopfs verfolgen, während ein anderes Register den Basis-IP-Kopf verfolgt.
Der Befehl VLAN (z. B. Befehl eins) untersucht das Zwei-Byte-Feld in der Zeigerposition zur syntaktischen Analyse (möglicherweise ein Typen-, Längen- oder TPID-Feld) auf einen Wert, der einen mit VLAN gekennzeichneten Kopf (z. B. 8100 in Hexadezimal) angibt. Wenn der Kopf mit VLAN gekennzeichnet ist, wird der Zeiger um ein paar Bytes (z. B. eine Zwei-Byte-Einheit) inkrementiert und die Ausführung fährt mit dem Befehl CFI fort; ansonsten fährt die Ausführung mit dem Befehl 802.3 fort. In jedem Fall gibt die Operationsfreigabe des Befehls an, dass eine IM_CTL-Operation immer durchgeführt werden soll.
Wie vorstehend beschrieben, bewirkt eine IM_CTL-Operation, dass ein Steuerregister oder andere Datenstruktur mit einem oder mehreren Flags belegt wird, um den Status oder die Bedingung eines Pakets zu melden. Ein Steuerindikator kann angeben, ob ein Paket für eine 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 die Größe des Datenabschnitts eine festgelegte Schwelle überschreitet. Das Operationsargument 0x00A für den Befehl VLAN umfasst den im Steuerregister zu speichernden Wert, wobei einzelne Bits des Arguments speziellen Flags entsprechen. Erläuternd können die den gerade beschriebenen Bedingungen zugeordneten Flags in dieser IM_CTL-Operation auf Eins oder Wahr gesetzt werden.
Der Befehl CFI (z. B. Befehl zwei) untersucht das CFI-Bit oder -Flag in einem Kopf 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 und die syntaktische Analyseprozedur endet mit dem Aufruf des Befehls DONE (z. B. Befehl achtzehn). Wenn das CFI-Bit nicht gesetzt ist, dann wird der Zeiger um ein weiteres Paar von Bytes inkrementiert und die Ausführung fährt mit dem Befehl 802.3 fort. Wie vorstehend erläutert, gibt eine Null-Ausgabeoperation (z. B. "NONE") an, dass keine Ausgabeoperation durchgeführt wird. Außerdem stellt der Ausgabefreigabewert (z. B. Null) ferner sicher, dass keine Ausgabeoperation durchgeführt wird.
Im Befehl 802.3 (z. B. Befehl drei) wird ein Typen- oder Längenfeld (in Abhängigkeit von der Stelle des Zeigers und vom Format des Pakets) untersucht, um festzustellen, ob das Format der Schicht zwei des Pakets das herkömmliche Ethernet oder 802.3 Ethernet ist. Wenn der Wert im Kopffeld 802.3 Ethernet anzugeben scheint (z. B. einen Hexadezimalwert enthält, der geringer ist als 0600), wird der Zeiger um zwei Bytes inkrementiert (auf das, was ein LLC-SNAP-Feld sein sollte) und die Ausführung fährt mit dem Befehl LLC_1 fort. Ansonsten kann das Protokoll der Schicht zwei als herkömmliches Ethernet betrachtet werden und die Ausführung fährt mit dem Befehl IPV4_1 fort. Der Befehl 802.3 in dieser Ausführungsform der Erfindung umfasst keine Ausgabeoperation.
In den Befehlen LLC_1 und LLC_2 (z. B. Befehle vier und fünf) wird ein verdächtiges LLC-SNAP-Feld der Schicht zwei untersucht, um sicherzustellen, dass das Paket dem 802.3-Ethernet-Protokoll entspricht. Im Befehl LLC_1 wird ein erster Teil des Feldes getestet und, wenn es erfolgreich ist, wird der Zeiger um zwei Bytes inkrementiert und ein zweiter Teil wird im Befehl LLC_2 getestet. Wenn der Befehl LLC_2 erfolgreich ist, wird der Zeiger zur syntaktischen Analyse um vier Bytes vorgeschoben, um das zu erreichen, was ein Typenfeld sein sollte, und die Ausführung fährt mit dem Befehl IPV4_1 fort. Wenn ein Test misslingt, tritt jedoch die syntaktische Analyseprozedur aus. In der dargestellten Ausführungsform der Erfindung wird keine Ausgabeoperation durchgeführt, während das LLC-SNAP-Feld getestet wird.
Im Befehl IPV4_1 (z. B. Befehl sechs) sollte der Zeiger zur syntaktischen Analyse an einem Ethernet-Typ-Feld liegen. Dieses Feld wird untersucht, um festzustellen, ob das Protokoll der Schicht drei der Version vier des Internetprotokolls zu entsprechen scheint. Wenn dieser Test erfolgreich ist (z. B. das Typenfeld einen Hexadezimalwert von 0800 enthält), wird der Zeiger um zwei Bytes zum Beginn des Kopfs der Schicht drei vorgeschoben und die Ausführung des Programms 1000 fährt mit dem Befehl IPV4_2 fort. Wenn der Test nicht erfolgreich ist, dann fährt die Ausführung mit dem Befehl IPV6_1 fort. Ungeachtet der Testergebnisse gibt der Operationsfreigabewert (z. B. drei) an, dass die festgelegte LD_SAP-Ausgabeoperation immer durchgeführt wird.
Wie vorher beschrieben, wird in einer LD_SAP-Operation der Ethertyp eines Pakets (oder Dienstzugriffspunkt) in einem Register gespeichert. Ein Teil des Operationsarguments von 0x100, insbesondere die am weitesten rechts liegenden sechs Bits (z. B. Null), bildet einen Versatz zu einem Zwei-Byte-Wert mit dem Ethertyp. Der Versatz in diesem Beispiel ist Null, da im vorliegenden Zusammenhang, der Zeiger zur syntaktischen Analyse immer am Typenfeld liegt, das den Ethertyp enthält. In der gerade beschriebenen Ausführungsform bildet der Rest des Operationsarguments ein Flag, das festlegt, dass die Startposition des Kopfs der Schicht drei (z. B. ein Versatz vom Beginn des Pakets) auch gespeichert werden soll (z. B. im L3OFFSET-Register). Insbesondere ist bekannt, dass der Beginn des Kopfs der Schicht drei unmittelbar nach dem Zwei-Byte-Typenfeld liegt.
Der Befehl IPV4_2 (z. B. Befehl sieben) testet ein verdächtiges Versionsfeld der Schicht drei, um sicherzustellen, dass das Protokoll der Schicht drei die Version vier von IP ist. Insbesondere legt eine Spezifikation für die Version vier von IP fest, dass die ersten vier Bits des Kopfs der Schicht drei einen Wert von 0x4 enthalten. Wenn der Test misslingt, endet die syntaktische Analyseprozedur mit dem Befehl DONE. Wenn der Test erfolgreich ist, geht der Zeiger um sechs Bytes weiter und der Befehl IPV4_3 wird aufgerufen.
Die festgelegte LD_SUM-Operation, die nur durchgeführt wird, wenn der Vergleich im Befehl IPV4_2 erfolgreich ist, gibt an, dass ein Versatz zum Beginn eines Punkts, ab dem eine Prüfsumme berechnet werden kann, gespeichert werden sollte. Insbesondere sollte in der gerade beschriebenen Ausführungsform der Erfindung eine Prüfsumme ab dem Beginn des TCP-Kopfs berechnet werden (unter der Annahme, dass der Kopf der Schicht vier TCP ist). Der Wert des Operationsarguments (z. B. 0x00A) gibt an, dass die Prüfsumme zwanzig Bytes (z. B. zehn Zwei-Byte-Inkremente) vom aktuellen Zeiger liegt. Folglich wird ein Wert von zwanzig Bytes zur Zeigerposition zur syntaktischen Analyse addiert und das Ergebnis wird in einem Register oder einer anderen Datenstruktur (z. B. im CSUMSTART-Register) gespeichert.
Der Befehl IPV4_3 (z. B. Befehl acht) ist dazu ausgelegt, festzustellen, ob der IP-Kopf des Pakets eine IP-Fragmentierung angibt. Wenn der aus dem Kopf gemäß 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 und die Prozedur tritt aus (z. B. durch den Befehl DONE). Ansonsten wird der Zeiger um zwei Bytes inkrementiert und der Befehl IPV4_4 wird nach dem Durchführen einer LD_LEN-Operation aufgerufen.
Gemäß der LD_LEN-Operation wird die Länge des IP-Segments gespeichert. Das dargestellte Operationsargument (z. B. 0x03E) umfasst einen Versatz zum Gesamtlängenfeld, wo sich dieser Wert befindet. Insbesondere bilden die niedrigstwertigen sechs Bits den Versatz. Da der Zeiger bereits an diesem Feld vorbei vorgeschoben wurde, umfasst das Operationsargument einen negativen Wert. Ein Fachmann wird erkennen, dass dieser Binärwert (z. B. 111110) verwendet werden kann, um den Dezimalwert von negativer Zwei darzustellen. Folglich wird der vorliegende Versatz zum Zeiger minus vier Bytes (z. B. zwei Zwei-Byte-Einheiten) in einem Register oder einer anderen Datenstruktur (z. B. dem PAYLOADLEN-Register) gespeichert. Irgendein anderes geeignetes Verfahren zum Darstellen eines negativen Versatzes kann verwendet werden. Oder die IP-Segmentlänge kann gespeichert werden, während sich der Zeiger an einer Stelle befindet, die dem Gesamtlängenfeld vorangeht (z. B. während eines vorherigen Befehls).
Im Befehl IPV4_4 (z. B. Befehl neun) wird ein Ein-Byte-Protokollfeld untersucht, um festzustellen, ob das Protokoll der Schicht vier TCP zu sein scheint. Wenn ja, wird der Zeiger um vierzehn Bytes vorgeschoben und die Ausführung fährt mit dem Befehl TCP_1 fort; ansonsten endet die Prozedur.
Die festgelegte LD_FID-Operation, die nur durchgeführt wird, wenn der Vergleich im Befehl IPV4_4 erfolgreich ist, beinhaltet das Wiedergewinnen des Flussschlüssels des Pakets und das Speichern desselben in einem Register oder an einer anderen Stelle (z. B. im FLOWID-Register). Ein Fachmann wird erkennen, dass, damit der Vergleich im Befehl IPV4_4 erfolgreich ist, die Köpfe der Schicht drei und vier des Pakets IP (Version vier) bzw. TCP entsprechen müssen. Wenn dies der Fall ist, dann wird der gesamte Flussschlüssel (z. B. IP-Quell- und -Zieladressen plus TCP-Quell- und -Zielanschlussnummern) zusammenhängend im Kopfabschnitt des Pakets gespeichert. Insbesondere umfasst der Flussschlüssel den letzten Abschnitt des IP-Kopfs und den Anfangsabschnitt des TCP-Kopfs und kann in einer Operation extrahiert werden. Das Operationsargument (z. B. 0x182) umfasst folglich zwei Werte, die erforderlich sind, um den Flussschlüssel aufzufinden und zu begrenzen. Erläuternd identifizieren die am weitesten rechts liegenden sechs Bits des Arguments (z. B. 0x02) einen Versatz von der Zeigerposition in Zwei-Byte-Einheiten zum Beginn 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. Befehl zehn), der dem Fehlschlag des durch den Befehl IPV4_1 durchgeführten Vergleichs folgt, sollte der Zeiger zur syntaktischen Analyse am Typenfeld der Schicht zwei liegen. Wenn dieser Test erfolgreich ist (z. B. das Typenfeld einen Hexadezimalwert von 86DD hält), wird der Befehl IPV6_2 durchgeführt, nachdem eine LD_SUM-Operation durchgeführt ist, und der Zeiger wird um zwei Bytes zum Beginn des Protokolls der Schicht drei inkrementiert. Wenn der Test nicht erfolgreich ist, tritt die Prozedur aus.
Die angegebene LD_SUM-Operation im Befehl IPV6_1 ist ähnlich zur Operation, die im Befehl IPV4_2 durchgeführt wird, verwendet jedoch ein anderes Argument. Wiederum soll die Prüfsumme ab dem Beginn des TCP-Kopfs berechnet werden (unter der Annahme, dass der Kopf der Schicht vier TCP ist). Das festgelegte Operationsargument (z. B. 0x015) umfasst folglich einen Versatz zum Begin des TCP-Kopfs – einundzwanzig Zwei-Byte-Schritte voraus. Der angegebene Versatz wird zur vorliegenden Zeigerposition addiert und in einem Register oder einer anderen Datenstruktur gespeichert (z. B. im CSUMSTART-Register).
Der Befehl IPV6_2 (z. B. Befehl elf) testet ein verdächtiges Versionsfeld der Schicht drei, um weiter sicherzustellen, dass das Protokoll der Schicht drei die Version sechs von IP ist. Wenn der Vergleich fehlschlägt, endet die Prozedur der syntaktischen Analyse mit dem Aufruf des Befehls DONE. Wenn sie erfolgreich ist, wird der Befehl IPV6_3 aufgerufen. Die Operation IM_R1, die nur dann durchgeführt wird, wenn der Vergleich in dieser Ausführungsform erfolgreich ist, speichert die Länge des IP-Kopfs von einem Nutzinformationslängenfeld. Wie ein Fachmann erkennen wird, umfasst das Gesamtlängenfeld (z. B. IP-Segmentgröße) eines IP-Kopfs der Version vier die Größe des Kopfs der Version vier. Das Nutzinformationslängenfeld (z. B. IP-Segmentgröße) eines IP-Kopfs der Version sechs umfasst jedoch nicht die Größe des Kopfs der Version sechs. Folglich wird die Größe des Kopfs der Version sechs, die durch die am weitesten rechts liegenden acht Bits des Ausgabearguments (z. B. 0x14, was zwanzig Zwei-Byte-Einheiten angibt) identifiziert wird, gespeichert. Erläuternd identifiziert der Rest des Arguments die Datenstruktur, in der die Kopflänge gespeichert werden soll (z. B. temporäres Register R1). Aufgrund der Änderung der Größe von Köpfen der Schicht drei zwischen Protokollen wird in einer Ausführungsform der Erfindung die Kopfgröße in anderen Einheiten angegeben, um eine größere Genauigkeit zu ermöglichen. Insbesondere wird in einer Ausführungsform der Erfindung die Größe des Kopfs in Bytes im Befehl IPV6_2 festgelegt, in welchem Fall das Ausgabeargument 0x128 sein könnte.
Der Befehl IPV6_3 (z. B. Befehl zwölf) in dieser Ausführungsform untersucht keinen Kopfwert. 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 Kopfs erwünscht ist. Nachdem die LD_FID-Operation durchgeführt ist, wird der Zeiger zur syntaktischen Analyse um sechs Bytes zu einem Feld des nächsten Kopfs des IP-Kopfs der Version sechs vorgeschoben. Da die Extraktionsmaske und die Vergleichswerte beide 0x0000 sind, sollte der Vergleich niemals fehlschlagen und die Fehlschlagabzweigung des Befehls sollte niemals aufgerufen werden.
Wie vorher beschrieben, speichert eine LD_FID-Operation einen Flussschlüssel in einem geeigneten Register oder einer anderen Datenstruktur (z. B. im FLOWID-Register). Erläuternd umfasst das Operationsargument von 0x484 zwei Werte zur Identifikation und Begrenzung des Flussschlüssels. Insbesondere geben die am weitesten rechts liegenden sechs Bits (z. B. 0x04) an, dass der Flussschlüsselabschnitt in einem Versatz von acht Bytes (z. B. vier Zwei-Byte-Inkrementen) von der aktuellen Zeigerposition liegt. Der Rest des Operationsarguments (z. B. 0x12) gibt an, dass sechsunddreißig Bytes (z. B. das Dezimaläquivalent von 0x12 Zwei-Byte-Einheiten) vom berechneten Versatz kopiert werden sollen. In der dargestellten Ausführungsform der Erfindung wird der gesamte Flussschlüssel intakt kopiert, einschließlich der Quell- und Zieladressen der Schicht drei und der Quell- und Zielanschlüsse der Schicht vier.
Im Befehl IPV6_4 (z. B. Befehl dreizehn) wird ein verdächtiges Feld des nächsten Kopfs untersucht, um festzustellen, ob das Protokoll der Schicht vier des Protokollprofils des Pakets TCP zu sein scheint. Wenn ja, geht die Prozedur um sechsunddreißig Bytes (z. B. achtzehn Zwei-Byte-Einheiten) weiter und der Befehl TCP_1 wird aufgerufen; ansonsten tritt die Prozedur aus (z. B. durch den Befehl DONE). Die Operation LD_LEN wird durchgeführt, wenn der Wert im Feld des nächsten Kopfs 0x06 ist. Wie vorstehend beschrieben, speichert diese Operation die IP-Segmentgröße. Wiederum umfasst das Argument (z. B. 0x03F) einen negativen Versatz, in diesem Fall eine negative Eins. Dieser Versatz gibt an, dass das gewünschte Nutzinformationslängenfeld zwei Bytes vor der vorliegenden Position des Zeigers liegt. Folglich wird der negative Versatz zum vorliegenden Zeigerversatz addiert und das Ergebnis in einem geeigneten Register oder einer anderen Datenstruktur (z. B. im PAYLOADLEN-Register) gespeichert.
In den Befehlen TCP_1, TCP_2, TCP_3 und TCP_4 (z. B. Befehle vierzehn bis siebzehn) werden keine Kopfwerte – im Gegensatz zu bestimmten Flags, die in den Ausgabeoperationen der Befehle festgelegt sind – untersucht, sondern verschiedene Daten vom TCP-Kopf des Pakets werden gespeichert. In der dargestellten Ausführungsform umfassen die Daten, die gespeichert werden, eine TCP-Folgenummer, eine TCP-Kopflänge und ein oder mehrere Flags. Für jeden Befehl wird die festgelegte Operation durchgeführt und der nächste Befehl wird aufgerufen. Wie vorstehend beschrieben, misslingt ein Vergleich zwischen dem Vergleichswert von 0x0000 und einem Nullextraktionswert, wie in jedem dieser Befehle verwendet, niemals. Nach dem Befehl TCP_4 kehrt die syntaktische Analyseprozedur zum Befehl WAIT zurück, um auf ein neues Paket zu warten.
Für die Operation LD_SEQ im Befehl TCP_1 umfasst das Operationsargument (z. B. 0x081) zwei Werte, um eine TCP-Folgenummer zu identifizieren und zu extrahieren. Die am weitesten rechts liegenden sechs Bits (z. B. 0x01) geben an, dass sich die Folgenummer zwei Bytes von der aktuellen Position des Zeigers befindet. Der Rest des Arguments (z. B. 0x2) gibt die Anzahl von Zwei-Byte-Einheiten an, die von dieser Position kopiert werden müssen, um die Folgenummer zu erfassen. Erläuternd wird die Folgenummer 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 Flags zu konfigurieren, die in einer Aufgabe nach der syntaktischen Analyse verwendet werden sollen. Die am weitesten rechts liegenden sechs Bits (z. B. 0x05) bilden einen Versatz in Zwei-Byte-Einheiten zu einem Zwei-Byte-Abschnitt des TCP-Kopfs, der Flags enthält, die sich darauf auswirken können, ob das Paket für die Verbesserungen nach der syntaktischen Analyse der vorliegenden Erfindung geeignet ist. URG-, PSH-, RST-, SYN- und FIN-Flags können sich beispielsweise in der Versatzposition befinden und verwendet werden, um das Register zu konfigurieren. Die Ausgabemaske (z. B. 0x002F) gibt an, dass nur spezielle Abschnitte (z. B. Bits) des Flag-Feldes des TCP-Kopfs gespeichert werden.
Die Operation LD_R1 des Befehls TCP_3 ist ähnlich zu der im Befehl IPV6_2 durchgeführten Operation. Hier umfasst ein Operationsargument von 0x205 einen Wert (z. B. die niedrigstwertigen sechs Bits), der einen Versatz von fünf Zwei-Byte-Einheiten von der aktuellen Zeigerposition identifiziert. Diese Stelle sollte ein Kopflängefeld umfassen, das in einer Datenstruktur gespeichert werden soll, die durch den Rest des Arguments identifiziert wird (z. B. temporäres Register R1). Die Ausgabemaske (z. B. 0xF000) gibt an, dass nur die erste vier Bits gespeichert werden (z. B. ist das Kopflängenfeld nur vier Bits groß).
Wie ein Fachmann erkennen wird, kann der aus dem Kopflängenfeld extrahierte Wert eingestellt werden müssen, um die Verwendung von Zwei-Byte-Einheiten (z. B. sechzehn Bitworten) in der dargestellten Ausführungsform zu reflektieren. Gemäß dem Verschiebungsabschnitt des Befehls TCP_3 wird daher der aus dem Feld extrahierte und durch die Ausgabemaske (z. B. 0xF000) konfigurierte Wert zu den rechten elf Positionen verschoben, wenn er gespeichert wird, um die Berechnungen zu vereinfachen.
Die Operation LD_HDR des Befehls TCP_4 bewirkt das Laden eines Versatzes in das erste Byte von Paketdaten nach dem TCP-Kopf. Erläuternd können Pakete, die mit einem vorgewählten Protokollprofil kompatibel sind, an irgendeinem Punkt in Kopf- und Datenabschnitte getrennt werden. Das Speichern eines Versatzes zum Datenabschnitt macht es nun leichter, das Paket später aufzuteilen. Erläuternd umfassen die am weitesten rechts liegenden sieben Bits des 0x0FF Operationsarguments ein erstes Element des Versatzes zu den Daten. Ein Fachmann wird das Bitmuster (z. B. 1111111) als gleich einer negativen Eins erkennen. Folglich wird ein Versatzwert gleich dem aktuellen Zeiger zur syntaktischen Analyse (z. B. der Wert im ADDR-Register) minus zwei Bytes – was den Beginn des TCP-Kopfs auffindet – gespeichert. Der Rest des Arguments bedeutet, dass der Wert einer temporären Datenstruktur (z. B. temporäres Register R1) zu diesem Versatz addiert werden soll. In diesem speziellen Zusammenhang wird der im vorherigen Befehl gespeicherte Wert (z. B. die Länge des TCP-Kopfs) addiert. Diese zwei Werte kombinieren sich, um einen Versatz zum Beginn der Paketdaten zu bilden, der in einem geeigneten Register oder einer anderen Datenstruktur (z. B. im HDRSPLIT-Register) gespeichert wird.
Schließlich und wie vorstehend erwähnt, gibt der Befehl DONE (z. B. Befehl achtzehn) das Ende der syntaktischen Analyse eines Pakets an, wenn festgestellt wird, dass das Paket nicht einem oder mehreren der den dargestellten Befehlen zugeordneten Protokolle entspricht. Dies kann als "Reinigungs"-Befehl betrachtet werden. Insbesondere gibt die Ausgabeoperation LD_CTL mit einem Operationsargument von 0x001 an, dass ein No_Assist-Flag im vorstehend in Verbindung mit dem Befehl VLAN beschriebenen Steuerregister gesetzt werden soll (z. B. auf Eins). Das No_Assist-Flag, wie anderswo beschrieben, kann verwendet werden, um andere Module der Netzschnittstelle zu informieren, dass das vorliegende Paket für eine oder mehrere anderswo beschriebene Verarbeitungsverbesserungen ungeeignet ist.
Das dargestellte Programm oder der dargestellte Mikrocode demonstrierten nur ein Verfahren zum syntaktischen Analysieren eines Pakets. Andere Programme mit denselben Befehlen in einer anderen Folge oder vollkommen anderen Befehlen mit ähnlichen oder verschiedenen Formaten können verwendet werden, um Abschnitte von Köpfen zu untersuchen und zu speichern und Register und andere Datenstrukturen zu konfigurieren.
Die aus der Anwendung der verbesserten Verarbeitung einer vorliegenden Ausführungsform der Erfindung zu verwirklichenden Effizienzgewinne tun mehr als die zum syntaktischen Analysieren eines Pakets mit dem erläuterten Programm erforderliche Zeit zu kompensieren. Selbst wenn ein Kopf-Parser ein Paket an einer NIC in einer aktuellen Ausführungsform syntaktisch analysiert, kann das Paket ferner immer noch durch sein Protokollprofil durch einen Prozessor auf einem Host-Computer verarbeitet werden müssen (z. B. um die Protokollköpfe zu entfernen). Dies vermeidet die Belastung der Kommunikationsvorrichtung (z. B. Netzschnittstelle) mit einer solchen Aufgabe.
Eine Ausführungsform einer Flussdatenbank
5 stellt eine Flussdatenbank (FDB) 110 gemäß einer Ausführungsform der Erfindung dar. Erläuternd wird die FDB 110 als CAM (inhaltsadressierbarer Speicher) unter Verwendung einer umschreibbaren Speicherkomponente (z. B. RAM, SRAM, DRAM) implementiert. In dieser Ausführungsform umfasst die FDB 110 einen zuordnenden Abschnitt 502 und einen zugeordneten Abschnitt 504 und kann durch eine Flussnummer 506 indiziert werden.
Der Schutzbereich der Erfindung begrenzt nicht die Form oder Struktur der Flussdatenbank 110. In alternativen Ausführungsformen der Erfindung kann theoretisch jegliche Form von Datenstruktur verwendet werden (z. B. Datenbank, Tabelle, Warteschlange, Liste, Matrix), entweder monolithisch oder segmentiert, und kann in Hardware oder Software implementiert werden. Die dargestellte Form der FDB 110 ist lediglich eine Weise zum Warten von nützlichen Informationen hinsichtlich Kommunikationsflüssen durch die NIC 100. Wie ein Fachmann erkennen wird, ermöglicht die Struktur eines CAM eine sehr effiziente und schnelle zuordnende Suche.
In der dargestellten Ausführungsform der Erfindung ermöglichen die in der FDB 110 gespeicherten Informationen und die Operation des Flussdatenbank-Managers (FDBM) 108 (nachstehend beschrieben) Funktionen wie z. B. erneute Datenzusammenfügung, Stapelverarbeitung von Paketköpfen und andere Verbesserungen. Diese Funktionen können folgendermaßen kurz beschrieben werden.
Eine Form der erneuten Datenzusammenfügung beinhaltet die erneute Zusammenfügung oder Kombination von Daten von mehreren in Beziehung stehenden Paketen (z. B. Paketen von einem einzelnen Kommunikationsfluss oder einem einzelnen Datagramm). Ein Verfahren für die Stapelverarbeitung von Paketköpfen zieht die Verarbeitung von Protokollköpfen von mehreren in Beziehung stehenden Paketen durch ein Protokollprofil vielmehr gemeinsam als ein Paket auf einmal nach sich. Eine weitere erläuternde Funktion der NIC 100 beinhaltet die Verteilung oder Teilung einer solchen Protokollprofilverarbeitung (und/oder von anderen Funktionen) unter Prozessoren in einem Host-Computersystem mit mehreren Prozessoren. Noch eine weitere mögliche Funktion der NIC 100 besteht darin, die Übertragung von wieder zusammengefügten Daten zu einer Zielentität (z. B. einem Anwendungsprogramm) in einer effizienten Zusammenfassung (z. B. einer Speicherseite) zu ermöglichen, wodurch stückweise und sehr ineffiziente Übertragungen von Daten eines Pakets auf einmal vermieden werden. In dieser Ausführungsform der Erfindung besteht folglich ein Zweck der FDB 110 und des FDBM 108 darin, Informationen für die Verwendung der NIC 100 und/oder eines Host-Computersystems beim Aktivieren, Deaktivieren oder Durchführen von einer oder mehreren dieser Funktionen zu erzeugen.
Der zuordnende Abschnitt 502 der FDB 110 in 5 speichert den Flussschlüssel jedes gültigen Flusses, der für eine durch die NIC 100 bediente Entität bestimmt ist. In einer Ausführungsform der Erfindung umfasst der zuordnende Abschnitt 502 folglich die IP-Quelladresse 510, die IP-Zieladresse 512, den TCP-Quellanschluss 514 und den TCP-Zielanschluss 516. Wie in einem vorherigen Abschnitt beschrieben, können diese Felder von einem Paket extrahiert und zum FDBM 108 durch den Kopf-Parser 106 geliefert werden.
Obwohl jede durch die NIC 100 bediente Zielentität an mehreren Kommunikationsflüssen oder TCP-Verbindungen von Ende zu Ende teilnehmen kann, existiert nur ein Fluss auf einmal zwischen einer speziellen Quellentität und einer speziellen Zielentität. Daher sollte jeder Flussschlüssel im zuordnenden Abschnitt 502, der einem gültigen Fluss entspricht, gegenüber allen anderen gültigen Flüssen eindeutig sein. In alternativen Ausführungsformen der Erfindung besteht der zuordnende Abschnitt 502 aus verschiedenen Feldern, die alternative Flussschlüsselformen reflektieren, die durch die Protokolle, die vom Kopf-Parser syntaktisch analysiert werden, und die Informationen, die zum Identifizieren von Kommunikationsflüssen verwendet werden, bestimmt werden können.
Der zugeordnete Abschnitt 504 in der dargestellten Ausführungsform umfasst einen Flussgültigkeitsindikator 520, eine Flussfolgenummer 522 und einen Flussaktivitätsindikator 524. Diese Felder liefern Informationen hinsichtlich des Flusses, der durch den Flussschlüssel identifiziert wird, der im entsprechenden Eintrag im zuordnenden Abschnitt 502 gespeichert ist. Die Felder des zugeordneten Abschnitts 504 können durch den FDBM 108 wiedergewonnen und/oder aktualisiert werden, wie im folgenden Abschnitt beschrieben.
Der Flussgültigkeitsindikator 520 in dieser Ausführungsform gibt an, ob der zugehörige Fluss gültig oder ungültig ist. Erläuternd wird der Flussgültigkeitsindikator so gesetzt, dass er einen gültigen Fluss angibt, wenn das erste Paket von Daten in einem Fluss empfangen wird, und kann zurückgesetzt werden, um die Gültigkeit eines Flusses erneut zu aktivieren, jedes Mal wenn ein Abschnitt eines Datagramms eines Flusses (z. B. eines Pakets) korrekt empfangen wird.
Der Flussgültigkeitsindikator 520 kann als ungültig markiert werden, nachdem das letzte Paket von Daten in einem Fluss empfangen ist. Der Flussgültigkeitsindikator kann auch so gesetzt werden, dass er einen ungültigen Fluss angibt, sobald ein Fluss aus irgendeinem anderen Grund als dem Empfang eines Enddatenpakets abgebrochen (z. B. beendet oder abgebrochen) werden soll. Ein Paket kann beispielsweise außerhalb der Reihe von anderen Paketen eines Datagramms empfangen werden, ein Steuerpaket, das angibt, dass eine Datenübertragung oder ein Fluss abgebrochen wird, kann empfangen werden, ein Versuch kann unternommen werden, um einen Fluss wiederherzustellen oder erneut zu synchronisieren (in welchem Fall der ursprüngliche Fluss beendet wird), usw. In einer Ausführungsform der Erfindung ist der Flussgültigkeitsindikator 520 ein einzelnes Bit, ein einzelnes Flag oder ein einzelner Wert.
Die Flussfolgenummer 522 in der dargestellten Ausführungsform umfasst eine Folgenummer des nächsten Abschnitts von Daten, die im zugehörigen Fluss erwartet werden. Da das in einem Fluss gesandte Datagramm typischerweise über mehrere Pakete empfangen wird, stellt die Flussfolgenummer einen Mechanismus bereit, um sicherzustellen, dass die Pakete in der korrekten Reihenfolge empfangen werden. In einer Ausführungsform der Erfindung fügt die NIC 100 beispielsweise Daten von mehreren Paketen eines Datagramms wieder zusammen. Um diese erneute Zusammenfügung in der effizientesten Weise durchzuführen, müssen die Pakete der Reihe nach empfangen werden. Folglich speichert die Flussfolgenummer 522 einen Identifizierer, um das nächste Paket oder den nächsten Abschnitt von Daten zu identifizieren, das/der empfangen werden sollte.
In einer Ausführungsform der Erfindung entspricht die Flussfolgenummer 522 dem TCP-Folgenummerfeld, das in den TCP-Protokollköpfen zu finden ist. Wie ein Fachmann erkennen wird, identifiziert die TCP-Folgenummer eines Pakets die Position der Daten des Pakets relativ zu anderen in einem Datagramm gesandten Daten. Für Pakete und Flüsse, die andere Protokolle als TCP beinhalten, kann ein alternatives Verfahren zum Überprüfen oder Sicherstellen des Empfangs von Daten in der korrekten Reihenfolge verwendet werden.
Der Flussaktivitätsindikator 524 in der dargestellten Ausführungsform reflektiert die Neuheit der Aktivität eines Flusses oder mit anderen Worten das Alter eines Flusses. In dieser Ausführungsform der Erfindung ist der Flussaktivitätsindikator 524 einem Zähler zugeordnet, wie z. B. einem Flussaktivitätszähler (in 5 nicht dargestellt). Der Flussaktivitätszähler wird jedes Mal aktualisiert (z. B. inkrementiert), wenn ein Paket als Teil eines Flusses empfangen wird, der bereits in der Flussdatenbank 110 gespeichert ist. Der aktualisierte Zählerwert wird dann im Flussaktivitätsindikatorfeld des Flusses des Pakets gespeichert. Der Flussaktivitätszähler kann auch 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 Pakete aktualisiert, die Daten enthalten (z. B. wird er nicht für Steuerpakete aktualisiert). In noch einer weiteren alternativen Ausführungsform werden mehrere Zähler für die Aktualisierung der Flussaktivitätsindikatoren von verschiedenen Flüssen verwendet.
Da nicht immer festgestellt werden kann, wenn ein Kommunikationsfluss geendet hat (z. B. kann das Endpaket verloren gegangen sein), kann der Flussaktivitätsindikator verwendet werden, um Flüsse zu identifizieren, die veraltet sind oder die aus irgendeinem anderen Grund abgebrochen werden sollten. Wenn die Flussdatenbank 110 beispielsweise vollständig belegt zu sein scheint (z. B. ist der Flussgültigkeitsindikator 520 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 dargestellten Ausführungsform der Erfindung kann sich die Größe der Felder in der FDB 110 von einem Eintrag zum anderen unterscheiden. IP-Quell- und -Zieladressen sind beispielsweise in der Version vier des Protokolls vier Bytes groß, sind jedoch in der Version sechs sechzehn Bytes groß. In einer alternativen Ausführungsform der Erfindung können die Einträge für ein spezielles Feld in der Größe einheitlich sein, wobei kleinere Einträge nach Bedarf aufgefüllt werden.
In einer weiteren alternativen Ausführungsform der Erfindung können die Felder innerhalb der FDB 110 kombiniert werden. Insbesondere kann der Flussschlüssel eines Flusses als einzige Entität oder einziges Feld gespeichert werden, anstatt als Anzahl von separaten Feldern gespeichert zu werden, wie in 5 gezeigt. Ebenso sind der Flussgültigkeitsindikator 520, die Flussfolgenummer 522 und der Flussaktivitätsindikator 524 als separate Einträge in 5 dargestellt. In einer alternativen Ausführungsform der Erfindung kann jedoch einer oder können mehrere dieser Einträge kombiniert werden. Insbesondere umfassen in einer alternativen Ausführungsform der Flussgültigkeitsindikator 520 und der Flussaktivitätsindikator 524 einen einzigen Eintrag mit einem ersten Wert (z. B. Null), wenn der zugehörige Fluss des Eintrags ungültig ist. Solange der Fluss gültig ist, wird jedoch der kombinierte Eintrag inkrementiert, wenn Pakete empfangen werden, und wird bei der Beendung des Flusses auf den ersten Wert zurückgesetzt.
In einer Ausführungsform der Erfindung enthält die FDB 110 ein Maximum von vierundsechzig Einträgen, die durch die Flussnummer 506 indiziert werden, was folglich ermöglicht, dass die Datenbank vierundsechzig gültige Flüsse auf einmal verfolgt. In alternativen Ausführungsformen der Erfindung können mehr oder weniger Einträge in Abhängigkeit von der Größe des für die Flussdatenbank 110 zugewiesenen Speichers zugelassen werden. Zusätzlich zur Flussnummer 506 kann ein Fluss durch seinen Flussschlüssel (im zuordnenden Abschnitt 502 gespeichert) identifizierbar sein.
In der dargestellten Ausführungsform der Erfindung ist die Flussdatenbank 110 leer (z. B. sind alle Felder mit Nullen gefüllt), wenn die NIC 100 initialisiert wird. Wenn das erste Paket eines Flusses empfangen wird, analysiert der Kopf-Parser 106 einen Kopfabschnitt des Pakets syntaktisch. Wie in einem vorherigen Abschnitt beschrieben, fügt der Kopf-Parser einen Flussschlüssel zusammen, um den Fluss zu identifizieren, und extrahiert andere Informationen hinsichtlich des Pakets und/oder des Flusses. Der Flussschlüssel und andere Informationen werden zum Flussdatenbank-Manager 108 geleitet. Der FDBM 108 durchsucht dann die FDB 110 nach einem aktiven Fluss, der dem Flussschlüssel zugeordnet ist. Da die Datenbank leer ist, besteht keine Übereinstimmung.
In diesem Beispiel wird der Flussschlüssel daher (z. B. als Flussnummer Null) durch Kopieren der IP-Quelladresse, der IP-Zieladresse, des TCP-Quellanschlus ses und des TCP-Zielanschlusses in die entsprechenden Felder gespeichert. Der Flussgültigkeitsindikator 520 wird dann gesetzt, um einen gültigen Fluss anzugeben, die Flussfolgenummer 522 wird von der TCP-Folgenummer (erläuternd durch den Kopf-Parser bereitgestellt) abgeleitet und der Flussaktivitätsindikator 524 wird auf einen Anfangswert (z. B. Eins) gesetzt, der von einem Zähler abgeleitet werden kann. Ein Verfahren zum Erzeugen einer geeigneten Flussfolgenummer, die verwendet werden kann, um zu überprüfen, dass der nächste Abschnitt von Daten, die für den Fluss empfangen werden, der Reihe nach empfangen wird, besteht darin, die TCP-Folgenummer und die Größe der Daten des Pakets hinzuzufügen. In Abhängigkeit von der Konfiguration des Pakets (z. B. ob das SYN-Bit in einem Flag-Feld des TCP-Kopfs des Pakets gesetzt ist), kann jedoch die Summe eingestellt werden müssen (z. B. durch Addieren von Eins), um den nächsten erwarteten Abschnitt von Daten korrekt zu identifizieren.
Wie vorstehend beschrieben, besteht ein Verfahren zum Erzeugen eines geeigneten Anfangswerts für einen Flussaktivitätsindikator darin, einen Zählerwert zu kopieren, der für jedes als Teil eines Flusses empfangene Paket inkrementiert wird. Für das erste Paket, das empfangen wird, nachdem die NIC 100 initialisiert ist, kann beispielsweise ein Flussaktivitätszähler auf den Wert von eins inkrementiert werden. Dieser Wert kann dann im Flussaktivitätsindikator 524 für den zugehörigen Fluss gespeichert werden. Das nächste als Teil desselben (oder eines neuen) Flusses empfangene Paket bewirkt, dass der Zähler auf zwei inkrementiert wird, welcher Wert im Flussaktivitätsindikator für den zugehörigen Fluss gespeichert wird. In diesem Beispiel sollten keine zwei Flüsse denselben Flussaktivitätsindikator aufweisen, außer bei der Initialisierung, wenn sie alle gleich Null oder irgendeinem anderen vorbestimmten Wert sein können.
Beim Empfang und syntaktischen Analysieren eines späteren Pakets, das an der NIC 100 empfangen wird, wird die Flussdatenbank nach einem gültigen Fluss durchsucht, der dem Flussschlüssel dieses Pakets entspricht. Erläuternd werden nur die Flussschlüssel von aktiven Flüssen (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 zuordnenden Abschnitt 502) durchsucht werden, aber eine Übereinstimmung wird nur gemeldet, wenn sein Flussgültigkeitsindikator einen gültigen Fluss angibt. Mit einem CAM wie z. B. der FDB 110 in 5 können Flussschlüssel und Flussgültigkeitsindikatoren parallel durchsucht werden.
Wenn ein späteres Paket den nächsten Abschnitt von Daten für einen vorherigen Fluss (z. B. den Fluss Nummer Null) enthält, wird dieser Fluss dementsprechend aktualisiert. In einer Ausführungsform der Erfindung hat dies die Aktualisierung der Flussfolgenummer 522 und das Inkrementieren des Flussaktivitätsindikators 524, um seine neue Aktivität zu reflektieren, zur Folge. Der Flussgültigkeitsindikator 520 kann auch 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 zur FDB 110 in einer ähnlichen Weise zum ersten Fluss hinzugefügt. Wenn ein Fluss beendet oder abgebrochen wird, wird der zugehörige Eintrag in der FDB 110 ungültig gemacht. In einer Ausführungsform der Erfindung wird der Flussgültigkeitsindikator 520 für den beendeten Fluss nur gelöscht (z. B. auf Null gesetzt). In einer anderen Ausführungsform werden ein oder mehrere Felder eines beendeten Flusses gelöscht oder auf einen willkürlichen oder vorbestimmten Wert gesetzt. Aufgrund der stoßweisen Art von Netzpaketverkehr werden alle oder die meisten der Daten von einem Datagramm im Allgemeinen in einer kurzen Menge an Zeit empfangen. Folglich muss jeder gültige Fluss in der FDB 110 normalerweise nur für einen kurzen Zeitraum aufrechterhalten werden und sein Eintrag kann dann verwendet werden, um einen anderen Fluss zu speichern.
Aufgrund der begrenzten Menge an Speicher, die für die Flussdatenbank 110 in einer Ausführungsform der Erfindung zur Verfügung steht, kann die Größe jedes Feldes begrenzt sein. In dieser Ausführungsform werden sechzehn Bytes für die IP-Quelladresse 510 zugewiesen und sechzehn Bytes werden für die IP-Zieladresse 512 zugewiesen. Für IP-Adressen, die kürzer als sechzehn Bytes lang sind, kann der zusätzliche Raum mit Nullen aufgefüllt werden. Ferner werden dem TCP-Quellanschluss 514 und dem TCP-Zielanschluss 516 jeweils zwei Bytes zugewiesen. In dieser Ausführungsform umfasst der Flussgültigkeitsindikator 520 auch ein Bit, der Flussfolgenummer 522 werden vier Bytes zugewiesen und dem Flussaktivitätsindikator 524 werden auch vier Bytes zugewiesen.
Wie ein Fachmann aus den vorstehend beschriebenen Ausführungsformen erkennen wird, ist ein Fluss zu einer TCP-Verbindung von Ende zu Ende ähnlich, aber nicht identisch. Eine TCP-Verbindung kann für einen relativ ausgedehnten Zeitraum existieren, der ausreicht, um mehrere Datagramme von einer Quellentität zu einer Zielentität zu übertragen. Ein Fluss kann jedoch nur für ein Datagramm existieren. Während einer TCP-Verbindung von Ende zu Ende können folglich mehrere Flüsse aufgebaut und abgebrochen werden (z. B. einmal für jedes Datagramm). Wie vorstehend beschrieben, kann ein Fluss aufgebaut werden (z. B. zur FDB 110 hinzugefügt und als gültig markiert werden), wenn die NIC 110 den ersten Abschnitt von Daten in einem Datagramm erfasst, und kann abgebrochen werden (z. B. in der FDB 110 als ungültig markiert werden), wenn der letzte Abschnitt von Daten empfangen wird. Erläuternd besitzt jeder während einer einzelnen TCP-Verbindung von Ende zu Ende aufgebaute Fluss denselben Flussschlüssel, da die Adressen- und Anschlussidentifizierer der Schicht drei und Schicht vier, die verwendet werden, um den Flussschlüssel zu bilden, dieselben bleiben.
In der dargestellten Ausführungsform bestimmt die Größe der Flussdatenbank 110 (z. B. die Anzahl von Flusseinträgen) die maximale Anzahl von Flüssen, die auf einmal verschachtelt werden (z. B. gleichzeitig aktiv sein) können, während die Funktionen der erneuten Datenzusammenfügung und Stapelverarbeitung von Protokollköpfen ermöglicht werden. Mit anderen Worten, in der in 5 dargestellten Ausführungsform kann die NIC 100 bis zu vierundsechzig Flüsse aufbauen und Pakete von bis zu vierundsechzig verschiedenen Datagrammen empfangen (d. h. vierundsechzig Flüsse können aktiv sein), ohne einen Fluss abzubrechen. Wenn eine maximale Anzahl von Flüssen durch die NIC 100 bekannt wären, könnte die Flussdatenbank 110 auf die entsprechende Anzahl von Einträgen begrenzt werden.
Die Flussdatenbank kann klein gehalten werden, da ein Fluss in der gerade beschriebenen Ausführungsform nur ein Datagramm dauert, und aufgrund der stoßweisen Art von Paketverkehr werden die Pakete eines Datagramms im Allgemeinen in einem kurzen Zeitraum empfangen. Die kurze Dauer eines Flusses kompensiert eine begrenzte Anzahl von Einträgen in der Flussdatenbank. In einer Ausführungsform der Erfindung wird, wenn die FDB 110 mit aktiven Flüssen gefüllt ist und ein neuer Fluss begonnen wird (d. h. ein erster Abschnitt von Daten in einem neuen Datagramm), der älteste (z. B. der vor längster Zeit aktive) Fluss durch den neuen ersetzt.
In einer alternativen Ausführungsform der Erfindung können Flüsse für eine beliebige Anzahl von Datagrammen (oder ein anderes Maß von Netzverkehr) oder für eine festgelegte Länge oder einen festgelegten Bereich von Zeit aktiv gehalten werden. Wenn beispielsweise ein Datagramm endet, kann sein Fluss in der FDB 110 "offen" gehalten werden (d. h. nicht abgebrochen werden), wenn die Datenbank nicht voll ist (z. B. ist der Eintrag des Flusses nicht für einen anderen Fluss erforderlich). Dieses Schema kann ferner die effiziente Operation der NIC 100 verbessern, wenn ein weiteres Datagramm mit demselben Flussschlüssel empfangen wird. Insbesondere wird die Mehrbelastung, die beim Aufbauen eines anderen Flusses beteiligt ist, vermieden und mehr erneute Datenzusammenfügung und Paketstapelverarbeitung (wie nachstehend beschrieben) können durchgeführt werden. Vorteilhafterweise kann ein Fluss in der Flussdatenbank 110 offen gehalten werden, bis die TCP-Verbindung von Ende zu Ende, die den Fluss umfasst, endet.
Eine Ausführungsform eines Flussdatenbank-Managers
6A–6E stellen ein Verfahren zum Betreiben eines Flussdatenbank-Managers (FDBM) wie z. B. eines Flussdatenbank-Managers 108 von 1A zum Managen der Flussdatenbank (FDB) 110 dar. Erläuternd speichert und aktualisiert der FDBM 108 Flussinformationen, die in der Flussdatenbank 110 gespeichert werden, und erzeugt einen Operationscode für ein von der NIC 100 empfangenes Paket. Der FDBM 108 bricht auch einen Fluss ab (z. B. ersetzt, entfernt er 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 reflektiert der Operationscode eines Pakets die Kompatibilität des Pakets mit vorbestimmten Kriterien für die Durchführung von einer oder mehreren Funktion der NIC 100 (z. B. erneute Datenzusammenfügung, Stapelverarbeitung von Paketköpfen, Lastverteilung). Mit anderen Worten, in Abhängigkeit vom Operationscode eines Pakets, können andere Module der NIC 100 eine von diesen Funktionen durchführen oder nicht.
In einer weiteren Ausführungsform der Erfindung gibt ein Operationscode einen Paketstatus an. Ein Operationscode kann beispielsweise angeben, dass ein Paket: keine Daten enthält, ein Steuerpaket ist, mehr als eine festgelegte Menge an Daten enthält, das erste Paket eines neuen Flusses ist, das letzte Paket eines existierenden Flusses ist, außerhalb der Reihe liegt, ein bestimmtes Flag enthält (z. B. in einem Protokollkopf), das keinen erwarteten Wert besitzt (folglich möglicherweise einen Ausnahmezustand angibt), usw.
Die Operation des Flussdatenbank-Managers 108 hängt von Paketinformationen, die vom Kopf-Parser 106 geliefert werden, und von Daten, die aus der Flussdatenbank 110 entnommen werden, ab. Nachdem der FDBM 108 die Paketinformationen und/oder Daten verarbeitet, werden Steuerinformationen (z. B. der Operationscode des Pakets) in der Steuerwarteschlange 118 gespeichert und die FDB 110 kann geändert werden (z. B. kann ein neuer Fluss eingetragen werden oder ein existierender aktualisiert oder abgebrochen werden).
Mit Bezug nun auf 6A–6E ist der Zustand 600 ein Startzustand, in dem der FDBM 108 auf Informationen wartet, die von einem Paket entnommen werden, das durch die NIC 100 vom Netz 102 empfangen wird. Im Zustand 602 benachrichtigt der Kopf-Parser 106 oder ein anderes Modul der NIC 100 den FDBM 108 über ein neues Paket durch Liefern des Flussschlüssels des Pakets und irgendwelcher Steuerinformationen. Der Empfang dieser Daten kann als Anforderung, die FDB 110 zu durchsuchen, um festzustellen, ob ein Fluss mit diesem Flussschlüssel bereits existiert, interpretiert werden.
In einer Ausführungsform der Erfindung umfassen die zum FDBM 108 geleiteten Steuerinformationen eine Folgenummer (z. B. eine TCP-Folgenummer), die von einem Paketkopf entnommen wird. Die Steuerinformationen können auch den Status bestimmter Flags in den Köpfen von Paketen, ob das Paket Daten enthält und, wenn ja, ob die Menge an Daten eine gewisse Größe überschreitet, angeben. In dieser Ausführungsform empfängt der FDBM 108 auch ein No_Assist-Signal für ein Paket, wenn der Kopf-Parser feststellt, dass das Paket nicht gemäß einem der vorgewählten Protokollprofile formatiert ist (d. h. das Paket nicht "kompatibel" ist), wie in einem vorherigen Abschnitt erörtert. Erläuternd gibt das No_Assist-Signal an, dass eine oder mehrere Funktionen der NIC 100 (z. B. Erneute Datenzusammenfügung, Stapelverarbeitung, 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 aktiviert wurde. Wenn ja, geht die Prozedur zum Zustand 668 (6E) weiter. Ansonsten durchsucht der FDBM 108 die FDB 110 nach dem Flussschlüssel des Pakets im Zustand 606. In einer Ausführungsform der Erfindung werden nur gültige Flusseinträge in der Flussdatenbank durchsucht. Wie vorstehend erörtert, kann die Gültigkeit eines Flusses durch einen Gültigkeitsindikator wie z. B. den Flussgültigkeitsindikator 520 (in 5 gezeigt) reflektiert werden. Wenn im Zustand 608 festgestellt wird, dass der Flussschlüssel des Pakets nicht in der Datenbank gefunden wurde oder dass eine Übereinstimmung gefunden wurde, aber der zugehörige Fluss nicht gültig ist, geht die Prozedur zum Zustand 646 weiter (6D).
Wenn eine gültige Übereinstimmung in der Flussdatenbank gefunden wird, wird im Zustand 610 die Flussnummer (z. B. der Flussdatenbankindex für den übereinstimmenden Eintrag) des übereinstimmenden Flusses vermerkt und die Flussinformationen, die in der FDB 110 gespeichert sind, werden gelesen. Erläuternd umfassen diese Informationen den Flussgültigkeitsindikator 520, die Flussfolgenummer 522 und den Flussaktivitätsindikator 524 (in 5 gezeigt).
Im Zustand 612 bestimmt der FDBM 108 aus Informationen, die vom Kopf-Parser 106 empfangen werden, ob das Paket TCP-Nutzinformationsdaten enthält. Wenn nicht, geht die dargestellte Prozedur zum Zustand 638 (6C) weiter; ansonsten fährt die Prozedur mit dem Zustand 614 fort.
Im Zustand 614 stellt der Flussdatenbank-Manager fest, ob das Paket einen Versuch bildet, eine Kommunikationsverbindung oder einen Fluss zurückzusetzen. Erläuternd kann dies durch Untersuchen des Zustandes eines SYN-Bits in einem der Protokollköpfe des Pakets (z. B. einem TCP-Kopf) bestimmt werden. In einer Ausführungsform der Erfindung wird der Wert von einem oder mehreren Steuer- oder Flag-Bits (wie z. B. des SYN-Bits) durch den Kopf-Parser zum FDBM geliefert. Wie ein Fachmann erkennen wird, kann eine TCP-Entität versuchen, einen Kommunikationsfluss oder eine Kommunikationsverbindung mit einer anderen Entität zurückzusetzen (z. B. aufgrund eines Problems an einem der Host-Computer der Entität), und einen ersten Abschnitt von Daten zusammen mit der Neuverbindungsanforderung senden. Dies ist die Situation, die der Flussdatenbank-Manager im Zustand 614 zu erkennen versucht. Wenn das Paket ein Teil eines Versuchs ist, einen Fluss oder eine Verbindung erneut zu verbinden oder zurückzusetzen, fährt die Prozedur im Zustand 630 (6C) fort.
Im Zustand 616 vergleicht der Flussdatenbank-Manager 108 eine Folgenummer (z. B. eine TCP-Folgenummer), die von einem Paketkopf extrahiert wird, mit einer Folgenummer (z. B. Flussfolgenummer 522 von 5) des nächsten erwarteten Abschnitts von Daten für diesen Fluss. Erläuternd sollten diese Folgenummern korrelieren, wenn das Paket den nächsten Abschnitt von Daten des Flusses enthält. Wenn die Folgenummern nicht übereinstimmen, fährt die Prozedur im Zustand 628 fort.
Im Zustand 618 stellt der FDBM 108 fest, ob bestimmte Flags, die von einem oder mehreren der Protokollköpfe des Pakets extrahiert werden, erwarteten Werten entsprechen. In einer Ausführungsform der Erfindung wird beispielsweise erwartet, dass die URG-, PSH-, RST- und FIN-Flags vom TCP-Kopf des Pakets gelöscht (d. h. gleich Null) sind. Wenn irgendeines dieser Flags gesetzt (z. B. gleich Eins) ist, kann eine Ausnahmebedingung existieren, was es folglich möglich macht, dass eine oder mehrere der Funktionen (z. B. erneute Datenzusammenfügung, Stapelverarbeitung, Lastverteilung), die von der NIC 100 geboten werden, für dieses Paket nicht durchgeführt werden sollten. Solange die Flags gelöscht sind, fährt die Prozedur im Zustand 620 fort; ansonsten fährt die Prozedur im Zustand 626 fort.
Im Zustand 620 stellt der Flussdatenbank-Manager fest, ob mehr Daten während dieses Flusses erwartet werden. Wie vorstehend erörtert, kann ein Fluss in der Dauer auf ein einzelnes Datagramm begrenzt sein. Daher stellt der FDBM im Zustand 620 fest, ob dieses Paket der Endabschnitt von Daten für das Datagramm dieses Flusses zu sein scheint. Erläuternd wird diese Feststellung auf der Basis der Menge an Daten, die im vorliegenden Paket enthalten sind, durchgeführt. Wie ein Fachmann erkennen wird, kann ein Datagramm mit mehr Daten als in einem Paket getragen werden können, über mehrere Pakete gesandt werden. Die typische Weise der Verbreitung eines Datagramms unter mehreren Paketen besteht darin, so viel Daten wie möglich in jedes Paket zu geben. Folglich ist jedes Paket außer dem letzten gewöhnlich in der Größe gleich oder fast gleich der maximalen Übertragungseinheit (MTU), die für das Netz zugelassen ist, über das die Pakete gesandt werden. Das letzte Paket hält den Rest, was gewöhnlich verursacht, dass es kleiner ist als die MTU.
Daher besteht eine Weise der Identifikation des Endabschnitts von Daten im Datagramm eines Flusses darin, die Größe jedes Pakets zu untersuchen und sie mit einer Zahl (z. B. MTU) zu vergleichen, deren Überschreitung von einem Paket erwartet wird, außer wenn der letzte Datenabschnitt getragen wird. Vorstehend wurde beschrieben, dass Steuerinformationen vom FDBM 108 vom Kopf-Parser 106 empfangen werden. Eine Angabe der Größe der von einem Paket getragenen Daten kann in diesen Informationen enthalten sein. Insbesondere ist der Kopf-Parser 106 in einer Ausführungsform der Erfindung dazu konfiguriert, die Größe des Datenabschnitts jedes Pakets mit einem vorgewählten Wert zu vergleichen. In einer Ausführungsform der Erfindung ist dieser Wert programmierbar. Dieser Wert wird in der dargestellten Ausführungsform der Erfindung auf die maximale Menge von Daten, die ein Paket ohne Überschreitung der MTU tragen kann, gesetzt. In einer alternativen Ausführungsform wird der Wert auf eine Menge gesetzt, die etwas geringer ist als die maximale Menge an Daten, die getragen werden kann.
Im Zustand 620 stellt der Flussdatenbank-Manager 108 folglich fest, ob das empfangene Paket den Endabschnitt von Daten für das Datagramm des Flusses zu tragen scheint. Wenn nicht, fährt die Prozedur zum Zustand 626 fort.
Im Zustand 622 wurde festgestellt, dass das Paket mit vorgewählten Protokollen kompatibel ist und für eine oder mehrere Funktionen, die von der NIC 100 geboten werden, geeignet ist. Insbesondere wurde das Paket für eine oder mehrere der vorstehend erörterten Funktionen geeignet formatiert. Der FDBM 108 hat festgestellt, dass das empfangene Paket ein Teil eines existierenden Flusses ist, mit den vorgewählten Protokollen kompatibel ist und den nächsten Abschnitt von Daten für den Fluss (aber nicht den Endabschnitt) enthält. Ferner ist das Paket kein Teil eines Versuchs, einen Fluss/eine Verbindung zurückzusetzen, und wichtige Flags besitzen ihre erwarteten Werte. Folglich kann die Flussdatenbank 110 folgendermaßen aktualisiert werden.
Der Aktivitätsindikator (z. B. Flussaktivitätsindikator 524 von 5) für diesen Fluss wird modifiziert, um die neue Flussaktivität zu reflektieren. In einer Ausführungsform der Erfindung wird der Flussaktivitätsindikator 524 als Zähler implementiert oder wird einem Zähler zugeordnet, d. h., wird jedes Mal, wenn Daten für einen Fluss empfangen werden, inkrementiert. In einer weiteren Ausführungsform der Erfindung wird ein Aktivitätsindikator oder Zähler jedes Mal aktualisiert, wenn ein Paket mit einem Flussschlüssel, der einem gültigen Fluss entspricht (z. B. ob das Paket Daten enthält oder nicht), empfangen wird.
In der dargestellten Ausführungsform wird, nachdem ein Flussaktivitätsindikator oder -zähler inkrementiert wird, er untersucht, um festzustellen, ob er auf Null "übergegangen" ist (d. h. ob er an seinem Maximalwert vorbei inkrementiert wurde). Wenn ja, werden der Zähler und/oder die Flussaktivitätsindikatoren für jeden Eintrag in der Flussdatenbank 110 auf Null gesetzt und der Aktivitätsindikator des aktuellen Flusses wird wieder inkrementiert. Folglich verursacht in einer Ausführungsform der Erfindung das Übergehen eines Flussaktivitätszählers oder -indikators die erneute Initialisierung des Flussaktivitätsmechanismus für die Flussdatenbank 110. Anschließend wird der Zähler inkrementiert und die Flussaktivitätsindikatoren werden wieder aktualisiert, wie vorher beschrieben. Ein Fachmann wird erkennen, dass viele weitere geeignete Verfahren bestehen, die in einer Ausführungsform der vorliegenden Erfindung angewendet werden können, um anzugeben, dass ein Fluss in jüngerer Zeit aktiv war als ein anderer.
Im Zustand 622 wird auch die Flussfolgenummer 522 aktualisiert. Erläuternd wird die neue Flussfolgenummer durch Addieren der Größe der neu empfangenen Daten zur existierenden Flussfolgenummer bestimmt. In Abhängigkeit von der Konfiguration des Pakets (z. B. Werte in seinen Köpfen) kann diese Summe eingestellt werden müssen. Diese Summe kann beispielsweise einfach die Gesamtmenge an Daten, die bisher für das Datagramm des Flusses empfangen wurden, angeben. Daher kann ein Wert addiert werden müssen (z. B. ein Byte), um eine Folgenummer des nächsten Bytes von Daten für das Datagramm anzugeben. Wie ein Fachmann erkennen wird, können andere geeignete Verfahren zum Sicherstellen, dass Daten der Reihe nach empfangen werden, anstelle des hier 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 ein Operationscode dem Paket zugeordnet. In der dargestellten Ausführungsform der Erfindung umfassen Operationscodes Codes, die durch den Flussdatenbank-Manager 108 erzeugt und in der Steuerwarteschlange 118 gespeichert werden. In dieser Ausführungsform ist ein Operationscode drei Bits groß, was folglich acht Operationscodes ermöglicht. Die Operationscodes können eine Vielzahl von anderen Formen und Bereichen in anderen Ausführungsformen aufweisen. Für die dargestellte Ausführungsform der Erfindung beschreibt die TABELLE 1 jeden Operationscode hinsichtlich der Kriterien, die zur Auswahl jedes Codes führen, und die Verzweigungen dieser Auswahl. Für die Zwecke von TABELLE 1 umfasst das Aufbauen eines Flusses das Einfügen eines Flusses in die Flussdatenbank 110. Das Abbrechen eines Flusses umfasst das Entfernen oder Invalidieren eines Flusses in der Flussdatenbank 110. Die erneute Zusammenfügung von Daten kann von der DMA-Maschine 120 durchgeführt werden.
In der dargestellten Ausführungsform der Erfindung wird der Operationscode 4 im Zustand 624 für Pakete im vorliegenden Zusammenhang der Prozedur (z. B. kompatible Pakete, die den nächsten, aber nicht letzten Datenabschnitt eines Flusses tragen) ausgewählt. Folglich wird der existierende Fluss nicht abgebrochen und es besteht kein Bedarf, einen neuen Fluss aufzubauen. Wie vorstehend beschrieben, ist ein kompatibles Paket in dieser Ausführungsform ein Paket, das einem oder mehreren der vorgewählten Protokolle entspricht. Durch Ändern oder Vermehren der vorgewählten Protokolle kann theoretisch jegliches Paket in einer alternativen Ausführungsform der Erfindung kompatibel sein.
Wenn nun zur 6A–6E zurückgekehrt wird, endet die dargestellte Prozedur nach dem Zustand 624 im Zustand 670.
Im Zustand 626 (vom Zustand 618 oder Zustand 620 erreicht), wird der Operationscode 3 für das Paket ausgewählt. Erläuternd gibt der Operationscode 3 an, dass das Paket kompatibel ist und einem gültigen Fluss entspricht (z. B. entspricht der Flussschlüssel des Pakets dem Flussschlüssel eines gültigen Flusses in der FDB 110). Der Operationscode 3 kann auch bedeuten, dass das Paket Daten enthält, keinen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung erneut zu synchronisieren oder zurückzusetzen, und die Folgenummer des Pakets der erwarteten Folgenummer (aus der Flussdatenbank 110) entspricht. Entweder ein wichtiges Flag (z. B. eines der TCP-Flags URG, PSH, RST oder FIN) wird jedoch gesetzt (im Zustand 618 bestimmt) oder die Daten des Pakets sind geringer als der vorstehend beschriebenen Schwellenwert (im Zustand 620), was folglich angibt, dass keine weiteren Daten wahrscheinlich diesem Paket in diesem Fluss folgen. Daher wird der existierende Fluss abgebrochen, aber kein neuer Fluss wird erzeugt. Erläuternd kann der Fluss durch Löschen des Gültigkeitsindikators des Flusses (z. B. Setzen desselben auf Null) abgebrochen werden. Nach dem Zustand 626 endet die dargestellte Prozedur im Zustand 670.
Im Zustand 628 (vom Zustand 616 erreicht), wird der Operationscode 2 für das Paket ausgewählt. Im vorliegenden Zusammenhang kann der Operationscode 2 angeben, dass das Paket kompatibel ist, einem gültigen Fluss entspricht (z. B. entspricht der Flussschlüssel des Pakets dem Flussschlüssel eines gültigen Flusses in der FDB 110), Daten enthält und keinen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung erneut zu synchronisieren oder zurückzusetzen. Die aus dem Paket extrahierte Folgenummer (im Zustand 616) entspricht jedoch nicht der erwarteten Folgenummer aus der Flussdatenbank 110. Dies kann beispielsweise vorkommen, wenn ein Paket außerhalb der Reihe empfangen wird. Folglich wird der existierende Fluss abgebrochen, aber kein neuer Fluss wird aufgebaut. Erläuternd kann der Fluss durch Löschen des Gültigkeitsindikators des Flusses (z. B. Setzen desselben auf Null) abgebrochen werden. Nach dem Zustand 628 endet die dargestellte Prozedur im Zustand 670.
In den Zustand 630 wird vom Zustand 614 eingetreten, wenn festgestellt 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 stellt der Flussdatenbank-Manager 108 fest, ob erwartet wird, dass mehr Daten folgen. Wie in Verbindung mit dem Zustand 620 erläutert, kann diese Feststellung auf der Basis der Steuerinformationen durchgeführt werden, die durch den Flussdatenbank-Manager vom Kopf-Parser empfangen werden. Wenn mehr Daten erwartet werden (z. B. die Menge an Daten im Paket gleich einem Schwellenwert ist oder diesen überschreitet), fährt die Prozedur im Zustand 634 fort.
Im Zustand 632 wird der Operationscode 2 für das Paket ausgewählt. Der Operationscode 2 wurde auch im Zustand 628 in einem anderen Zusammenhang ausgewählt. Im vorliegenden Zusammenhang kann der Operationscode 2 angeben, dass das Paket kompatibel ist, einem gültigen Fluss entspricht und Daten enthält. Der Operationscode 2 kann auch in diesem Zusammenhang bedeuten, dass das Paket einen Versuch bildet, einen Kommunikationsfluss oder eine Kommunikationsverbindung erneut zu synchronisieren oder zurückzusetzen, aber dass keine weiteren Daten erwartet werden, sobald der Fluss/die Verbindung zurückgesetzt ist. Daher wird der existierende Fluss abgebrochen und kein neuer Fluss wird aufgebaut. Erläuternd kann der Fluss durch Löschen des Gültigkeitsindikators des Flusses (z. B. Setzen desselben auf Null) abgebrochen werden. Nach dem Zustand 632 endet die dargestellte Prozedur im Zustand 670.
Im Zustand 634 antwortet der Flussdatenbank-Manager 108 auf einen Versuch, einen Kommunikationsfluss/eine Kommunikationsverbindung zurückzusetzen oder erneut zu synchronisieren, wodurch zusätzliche Daten erwartet werden. Folglich wird der existierende Fluss abgebrochen und folgendermaßen ersetzt. Der existierende Fluss kann durch die im Zustand 610 wiedergewonnene Flussnummer oder durch den Flussschlüssel des Pakets identifiziert werden. Die Folgenummer des Flusses (z. B. Flussfolgenummer 522 in 5) wird auf den nächsten erwarteten Wert gesetzt. Erläuternd hängt dieser Wert von der Folgenummer (z. B. der TCP-Folgenummer), die vom Paket wiedergewonnen wird (z. B. durch den Kopf-Parser 106), und von der Menge an Daten, die im Paket enthalten sind, ab. In einer Ausführungsform der Erfindung werden diese zwei Werte addiert, um eine neue Flussfolgenummer zu bestimmen. Wie vorher erörtert, kann diese Summe eingestellt werden müssen (z. B. durch Addieren von Eins). Im Zustand 634 wird auch der Flussaktivitätsindikator aktualisiert (z. B. inkrementiert). Wie in Verbindung mit dem Zustand 622 erläutert, werden, wenn der Flussaktivitätsindikator übergeht, die Aktivitätsindikatoren für alle Flüsse in der Datenbank auf Null gesetzt und der vorliegende Fluss wird wieder inkrementiert. Schließlich wird der Flussgültigkeitsindikator gesetzt, um anzugeben, dass der Fluss gültig ist.
Im Zustand 636 wird der Operationscode 7 für das Paket ausgewählt. Im vorliegenden Zusammenhang gibt der Operationscode 7 an, dass das Paket kompatibel ist, einem gültigen Fluss entspricht und Daten enthält. Der Operationscode 7 kann in diesem Zusammenhang ferner bedeuten, dass das Paket einen Versuch bildet, einen Kommunikationsfluss/eine Kommunikationsverbindung erneut zu synchronisieren oder zurückzusetzen, und dass zusätzliche Daten erwartet werden, sobald der Fluss/die Verbindung zurückgesetzt ist. Daher wird der existierende Fluss tatsächlich abgebrochen und ein neuer (mit demselben Flussschlüssel) wird an seiner Stelle gespeichert. Nach dem Zustand 636 endet die dargestellte Prozedur im Endzustand 670.
In den Zustand 638 wird nach dem Zustand 612 eingetreten, wenn festgestellt wird, dass das empfangene Paket keine Daten enthält. Dies gibt häufig an, dass das Paket ein Steuerpaket ist. Im Zustand 638 stellt der Flussdatenbank-Manager 108 fest, ob ein oder mehrere Flags, die vom Paket durch den Kopf-Parser extrahiert werden, erwarteten oder gewünschten Werten entsprechen. In einer Ausführungsform der Erfindung müssen beispielsweise die TCP-Flags URG, PSH, RST und FIN gelöscht sein, damit die DMA-Maschine 120 Daten von mehreren in Beziehung stehenden Paketen (z. B. Paketen mit einem identischen Flussschlüssel) erneut zusammenfügt. Wie vorstehend erörtert, kann das TCP-SYN-Bit auch untersucht werden. Im vorliegenden Zusammenhang (z. B. ein Paket ohne Daten) wird auch erwartet, dass das SYN-Bit gelöscht ist (z. B. einen Wert von Null speichert). Wenn die Flags (und das SYN-Bit) ihre erwarteten Werte besitzen, fährt die Prozedur im Zustand 642 fort. Wenn jedoch irgendwelche dieser Flags gesetzt sind, kann eine Ausnahmebedingung existieren, was es folglich möglich macht, dass eine oder mehrere von der NIC 100 gebotene Funktionen (z. B. erneute Datenzusammenfügung, Stapelverarbeitung, Lastverteilung) für dieses Paket ungeeignet sind, in welchem Fall die Prozedur zum Zustand 640 weitergeht.
Im Zustand 640 wird der Operationscode 1 für das Paket ausgewählt. Erläuternd gibt der Operationscode 1 an, dass das Paket kompatibel ist und einem gültigen Fluss entspricht, aber keine Daten enthält und ein oder mehrere wichtige Flags oder Bits in dem (den) Kopf (Köpfen) des Pakets gesetzt sind. Folglich wird der existierende Fluss abgebrochen und kein neuer Fluss wird aufgebaut. Erläuternd kann der Fluss durch Löschen des Gültigkeitsindikators des Flusses (z. B. Setzen desselben auf Null) abgebrochen werden. Nach dem Zustand 640 endet die dargestellte 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 vorstehend in Verbindung mit dem Zustand 622 beschrieben, werden, wenn der Aktivitätsindikator übergeht, in einer vorliegenden Ausführungsform der Erfindung alle Flussaktivitätsindikatoren in der Datenbank auf Null gesetzt und der aktuelle Fluss wird wieder inkrementiert. Der Gültigkeitsindikator des Flusses kann ebenso wie die Folgenummer des Flusses auch zurückgesetzt werden.
Im Zustand 644 wird der Operationscode 0 für das Paket ausgewählt. Erläuternd gibt der Operationscode 0 an, dass das Paket kompatibel ist, einem gültigen Fluss entspricht und dass das Paket keine Daten enthält. Das Paket kann beispielsweise ein Steuerpaket sein. Der Operationscode 0 gibt ferner an, dass keines der durch den Kopfs-Parser 106 geprüften und beschrieben beschriebenen Flags (z. B. URG, PSH, RST und FIN) gesetzt ist. Folglich wird der existierende Fluss nicht abgebrochen und kein neuer Fluss wird aufgebaut. Nach dem Zustand 644 endet die dargestellte Prozedur im Endzustand 670.
In den Zustand 646 wird vom Zustand 608 eingetreten, wenn der Flussschlüssel des Pakets keinem der Flussschlüssel von gültigen Flüssen in der Flussdatenbank entspricht. Im Zustand 646 stellt der FDBM 108 fest, ob die Flussdatenbank 110 voll ist, und kann irgendeine Angabe dessen, ob die Datenbank voll ist, speichern. In einer Ausführungsform der Erfindung wird die Flussdatenbank als voll betrachtet, wenn der Gültigkeitsindikator (z. B. Flussgültigkeitsindikator 520 von 5) für jede Flussnummer (z. B. für jeden Fluss in der Datenbank) gesetzt ist. Wenn die Datenbank voll ist, fährt die Prozedur im Zustand 650 fort, ansonsten fährt sie im Zustand 648 fort.
Im Zustand 648 wird die niedrigste Flussnummer eines ungültigen Flusses (z. B. eines Flusses, für den der zugehörige Flussgültigkeitsindikator gleich Null ist) bestimmt. Erläuternd befindet sich diese Flussnummer dort, wo ein neuer Fluss gespeichert wird, wenn das empfangene Paket die Erzeugung eines neuen Flusses rechtfertigt. Nach dem Zustand 648 fährt die Prozedur im Zustand 652 fort.
Im Zustand 650 wird die Flussnummer des vor längster Zeit aktiven Flusses bestimmt. Wie vorstehend erörtert, wird in der dargestellten Ausführungsform der Erfindung der Aktivitätsindikator eines Flusses (z. B. Flussaktivitätsindikator 524 von 5) jedes Mal aktualisiert (z. B. inkrementiert), wenn Daten für einen Fluss empfangen werden. Daher kann in dieser Ausführungsform der vor längster Zeit aktive Fluss als Fluss mit dem vor längster Zeit aktualisierten (z. B. niedrigsten) Flussaktivitätsindikator identifiziert werden. Wenn mehrere Flüsse Flussaktivitätsindikatoren, die auf einen gemeinsamen Wert gesetzt sind (z. B. Null), aufweisen, kann erläuternd eine Flussnummer aus ihnen willkürlich oder durch irgendwelche anderen Kriterien ausgewählt werden. Nach dem Zustand 650 fährt die Prozedur im Zustand 652 fort.
Im Zustand 652 stellt der Flussdatenbank-Manager 108 fest, ob das Paket Daten enthält. Erläuternd geben die Steuerinformationen, die vom Kopf-Parser zum FDBM 108 geliefert werden, an, ob das Paket Daten aufweist. Wenn das Paket keine Daten enthält (z. B. das Paket ein Steuerpaket ist), fährt die dargestellte Prozedur im Zustand 668 fort.
Im Zustand 654 stellt der Flussdatenbank-Manager 108 fest, ob die mit dem vorliegenden Paket wiedergewonnenen Daten den Endabschnitt von Daten für das zugehörige Datagramm/den zugehörigen Fluss zu enthalten scheinen. Wie in Verbindung mit dem Zustand 620 beschrieben, kann diese Feststellung auf der Basis der Menge an Daten, die im Paket enthalten sind, durchgeführt werden. Wenn die Menge an Daten geringer ist als ein Schwellenwert (ein programmierbarer Wert in der dargestellten Ausführungsform), dann werden keine weiteren Daten erwartet und dies sind wahrscheinlich die einzigen Daten für diesen Fluss. In diesem Fall fährt die Prozedur im Zustand 668 fort. Wenn jedoch die Daten den Schwellenwert treffen oder überschreiten, in welchem Fall mehr Daten erwartet werden können, fährt die Prozedur zum Zustand 656 fort.
Im Zustand 656 werden die Werte bestimmter Flags untersucht. Diese Flags können beispielsweise die URG-, PSH-, RST-, FIN-Bits eines TCP-Kopfs umfassen. Wenn irgendwelche der untersuchten Flags nicht ihre erwarteten oder gewünschten Werte aufweisen (z. B. wenn irgendwelche der Flags gesetzt sind), kann eine Ausnahmebedingung existieren, die eine oder mehrere der Funktionen der NIC 100 (z. B. erneute Datenzusammenfügung, Stapelverarbeitung, Lastverteilung) für dieses Paket ungeeignet macht. In diesem Fall fährt die Prozedur im Zustand 668 fort; ansonsten geht die Prozedur zum Zustand 658 weiter.
Im Zustand 658 gewinnt der Flussdatenbank-Manager die im Zustand 646 gespeicherten Informationen hinsichtlich dessen, ob die Flussdatenbank 110 voll ist, wieder. Wenn die Datenbank voll ist, fährt die Prozedur im Zustand 664 fort; ansonsten fährt die Prozedur im Zustand 660 fort.
Im Zustand 660 wird ein neuer Fluss zur Flussdatenbank 110 für das vorliegende Paket hinzugefügt. Erläuternd wird der neue Fluss an der Flussnummer gespeichert, der im Zustand 648 identifiziert oder wiedergewonnen wird. Das Hinzufügen eines neuen Flusses kann das Setzen einer Folgenummer (z. B. Flussfolgenummer 522 von 5) beinhalten. Die Flussfolgenummer 522 kann durch Addieren einer Folgenummer (z. B. TCP-Folgenummer), die vom Paket wiedergewonnen wird, und der Menge an Daten, die im Paket enthalten sind, erzeugt werden. Wie vorstehend erörtert, kann diese Summe eingestellt werden müssen (z. B. durch Addieren von Eins).
Das Speichern eines neuen Flusses kann auch das Initialisieren eines Aktivitätsindikators (z. B. Flussaktivitätsindikators 524 von 5) umfassen. In einer Ausführungsform der Erfindung beinhaltet diese Initialisierung das Speichern eines Werts, der von einem Zähler wiedergewonnen wird, der jedes Mal inkrementiert wird, wenn Daten für einen Fluss empfangen werden. Wenn der Zähler oder ein Flussaktivitätsindikator an seinem maximalen speicherbaren Wert vorbei inkrementiert wird, werden erläuternd der Zähler und alle Flussaktivitätsindikatoren gelöscht oder zurückgesetzt. Im Zustand 660 wird auch ein Gültigkeitsindikator (z. B. Flussgültigkeitsindikator 520 von 5) gesetzt, um anzugeben, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des Pakets auch in der Flussdatenbank in dem Eintrag, der der zugewiesenen Flussnummer entspricht, gespeichert.
Im Zustand 662 wird der Operationscode 6 für das Paket ausgewählt. Erläuternd gibt der Operationscode 6 an, dass das Paket kompatibel ist, keinen gültigen Flüssen entsprach und den ersten Abschnitt von Daten für einen neuen Fluss enthält. Ferner weisen die Flags des Pakets ihre erwarteten oder erforderlichen Werte auf, zusätzliche Daten werden im Fluss erwartet und die Flussdatenbank ist nicht voll. Folglich gibt der Operationscode 6 an, dass kein existierender Fluss abzubrechen ist und dass ein neuer Fluss in der Flussdatenbank gespeichert wurde. Nach dem Zustand 662 endet die dargestellte Prozedur im Zustand 670.
Im Zustand 664 wird ein existierender Eintrag in der Flussdatenbank ersetzt, so dass ein neuer Fluss, der durch das vorliegende Paket eingeleitet wird, gespeichert werden kann. Daher wird die Flussnummer des vor längster Zeit aktiven Flusses, die im Zustand 650 identifiziert wird, wiedergewonnen. Dieser Fluss kann folgendermaßen ersetzt werden. Die Folgenummer des existierenden Flusses (z. B. Flussfolgenummer 522 von 5) wird gegen einen Wert ausgetauscht, der durch Kombinieren einer Folgenummer, die vom Paket extrahiert wird (z. B. TCP-Folgenummer), mit der Größe des Datenabschnitts des Pakets abgeleitet wird. Diese Summe kann eingestellt werden müssen (z. B. durch Addieren von Eins). Dann wird der Aktivitätsindikator des existierenden Flusses (z. B. Flussaktivitätsindikator 524) ersetzt. Der Wert eines Flussaktivitätszählers kann beispielsweise in den Flussaktivitätsindikator kopiert werden, wie vorstehend erörtert. Der Gültigkeitsindikator eines Flusses (z. B. Flussgültigkeitsindikator 520 von 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 wurde auch im Zustand 636 ausgewählt. Im vorliegenden Zusammenhang kann der Operationscode 7 angeben, dass das Paket kompatibel ist, nicht dem Flussschlüssel von irgendwelchen gültigen Flüssen entsprach und den ersten Abschnitt von Daten für einen neuen Fluss enthält. Ferner weisen die Flags des Pakets kompatible Werte auf und zusätzliche Daten werden im Fluss erwartet. Schließlich gibt jedoch in diesem Zusammenhang der Operationscode 7 an, dass die Flussdatenbank voll ist, so dass ein existierender Eintrag abgebrochen wurde und der neue an seiner Stelle gespeichert wurde. Nach dem Zustand 666 endet die dargestellte Prozedur im Endzustand 670.
Im Zustand 668 wird der Oerationscode 5 für das Paket ausgewählt. In den Zustand 668 wird von verschiedenen Zuständen eingetreten und der Operationscode 5 stellt folglich eine Vielzahl von möglichen Bedingungen oder Situationen dar. Der Operationscode 5 kann beispielsweise ausgewählt werden, wenn ein No_Assist-Signal für ein Paket erfasst wird (im Zustand 604). Wie vorstehend erörtert, kann das No_Assist-Signal angeben, dass das entsprechende Paket nicht mit einem Satz von vorgewählten Protokollen kompatibel ist. In dieser Ausführungsform der Erfindung sind inkompatible Pakete für eine oder mehrere der verschiedenen Funktionen der NIC 100 (z. B. erneute Datenzusammenfügung, Stapelverarbeitung, Lastverteilung) nicht berechtigt.
In den Zustand 668 kann auch vom Zustand 652 eingetreten werden und der Operationscode 5 ausgewählt werden, in welchem Fall der Code angeben kann, dass das empfangene Paket keinen gültigen Flussschlüsseln entspricht und ferner keine Daten enthält (z. B. kann es ein Steuerpaket sein).
In den Zustand 668 kann auch vom Zustand 654 eingetreten werden. In diesem Zusammenhang kann der Operationscode 5 angeben, dass das Paket keinen gültigen Flussschlüsseln entspricht. Er kann ferner angeben, dass das Paket Daten enthält, aber dass die Größe des Datenabschnitts geringer ist als der in Verbindung mit dem Zustand 654 erörterte Schwellenwert. In diesem Zusammenhang scheint es, dass die Daten des Pakets vollständig sind (z. B. alle Daten für ein Datagramm umfassen), was bedeutet, dass keine weiteren Daten mit Daten dieses Pakets zusammenzufügen sind und daher kein Grund besteht, einen neuen Eintrag in der Datenbank für diesen Fluss mit einem Paket durchzuführen.
Schließlich kann in den Zustand 668 auch vom Zustand 656 eingetreten werden. In diesem Zusammenhang kann der Operationscode 5 angeben, dass das Paket keinen gültigen Flussschlüsseln entspricht, Daten enthält und mehr Daten erwartet werden, aber mindestens ein Flag in einem oder mehreren der Protokollköpfe des Pakets nicht seinen erwarteten Wert aufweist. In einer Ausführungsform der Erfindung wird beispielsweise erwartet, dass die TCP-Flags URG, PSH, RST und FIN gelöscht sind. Wenn irgendwelche dieser Flags gesetzt sind, kann eine Ausnahmebedingung existieren, was es folglich möglich macht, dass eine der von der NIC 100 gebotenen Funktionen für dieses Paket ungeeignet ist.
Wie TABELLE 1 reflektiert, ist kein Fluss abzubrechen und kein neuer Fluss wird aufgebaut, wenn der Operationscode 5 ausgewählt wird. Nach dem Zustand 668 endet die dargestellte Prozedur im Zustand 670.
Ein Fachmann wird erkennen, dass die in 6A–6E dargestellte und vorstehend erörterte Prozedur nur eine geeignete Prozedur zum Warten und Aktualisieren einer Flussdatenbank und zum Bestimmen der Eignung eines Pakets für bestimmte Verarbeitungsfunktionen ist. Insbesondere können verschiedene Operationscodes verwendet werden oder können in einer anderen Weise implementiert werden, wobei ein Ziel darin besteht, Informationen für die spätere Verarbeitung des Pakets durch die NIC 100 zu erzeugen.
Obwohl Operationscodes für alle Pakete durch einen Flussdatenbank-Manager in der dargestellten Prozedur zugewiesen werden, kann in einer alternativen Prozedur ein Operationscode, der durch den FDBM zugewiesen wird, durch ein anderes Modul der NIC 100 ersetzt oder geändert werden. Dies kann durchgeführt werden, um ein spezielles Verfahren zur Behandlung von bestimmten Typen von Paketen sicherzustellen. In einer Ausführungsform der Erfindung weist das IPP-Modul 104 beispielsweise einen vorbestimmten Operationscode (z. B. Operationscode 2 von TABELLE 1) Jumbopaketen (z. B. Paketen, die eine größere Größe als eine MTU besitzen) zu, so dass die DMA-Maschine 120 sie nicht erneut zusammenfügt. Insbesondere kann das IPP-Modul unabhängig feststellen, dass das Paket ein Jumbopaket ist (z. B. von Informationen, die von einem MAC-Modul geliefert werden), und daher den vorbestimmten Code zuweisen. Erläuternd führen der Kopf-Parser 106 und der FDBM 108 ihre normalen Funktionen für ein Jumbopaket durch und das IPP-Modul 104 empfängt einen ersten Operationscode, der durch den FDBM zugewiesen wird. Das IPP-Modul ersetzt jedoch diesen Code, bevor das Jumbopaket und Informationen hinsichtlich des Pakets gespeichert werden. In einer alternativen Ausführungsform kann der Kopf-Parser 106 und/oder der Flussdatenbank-Manager 108 dazu konfiguriert sein, einen speziellen Typ von Paket (z. B. Jumbo) zu erkennen und einen vorbestimmten Operationscode zuzuweisen.
Die Operationscodes, die in der Ausführungsform der Erfindung angewendet werden, die in 6A–6E dargestellt ist, sind in der folgenden TABELLE 1 dargestellt und erläutert. Die TABELLE 1 enthält erläuternde Kriterien, die verwendet werden, um jeden Operationscode auszuwählen, und erläuternde Ergebnisse oder Effekte jedes Codes.
TABELLE 1
Eine Ausführungsform eines Lastverteilers
In einer Ausführungsform der Erfindung ermöglicht der Lastverteiler 112, dass die Verarbeitung von Paketen durch ihre Protokollprofile unter einer Anzahl von Prozessoren verteilt wird. Erläuternd erzeugt der Lastverteiler 112 einen Identifizierer (z. B. eine Prozessornummer) eines Prozessors, an den ein Paket übermittelt werden soll. Die mehreren Prozessoren können sich innerhalb eines Host-Computersystems befinden, das von der NIC 100 bedient wird. In einer alternativen Ausführungsform befinden sich ein oder mehrere Prozessoren zum Bearbeiten von Paketen durch ein Protokollprofil an der NIC 100.
Ohne ein wirksames Verfahren zum Teilen oder Verteilen der Verarbeitungslast könnte ein Prozessor überlastet werden, wenn erforderlich wäre, dass er den ganzen oder das meiste des an der NIC 100 empfangenen Netzverkehrs verarbeitet, insbesondere in einer Hochgeschwindigkeits-Netzumgebung. Die resultierende Verzögerung bei der Verarbeitung von Netzverkehr könnte Operationen auf dem Host-Computersystem sowie anderen Computersystemen, die mit dem Host-System über das Netz kommunizieren, verschlechtern.
Wie ein Fachmann erkenne wird, kann das einfache Verteilen von Paketen unter Prozessoren in einem Satz von Prozessoren (wie z. B. in einem Round-Robin-Schema) kein effizienter Plan sein. Ein solcher Plan könnte leicht dazu führen, dass Pakete außerhalb der Reihe verarbeitet werden. Wenn beispielsweise zwei Pakete von einem Kommunikationsfluss oder einer Kommunikationsverbindung, die an einer Netzschnittstelle in der korrekten Reihenfolge empfangen werden, zu zwei verschiedenen Prozessoren übermittelt werden würden, kann das zweite Paket vor dem ersten verarbeitet werden. Dies könnte beispielsweise vorkommen, wenn der Prozessor, der das erste Paket empfangen hat, das Paket nicht sofort verarbeiten könnte, da er mit einer anderen Aufgabe beschäftigt war. Wenn Pakete außerhalb der Reihe verarbeitet werden, muss im Allgemeinen ein Wiedergewinnungsschema eingeleitet werden, was folglich noch mehr Ineffizienz und mehr Verzögerung einführt.
Daher werden in einer vorliegenden Ausführungsform der Erfindung Pakete unter mehreren Prozessoren auf der Basis ihrer Flussidentitäten verteilt. Wie vorstehend beschrieben, kann ein Kopf-Parser einen Flussschlüssel aus den Quell- und Zielidentifizierern der Schicht drei (z. B. IP) und der Schicht vier (z. B. TCP), die von den Köpfen eines Pakets wiedergewonnen werden, erzeugen. Der Flussschlüssel kann verwendet werden, um den Kommunikationsfluss zu identifizieren, zu dem das Paket gehört. In dieser Ausführungsform der Erfindung werden folglich alle Pakete mit einem identischen Flussschlüssel zu einem einzelnen Prozessor übermittelt. Solange die Pakete durch die NIC 100 der Reihe nach empfangen werden, sollten sie zum Host-Computer geliefert und der Reihe nach durch ihren zugewiesenen Prozessor verarbeitet werden.
Erläuternd weisen mehrere Pakete, die von einer Quellentität zu einer Zielentität gesandt werden, denselben Flussschlüssel auf, selbst wenn die Pakete ein Teil von separaten Datagrammen sind, solange ihre Identifizierer der Schicht drei und Schicht vier gleich bleiben. Wie vorstehend erörtert, werden separate Flüsse für jedes Datagramm innerhalb einer TCP-Verbindung von Ende zu Ende aufgebaut und abgebrochen. Genau wie alle Pakete innerhalb eines Flusses zu einem Prozessor gesandt werden, werden daher alle Pakete innerhalb einer TCP-Verbindung von Ende zu Ende auch zum gleichen Prozessor gesandt. Dies hilft, die korrekte Reihenfolge von Paketen für die ganze Verbindung, selbst zwischen Datagrammen, sicherzustellen.
In Abhängigkeit von der Netzumgebung, in der die NIC 100 arbeitet (z. B. den vom Netz 102 unterstützten Protokollen) kann der Flussschlüssel zu groß sein, um ihn als Identifizierer eines Prozessors zu verwenden. In einer vorstehend beschriebenen Ausführungsform der Erfindung misst ein Flussschlüssel beispielsweise 288 Bits. Unterdessen kann die Anzahl von Prozessoren, die am Lastausgleichschema teilnehmen, viel kleiner sein. In der nachstehend in Verbindung mit 7 beschriebenen Ausführungsform der Erfindung wird beispielsweise ein Maximum von vierundsechzig Prozessoren unterstützt. Folglich ist in dieser Ausführungsform nur eine Sechs-Bit-Zahl erforderlich, um den ausgewählten Prozessor zu identifizieren. Der größere Flussschlüssel kann daher in einen kleineren Bereich von Werten abgebildet oder Hash-codiert werden.
7 stellt ein Verfahren zum Erzeugen eines Identifizierers (z. B. einer Prozessornummer), um einen Prozessor zum Verarbeiten eines von der NIC 100 empfangenen Pakets festzulegen, auf der Basis des Flussschlüssels des Pakets dar. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet und ein empfangenes Paket ist gemäß einem kompatiblen Protokollprofil (z. B. Ethernet auf der Schicht zwei, IP auf der Schicht drei und TCP auf der Schicht vier) formatiert.
Der Zustand 700 ist ein Startzustand. Im Zustand 702 wird ein Paket von der NIC 100 empfangen und ein Kopfabschnitt des Pakets wird durch den Kopf-Parser 106 syntaktisch analysiert (ein Verfahren zur syntaktischen Analyse ist in einem vorherigen Abschnitt beschrieben). Im Zustand 704 empfängt der Lastverteiler 112 den Flussschlüssel des Pakets, der durch den Kopf-Parser 106 erzeugt wurde.
Da der Flussschlüssel eines Pakets in dieser Ausführungsform 288 Bits breit ist, wird im Zustand 706 eine Hash-Codierungs-Funktion durchgeführt, um einen Wert zu erzeugen, der im Betrag kleiner ist. Die Hash-Operation kann beispielsweise eine CRC-Funktion (zyklische Redundanzprüfung) mit zweiunddreißig Bits, wie z. B. ATM (asynchroner Übertragungsmodus) Anpassungsschicht 5 (AAL5), umfassen. AAL5 erzeugt Zahlen mit zweiunddreißig Bits, die unter den 2³² möglichen Werten ziemlich gleichmäßig verteilt sind. Ein weiteres geeignetes Verfahren zur Hash-Codierung ist die Standard-Ethernet-CRC-32-Funktion. Andere Hash-Funktionen, die in der Lage sind, relativ kleine Zahlen aus relativ großen Flussschlüsseln zu erzeugen, wobei die erzeugten Zahlen unter einem Bereich von Werten relativ gut verteilt sind, sind auch geeignet.
Mit dem resultierenden Hash-Wert wird im Zustand 708 eine Modul-Operation über die Anzahl von Prozessoren, die zur Verteilung oder Teilung der Verarbeitung zur Verfügung stehen, durchgeführt. Erläuternd programmiert oder speichert die auf dem Host-Computer ausführende Software (z. B. ein Vorrichtungstreiber für die NIC 100) die Anzahl von Prozessoren, so dass sie vom Lastverteiler 112 gelesen oder wiedergewonnen werden kann (z. B. in einem Register). Die Anzahl von Prozessoren, die zum Lastausgleich zur Verfügung stehen, können alle oder eine Teilmenge der Anzahl von Prozessoren sein, die in einem Host-Computersystem installiert sind. In der dargestellten Ausführungsform ist die Anzahl von in einem Host-Computersystem verfügbaren Prozessoren programmierbar, mit einem Maximalwert von vierundsechzig. Das Ergebnis der Modul-Operation in dieser Ausführungsform ist daher die Nummer des Prozessors (z. B. von Null bis dreiundsechzig), zu dem das Paket zur Verarbeitung übermittelt werden soll. In dieser Ausführungsform der Erfindung wird der Lastverteiler 112 in der Hardware implementiert, was folglich eine schnelle Ausführung der Hash-Codierungs- und Modul-Funktionen ermöglicht. In einer alternativen Ausfüh rungsform der Erfindung kann theoretisch einer beliebigen Anzahl von Prozessoren Rechnung getragen werden.
Im Zustand 710 wird die Nummer des Prozessors, der das Paket durch sein Protokollprofil verarbeitet, im Speicher des Host-Computers gespeichert. Erläuternd wird der Zustand 710 parallel mit der Speicherung des Pakets in einem Host-Speicher-Puffer durchgeführt. In einer Ausführungsform der Erfindung wird ein Deskriptor-Ring im Speicher des Host-Computers konstruiert, um die Prozessornummer und möglicherweise andere Informationen hinsichtlich des Pakets (z. B. einen Zeiger auf das Paket, seine Größe, seine TCP-Prüfsumme) zu halten.
Ein Deskriptor-Ring in dieser Ausführungsform ist eine Datenstruktur mit einer Anzahl von Einträgen oder "Deskriptoren" zum Speichern von Informationen, die von einem Host-Computersystem der Netzschnittstellenschaltung verwendet werden sollen. In der dargestellten Ausführungsform speichert ein Deskriptor vorübergehend Paketinformationen, nachdem das Paket von der NIC 100 empfangen wurde, jedoch bevor das Paket vom Host-Computersystem verarbeitet wird. Die in einem Deskriptor gespeicherten Informationen können beispielsweise vom Vorrichtungstreiber für die NIC 100 oder zur Verarbeitung des Pakets durch sein Protokollprofil verwendet werden.
Im Zustand 712 wird eine Unterbrechung oder eine andere Benachrichtigung an den Host-Computer ausgegeben, um ihn zu informieren, dass ein neues Paket von der NIC 100 geliefert wurde. In einer Ausführungsform der Erfindung, in der die NIC 100 mit dem Host-Computer durch einen PCI-Bus (Peripheriekomponentenverbindungsbus) gekoppelt ist, kann das INTA-Signal über den Bus aktiviert werden. Eine PCI-Steuereinheit im Host empfängt das Signal und das Host-Betriebssystem wird benachrichtigt (z. B. über eine Unterbrechung).
Im Zustand 714 wird die auf dem Host-Computer arbeitende Software (z. B. ein Vorrichtungstreiber für die NIC 100) aufgerufen (z. B. durch die Betriebssystem-Unterbrechungsbehandlungsroutine des Host-Computers), um ein neu empfangenes Paket zu bearbeiten. Die Software sammelt Informationen von einem oder mehreren Deskriptoren im Deskriptor-Ring und setzt Informationen, die zum Vollenden der Verarbeitung jedes neuen Pakets erforderlich sind, in eine Warteschlange für den festgelegten Prozessor (d. h. gemäß der Prozessornum mer, die im Deskriptor des Pakets gespeichert ist). Erläuternd entspricht jeder Deskriptor einem separaten Paket. Die in der Prozessorwarteschlange für jedes Paket gespeicherten Informationen können einen Zeiger auf einen das Paket enthaltenden Puffer, die TCP-Prüfsumme des Pakets, Versätze von einem oder mehreren Protokollköpfen usw. umfassen. Außerdem kann jeder Prozessor, der am Lastverteilungsschema teilnimmt, eine zugehörige Warteschlange für die Verarbeitung von Netzpaketen aufweisen. In einer alternativen Ausführungsform der Erfindung können mehrere Warteschlangen verwendet werden (z. B. für mehrere Prioritätsniveaus oder für verschiedene Protokollprofile).
Erläuternd ist ein Prozessor auf dem Host-Computersystem dazu konfiguriert, alle Benachrichtigungen und/oder Unterbrechungen zu empfangen, die dem Empfang von Netzpaketen von der NIC 100 zugeordnet sind, und die geeignete Softwareroutine oder den geeigneten Vorrichtungstreiber zu benachrichtigen. Diese anfängliche Verarbeitung kann alternativ unter mehreren Prozessoren verteilt werden. Außerdem wird in einer Ausführungsform der Erfindung ein Teil der Wiedergewinnung und Bearbeitung von Deskriptorinhalten als Teil der Bearbeitung der Unterbrechung durchgeführt, die erzeugt wird, wenn ein neues Paket im Deskriptor-Ring gespeichert wird. Der zur Verarbeitung des Pakets ausgewählte Prozessor führt den Rest der Wiedergewinnungs/Bearbeitungs-Prozedur durch.
Im Zustand 716 wird der zur Verarbeitung eines neuen Pakets festgelegte Prozessor benachrichtigt oder aufgeweckt. In einer Ausführungsform der Erfindung, die auf einem Solaris^TM Arbeitsplatzrechner arbeitet, werden einzelne Prozesse, die vom Prozessor ausgeführt werden, als "Threads" konfiguriert. Ein Thread ist ein Prozess, der in einem normalen Modus (z. B. nicht auf einer Unterbrechungsebene) läuft, so dass er eine minimale Auswirkung auf andere Prozesse hat, die auf dem Arbeitsplatzrechner ausgeführt werden. Ein Prozess im normalen Modus kann jedoch mit einer hohen Priorität ausgeführt werden. Alternativ kann ein Thread auf einer relativ niedrigen Unterbrechungsebene laufen.
Ein Thread, der für die Verarbeitung eines eingehenden Pakets verantwortlich ist, kann sich blockieren, wenn er keine Pakete zu verarbeiten hat, und aufwachen, wenn er Arbeit auszuführen hat. Eine "Bedingungsvariable" kann verwendet werden, um anzugeben, ob der Thread ein Paket zu verarbeiten hat. Erläuternd wird die Bedingungsvariable auf einen ersten Wert gesetzt, wenn der Thread ein Paket verarbeiten soll (z. B. wenn ein Paket zur Verarbeitung durch den Prozessor empfangen wird), und wird auf einen zweiten Wert gesetzt, wenn keine weiteren Pakete zu verarbeiten sind. In der dargestellten Ausführungsform der Erfindung kann eine Bedingungsvariable der Warteschlange jedes Prozessors zugeordnet werden.
In einer alternativen Ausführungsform wird der angegebene Prozessor im Zustand 716 durch einen "Kreuzprozessoraufruf" benachrichtigt. Ein Kreuzprozessoraufruf ist eine Weise zur Kommunikation unter Prozessoren, wobei ein Prozessor von einem anderen Prozessor entfernt unterbrochen wird. Andere Verfahren, durch die ein Prozessor einen anderen Prozessor benachrichtigt oder einen Prozessor zu diesem verteilt, können anstelle von Threads und Kreuzprozessoraufrufen verwendet werden.
Im Zustand 718 beginnt ein Thread oder ein anderer Prozess im ausgewählten Prozessor die Verarbeitung des Pakets, das in der Warteschlange des Prozessors gespeichert wurde. Verfahren zur Verarbeitung eines Pakets durch sein Protokollprofil sind Fachleuten gut bekannt und müssen nicht im Einzelnen beschrieben werden. Die dargestellte Prozedur endet dann mit dem Endzustand 720.
In einer alternativen Ausführungsform der Erfindung ist eine Hochgeschwindigkeits-Netzschnittstelle dazu konfiguriert, ATM-Verkehr (Verkehr des asynchronen Übertragungsmodus) zu empfangen und zu verarbeiten. In dieser Ausführungsform wird ein Lastverteiler vielmehr als Satz von Befehlen (z. B. als Software) als als Hardwaremodul implementiert. Wie ein Fachmann weiß, ist ATM-Verkehr verbindungsorientiert und kann durch einen virtuellen Verbindungsidentifizierer (VCI) identifiziert werden, der einem virtuellen Kreis entspricht, der zwischen den Quell- und Zielentitäten des Pakets aufgebaut ist. Jedes Paket, das ein Teil eines virtuellen Kreises ist, umfasst den VCI in seinem Kopf.
Vorteilhafterweise ist ein VCI in der Größe relativ klein (z. B. sechzehn Bits). In dieser alternativen Ausführungsform kann daher der VCI eines Pakets anstelle eines Flussschlüssels für den Zweck der Verteilung oder Teilung der Last der Verarbeitung von Paketen durch ihre Protokollprofile verwendet werden. Erläuternd wird Verkehr von verschiedenen VCIs zu verschiedenen Prozessoren gesandt, aber um eine korrekte Reihenfolge von Paketen sicherzustellen, werden alle Pakete mit demselben VCI zum gleichen Prozessor gesandt. Wenn ein ATM-Paket an einer Netzschnittstelle empfangen wird, wird der VCI von seinem Kopf wiedergewonnen und zum Lastverteiler geliefert. Der Modul des VCI über die Anzahl von Prozessoren, die für die Lastverteilung zur Verfügung stehen, wird dann berechnet. Ähnlich der dargestellten Ausführungsform werden das Paket und seine zugehörige Prozessornummer zum Host-Computer geliefert.
Wie vorstehend beschrieben, wird die Lastverteilung in einer vorliegenden Ausführungsform der Erfindung auf der Basis der Quell- und Zielentitätsidentifizierer der Schicht drei und/oder Schicht vier eines Pakets durchgeführt. In einer alternativen Ausführungsform der Erfindung kann jedoch die Lastverteilung auf der Basis der Adressen der Schicht zwei durchgeführt werden. In dieser alternativen Ausführungsform werden Pakete mit denselben Ethernet-Quell- und -Zieladressen beispielsweise zu einem einzelnen Prozessor gesandt.
Wie ein Fachmann erkennen wird, kann dies jedoch dazu führen, dass ein Prozessor viel mehr Pakete empfängt, als wenn die Identifizierer der Schicht drei und/oder Schicht vier verwendet werden würden. Wenn beispielsweise eine große Menge an Verkehr durch einen Router empfangen wird, der sich nahe (in einer logischen Hinsicht) zum Host-Computer befindet, kann die Quell-Ethernet-Adresse für den ganzen Verkehr die Adresse des Routers sein, selbst wenn der Verkehr von mehreren verschiedenen Endbenutzern und/oder Computern stammt. Wenn der Host-Computer dagegen im gleichen Ethernet-Segment wie alle Endbenutzer/Computer liegt, zeigen die Quelladressen der Schicht zwei eine größere Vielfalt und ermöglichen eine wirksamere Lastteilung.
Weitere Verfahren zur Verteilung der Verarbeitung von Paketen, die von einem Netz empfangen werden, können sich von der in 7 dargestellten Ausführungsform unterscheiden, ohne den Schutzbereich der Erfindung zu überschreiten. Insbesondere wird ein Fachmann erkennen, dass viele alternative Prozeduren zum Zuweisen der Pakete eines Flusses zu einem Prozessor und Liefern dieser Pakete zum Prozessor verwendet werden können.
Eine Ausführungsform einer Paketwarteschlange
Wie vorstehend beschrieben, speichert die Paketwarteschlange 116 Pakete, die vom IPP-Modul 104 empfangen werden, vor ihrer erneuten Zusammenfügung durch die DMA-Maschine 120 und ihrer Übertragung zum Host-Computersystem. 8 stellt eine Paketwarteschlange 116 gemäß einer Ausführungsform der Erfindung dar.
In der dargestellten Ausführungsform wird die Paketwarteschlange 116 als FIFO-Warteschlange (First-In-First-Out-Warteschlange), die bis zu 256 Einträge enthält, implementiert. Jede Paketwarteschlange in dieser Ausführungsform speichert ein Paket plus verschiedene Informationen hinsichtlich des Pakets. Der Eintrag 800 umfasst beispielsweise einen Paketabschnitt 802 plus einen Paketstatusabschnitt. Da Pakete mit verschiedenen Größen in der Paketwarteschlange 116 gespeichert werden, kann der Paketabschnitt 802 ein Füllfeld 802a umfassen, um das Paket zu ergänzen, so dass der Paketabschnitt an einer geeigneten Grenze (z. B. Byte, Wort, Doppelwort) endet.
Das Füllfeld 802a kann willkürliche Daten oder Daten mit einem festgelegten Muster umfassen. Das Füllfeld 802a kann vom gespeicherten Paket durch das Muster der Fülldaten oder durch ein Kennzeichenfeld unterschieden werden.
Erläuternd umfassen Paketstatusinformationen den TCP-Prüfsummenwert 804 und die Paketlänge 806 (z. B. Länge des im Paketabschnitt 802 gespeicherten Pakets). Das Speichern der Paketlänge kann ermöglichen, dass das Paket vom Paketabschnitt 802 leicht identifiziert und wiedergewonnen wird. Paketstatusinformationen können auch Diagnose/Status-Informationen 808 umfassen. Diagnose/Status-Informationen 808 können ein Flag, das angibt, dass das Paket schlecht ist (z. B. unvollständig, mit einem Fehler empfangen), einen Indikator, dass eine Prüfsumme für das Paket berechnet wurde oder nicht, einen Indikator, dass die Prüfsumme einen bestimmten Wert besitzt, einen Versatz zum Abschnitt des Pakets, an dem die Prüfsumme berechnet wurde, usw. umfassen. Andere Flags oder Indikatoren können auch für Diagnose-, Filter- oder andere Zwecke enthalten sein. In einer Ausführungsform der Erfindung sind der Flussschlüssel des Pakets (vorstehend beschrieben und verwendet, um den Fluss, der das Paket umfasst, zu identifizieren) und/oder die Flussnummer (z. B. der entsprechende Index des Flusses des Pakets in der Flussdatenbank 110) in den Diag nose/Status-Informationen 808 enthalten. In einer weiteren Ausführungsform ist ein Kennzeichenfeld zum Identifizieren oder Begrenzen des Füllfeldes 802a in den Diagnose/Status-Informationen 808 enthalten.
In einer alternativen Ausführungsform der Erfindung werden irgendwelche oder alle der vorstehend beschriebenen Paketstatusinformationen vielmehr in der Steuerwarteschlange 118 als der Paketwarteschlange 116 gespeichert.
In der dargestellten Ausführungsform der Erfindung wird die Paketwarteschlange 116 in der Hardware (z. B. als Direktzugriffspeicher) implementiert. In dieser Ausführungsform ist der Prüfsummenwert 804 sechzehn Bits groß und kann durch den Prüfsummengenerator 114 gespeichert werden. Die Paketlänge 806 ist vierzehn Bits groß und kann vom Kopf-Parser 106 gespeichert werden. Schließlich können Abschnitte der Diagnose/Status-Informationen 808 durch einen oder mehrere des IPP-Moduls 104, den Kopf-Parser 106, den Flussdatenbank-Manager 108, den Lastverteiler 112 und den Prüfsummengenerator 114 gespeichert werden.
Die Paketwarteschlange 116 in 8 wird mit zwei Zeigern indiziert. Der Lesezeiger 810 identifiziert den aus der Warteschlange zu lesenden nächsten Eintrag, während der Schreibzeiger 812 den Eintrag identifiziert, in dem das nächste empfangene Paket und zugehörige Informationen gespeichert werden sollen. In einer vorliegenden Ausführungsform der Erfindung wird das im Paketabschnitt 802 eines Eintrags gespeicherte Paket aus der Paketwarteschlange 116 extrahiert, wenn seine Daten durch die DMA-Maschine 120 erneut zusammengefügt und/oder zum Host-Computersystem übertragen werden sollen.
Eine Ausführungsform einer Steuerwarteschlange
In einer Ausführungsform der Erfindung speichert die Steuerwarteschlange 118 Steuer- und Statusinformationen hinsichtlich eines von der NIC 100 empfangenen Pakets. In dieser Ausführungsform hält die Steuerwarteschlange 118 Informationen, die zum Ermöglichen der Stapelverarbeitung von Protokollköpfen und/oder der erneuten Zusammenfügung von Daten von mehreren in Beziehung stehenden Paketen verwendet werden. Die Steuerwarteschlange kann auch Informationen, die vom Host-Computer verwendet werden sollen, oder eine Reihe von Befehlen, die auf einem Host-Computer arbeiten (z. B. ein Vorrichtungstreiber für die NIC 100), speichern. Die in der Steuerwarteschlange 118 gespeicherten Informationen können Informationen, die in der Paketwarteschlange 116 gespeichert sind, ergänzen oder duplizieren.
9 stellt die Steuerwarteschlange 118 in einer Ausführungsform der Erfindung dar. Die dargestellte Steuerwarteschlange enthält einen Eintrag für jedes in der Paketwarteschlange 116 gespeicherte Paket (z. B. bis zu 256 Einträge). In einer Ausführungsform der Erfindung entspricht jeder Eintrag in der Steuerwarteschlange 118 dem Eintrag (z. B. Paket) in der Paketwarteschlange 116 mit derselben Nummer. 9 stellt einen Eintrag 900 mit verschiedenen Feldern dar, wie z. B. eine CPU-Nummer 902, ein No_Assist-Signal 904, einen Operationscode 906, einen Nutzinformationsversatz 908, eine Nutzinformationsgröße 910 und andere Statusinformationen 912. Ein Eintrag kann auch andere Status- oder Steuerinformationen umfassen (in 9 nicht gezeigt). Einträge in der Steuerwarteschlange 118 in alternativen Ausführungsformen der Erfindung können andere Informationen umfassen.
Die CPU-Nummer (oder Prozessornummer) 902, die in einem vorherigen Abschnitt erörtert wurde, gibt an, welcher von mehreren Prozessoren auf dem Host-Computersystem die Protokollköpfe des Pakets verarbeiten sollte. Erläuternd ist die CPU-Nummer 902 sechs Bits groß. Das No_Assist-Signal 904, das auch in einem vorherigen Abschnitt beschrieben ist, gibt an, ob das Paket mit irgendeinem eines Satzes von vorgewählten Protokollen kompatibel ist (z. B. gemäß diesem formatiert ist), die vom Kopf-Parser 106 syntaktisch analysiert werden können. Das No_Assist-Signal 904 kann ein einzelnes Flag (z. B. ein Bit) umfassen. In einer Ausführungsform der Erfindung kann der Zustand oder Wert des No_Assist-Signals 904 vom Flussdatenbank-Manager 108 verwendet werden, um festzustellen, ob die Daten eines Pakets erneut zusammengefügt werden können und/oder ob seine Köpfe mit jenen von in Beziehung stehenden Paketen verarbeitet werden können. Insbesondere kann der FDBM das No_Assist-Signal beim Feststellen, welcher Operationscode dem Paket zuzuweisen ist, verwenden.
Der Operationscode 906 liefert Informationen zur DMA-Maschine 120, um bei der erneuten Zusammenfügung der Daten des Pakets zu unterstützen. Wie in einem vorherigen Abschnitt beschrieben, kann ein Operationscode angeben, ob ein Paket Daten umfasst oder ob die Daten eines Pakets für die erneute Zusammenfügung geeignet sind. Erläuternd ist der Operationscode 906 drei Bits groß. Der Nutzinformationsversatz 908 und die Nutzinformationsgröße 910 entsprechen dem Versatz bzw. der Größe der TCP-Nutzinformationen (z. B. TCP-Daten) des Pakets. Diese Felder können sieben bzw. vierzehn Bits groß sein.
In der dargestellten Ausführungsform umfassen weitere Statusinformationen 912 Diagnose- und/oder Statusinformationen hinsichtlich des Pakets. Die Statusinformationen 912 können eine Startposition für eine Prüfsummenberechnung (die sieben Bits groß sein kann), einen Versatz des Protokollkopfs der Schicht drei (z. B. IP) (der auch sieben Bits groß sein kann) usw. umfassen. Die Statusinformationen 912 können auch einen Indikator hinsichtlich dessen umfassen, ob die Größe des Pakets einen ersten Schwellenwert überschreitet (z. B. ob das Paket größer ist als 1522 Bytes) oder unter einen zweiten Schwellenwert fällt (z. B. ob das Paket 256 Bytes oder geringer ist). Diese Informationen können bei der erneuten Zusammenfügung von Paketdaten nützlich sein. Erläuternd umfassen diese Indikatoren Ein-Bit-Flags.
In einer alternativen Ausführungsform der Erfindung umfassen die Statusinformationen 912 einen Flussschlüssel und/oder eine Flussnummer des Pakets (z. B. den Index des Flusses des Pakets in der Flussdatenbank 110). Der Flussschlüssel oder die Flussnummer kann beispielsweise zur Fehlersuche oder für andere Diagnosezwecke verwendet werden. In einer Ausführungsform der Erfindung kann die Flussnummer des Pakets in den Statusinformationen 912 gespeichert werden, so dass mehrere Pakete in einem einzelnen Fluss identifiziert werden können. Ein solches in Beziehung stehendes Paket kann dann gemeinsam zu einem Host-Computer übertragen und/oder von diesem verarbeitet werden.
9 stellt einen Lesezeiger und einen Schreibzeiger zum Indizieren der Steuerwarteschlange 118 dar. Der Lesezeiger 914 gibt einen von der DMA-Maschine 120 zu lesenden Eintrag an. Der Schreibzeiger 916 gibt den Eintrag an, in dem Informationen hinsichtlich des nächsten Pakets, das in der Paketwarteschlange 116 gespeichert ist, zu speichern sind.
In einer alternativen Ausführungsform der Erfindung kann ein zweiter Lesezeiger (in 9 nicht gezeigt) zum Indizieren der Steuerwarteschlange 118 verwendet werden. Wenn ein Paket zum Host-Computer übertragen werden soll, werden erläuternd von den Einträgen in der Steuerwarteschlange entnommene Informationen durchsucht, um festzustellen, ob ein in Beziehung stehendes Paket (z. B. ein Paket im gleichen Fluss wie das zu übertragende Paket) auch gleich übertragen wird. Wenn ja, wird der Host-Computer benachrichtigt, so dass Protokollköpfe von den in Beziehung stehenden Paketen gemeinsam verarbeitet werden können. In dieser alternativen Ausführungsform der Erfindung werden in Beziehung stehende Pakete durch Vergleichen ihrer Flussnummern (oder Flussschlüssel) in den Statusinformationen 912 identifiziert. Der zweite Lesezeiger kann verwendet werden, um in der Steuerwarteschlange nach Paketen mit entsprechenden Flussnummern vorauszuschauen.
In einer Ausführungsform der Erfindung kann die CPU-Nummer 902 in der Steuerwarteschlange durch den Lastverteiler 112 gespeichert werden und das No_Assist-Signal 904 kann durch den Kopf-Parser 106 gespeichert werden. Der Operationscode 906 kann durch den Flussdatenbank-Manager 108 gespeichert werden und der Nutzinformationsversatz 908 und die Nutzinformationsgröße 910 können durch den Kopf-Parser 106 gespeichert werden. Abschnitte von anderen Statusinformationen können durch die vorangehenden Module und/oder andere, wie z. B. das IPP-Modul 104 und den Prüfsummengenerator 114, geschrieben werden. In einer speziellen Ausführungsform der Erfindung werden jedoch viele von diesen Informationselementen durch das IPP-Modul 104 oder irgendein anderes Modul, das etwas in einer Koordinatorrolle wirkt, gespeichert.
Die US-Patentanmeldung Nr. 09/259 765 mit dem Titel "A High Performance Network Interface" und eingereicht am 1. März 1999, stellt zusätzliche Details einer Netzschnittstelle bereit, in der eine Ausführungsform der Erfindung ausgeführt werden kann.
Sun, Sun Microsystems, SPARC und Solaris sind Handelsmarken oder eingetragene Handelsmarken von Sun Microsystems, Incorporated in den Vereinigten Staaten und anderen Ländern.
Die vorangehenden Beschreibungen von Ausführungsformen der Erfindung wurden nur für Erläuterungs- und Beschreibungszwecke dargestellt. Sie sollen nicht erschöpfend sein oder die Erfindung auf die offenbarten Formen begrenzen. Folglich soll die obige Offenbarung die Erfindung nicht begrenzen; der Schutzbereich der Erfindung ist durch die beigefügten Ansprüche definiert.

Claims

Verfahren für das Management eines Kommunikationsflusses, der ein oder mehrere Pakete enthält, die von einer Netzschnittstelle (100) für einen Host-Computer empfangen werden, wobei das Verfahren gekennzeichnet ist durch: Erzeugen (134) eines Flussidentifizierers, um einen Kommunikationsfluss zu identifizieren, der ein bei einer Netzschnittstelle für einen Host-Computer empfangenes (132) Paket enthält; Durchsuchen (606) einer Flussdatenbank nach einem Flussdatensatz, der dem Kommunikationsfluss zugeordnet ist; Invalidieren (626) des Kommunikationsflusses in dem Flussdatensatz (506), falls das Paket das letzte Paket in dem Kommunikationsfluss ist; und Zuordnen (136, 626) eines Operationscodes zu dem Paket, wobei der Operationscode so konfiguriert ist, dass er die Verarbeitung des Pakets durch die Netzschnittstelle erleichtert.
Verfahren nach Anspruch 1, das ferner das Speichern (140) des Operationscodes umfasst, wenn das Paket für eine direkte Übertragung von der Netzschnittstelle zu dem Host-Computer gespeichert wird.
Verfahren nach Anspruch 1, das ferner das syntaktische Analysieren (134) des Pakets umfasst, um einen Status des Pakets wiederzugewinnen.
Verfahren nach Anspruch 3, bei dem der Status eine Folgennummer des Pakets umfasst.
Verfahren nach Anspruch 3, bei dem der Status einen Indikator umfasst, der so konfiguriert ist, dass er angibt, ob das Paket einen Datenabschnitt enthält.
Verfahren nach Anspruch 3 oder Anspruch 5, bei dem der Status einen Identifizierer einer Quelle des Pakets sowie einen Identifizierer eines Ziels des Pakets umfasst.
Verfahren nach Anspruch 3, bei dem das Invalidieren (626) umfasst: Bestimmen (620) anhand des Status, ob das Paket das letzte Paket in dem Kommunikationsfluss ist; und falls das Paket das letzte Paket ist, Aktualisieren eines Flussgültigkeitsindikators (520) in dem Flussdatensatz.
Verfahren nach Anspruch 3, das ferner die Aktualisierung des Flussdatensatzes umfasst, um den Status zu reflektieren, die eines der Folgenden umfasst: Modifizieren (622) einer Flussfolgennummer in dem Flussdatensatz, Modifizieren (622) eines Flussaktivitätsindikators (524) in dem Flussdatensatz oder Modifizieren (622) eines Flussgültigkeitsindikators (520) in dem Flussdatensatz.
Verfahren nach Anspruch 1, das ferner das Hinzufügen (660) eines Flussdatensatzes zu der Flussdatenbank für den Kommunikationsfluss umfasst, falls ein Flussdatensatz, der dem Kommunikationsfluss zugeordnet ist, in der Flussdatenbank nicht gefunden wird.
Verfahren nach Anspruch 1, das ferner das Setzen (664) des Flussdatensatzes umfasst, falls das Paket ein erstes Paket in dem Kommunikationsfluss ist.
Verfahren nach Anspruch 1, bei dem das Erzeugen (134) das Empfangen des Flussidentifizierers von einem Netzschnittstellen-Modul, das so konfiguriert ist, dass es einen Kopfabschnitt des Pakets syntaktisch analysiert, umfasst.
Verfahren nach Anspruch 1, bei dem das Erzeugen (134) umfasst: syntaktisches Analysieren eines Kopfabschnitts des Pakets, um Netzadressen einer Quelle des Pakets und eines Ziels des Pakets wiederzugewinnen; und Kombinieren der Netzadressen, um den Flussidentifizierer zu bilden.
Verfahren nach Anspruch 1, bei dem das Zuordnen (626) umfasst: Bestimmen (604), ob das Paket für eine durch die Netzschnittstelle ausgeführte Funktion geeignet ist; und Zuweisen eines Operationscodes für das Paket, um diese Eignung zu reflektieren.
Verfahren nach Anspruch 13, bei dem das Zuordnen (626) ferner das Bestimmen (612), ob das Paket einen Datenabschnitt enthält, umfasst.
Verfahren nach Anspruch 13, bei dem das Zuordnen ferner das Bestimmen, ob ein Datenabschnitt des Pakets eine vorgegebene Größe übersteigt, umfasst.
Verfahren nach Anspruch 13, bei dem das Zuordnen ferner das Bestimmen (616), ob das Paket außerhalb der Reihe empfangen wurde, umfasst.
Verfahren nach Anspruch 13, bei dem das Zuordnen ferner das Bestimmen (646), ob die Flussdatenbank voll ist, umfasst.
Verfahren nach Anspruch 1, das ferner umfasst: Bestimmen (646), ob die Flussdatenbank voll ist; Auswählen (650) eines alten Flussdatensatzes in der Datenbank, wobei der alte Flussdatensatz einem ersten Kommunikationsfluss entspricht, der früher als ein zweiter Kommunikationsfluss verwendet wurde; und Ersetzen (664) des alten Flussdatensatzes durch einen neuen Flussdatensatz, der dem Kommunikationsfluss zugeordnet ist.
Verfahren nach Anspruch 1, das ferner umfasst: Empfangen (132) eines ersten Pakets bei einer Netzschnittstelle (100), wobei das erste Paket einen ersten Abschnitt einer Datensammlung enthält; wobei das Erzeugen eines Flussidentifizierers (134) das Identifizieren eines ersten Flussidentifizierers umfasst, wobei der erste Flussidentifizierer einen Identifizierer einer Quelle des Pakets und einen Identifizierer eines Ziels des Pakets umfasst; und Aufbauen (136) eines ersten Kommunikationsflusses für die Datensammlung, wobei der erste Kommunikationsfluss durch den ersten Flussidentifizierer identifiziert werden kann; wobei der erste Kommunikationsfluss so konfiguriert ist, dass er bei Empfang eines Endabschnitts der Datensammlung bei der Netzschnittstelle beendet wird.
Verfahren nach Anspruch 19, das ferner umfasst: Empfangen (132) eines zweiten Pakets bei der Netzschnittstelle, wobei das zweite Paket einen zweiten Abschnitt der Datensammlung enthält; Bestimmen (620), ob der zweite Abschnitt der Datensammlung den Endabschnitt der Datensammlung enthält; und Beenden (626) des ersten Kommunikationsflusses, falls der zweite Abschnitt den Endabschnitt enthält.
Verfahren nach Anspruch 19, bei dem das Aufbauen (136) eines ersten Kommunikationsflusses umfasst: Speichern (660) des ersten Flussidentifizierers in einer Datenbank (110); und Angeben (660), dass der erste Kommunikationsfluss gültig ist, mit einem Gültigkeitsindikator (520).
Verfahren nach Anspruch 21, bei dem das Beenden (626) umfasst: Modifizieren des Gültigkeitsindikators (520), um anzugeben, dass der erste Kommunikationsfluss ungültig ist, oder Entfernen des ersten Flussidentifizierers aus der Datenbank (110).
Verfahren nach Anspruch 19, das ferner umfasst: Empfangen (132) eines zweiten Pakets bei der Netzschnittstelle; und Zuordnen (136) des Operationscodes zu dem zweiten Paket, um anzugeben, ob der erste Kommunikationsfluss beendet werden soll.
Verfahren nach Anspruch 23, bei dem das Zuordnen (136) umfasst: Empfangen von Informationen, die aus einem Kopfabschnitt des zweiten Pakets extrahiert werden; und Bestimmen, ob die Informationen angeben, dass das zweite Paket den Endabschnitt der Datensammlung enthält.
Verfahren nach Anspruch 24, bei dem das Zuordnen (136) ferner umfasst: Untersuchen der Informationen, um festzustellen, ob ein zweiter Kommunikationsfluss aufgebaut werden soll und ob ein Datenabschnitt des zweiten Pakets mit einem Datenabschnitt eines weiteren Pakets zusammengefügt werden soll.
Verfahren nach Anspruch 19, bei dem das Aufbauen (136) eines ersten Kommunikationsflusses das Setzen eines Flussgültigkeitsindikators (520) in einem ersten Flussdatensatz in einer Datenbank (110) umfasst, um anzugeben, dass der erste Kommunikationsfluss gültig ist.
Verfahren nach Anspruch 1, das ferner umfasst: Empfangen einer Folge von Paketen in dem Kommunikationsfluss nach dem Paket; und für jedes Paket in der Folge: Aktualisieren (622) des Flussdatensatzes mit einem Status des Folgen pakets; Bestimmen (620), ob das Folgenpaket das letzte Paket in dem Kommunikationsfluss ist; und falls das Folgenpaket das letzte Paket ist, Invalidieren (626) des Kommunikationsflusses in der Flussdatenbank.
Verfahren nach Anspruch 27, das ferner für jedes der Pakete in der Folge umfasst: Zuordnen (624) eines Operationscodes zu dem Folgenpaket, um einen Status des Folgenpakets anzugeben und um dadurch die Verarbeitung des Folgenpakets durch die Netzschnittstelle zu erleichtern.
Verfahren nach einem der Ansprüche 3 bis 28, bei dem das Zuordnen (626) das Erzeugen (136) eines Operationscodes anhand des Status des Pakets umfasst.
Verfahren nach Anspruch 29, bei dem das Erzeugen (136) eines der Folgenden umfasst: Angeben (604), ob ein Kopfabschnitt des Pakets mit einem Protokoll einer Menge von im Voraus gewählten Kommunikationsprotokollen in Übereinstimmung ist; Bestimmen (618), ob ein Statusindikator, der aus dem Paket extrahiert wird, einen vorgegebenen Wert hat; Bestimmen (612), ob das Paket einen Datenabschnitt enthält; Bestimmen, ob ein Datenabschnitt des Pakets eine vorgegebene Größe übersteigt; Bestimmen (616), ob eine Folgennummer des Pakets mit einer Folgennummer (522), die dem Kommunikationsfluss in der Flussdatenbank zugeordnet ist, korreliert ist; und Bestimmen, ob das Paket eine Anforderung zum Zurücksetzen eines Flusses umfasst.
Netzschnittstelle (100), die umfasst: eine Datenbank (110), die so konfiguriert ist, dass sie das Management eines Netzflusses erleichtert, wobei der Netzfluss ein oder mehrere Pakete enthält, die von einer Quell-Entität zu einer Ziel-Entität, die mit der Netzschnittstelle gekoppelt sind, gesendet werden; einen Flussdatensatz (506) in der Datenbank, der so konfiguriert ist, dass er einen Status des Netzflusses verfolgt; einen Datenbank-Manager (108), der so konfiguriert ist, dass er den Flussdatensatz jedes Mal aktualisiert, wenn ein Paket in dem Netzfluss empfangen wird; und einen Operationscode-Generator, der so konfiguriert ist, dass er einen Operationscode für jedes Paket in dem Netzfluss erzeugt, wobei der Operationscode so konfiguriert ist, dass er einen Status des Pakets angibt; wobei der Datenbank-Manager einen Flussschlüssel empfängt, der den Netzfluss identifiziert, und die Datenbank aktualisiert, wenn das erste Paket empfangen wird.
Netzschnittstelle nach Anspruch 31, bei der der Flussdatensatz umfasst: einen Flussaktivitäts-Indikator (524), der so konfiguriert ist, dass er die Neuheit angibt, mit der ein Paket in dem Netzfluss empfangen wurde; und eine Flussfolgennummer (522), die so konfiguriert ist, dass sie eine Folgennummer eines nächsten Pakets angibt, von dem erwartet wird, dass es in dem Netzfluss empfangen wird.
Netzschnittstelle nach Anspruch 32, bei der der Flussdatensatz ferner einen Flussgültigkeitsindikator (520) umfasst, der so konfiguriert ist, dass er angibt, ob der Netzfluss gültig ist; wobei der Flussgültigkeitsindikator so eingestellt ist, dass er den Netzfluss invalidiert, wenn ein letztes Paket in dem Netzfluss empfangen wird.
Netzschnittstelle nach Anspruch 31, die ferner umfasst: einen Parser (106), der so konfiguriert ist, dass er das erste Paket syntaktisch analysiert und den Flussschlüssel für den Datenbank-Manager bereitstellt.
Netzschnittstelle nach Anspruch 34, bei der der Parser so konfiguriert ist, dass er aus dem ersten Paket einen Identifizierer einer Quelle des ersten Pakets und einen Identifizierer eines Ziels des ersten Pakets wiedergewinnt.
Netzschnittstelle nach Anspruch 34, bei der der Flussschlüssel den Quellidentifizierer und den Zielidentifizierer umfasst.
Netzschnittstelle nach Anspruch 31, die ferner einen Steuerspeicher umfasst, wobei der Datenbank-Manager ferner so konfiguriert ist, dass er den Operationscode in dem Steuerspeicher speichert.
Netzschnittstelle nach Anspruch 31, bei der der Datenbank-Manager den Operationscode-Generator umfasst.
Netzschnittstelle nach einem der Ansprüche 31 bis 38, die ferner umfasst: eine Fluss-Beendigungseinrichtung, die so konfiguriert ist, dass sie den Netzfluss beendet, wenn ein letztes Paket in dem Fluss bei der Netzschnittstelle empfangen wird.
Netzschnittstelle nach einem der Ansprüche 31 bis 39, die umfasst: eine Extraktionseinrichtung (106), die so konfiguriert ist, dass sie einen Statusindikator aus einem Paket extrahiert; einen Flussklassifizierer, der so konfiguriert ist, dass er den Flussschlüssel konstruiert; wobei die Datenbank (110) so konfiguriert ist, dass sie einen Status des Flusses speichert; und wobei der Datenbank-Manager (108) so konfiguriert ist, dass er: die Datenbank nach dem Fluss durchsucht (606); und den Flussstatus anhand des Statusindikators aktualisiert (622).
Netzschnittstelle nach Anspruch 40, bei der der Operationscode-Generator so konfiguriert ist, dass er den Operationscode anhand des Statusindikators erzeugt.
Netzschnittstelle nach Anspruch 40, bei der der Operationscode-Generator so konfiguriert ist, dass er den Operationscode dadurch erzeugt, dass er eines der Folgenden bestimmt: ob ein Kopfabschnitt eines Pakets mit einem Protokoll einer Menge von im Voraus gewählten Kommunikationsprotokollen in Übereinstimmung ist; ob ein Paket einen Datenabschnitt enthält; ob ein Datenabschnitt eines Pakets eine vorgegebene Größe übersteigt; ob ein Paket eine Anforderung zum Zurücksetzen des Flusses enthält.
Computerprogramm, das ausführbare Befehle enthält, die, wenn sie von einem Computer oder von einem Computernetz ausgeführt werden, den Computer oder das Computernetz dazu veranlassen, die Verfahrensschritte nach einem der Ansprüche 1 bis 30 auszuführen.
Computerlesbares Speichermedium, das ein Computerprogramm nach Anspruch 43 enthält.