DE69828233T2

DE69828233T2 - Hardware Erzeugung von Kontrollsumme für Netzwerkprotokollstapel

Info

Publication number: DE69828233T2
Application number: DE69828233T
Authority: DE
Inventors: Brian M. Dowling; Christian J. Warling; James G. Wendt
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1997-09-25
Filing date: 1998-06-03
Publication date: 2005-12-01
Anticipated expiration: 2018-06-04
Also published as: JPH11168451A; US6289023B1; DE69828233D1; EP0905938A2; EP0905938A3; EP0905938B1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf Prüfsummen, die die Integrität von Datenpaketen verifizieren, wenn die Datenpakete durch Netzwerkprotokollstapel fließen. Insbesondere verwendet die vorliegende Erfindung eine Hardware, um eine Prüfsumme zu erzeugen, die zusammen mit dem Datenpaket durch den Stapel fließt, wodurch ermöglicht wird, dass irgendeine spezielle Schicht des Protokollstapels auf die Prüfsumme zugreift, ohne die Zeiteinbuße einzufahren, die einem Berechnen der Prüfsumme zugeordnet ist, nachdem das Paket an der Schicht ankommt.
Beschreibung der verwandten Technik
Auf dem Gebiet einer Computervernetzung werden Protokollstapel häufig verwendet, um Daten zwischen Netzwerkknoten zu senden bzw. zu übertragen, die durch Netzwerkmedien gekoppelt sind. Netzwerkknoten umfassen Vorrichtungen, wie beispielsweise Arbeitsplatzcomputer, Server, Netzwerkdrucker, Netzwerkscanner und dergleichen. Um die Entwicklung und Implementierung von Protokollstapeln zu harmonisieren, verbreitete die internationale Normungsorganisation (ISO; ISO = International Standards Organization) ein Referenzmodell Open System Interconnection (OSI), das sieben Schichten von Netzwerkprotokollen vorschreibt.
1 ist ein Blockdiagramm 10 des OSI-Referenzmodells. Das Modell umfasst eine Hardwareschicht 12, eine Datenverbindungsschicht 14, eine Netzwerkschicht 16, eine Transportschicht 18, eine Sitzungsschicht 20, eine Präsentationsschicht 22 und eine Anwendungsschicht 24. Jede Schicht ist für ein Durchführen einer speziellen Aufgabe verantwortlich. Die Hardwareschicht 12 ist für ein Handhaben sowohl der mechanischen als auch elektrischen Details der physischen Übertragung eines Datenstroms verantwortlich. Die Datenverbindungsschicht 14 ist für ein Handhaben der Pakete verantwortlich, einschließlich einer jeglichen Fehlererfassung und -erholung, die bei der physischen Schicht auftrat. Die Netzwerkschicht 16 ist für ein Bereitstellen von Verbindungen und ein Führen bzw. Leiten von Paketen in dem Kommunikationsnetzwerk verantwortlich, einschließlich eines Handhabens der Adresse von ausgehenden Paketen, eines Decodierens der Adresse von eingehenden Paketen und eines Beibehaltens von Leitungsinformationen für eine geeignete Antwort auf sich verändernde Lasten. Die Transportschicht 18 ist für einen Zugriff auf niedriger Ebene auf das Netzwerk und die Übertragung von Nachrichten zwischen den Benutzern verantwortlich, einschließlich eines Partitionierens von Nachrichten in Pakete, eines Beibehaltens einer Paketreihenfolge, einer Flusssteuerung und einer physischen Adresserzeugung. Die Sitzungsschicht 20 ist für ein Implementieren der Prozess-zu-Prozess-Protokolle verantwortlich. Die Präsentationsschicht 22 ist zum Auflösen der Unterschiede bei Formaten unter den verschiedenen Stellen in dem Netzwerk verantwortlich, einschließlich Schriftzeichenumwandlungen und Halbduplex/Vollduplex (Echo). Die Anwendungsschicht 24 schließlich ist für ein direktes in Wechselwirkung Treten mit den Benutzern verantwortlich. Die Schicht 24 kann Anwendungen umfassen, wie beispielsweise elektronische Post, verteilte Datenbanken, Netzbrowser und dergleichen.
Bevor die ISO das OSI-Referenzmodell verbreitete, verbreitete die DARPA (Defense Advanced Research Projects Agency = Forschungseinrichtung des US-Verteidigungsministeriums) das ARPNET-Referenzmodell. Das ARPNET-Referenzmodell umfasst vier Schichten, eine Netzwerkhardwareschicht, eine Netzwerkschnittstellenschicht, eine Host-zu-Host-Schicht und eine Prozess-/Anwendungsschicht.
Wie die Namen derselben implizieren, liefern das OSI-Referenzmodell und das ARPNET-Referenzmodell Richtlinien, denen Entwickler von Protokollen entweder folgen können oder nicht. Die meisten Vernetzungsprotokolle definieren jedoch Schichten, die einem Referenzmodell zumindest locker entsprechen.
In dem Computerbereich gibt es viele beliebte Protokolle, die verwendet werden, um Daten zwischen Netzwerkknoten zu übertragen. Zum Beispiel sind TCP/IP, AppleTalk^®, NetBEUI und IPX alle beliebte Protokolle, die verwendet werden, um Daten zwischen Servern, Arbeitsplatzrechnern, Druckern und anderen Vorrichtungen zu übertragen, die mit Computernetzwerken gekoppelt sind.
Es ist üblich, dass viele der Protokolle gleichzeitig innerhalb eines einzigen Netzwerkknotens wirksam sind, selbst falls der Netzwerkknoten eine einzige Netzwerkschnittstelle aufweist. Zum Beispiel kann ein typischer Computerarbeitsplatzrechner TCP/IP verwenden, um über das Internet zu kommunizieren, und IPX, um mit einem Netzwerkserver zu kommunizieren. Gleichermaßen kann ein Drucker konfiguriert sein, um Druckaufträge unter Verwendung entweder des AppleTalk^®-Protokolls oder des NetBEUI-Protokolls zu empfangen. Typischerweise führt bzw. leitet eine Softwareroutine, die an einer Datenverbindungsschicht 14 oder einer Netzwerkschicht 16 existiert, Datenpakete zwischen dem Netzwerkadapter und dem ordnungsgemäßen Protokollstapel.
Verschiedene Protokolle definieren ebenfalls Verfahren, um die Integrität von Daten zu verifizieren, die durch das Protokoll übertragen werden. Man betrachte z. B. ein TCP/IP-Paket, wie dasselbe an einem Ethernet-Netzwerkadapter ankommt. Das gesamte Ethernet-Paket ist durch einen Zyklische-Redundanzprüfung-Code (CRC-Code; CRC = cyclic redundancy check) geschützt, der durch den Sendenetzwerkadapter berechnet und in das Ethernet-Paket ge stopft wird und durch den Empfangnetzwerkadapter verwendet wird, um die Integrität des Ethernet-Pakets zu verifizieren. Falls die Integrität des Pakets nicht verifiziert werden kann, wird das Paket ausgesondert.
Innerhalb des Ethernet-Pakets ist der IP-Abschnitt des TCP/IP-Protokolls eingekapselt. Der IP-Abschnitt weist einen 16-Bit-Prüfsummencode auf, der den IP-Kopfblock schützt. Falls die Integrität des IP-Kopfblocks nicht verifiziert werden kann, wird das Paket ausgesondert. Der TCP-Abschnitt des TCP/IP-Protokolls ist innerhalb des IP-Abschnitts eingekapselt und weist einen 16-Bit-Prüfsummencode auf, der den TCP-Kopfblock und die Inhalte des TCP-Abschnitts des Pakets schützt. Falls die Integrität des TCP-Kopfblocks oder die Inhalte des TCP-Abschnitts nicht verifiziert werden können, wird das Paket ausgesondert und der Absender überträgt das Paket wieder, nachdem derselbe kein Bestätigungspaket von dem beabsichtigten Empfänger empfangen hat.
Die Integrität des Ethernet-Pakets wird durch die Vernetzungshardware an der Hardwareschicht 12 verifiziert und wird deshalb ziemlich schnell durchgeführt. Die höheren Schichten des Protokollstapels sind jedoch typischerweise durch eine Software implementiert. Ein Berechnen einer Prüfsumme unter Verwendung einer Softwareroutine ist erheblich langsamer. Im Stand der Technik könnte eine Prüfsumme, die durch eine höhere Schicht des Protokollstapels benötigt wird, nicht an der Hardwareschicht erzeugt werden, weil die Hardwareschicht keine Kenntnis der höheren Schicht des Stapels aufwies.
Eine Lösung des Stands der Technik, die die Erzeugung einer Prüfsumme an einer höheren Schicht eines Protokollstapels beschleunigt, besteht darin, eine Hardwareprüfsummenbildungseinrichtung zu verwenden, die durch die höhere Schicht des Protokollstapels gesteuert ist. Wenn z. B. ein TCP-Modul versucht, die Integrität eines TCP-Kopfblocks und der jeweiligen Daten desselben zu verifizieren, schreibt das TCP-Modul zu einem Register der Hardwareprüfsummenbildungseinrichtung, um den Prüfsummenbildungsprozess zu beginnen, und fragt die Einrichtung ab, um zu bestimmen, wann die Prüfsumme vollständig ist. Während eine derartige Lösung schneller als eine Prüfsumme ist, die lediglich durch eine Softwareroutine erzeugt wird, gibt es immer noch eine erhebliche Verzögerung, während die Prüfsumme erzeugt wird.
Ein anderes Verfahren zum Berechnen von Prüfsummen unter Verwendung einer Hardware wurde durch Snyder et al. im US-Patent Nr. 5,522,039 mit dem Titel „Calculation of Network Data Check Sums by Dedicated Hardware With Software Corrections" offenbart. Dieses Patent offenbart ein Erzeugen einer „Bruttoprüfsumme" für das gesamte Paket, wenn das Paket über eine Direktspeicherzugriffsoperation (DMA-Operation; DMA = direct memory access) zwischen einem Adapterspeicher und einem Systemspeicher übertragen wird. Höhere Schichten des Protokollstapels berechnen dann die erforderliche Prüfsumme durch ein Berechnen einer Prüfsumme für die Abschnitte des Pakets, die nicht benötigt werden, und dann ein Subtrahieren dieser Prüfsumme von der Bruttoprüfsumme, um eine „Nettoprüfsumme" zu bilden, die die Prüfsumme ist, die durch diese Schicht des Protokollstapels benötigt wird. Da die Prüfsumme für den Abschnitt über einer relativ kleinen Anzahl von Bytes berechnet wird, fährt das durch Snyder et al. offenbarte Schema eine kleinere Zeiteinbuße als andere Verfahren des Stands der Technik ein.
Die EP-A-0 572 146 und die US-A-5 500 864 beschreiben grundlegend die Erzeugung einer Prüfsumme, aber nicht die Vorsehung eines Codekanals, der einem Protokollstapel zugeordnet ist.
Zusammenfassung der Erfindung
Die vorliegende Erfindung sieht eine Protokollstapelschicht mit der Fähigkeit vor, ein Datenpaket unter Verwendung einer Fly-By-Prüfsumme zu verifizieren, die an einer unteren Schicht des Protokollstapels erzeugt wurde. Bei einem Ausführungsbeispiel umfasst ein Netzwerkadapter einen oder mehrere Protokollstapel und eine LAN-Steuerung, die eine Fly-By-Prüfsummenerzeugungseinheit umfasst.
Bei diesem Ausführungsbeispiel ist ein Prüfsummenalgorithmus bei der Fly-By-Prüfsummenerzeugungseinheit für jede Protokollschicht registriert, die eine Fly-By-Prüfsumme empfangen soll. Die Fly-By-Prüfsummenerzeugung ist mit dem Typ eines Prüfsummenalgorithmus, der ausgeführt werden soll, sowie Anfangs- und Endbytepositionen versehen, die den Abschnitt des eingehenden Pakets definieren, das mit einer Prüfsumme versehen werden soll. Wenn ein eingehendes Paket von Netzwerkmedien zu einem Netzwerkadapterspeicher über eine DMA-Operation übertragen wird, berechnet die Fly-By-Prüfsummenerzeugungseinheit parallel eine Fly-By-Prüfsumme für jeden Prüfsummenalgorithmus, der registriert wurde.
Die Fly-By-Prüfsummen werden dann den geeigneten Protokollstapel hinauf innerhalb eines Prüfsummenkanals zusammen mit Daten von dem eingehenden Paket übertragen, das verwendet wurde, um die Fly-By-Prüfsumme zu erzeugen. Wenn die Daten eine Schicht des Protokollstapels erreichen, für den die Fly-By-Prüfsumme erzeugt wurde, wird die Fly-By-Prüfsumme von dem Prüfsummenkanal entfernt und verwendet, um die Integrität der Daten zu verifizieren. Durch ein Berechnen von Prüfsummen, wenn Pakete von Netzwerkmedien empfangen werden, minimiert die vorliegende Erfindung die Verzögerung, die durch ein Verifizieren der Integrität von Daten an höheren Schichten von Protokollstapeln eingefahren wird.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm eines OSI-Referenzmodells (OSI = Open System Interconnection).
2 zeigt einen Netzwerkknoten gemäß der vorliegenden Erfindung.
3 ist ein Blockdiagramm, das einen Netzwerkadapter gemäß der vorliegenden Erfindung zeigt.
4 ist ein Blockdiagramm einer Fly-By-Prüfsummenerzeugungseinheit, die in 3 gezeigt ist.
5 zeigt ein Paket, das Daten umfasst, die unter Verwendung des TCP/IP-Protokolls codiert sind.
Detaillierte Beschreibung der bevorzugten
Ausführungsbeispiele
Die vorliegende Erfindung ermöglicht, dass Prüfsummen, die durch obere Schichten eines Protokollstapels benötigt werden, durch eine Hardware an einer unteren Schicht des Protokollstapels erzeugt werden. Derartige Prüfsummen werden hierin als „Fly-By"-Prüfsummen bezeichnet. 2 zeigt einen Netzwerkknoten 26 gemäß der vorliegenden Erfindung und gemäß des OSI-Referenzmodells (OSI = Open System Interconnection), das durch die internationale Normungsorganisation (ISO; ISO = International Standards Organization) verbreitet wird. Ähnlich dem OSI-Referenzmodell, das in 1 gezeigt ist, umfasst der Knoten 26 ebenfalls eine Hardwareschicht 12, eine Datenverbindungsschicht 14, eine Netzwerkschicht 16, eine Transportschicht 18, eine Sitzungsschicht 20, eine Präsentationsschicht 22 und eine Anwendungsschicht 24. Protokollstapel 32, 34 und 36 sind symbolisch als innerhalb der Netzwerkschicht 16, der Transportschicht 18, der Sitzungsschicht 20, der Präsentationsschicht 22 und der Anwendungsschicht 24 existierend ge zeigt. Fachleute auf dem Gebiet erkennen jedoch, dass der Grad, zu dem irgendein Netzwerkprotokoll zu dem OSI-Referenzmodell konform ist, variiert.
Die Hardwareschicht 12 umfasst eine Lokales-Netz-Steuerung (LAN-Steuerung; LAN = local area network), die mit Netzwerkmedien 38 gekoppelt ist, die wiederum mit anderen Netzwerkknoten gekoppelt sind. Innerhalb der Hardwareschicht 12 erzeugt eine Fly-By-Prüfsummenerzeugungseinheit 40 Fly-By-Prüfsummen, die durch eine oder mehrere der Schichten des Protokollstapels verwendet werden. Ein Block 42 stellt andere LAN-Steuerungsfunktionen dar, die unten mit Bezug auf 3 genauer erläutert werden.
Bei einem typischen Protokollstapel des Stands der Technik ist im Allgemeinen eine spezielle Schicht des Protokollstapels sich lediglich benachbarter Schichten bewusst. Unter Bezugnahme auf 1 weist folglich die Hardwareschicht 12 keine Kenntnis der Transportschicht 18 auf. Deshalb ist die Hardwareschicht 12 nicht in der Lage, eine Prüfsumme für die Transportschicht 18 zu erzeugen, obwohl die Schicht 12 eine derartige Prüfsumme möglicherweise effizienter erzeugen kann.
Wenn bei der vorliegenden Erfindung eine Schicht eines Protokollstapels initialisiert ist, kann ein Prüfsummenalgorithmus bei der Fly-By-Prüfsummenerzeugungseinheit 40 registriert werden. Der Algorithmus kann durch das Betriebssystem oder durch die jeweilige Schicht des Protokollstapels registriert werden. Die Informationen, die zu der Einheit 40 geliefert werden, wenn der Prüfsummenalgorithmus registriert ist, umfassen den Typ eines Prüfsummenalgorithmus und die Anfangs- und Endbytepositionen des Datenpakets. Die Anfangs- und Endbytepositionen bezeichnen den Abschnitt des Datenpakets, der in der Prüfsumme eingeschlossen sein sollte. Nachdem einer oder mehrere Prüfsummenalgorithmen bei der Einheit 40 registriert wurden, wird eine Fly-By-Prüfsumme parallel für jeden Algorithmus er zeugt, wenn ein Datenpaket zu der Datenverbindungsschicht 30 übertragen wird.
Die Datenverbindungsschicht 30 umfasst einen Prüfsummenkanal 46 und Protokollstapel 32, 34 und 36 umfassen Prüfsummenkanäle 48, 50 bzw. 52. Wie derselbe hierin verwendet wird, wird der Ausdruck „Prüfsummenkanal" verwendet, um sich kollektiv auf verschiedene Datenstrukturen zu beziehen, die erforderlich sind, um Prüfsummen einen Protokollstapel hinauf zusammen mit den jeweiligen Daten, die der Prüfsumme zugeordnet sind, weiterzuleiten. Fachleute auf dem Gebiet erkennen, dass ein Prüfsummenkanal unter Verwendung einer Vielfalt von Verfahren implementiert sein kann, wie beispielsweise einer Angabe, die einen Raum in der Datenstruktur reserviert, in der das jeweilige Datenpaket gespeichert ist, oder ein Definieren einer getrennten Datenstruktur und ein Verwenden von Verbindungen, um einem Datenpaket eine Prüfsumme zuzuordnen.
Da unterschiedliche Schichten der Protokollstapel wenig oder keine Kenntnis der anderen Schichten aufweisen, werden Fly-By-Prüfsummen, die durch die Fly-By-Prüfsummenerzeugungseinheit 40 erzeugt werden, einfach durch die Prüfsummenkanäle nach oben ausgebreitet. Wenn eine spezielle Schicht ein Paket empfängt und diese Schicht eine Prüfsumme erfordert, um die Integrität des Pakets zu verifizieren, und der erforderliche Prüfsummenalgorithmus bei der Einheit 40 registriert wurde, liest die Schicht einfach die Prüfsumme aus dem Prüfsummenkanal.
Man nehme z. B. an, dass der Protokollstapel 32 das TCP/IP-Protokoll implementiert und der Protokollstapel 34 das IPX-Protokoll implementiert. Wenn die TCP-Schicht initialisiert ist, benachrichtigt die TCP-Schicht die Fly-By-Prüfsummenerzeugungseinheit 40, dass dieselbe eine Prüfsumme benötigt, die aus einem 16-Bit-Einerkomplement an der Einerkomplementsumme aller 16-Bit-Wörter in dem TCP-Kopfblock und den Inhalten gebildet ist, was der Prüfsum menalgorithmus ist, der durch das TCP/IP-Protokoll definiert ist. Dieselbe teilt der Einheit 40 ferner die Anfangs- und Endbytepositionen des Ethernet-Pakets mit, auf dem die Prüfsumme erzeugt werden sollte. Die Einheit 40 antwortet durch ein Bestätigen, dass der Prüfsummenalgorithmus registriert wurde, und ein Benachrichtigen der TCP-Schicht, dass die ordnungsgemäße Prüfsumme die erste Prüfsumme in dem Prüfsummenkanal sein wird.
Wenn die IPX-Schicht initialisiert ist, benachrichtigt die IPX-Schicht ebenfalls die Einheit 40 über den Prüfsummenalgorithmus, den dieselbe benötigt, und die Anfangs- und Endbytepositionen des Ethernet-Pakets, auf dem die Prüfsumme erzeugt werden sollte. Die Einheit 40 antwortet durch ein Bestätigen, dass der Prüfsummenalgorithmus registriert wurde, und ein Benachrichtigen der IPX-Schicht, dass die ordnungsgemäße Prüfsumme die zweite Prüfsumme in dem Prüfsummenkanal sein wird.
Wenn ein eingehendes Paket durch einen Netzwerkadapter empfangen wird, erzeugt die Einheit 40 eine Prüfsumme basierend auf diesem Paket für jeden Prüfsummenalgorithmus, der registriert wurde. Der Adapter weiß typischerweise nicht, welche Protokolle in dem Paket enthalten sein können.
Während sich die Datenverbindungsschicht 30 der unteren Schicht jedes Protokollstapels bewusst ist und in der Lage ist, das Paket zu dem ordnungsgemäßen Stapel zu richten, weiß die Schicht 30 nicht, welche Schicht einen speziellen Prüfsummenalgorithmus registriert hat. Folglich führt bzw. leitet die Datenverbindungsschicht 30 alle Fly-By-Prüfsummen durch den Prüfsummenkanal des geeigneten Protokollstapels hinauf.
Die Fly-By-Prüfsummen laufen den Prüfsummenkanal weiter hinauf, der einem Protokollstapel zugeordnet ist, bis dieselben an der Schicht ankommen, die den Prüfsummenalgo rithmus registrierte. Falls z. B. der Protokollstapel 32 das TCP/IP-Protokoll implementiert, wie es oben erörtert ist, dann erlangt die TCP-Schicht die erste Prüfsumme aus dem Prüfsummenkanal wieder, falls der Protokollstapel 34 das IPX-Protokoll implementiert, dann erlangt die IPX-Schicht die zweite Prüfsumme aus dem Prüfsummenkanal wieder usw. Obwohl erwartet wird, dass die vorliegende Erfindung am vorteilhaftesten ist, wenn dieselbe verwendet wird, um Fly-By-Prüfsummen für die oberen Schichten von Protokollstapeln zu erzeugen, ist die vorliegende Erfindung breit genug, um eine Anwendung zu umschließen, die einen Prüfsummenalgorithmus bei einer Fly-By-Prüfsummenerzeugungseinheit 40 registriert und dann eine Fly-By-Prüfsumme verwendet, die gemäß dem registrierten Prüfsummenalgorithmus an der Anwendungsschicht berechnet wurde.
Bei vielen Netzwerkanwendungen umfasst ein Netzwerkadapter einen oder mehrere Protokollstapel und führt bzw. leitet Daten zu einem Hostsystem nach einem Verarbeiten durch einen Protokollstapel. Zum Beispiel empfängt Hewlett-Packards Linie von JetDirect-Netzwerkadaptern Daten von einem Netzwerk, verarbeitet die Daten durch einen Protokollstapel und überträgt die Daten dann zu einem Drucker. Wenn die Daten zu dem Drucker übertragen werden, wurden alle Netzwerkprotokolle von den Daten entfernt und dieselben sind in einem Format Daten ähnlich, die über ein paralleles Tor (Port) zu einem Drucker übertragen werden. Bei einem derartigen Netzwerkadapter wird ein eingehendes Paket durch ein Sende/Empfangsgerät empfangen und dann in einem Speicher gespeichert, der durch den Adapter vorgesehen ist. Das Paket wird dann durch den Protokollstapel verarbeitet und die resultierenden Daten werden zu dem Hostsystem geführt bzw. geleitet.
Viele Verkäufer stellen anwendungsspezifische integrierte Schaltungen (ASICs; ASICs = application specific integrated circuits) bereit, die eine LAN-Steuerungskernschaltungsanordnung zusammen mit einer definierbaren Logik umfassen, die durch den Entwickler eines Netzwerkadapters verwendet wird, um verschiedene Funktionen zu implementieren. Es ist erwünscht, so viel Funktionalität wie möglich in eine derartige ASIC zu packen, um die Schaltungsanordnung zu minimieren, die außerhalb der ASIC erforderlich ist, wodurch die Kosten des Netzwerkadapters minimiert werden. Derartige ASICs weisen jedoch typischerweise nicht genügend definierbare Logik auf, um eine Speicherung von ganzen Paketen innerhalb der ASIC zu ermöglichen. Folglich ist es nicht praktisch, ein Paket innerhalb der ASIC zu empfangen und dann eine Prüfsumme zu sammeln, wenn das Paket aus der ASIC und in einen Adapterspeicher mittels eines DMA übertragen wird.
Die vorliegende Erfindung ermöglicht, dass eine Prüfsumme innerhalb der ASIC gesammelt wird, während ein Datenpaket simultan durch die ASIC empfangen und aus der ASIC und in einen Adapterspeicher mittels eines DMA übertragen wird. 3 ist ein Blockdiagramm eines Netzwerkadapters 54, der ein Ausführungsbeispiel der vorliegenden Erfindung ist. Der Netzwerkadapter 54 umfasst eine ASIC 56, einen Adaptermikroprozessor 58, einen Adapterspeicher 60 und eine Adapter-Eingangs-/Ausgangseinheit (Adapter-I/O-Einheit) 62, die alle durch einen Adapterbus 63 miteinander gekoppelt sind. Die Adapter-I/O-Einheit ist ebenfalls über einen Systembus 61 mit einem Hostsystem gekoppelt, wie beispielsweise einem Drucker oder einem Computernetzwerk, wobei eine gepunktete Linie 59 die Systembusschnittstelle darstellt.
Die ASIC 56 umfasst ein Sende/Empfangsgerät 64, eine Medienzugriffssteuereinheit (MAC-Einheit; MAC = media access control) 66, einen Bytepuffer 68, eine DMA-Einheit 70 und eine Fly-By-Prüfsummenerzeugungseinheit 72. Das Sende/Empfangsgerät 64 ist mit Netzwerkmedien 74 und der MAC-Einheit 66 gekoppelt. Die MAC-Einheit 66 ist ebenfalls mit einem Eingang des Bytepuffers 68, der DMA-Einheit 70 und der Fly-By-Prüfsummenerzeugungseinheit 72 gekoppelt. Ein Ausgang des Bytepuffers 68 ist mit der DMA-Einheit 70 und der Fly-By-Prüfsummenerzeugungseinheit 72 gekoppelt. Die DMA-Einheit 70 und die Fly-By-Prüfsummenerzeugungseinheit 72 sind jeweils mit dem Adapterbus 63 gekoppelt und die Fly-By-Prüfsummenerzeugungseinheit 72 ist mit der DMA-Einheit 70 gekoppelt.
Die Adaptermikroprozessoreinheit 58 ist ein Mikroprozessor, der einen Code ausführt, der verschiedene Funktionen des Netzwerkadapters 54 steuert und den Protokollstapel implementiert. Die Adapterspeichereinheit 60 stellt sowohl einen Nur-Lese-Speicher (ROM; ROM = read-only memory) als auch einen Direktzugriffsspeicher (RAM; RAM = random access memory) dar. Der ROM enthält einen Programmcode, der durch die Mikroprozessoreinheit 58 ausgeführt wird, und der RAM wird verwendet, um eingehende und ausgehende Pakete zu puffern und andere Daten zu speichern und kann ebenfalls einen Programmcode enthalten. Die Adapter-I/O-Einheit 62 stellt eine Kommunikationsverbindung zwischen dem Netzwerkadapter 54 und einem Hostsystem über den Systembus 61 bereit.
Wenn ein eingehendes Paket beginnt, an dem Netzwerkadapter 54 anzukommen, empfängt das Sende/Empfangsgerät 64 Paketbytes, die das eingehende Paket bilden. Wenn die Paketbytes empfangen werden, fließen dieselben durch die MAC-Einheit 66 und zu dem Eingang des Bytepuffers 68. Das Eingangssignal des Bytepuffers 68 wird ferner zu der Fly-By-Prüfsummenerzeugungseinheit 72 geliefert, um die Erzeugung eines „Paketende"-Signals zu ermöglichen, was unten genauer beschrieben wird.
Wenn die Paketbytes aus dem Ausgang des Bytepuffers 68 hervorgehen, werden dieselben zu der DMA-Einheit 70 und der Fly-By-Prüfsummenerzeugungseinheit 72 geliefert. Die DMA-Einheit 70 überträgt die Paketbytes zu dem Adapterspeicher 60. Während die DMA-Einheit 70 die Paketbytes überträgt, berechnet die Fly-By-Prüfsummenerzeugungseinheit 72 Prüfsummen für Prüfsummenalgorithmen, die registriert wurden.
Nachdem die Prüfsummen vollständig sind, werden dieselben zu dem Adapterspeicher 60 über die DMA-Einheit 70 übertragen.
Wenn das Paket einmal in dem Speicher 60 zusammen mit jeglichen Prüfsummen, die berechnet wurden, gespeichert ist, führt der Adaptermikroprozessor 58 einen Code aus, der eine Verarbeitung durchführt, die durch die Protokollstapel benötigt wird, wie es oben mit Bezug auf 2 erörtert ist.
4 ist ein Blockdiagramm der Fly-By-Prüfsummenerzeugungseinheit 72 von 3. Die Einheit 72 umfasst Prüfsummenmodule 78, 80 und 82. Ein Prüfsummenmodul ist für jeden Prüfsummenalgorithmus erforderlich, der durch die Einheit 72 implementiert werden soll. Jedes Prüfsummenmodul umfasst eine Prüfsummenalgorithmuseinheit 84, einen Prüfsummensammler bzw. -akkumulator 86, ein Anfangsbyteregister 88 und ein Endbyteregister 90. Die Register 88 und 90 und der Sammler 86 sind jeweils mit der Prüfsummenalgorithmuseinheit 84 gekoppelt und der Prüfsummenalgorithmus 84 ist mit der Adapter-DMA-Einheit 70, dem Adapterbus 63 und dem Eingang und dem Ausgang des Puffers 68 gekoppelt.
Die Prüfsummenalgorithmuseinheit 84 speichert den Prüfsummenalgorithmus, der verwendet wird, um Fly-By-Prüfsummen zu erzeugen, wenn Paketbytes von Netzwerkmedien 74 zu dem Adapterspeicher 60 über das Sende/Empfangsgerät 64, die MAC-Einheit 66, den Puffer 68 und die DMA-Einheit 70 übertragen werden. Bei einem Ausführungsbeispiel umfasst die Einheit 72 einen oder mehrere vordefinierte Prüfsummenalgorithmen. Es ist anzumerken, dass unterschiedliche Protokolle das gleiche Prüfsummenprotokoll verwenden können, selbst wenn der Bytebereich, von dem eine Prüfsumme gebildet werden soll, in dem Paket unterschiedlich ist. Bei einem anderen Ausführungsbeispiel umfasst die Prüfsummenalgorithmuseinheit 72 einen programmierbaren Speicher, der über die Adapter-I/O-Einheit 62 über den Adapterbus 63 programmiert werden kann. Das Anfangsbyteregister 88 speichert die Positionsnummer des ersten Bytes des Pakets, das in die Prüfsumme eingeschlossen sein soll, und das Endbyteregister 90 speichert die Positionsnummer des letzten Bytes, das in die Prüfsumme eingeschlossen sein soll. Die Nummer des ersten Bytes wird als ein Versatz von dem Anfang des Pakets gespeichert und die Nummer des letzten Bytes wird als ein Versatz von dem Ende des Pakets gespeichert. Da ein Versatz von dem Ende des Pakets nicht bestimmt werden kann, bis das Ende des Pakets empfangen wurde, basiert die minimale Anzahl von Einträgen, die in dem Puffer 68 vorgesehen sind, auf dem größten Versatz von dem Ende des Pakets, der in dem Endbyteregister 90 gespeichert sein wird.
Man betrachte beispielsweise ein eingehendes Ethernet-Paket, das Daten umfasst, die unter Verwendung des TCP/IP-Protokolls codiert sind, wie beispielsweise ein Paket 92 in 5. Das TCP/IP-Protokoll definiert die Prüfsumme wie folgt:
Die Prüfsumme ist ein 16-Bit-Einerkomplement der Einerkomplementsumme aller 16-Bit-Wörter in dem Kopfblock und dem Text. Falls ein Segment eine ungerade Anzahl von Kopfblock- und Text-Oktetts enthält, von denen eine Prüfsumme gebildet werden soll, wird das letzte Oktett an der Rechten mit Nullen aufgefüllt, um ein 16-Bit-Wort für Prüfsummenzwecke zu bilden. Die Auffüllung wird nicht als ein Teil des Segments übertragen. Während die Prüfsumme berechnet wird, wird das Prüfsummenfeld selbst mit Nullen ersetzt.
Die Prüfsummenalgorithmuseinheit 84 ist konfiguriert, um diesen Algorithmus zu implementieren, entweder durch ein Auswählen eines vordefinierten Algorithmus, der in der Einheit 72 vorhanden ist, oder durch ein Speichern des Algorithmus in der Einheit 72.
Wie es in 5 zu sehen ist, ist das Ethernet-Paket 92 124 Byte lang. Bytes 1–14 halten einen Ethernet-MAC-Kopfblock 94, Bytes 15–34 halten einen IP-Kopfblock 96, Bytes 35–54 halten einen TCP-Kopfblock 98, Bytes 55–120 halten einen TCP-Datenabschnitt 100 und Bytes 121–124 halten einen MAC-CRC-Code 103. Da die TCP-Prüfsumme den TCP-Kopfblock 98 umfasst, ist das Anfangsbyteregister 88 zu 35 gesetzt und ist das Endbyteregister 90 zu 4 gesetzt (was ein Versatz von dem Ende des Pakets ist).
Wenn Paketbytes, die das Ethernet-Paket 92 bilden, beginnen, von der MAC-Einheit 66 zu der DMA-Einheit 70 über den Puffer 68 übertragen zu werden, werden die Paketbytes, die an dem Ausgang des Puffers 68 erscheinen, ebenfalls zu der Prüfsummenalgorithmuseinheit 84 geliefert. Wenn die Byteposition, die in dem Anfangsbyteregister 88 gespeichert ist, erreicht ist, beginnt die Prüfsummenalgorithmuseinheit 84, die Prüfsumme in dem Prüfsummensammler 86 zu sammeln. Wenn das letzte Paketbyte des Pakets zu dem Eingang des Puffers 68 übertragen wird, erzeugt die Einheit 84 ein „Paketende"-Signal. Basierend auf dem Paketende-Signal, der Byteposition, die in dem Endbyteregister 90 gespeichert ist, und der Anzahl von Einträgen in dem Puffer 68 beendet die Einheit 84 ein Sammeln der Prüfsumme und nimmt irgendeine Nachverarbeitung der Prüfsumme in dem Sammler 86 vor, wie beispielsweise ein Auffüllen eines letzten Oktetts an der Rechten mit Nullen, um ein 16-Bit-Wort für Prüfsummenzwecke zu bilden, falls der TCP-Kopfblock 98 und der TCP-Datenabschnitt 100 zusammen eine ungerade Anzahl von Oktetts enthalten, von denen eine Prüfsumme gebildet werden soll, wie es durch das TCP/IP-Protokoll erforderlich ist. Nachdem die Prüfsumme vollständig ist, wird dieselbe zu der DMA-Einheit 70 und dann dem Adapterspeicher 60 übertragen. Unter Bezugnahme auf 2 wird die Prüfsumme dann zu dem Prüfsummenkanal 46 der Datenverbindungsschicht 30 und dann durch den Prüfsummenkanal des TCP/IP-Protokolls nach oben übertragen.
Unterschiedliche Typen von Protokollkopfblöcken können unterschiedliche Längen aufweisen, so dass die erzeugte Prüfsumme die Inhalte des Pakets genau widerspiegeln kann oder nicht. Die Protokollschicht jedoch, die den Prüfsummenalgorithmus registrierte, wird in der Lage sein, zu bestimmen, ob dieselbe die Fly-By-Prüfsumme verwenden kann, die durch die Fly-By-Prüfsummenerzeugungseinheit 72 berechnet wurde, da diese Protokollschicht erkennen wird, ob der spezielle Kopfblock dem Kopfblocktyp entspricht, für den ein Prüfsummenalgorithmus registriert wurde. In einem typischen Protokolldialog trägt die Mehrheit von Paketen eine Benutzerinformation (wie beispielsweise einen Druckauftrag) und diese Pakete weisen ein voraussagbares Format auf und die Anfangs- und Endbytes sind bekannt. Falls ein Protokoll große Mengen an Daten unter Verwendung von zwei oder mehr Formaten übertragen würde, dann kann ein Prüfsummenalgorithmus für jedes Format registriert sein und die geeignete Protokollschicht wüsste, welche Prüfsumme basierend auf dem Format des Kopfblocks auszuwählen ist.
Bei einer anderen Konfiguration kann die vorliegende Erfindung modifiziert sein, um ebenfalls die Anfangs- und Endbytepositionen zusammen mit der Prüfsumme den Prüfsummenkanal hinauf zu senden. Zusätzlich kann es erwünscht sein, ebenfalls eine Angabe des Prüfsummenalgorithmus den Prüfsummenkanal hinauf zu senden. Falls natürlich eine spezielle Protokollebene einen Prüfsummenalgorithmus registrierte, würde diese Protokollebene diese Informationen kennen. Es kann jedoch erwünscht sein, dass ein Betriebssystem eines oder mehrere Prüfsummenprotokolle registriert und dann die Anfangs- und Endbytepositionen und den Prüfsummenindikator zusammen mit der Prüfsumme den Prüfsummenkanal hinauf sendet. Bei einer derartigen Konfiguration kann die spezielle Protokollebene den Prüfsummenkanal überwachen und eine Fly-By-Prüfsumme in dem Kanal verwenden, falls eine gültige Prüfsumme verfügbar ist, oder eine Prüfsumme unter Verwendung anderer Verfahren berechnen, falls eine Fly-By-Prüfsumme nicht verfügbar ist.
Die vorliegende Erfindung ist besonders gut geeignet für Netzwerkknoten, die eine große Menge von eingehenden Netzwerkpaketen empfangen, wie beispielsweise ein Drucker, der Druckaufträge über ein Netzwerk empfängt, oder ein Netzwerkcomputer, der ausführbare Programme über ein Netzwerk lädt. Es wurde herausgefunden, dass die vorliegende Erfindung einen Durchsatz bei derartigen Netzwerkknoten um näherungsweise 10 %–20 % erhöht.
Die vorliegende Erfindung erfordert lediglich kleinere Änderungen an Vernetzungsprotokollen des Stands der Technik. Die Protokolle und/oder das Betriebssystem des Hostsystems muss/müssen die Fly-By-Prüfsummenerzeugungseinheit 72 initialisieren, um den erwünschten Prüfsummenalgorithmus durchzuführen, und jede Schicht des Protokolls, die die Fly-By-Prüfsumme verwendet, muss die Fly-By-Prüfsumme den Stapel hinauf leiten, was ohne weiteres durch ein Leiten eines Zeigers zu der Fly-By-Prüfsumme oder durch ein Definieren eines Raums in der Datenstruktur vorgenommen werden kann, der das Datenpaket speichert, das der Prüfsumme zugeordnet ist. Es ist anzumerken, dass die höchste Schicht, die die Fly-By-Prüfsumme verwendet, die Prüfsumme nicht zu höheren Schichten leiten muss. Schließlich muss jede Schicht, die die Fly-By-Prüfsumme verwendet, ein Paket erkennen, für das eine Fly-By-Prüfsumme verfügbar ist, und in der Lage sein, diese Prüfsumme von dem Prüfsummenkanal zu erhalten.
Bei einem einfachen Ausführungsbeispiel, bei dem eine Prüfsumme lediglich für eine Schicht eines Protokolls erzeugt wird, kann die Fly-By-Prüfsummenerzeugungseinheit 72 konfiguriert sein, um eine einzige Prüfsumme zu erzeugen, die vordefinierte Anfangs- und Endbytepositionen aufweist, wodurch der Bedarf eliminiert wird, einen Prüfsummenalgorithmus zu registrieren. Bei einem typischen Ethernet-Paket, das Daten enthält, die mit dem TCP/IP-Protokoll codiert sind, enthalten außerdem die letzten vier Bytes des Pakets immer den MAC-CRC-Code. Da dieser Code lediglich vier Bytes lang ist, ist es keine rechenmäßig intensive Aufgabe, die Prüfsumme des MAC-CRC-Codes zu berechnen und diese Prüfsumme von der Fly-By-Prüfsumme zu subtrahieren. Dabei werden der Puffer 68 von 3 und das Endbyteregister 90 von 4 nicht benötigt, wodurch die Menge an Logik minimiert wird, die erforderlich ist, um die vorliegende Erfindung zu implementieren.
Ein anderer Vorteil der vorliegenden Erfindung besteht darin, dass dieselbe vollständig rückwärtskompatibel mit Protokollstapeln ist, die Fly-By-Prüfsummen nicht unterstützen, wie beispielsweise Alt- bzw. Legacy-Protokolle oder Protokolle, die selten verwendet werden. Derartige Protokolle können einfach Prüfsummen unter Verwendung von Verfahren des Stands der Technik berechnen.
Fachleute auf dem Gebiet erkennen, dass die vorliegende Erfindung nicht auf Prüfsummenalgorithmen begrenzt ist. Zum Beispiel kann die Prüfsummenalgorithmuseinheit 84 von 4 programmiert sein, um einen Fehlerkorrekturcode zu erzeugen, der den Protokollstapel hinauf geleitet wird. Alternativ kann die Prüfsummenalgorithmuseinheit 84 programmiert sein, um einen Entschlüsselungsalgorithmus auszuführen, der einen Abschnitt eines eingehenden Pakets unter Verwendung eines Entschlüsselungsschlüssels entschlüsselt, der durch das Hostsystem geliefert wird. Der entschlüsselte Abschnitt des Pakets kann dann den Protokollstapel hinauf unter Verwendung eines „entschlüsselten Kanals" geleitet werden, ähnlich dem oben beschriebenen Prüfsummenkanal.
Obwohl die vorliegende Erfindung mit Bezug auf einen Netzwerkadapter beschrieben wurde, der Protokollstapel umfasst, wie beispielsweise ein Netzwerkadapter, der bei einem Drucker verwendet wird, erkennen Fachleute auf dem Gebiet ferner, dass die hierin enthaltenen Lehren ebenfalls auf ein System angewendet werden können, bei dem die Protokollstapel durch das Hostsystem implementiert sind. Bei einem anderen Ausführungsbeispiel der vorliegenden Erfindung z. B. kann ein Netzwerkadapter, der eine Fly-By-Prüfsummenerzeugungseinheit gemäß der vorliegenden Erfindung aufweist, in einen PCI-Schlitz eines Arbeitsplatzrechners eingeführt werden, wobei die Protokollstapel als Softwareroutinen implementiert sind, die an dem Arbeitsplatzrechner ausführen. Bei einem derartigen Ausführungsbeispiel registriert eine spezielle Schicht eines Protokollstapels einen Prüfsummenalgorithmus bei der Fly-By-Prüfsummenerzeugungseinheit über die Adapter-I/O-Einheit, die mit dem PCI-Bus gekoppelt ist. Ob die eingehenden Paketbytes zuerst zu einem Adapterspeicher mittels eines DMA übertragen werden oder direkt zu einem Systemspeicher des Arbeitsplatzrechners mittels eines DMA übertragen werden, werden Fly-By-Prüfsummen im Wesentlichen wie oben beschrieben erzeugt.
Die Vorteile der vorliegenden Erfindung werden erreicht, weil von den Daten Prüfsummen erzeugt werden (oder dieselben anderweitig verarbeitet werden, wie es oben erörtert ist), wenn die Daten von den Netzwerkmedien empfangen werden und in einen Speicher mittels eines DMA übertragen werden. Da die Daten ohnehin bewegt werden, wird durch ein Berechnen der Prüfsumme eine geringe zusätzliche Einbuße eingefahren. Ein zusätzlicher Vorteil ist aus der Tatsache abgeleitet, dass von den Daten in der LAN-Steuerungs-ASIC eine Prüfsumme gebildet wird, wo es für einen Entwickler einfach ist, eine Hardware hinzuzufügen, die zum Durchführen der Prüfsumme in der Lage ist.
Obwohl die vorliegende Erfindung mit Bezug auf bevorzugte Ausführungsbeispiele beschrieben wurde, erkennen Fachleute auf dem Gebiet, dass Veränderungen in Form und Detail vorgenommen werden können, ohne von dem Schutzbereich der Erfindung abzuweichen.

Claims

Ein Verfahren zum Empfangen von Daten an einem Netzwerkknoten (26), der einen Netzwerkadapter (54) und einen Protokollstapel (32, 34, 36) umfasst, der eine Mehrzahl von Schichten (12, 14, 16, 18, 20, 22, 24) aufweist, wobei das Verfahren folgende Schritte aufweist: Übertragen von Paketbytes, die ein eingehendes Datenpaket bilden, von Netzwerkmedien (38; 74) zu einem Speicher (60); Berechnen eines Codes aus Paketbytes, die einen Abschnitt des eingehenden Datenpakets bilden, wenn die Paketbytes von den Netzwerkmedien (38; 74) zu dem Speicher (60) übertragen werden; Übertragen des Codes zu einem Codekanal (48, 50, 52), der dem Protokollstapel (32, 34, 36) zugeordnet ist; Empfangen von Daten, die aus dem Datenpaket extrahiert werden, an einer ersten Schicht der Mehrzahl von Schichten (12–24) des Protokollstapels; und Verifizieren der extrahierten Daten unter Verwendung des Codes von dem Codekanal (48, 50, 52).
Das Verfahren gemäß Anspruch 1, bei dem das Übertragen von Paketbytes, die ein eingehendes Datenpaket bilden, von Netzwerkmedien (74) zu dem Speicher (60) folgende Schritte aufweist: Empfangen von Paketbytes an einem Sende/Empfangsgerät (64), das mit den Netzwerkmedien (74) gekoppelt ist; Übertragen von Paketbytes von dem Sende/Empfangsgerät (64) zu einer Direktspeicherzugriffseinheit (70); und Übertragen von Paketbytes von der Direktspeicherzugriffseinheit (70) zu einem Adapterspeicher (60).
Das Verfahren gemäß Anspruch 1 oder 2, bei dem das Berechnen eines Codes aus Paketbytes, die einen Abschnitt des eingehenden Datenpakets bilden, wenn die Paketbytes von den Netzwerkmedien (38; 74) zu dem Speicher (60) übertragen werden, folgende Schritte aufweist: Zählen von Paketbytes des eingehenden Pakets; Sammeln des Codes basierend auf Paketbytes nachfolgend zu dem und einschließlich des Paketbytes, das durch die Anfangsbyteposition identifiziert ist; und Beenden des Sammeln des Codes.
Das Verfahren gemäß Anspruch 3, bei dem das Beenden des Sammeln des Codes folgenden Schritt aufweist: Beenden des Sammeln des Codes nach einem Einschließen eines Paketbytes, das durch eine Endbyteposition in dem Code identifiziert ist.
Das Verfahren gemäß Anspruch 3, bei dem das Beenden des Sammelns des Codes ein Durchführen einer Nachverarbeitung umfasst, die notwendig ist, um den Code abzuschließen.
Das Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem der Code ein Prüfsummencode ist.
Das Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem der Protokollstapel (32, 34, 36) ein TCP/IP-Stapel ist.
Das Verfahren gemäß einem der Ansprüche 1 bis 7, das ferner folgenden Schritt aufweist: Registrieren eines Prüfsummenalgorithmus.
Das Verfahren gemäß Anspruch 8, bei dem das Registrieren eines Prüfsummenalgorithmus ein Spezifizieren von Anfangs- und Endbytepositionen umfasst.
Das Verfahren gemäß Anspruch 8 oder 9, bei dem das Berechnen eines Codes aus Paketbytes folgenden Schritt aufweist: Berechnen eines Codes für jeden registrierten Prüfsummenalgorithmus aus Paketbytes, die einen Abschnitt des eingehenden Datenpakets bilden, wenn die Paketbytes von den Netzwerkmedien (38; 74) zu dem Speicher (60) übertragen werden.