DE112005000523B4 - Zwei parallele Maschinen für Hochgeschwindigkeitssende-IPSEC-Verarbeitung - Google Patents

Zwei parallele Maschinen für Hochgeschwindigkeitssende-IPSEC-Verarbeitung Download PDF

Info

Publication number
DE112005000523B4
DE112005000523B4 DE112005000523T DE112005000523T DE112005000523B4 DE 112005000523 B4 DE112005000523 B4 DE 112005000523B4 DE 112005000523 T DE112005000523 T DE 112005000523T DE 112005000523 T DE112005000523 T DE 112005000523T DE 112005000523 B4 DE112005000523 B4 DE 112005000523B4
Authority
DE
Germany
Prior art keywords
data
block
network
header
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112005000523T
Other languages
English (en)
Other versions
DE112005000523T5 (de
Inventor
Marufa Kaniz
Jeffrey Dwork
Robert Alan Williams
Mohammad Y. Maniar
Somnath Viswanath
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced Micro Devices Inc
Original Assignee
Advanced Micro Devices Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced Micro Devices Inc filed Critical Advanced Micro Devices Inc
Publication of DE112005000523T5 publication Critical patent/DE112005000523T5/de
Application granted granted Critical
Publication of DE112005000523B4 publication Critical patent/DE112005000523B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer

Abstract

Netzwerkschnittstellensystem (2) zur Verbindung eines Host-Systems (6) mit einem Netzwerk (8), um von dem Host-System (6) abgehende Daten dem Netzwerk (8) zuzuführen und um aus dem Netzwerk (8) eingehende Daten dem Host-System (6) zuzuführen, wobei das Netzwerkschnittstellensystem (2) umfasst: ein Bus-Schnittstellensystem (4), das ausgebildet ist, mit einem Host-Bus (106) in dem Host-System (6) verbunden zu werden und um Daten zwischen dem Netzwerksystem (8) und dem Host-System (6) auszutauschen; ein Mediumzugriffssteuerungssystem (10), das ausgebildet ist, mit dem Netzwerk (8) verbunden zu werden und um Daten zwischen dem Netzwerkschnittstellensystem (2) und dem Netzwerk (8) auszutauschen; ein Speichersystem (12), das mit dem Bus-Schnittstellensystem (4) und dem Mediumzugriffssteuerungssystem (10) verbunden ist, wobei das Speichersystem (12) ausgebildet ist, eingehende und abgehende Daten, die zwischen dem Netzwerk (8) und dem Host-System (6) ausgetauscht werden, zu speichern; ein Sicherheitssystem (14), das mit dem Speichersystem (12) verbunden ist, wobei das Sicherheitssystem (14) ausgebildet ist,...

Description

  • TECHNISCHES GEBIET
  • Die Erfindung betrifft im Allgemeinen das Gebiet der Computereinrichtungen und betrifft insbesondere Verfahren und Systeme zur Bereitstellung von Schnittstellen mit einer Hauptrechner- bzw. Host-Einrichtung oder einem Host-System mit einem Netzwerk.
  • HINTERGRUND DER ERFINDUNG
  • Host-Rechnersysteme, etwa Personalcomputer, werden häufig als Knoten in einem Kommunikationsnetzwerk betrieben, wobei Jeder Knoten in der Lage ist, Daten aus dem Netzwerk zum empfangen und Daten in das Netzwerk zu senden. Daten werden über ein Netzwerk in Gruppen oder Segmenten übertragen, wobei die Organisation und die Segmentierung der Daten durch ein Netzwerkbetriebssystemprotokoll vorgeschrieben sind, und es gibt viele unterschiedliche Protokolle. Es können Datensegmente, die unterschiedlichen Protokollen entsprechen, im gleichen Kommunikationsnetzwerk gleichzeitig vorhanden sein. Damit ein Knoten Informationspakete senden und empfangen kann, ist der Knoten mit einer peripheren Netzwerkschnittstelleneinrichtung ausgestattet, die dafür verantwortlich ist, Informationen zwischen dem Kommunikationsnetzwerk und dem Host-System auszutauschen. Beim Senden baut eine Prozessoreinheit in dem Host-System Daten- oder Informationspakete gemäß einem Netzwerkbetriebssystemprotokoll auf und gibt diese Pakete an die Netzwerkperipherie weiter. Beim Empfangen erhält die Prozessoreinheit die Pakete, die von der Netzwerkperipherie empfangen werden, und decodiert diese. Die Prozessoreinheit führt viele der Sende- und Empfangsfunktionen in Reaktion auf Befehle einer Interrupt-Abarbeitungsroutine aus, die mit der Netzwerkperipherie verknüpft ist. Wenn ein empfangenes Paket eine Verarbeitung anfordert, wird ein Interrupt an das Host-System durch die Netzwerkperipherie ausgegeben. Der Interrupt wird üblicherweise ausgegeben, wenn alle Bits eines Pakets oder eine gewisse festgelegte Anzahl an Bits in dem Paket durch die Netzwerkperipherie empfangen wurden.
  • Netzwerke werden typischerweise als eine Reihe oder ein Stapel aus Schichten oder Ebenen betrieben, wobei jede Schicht bestimmte Dienste für die unmittelbar darüber liegende Schicht anbietet. Es sind viele verschiedene, mit Schichten versehene Netzwerkarchitekturen möglich, wobei die Anzahl der Schichten, die Funktion und der Inhalt jeder Schicht bei unterschiedlichen Netzwerken unterschiedlich sein kann. Die internationale Standardorganisation (ISO) entwickelte ein offenes Modell zur Systemverbindung (OSI), in der ein Protokollstapel mit sieben Schichten einschließlich einer Anwendungsschicht (beispielsweise Schicht 7), einer Präsentationsschicht, einer Arbeitsschicht, einer Transportschicht, einer Netzwerkschicht, einer Datenverbindungsschicht und einer physikalischen Schicht (beispielsweise Schicht 1) enthalten sind, wobei die Steuerung von einer Schicht zur nächsten übertragen wird, wobei bei der Anwendungsschicht in einer Station begonnen wird, und wobei der Ablauf bis zur untersten Schicht, dann über den Kanal zu der nächsten Station und die gleiche Hierarchie in der Rückwärtsrichtung durchlaufen wird. Der Anwender eines Host-Systems wirkt im Allgemeinen auf ein Softwareprogramm ein, das in der höchsten Schicht (beispielsweise Anwendungsschicht) abgearbeitet wird, und die Signale werden über das Netzwerk zu der untersten (beispielsweise physikalischen) Schicht gesendet.
  • In der US 2004/0039936 A1 wird ein Verfahren zur Hochgeschwindigkeits-IPSEC-Verarbeitung beschrieben, in dem Netzwerkschnittstellensystem Verwendung findet, das ein Bus-Schnittstellensystem, ein Mediumzugriffssteuerungssystem, ein Speichersystem und ein Sicherheitssystem, um selektiv abgehende Daten zu verschlüsseln und selektiv eingehende Daten zu entschlüsseln, umfasst.
  • Eine bekannte Netzwerkarchitektur wird häufig als ein TCP/IP-Stapel bezeichnet, in der die Anwendungsschicht ein FTP (Dateitransferprotokoll), ein HTTP (Hypertexttransferprotokoll) oder ein SSH (sicherer Rahmen) ist. In diesen Netzwerken ist das Transportschichtprotokoll typischerweise als ein Sendesteuerprotokoll (TCP) oder ein Anwenderdatagrammprotokoll (UDP) eingerichtet, und die Netzwerkschicht wendet Protokolle, etwa das Internetprotokoll (IP), Adressenauflösungsprotokoll (ARP), Umkehradressenauflösungsprotokoll (RARP) oder ein Internetsteuernachrichtenprotokoll (ICMP) an. Die Datenverbindungsschicht ist im Allgemeinen in zwei Teilschichten aufgeteilt, zu denen eine Medienzugriffssteuerungs(MAC)-Unterschicht gehört, die steuert, wie ein Computer in dem Netzwerk Zugriff auf die Daten erhält und eine Erlaubnis erhält, diese zu senden, sowie eine logische Verbindungssteuerungs-(LLC)-Unterschicht, die die Blocksynchronisierung, die Ablaufsteuerung und die Fehlererkennung steuert. Die physikalische Schicht übermittelt die Daten als ein Bitstrom aus elektrischen Impulsen, Lichtsignalen und/oder Funksignalen über das Netzwerk auf physikalischer Ebene (beispielsweise elektrisch und mechanisch). Die physikalische Schicht implementiert Ethernet-, RS232-, asynchrone Transfermodus-(ATM)- oder andere Protokolle mit physikalischen Schichtkomponenten, wobei das Ethernet ein bekanntes lokales Nahbereichsnetzwerk (LAN) ist, das durch IEEE 802.3 definiert ist.
  • Eine oder mehrere Schichten in dem Netzwerkprotokollstapel stellen häufig Werkzeuge für die Fehlererkennung bereit, wozu die Prüfsummenbildung gehört, in der übertragene Nachrichten einen numerischen Prüfsummenwert enthalten, der typischerweise gemäß der Anzahl aus gesetzten Bits in der Nachricht berechnet wird. Der empfangende Netzwerkknoten verifiziert den Prüsummenwert, indem die Prüfsumme unter Anwendung des gleichen Algorithmus berechnet wird, wie er vom Sender benutzt wird, und indem das Ergebnis mit den Prüfsummendaten in der empfangenen Nachricht verglichen wird. Wenn die Werte unterschiedlich sind, kann der Empfänger annehmen, dass ein Fehler während der Übertragung über das Netzwerk aufgetreten ist. In einem Beispiel wenden die TCP- und die IP-Schicht (beispielsweise Schichten 4 und 3) typischerweise Prüfsummen für die Fehlererkennung in einer Netzwerkanwendung an.
  • Daten können ebenso in einer oder mehreren der Schichten in einem Netzwerkprotokollstapel aufgeteilt oder segmentiert werden. Beispielsweise stellt das TCP-Protokoll eine Teilung von Daten, die von der Anwendungsschicht empfangen werden, in Segmente bereit, wobei ein Kopfbereich jedem Segment hinzugefügt wird. Jeder Kopfbereich enthält Sende- und Empfängerports bzw. Anschlüsse, Segmentanordnungsinfomationen und eine Prüfsumme. Die Segmentierung wird beispielsweise verwendet, wenn eine untere Schicht Datennachrichten auf eine Größe beschränkt, die kleiner ist als eine Nachricht aus einer darüber liegenden Schicht. In einem Beispiel kann ein TCP-Rahmen bzw. Block größer sein als 64 kbytes, wohingegen ein Ethernet-Netzwerk lediglich Datenrahmen bzw. Blöcke mit einer deutlich geringeren Größe in der physikalischen Schicht zulässt. In diesem Fall kann die TCP-Schicht einen großen TCP-Block in kleinere segmentierte Blöcke unterteilen, um der Größenbeschränkung des Ethernets Rechnung zu tragen.
  • Eine oder mehrere der Netzwerkprotokollschichten kann Sicherheitsmechanismen anwenden, etwa eine Verschlüsselung und eine Authentifizierung, um zu verhindern, dass nicht autorisierte Systeme oder Anwender Daten lesen und/oder um sicherzustellen, dass die Daten aus einer erwarteten Quelle stammen. Beispielsweise wurden IP-Sicherheits-(IPsec)-Standards für die IP-Schicht (beispielsweise Schicht 3 des OSI-Modells) erstellt, um den sicheren Austausch von Daten zu ermöglichen, wobei diese Verfahrenstechnologie häufig eingesetzt wird, um virtuelle private Netzwerke (VPN) einzurichten. IPsec unterstützt zwei Betriebsmodi, zu denen ein Transportmodus und ein Tunnelmodus gehören. im Transportmodus verschlüsselt der Sender den Nutzdatenbereich der IP-Nachricht und der IP-Kopfbereich wird nicht verschlüsselt, wohingegen in dem Tunnelmodus sowohl der Kopfbereich als auch die Nutzdaten verschlüsselt werden. In dem Empfängersystem wird die Nachricht in der IP-Schicht entschlüsselt, wobei das Sendersystem und das Empfängersystem einen öffentlichen Schlüssel oder eine Sicherheitsassoziation bzw. Verknüpfung (SA) gemeinsam nutzen. Eine gemeinsame Nutzung eines Schlüssels wird typischerweise über eine Internet-Sicherheitsassoziation bzw. Zuordnung und ein Schlüsselverwaltungsprotokoll (ISAKMP) erreicht, das es dem Empfänger ermöglicht, einen öffentlichen Schlüssel zu erhalten und den Sender bei Anwendung digitaler Zertifikate zu authentifizieren.
  • In konventionellen Netzwerken werden die Aufgaben der oberen und mittleren Schichten in der Host-Systemsoftware ausgeführt. Wenn eine Anwendungssoftware in dem Host-Computer Daten zu einer weiteren Einrichtung in dem Netzwerk übertragen muss, gibt die Anwendung die Daten als ein Paket an die TCP-Schichtsoftware des Host-Betriebssystems (OS) weiter. Die TCP-Schichtsoftware erzeugt einen TCP-Block, der das Datenpaket und einen TCP-Kopfbereich enthält, und führt auch eine möglicherweise erforderliche TCP-Segmentierung und eine Prüfsummenerzeugung durch. Die Host IP-Schichtsoftware erzeugt dann einen IP-Kopfbereich und einen Anhang, sowie einen Ethernet-(MAC)-Kopfbereich und führt eine beliebige ausgewählte IPsec-Sicherheitsverarbeitung durch. Der resultierende IP-Block wird dann einer Netzwerkschnittstelle zur Übertragung an das Netzwerk zugeführt. In dem Empfänger-Host wird der empfangene Block dann entschlüsselt und/oder authentifiziert mittels einer IP-Software in der Empfänger-Host-CPU und es werden die IP-Prüfsummen verifiziert. Die Empfänger-TCP-Schichtsoftware verifiziert dann die TCP-Prüfsumme und setzt dann die segmentierten TCP-Blöcke zu einer Nachricht für das Ziel in der Softwareanwendung in der oberen Schicht zusammen. Derartige konventionelle Systeme erfordern es jedoch, dass die Host-Software viele oder alle Funktionen der Schicht 3 und der Schicht 4 (beispielsweise von IP und TCP/UDP) einschließlich der Segmentierung, der Prüfsummenbildung und der Sicherheitsverarbeitung einrichtet. Diese Funktionen sind im Allgemeinen rechenintensiv und erfordern einen wesentlichen Anteil der Host-Rechnungskapazität. Daher besteht ein Bedarf für verbesserte Netzwerksysteme und Verfahren, um die Bearbeitungsbelastung in Host-Systemen in Netzwerken zu reduzieren.
  • ÜBERBLICK ÜBER DIE ERFINDUNG
  • Das Folgende stellt eine vereinfachte Zusammenfassung der Erfindung dar, um ein grundlegendes Verständnis einiger Aspekte der Erfindung zu bieten. Dieser Überblick ist kein erschöpfender Überblick der Erfindung. Es ist weder beabsichtigt, wesentliche oder entscheidende Elemente der Erfindung anzuzeigen, noch den Schutzbereich der Erfindung abzugrenzen. Vielmehr ist der hauptsächliche Zweck dieses Überblicks, einige Konzepte der Erfindung in einer vereinfachten Form als Einleitung zur detaillierteren Beschreibung, die nachfolgend angegeben ist, zu präsentieren. Die Erfindung betrifft Systeme und Verfahren für Schnittstellen bildende Host-Systeme in Netzwerken.
  • Ein Aspekt der Erfindung betrifft ein Netzwerkschnittstellensystem zur Verbindung eines Host-Systems mit einem Netzwerk. Das Netzwerkschnittstellensystem umfasst ein Bus-Schnittstellensystem, ein Mediumzugriffssteuerungssystem und ein Sicherheitssystem. Das Sicherheitssystem ist ausgebildet, abgehende bzw. auszugebende Daten selektiv zu verschlüsseln und zu authentifizieren. Erfindungsgemäß umfasst das Sicherheitssystem zwei Prozessoren zur Verschlüsselung und Authentifizierung der abgehenden Daten. Abgehende Datenpakete werden abwechselnd zu einem oder zu dem anderen Prozessor gesendet.
  • Die Erfindung vermeidet eine mögliche Engstelle, die auftritt, wenn die Sicherheitsverarbeitung von einem Host-Prozessor durchgeführt wird. In der konventionellen Sicherheitsverarbeitung folgt die Authentifizierung auf die Verschlüsselung. Dies bedeutet, dass die Authentifizierung und die Verschlüsselung nicht gleichzeitig auf der Senderseite ausgeführt werden können, obwohl die Authentifizierung und die Verschlüsselung auf der Empfängerseite gleichzeitig ausgeführt werden können. Durch das Vorsehen mehrerer paralleler Prozessoren auf der Senderseite wird verhindert, dass das Senden langsamer vonstatten geht als das Empfangen.
  • Ein weiterer Aspekt der Erfindung betrifft eine einzelne integrierte Schaltung mit einem Sicherheitssystem, das ausgebildet ist, eine IPsec-Verarbeitung auszuführen. Das Sicherheitssystem umfasst mindestens zwei Sende-IPsec-Prozessoren.
  • Um die vorhergehenden Ziele und weitere Aspekte zu erreichen, werden in der folgenden Beschreibung und in den angefügten Zeichnungen detailliert gewisse anschauliche Aspekte und Ausführungsformen der Erfindung dargestellt. Diese sind für einige diverse Arten anschaulich, in der die Prinzipien der Erfindung eingesetzt werden können. Andere Aufgaben, Vorteile und neue Merkmale der Erfindung gehen aus der folgenden detaillierten Beschreibung der Erfindung hervor, wenn diese im Zusammenhang mit den Zeichnungen studiert wird.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1A ist eine schematische Ansicht, in der ein beispielhaftes Netzwerkschnittstellensystem gemäß einem oder mehreren Aspekten der vorliegenden Erfindung dargestellt ist;
  • 1B ist eine schematische Darstellung, in der ein beispielhafter Sendesicherheitsprozessor gezeigt ist;
  • 1C ist ein Flussdiagramm, in dem die Funktion einer beispielhaften Sende-IPsec-Eingabedatenflusssteuerung gemäß einem weiteren Aspekt der vorliegenden Erfindung gezeigt ist;
  • 1D ist ein Flussdiagramm, das die Funktion einer beispielhaften Sende-IPsec-Ausgangsdatenflusssteuerung gemäß einem weiteren Aspekt der vorliegenden Erfindung zeigt;
  • 2 ist eine schematische Ansicht, in der ein weiteres beispielhaftes Netzwerkschnittstellensystem dargestellt ist, in welchem diverse Aspekte der Erfindung ausgeführt werden können;
  • 3 ist eine schematische Ansicht, in der eine beispielhafte Einzelchipnetzwerksteuerungsausführungsform des Netzwerkschnittstellensystems aus 2 gezeigt ist;
  • 4 ist eine schematische Ansicht, in der ein Host-System gezeigt ist, das mit einem Netzwerk unter Anwendung der beispielhaften Netzwerksteuerung aus 3 verbunden ist;
  • 5A ist eine schematische Ansicht, in der ein Steuerstatusblock in einem Host-Systemspeicher mit Zeigern auf Deskriptorringen und Empfangsstatusringen in dem Host-System aus 2 gezeigt ist;
  • 5B ist eine schematische Ansicht, die einen Steuerungsstatusblock in dem Host-Speicher des Host-Systems aus 2 zeigt;
  • 5C ist eine schematische Ansicht, die Deskriptorverwaltungseinheitsregister in dem Netzwerkschnittstellensystem aus 2 zeigt;
  • 5D ist eine schematische Ansicht, in der ein beispielhafter Senderdeskriptorring in einem Host-Systemspeicher und Zeigerregister in einer Deskriptorverwaltungseinheit des Netzwerkschnittstellensystem aus 2 gezeigt sind;
  • 5E ist eine schematische Ansicht, in der ein beispielhafter Senderdeskriptor in dem Netzwerkschnittstellensystem aus 2 gezeigt ist;
  • 5F ist eine schematische Ansicht, in der ein Sendemarkierungs- und Flaggenbyte in dem Senderdeskriptor aus 5E gezeigt ist;
  • 5G ist eine schematische Ansicht, in der ein beispielhafter Empfängerdeskriptor in dem Netzwerkschnittstellensystem aus 2 gezeigt ist;
  • 5H ist eine schematische Ansicht, in der ein beispielhafter Empfängerdeskriptorring und ein Empfängerstatusring in einem Host-Systemspeicher sowie Zeigerregister in der Deskriptorverwaltungseinheit des Netzwerkschnittstellensystems aus 2 gezeigt sind;
  • 5I ist eine schematische Ansicht, in der ein beispielhafter Empfängerstatusring in einem Host-Systemspeicher und Zeigerregister in der Deskriptorverwaltungseinheit in dem Netzwerkschnittstellensystem aus 2 gezeigt sind;
  • 5J ist eine schematische Ansicht, in der ein beispielhafter Empfängerstatusringeintrag in dem Host-Systemspeicher gezeigt ist;
  • 6A und 6B sind schematische Ansichten, die abgehende Daten aus einem TCP mittels einer Transportmodus-ESP-Verarbeitung für IPv4 und IPv6 zeigen;
  • 6C und 6D sind schematische Ansichten, die abgehende Daten aus dem TCP über eine Tunnelmodus-ESP-Verarbeitung für IPv4 und IPv6 zeigen;
  • 6E ist eine schematische Ansicht, in der ein beispielhafter ESP-Kopfbereich, ein ESP-Anhang, Authentifizierungsdaten und geschützte Daten gezeigt sind;
  • 7A und 7B sind schematische Ansichten, die beispielhafte TCP-Blockformate für IPv4 und IPv6 zeigen;
  • 8A und 8B sind Tabellen, die Blockfelder zeigen, die durch die abgehende ESP- und AH-Verarbeitung in dem Netzwerkschnittstellensystem aus 2 modifiziert sind;
  • 8C und 8D sind schematische Ansichten, die Pseudokopfbereichprüfsummenberechnungen für IPv4 und IPv6 in dem Netzwerkschnittstellensystem aus 3 zeigen;
  • 9 ist eine schematische Ansicht, die eine Sicherheitsverarbeitung abgehender Daten in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 10 ist eine schematische Ansicht, die eine Sicherheitsverarbeitung eintreffender Netzwerkdaten in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 11A ist eine schematische Ansicht, die einen beispielhaften Sicherheitszuordnungstabellenschreibzugriff in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 11B ist eine schematische Ansicht, die ein beispielhaftes SA-Adressenregisterformat in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 11C ist eine schematische Ansicht, die ein beispielhaftes SPI-Tabelleneintragsformat in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 11D ist eine schematische Ansicht, die ein beispielhaftes SA-Speichereintragsformat in dem Netzwerkschnittstellensystem aus 3 zeigt;
  • 12 ist eine schematische Ansicht, die weitere Details einer Schicht-4-Prüfsummenberechnung für einen abgehenden Sendeblock in dem Netzwerkschnittstellensystem aus 3 zeigt; und
  • 13A und 13B sind Flussdiagramme, die eine Schicht 4-Prüfsummenbildung in dem Netzwerkschnittstellensystem aus 3 gemäß einem weiteren Aspekt der vorliegenden Erfindung zeigen.
  • ART BZW. ARTEN ZUM AUSFÜHREN DER ERFINDUNG
  • Es werden nunmehr eine oder mehrere Ausführungsformen der vorliegenden Erfindung mit Bezug zu den Zeichnungen beschrieben, wobei durchwegs gleiche Bezugszahlen verwendet werden, um gleiche Elemente zu bezeichnen.
  • 1A zeigt ein beispielhaftes Netzwerkschnittstellensystem 2 zur Verbindung eines Host-Systems 6 mit einem Netzwerk 8, wobei das Netzwerkschnittstellensystem 2 ausgebildet ist, abgehende bzw. auszugebende Daten des Host-Systems 6 dem Netzwerk 8 zuzuführen und eintreffende Daten aus dem Netzwerk 8 an das Host-System 6 zuzuführen. Das Netzwerkschnittstellensystem 2 umfasst ein Bus-Schnittstellensystem 4, das funktionsmäßig mit dem Host-System 6 verbunden ist, etwa über einen Bus in dem Host-System, wobei das Bus-Schnittstellensystem 4 ausgebildet ist, einen Datenaustausch zwischen dem Netzwerkschnittstellensystem 2 und dem Host-System 6 zu ermöglichen. Ein Mediumzugriffssteuerungs-(MAC)-System 10 in der Netzwerkschnittstelle 2 ist funktionsmäßig mit dem Netzwerk 8, etwa über einen mit einem Medium-unabhängigen Schnittstelle (beispielsweise MII, GMII, etc.) kompatiblen Sender/Empfänger (nicht gezeigt) verbunden, wobei das MAC-System 10 ausgebildet ist, Daten zwischen dem Netzwerkschnittstellensystem 2 und dem Netzwerk 8 auszutauschen. Das Bus-Schnittstellensystem 4 und das MAC-System 10 sind unter Anwendung beliebiger elektrischer Schaltungen oder Komponenten aufgebaut, die konfiguriert oder konfigurierbar sind, um Daten mit dem Netzwerkschnittstellensystem 2 auszutauschen. Insbesondere können die Systeme 4 und 10 eine beliebige Kombination aus Hardware, etwa Logikeinrichtungen, analogen Schaltungen, elektronischen Verbindungen, etc., aufweisen, die programmierbar oder konfigurierbar sind mittels Software und/oder Firmware in dem Schnittstellensystem 2.
  • Die Netzwerkschnittstelle 2 umfasst ferner ein Speichersystem 12, das mit dem Bus-Schnittstellensystem 4 und dem MAC-System 10 verbunden ist, und umfasst ein Sicherheitssystem 14, das mit dem Speichersystem 12 verbunden ist. Das Speichersystem 12 speichert eintreffende und abgehende Daten, die zwischen dem Netzwerk 8 und dem Host-System 6 ausgetauscht werden. Das Speichersystem 12 umfasst einen ersten und einen zweiten Speicher ”Speicher A” 16 und ”Speicher B” 18. Der erste Speicher 16 ist mit dem Bus-Schnittstellensystem 4 und dem Sicherheitssystem 14 zur Speicherung abgehender Daten vor der Sicherheitsverarbeitung und zur Speicherung eintreffender Daten nach der Sicherheitsverarbeitung verbunden. Der zweite Speicher 18 ist mit dem MAC-System 10 und dem Sicherheitssystem 14 zur Speicherung eintreffender Daten vor der Sicherheitsverarbeitung und zur Speicherung abgehender Daten nach der Sicherheitsverarbeitung verbunden. Das Speichersystem 12 und der erste und der zweite Speicher 16 und 18 davon können in beliebiger Form einer Speicherschaltung als flüchtige oder nicht-flüchtige Speicher vorgesehen sein, wozu, ohne einschränkend zu sein, eine Speicherschaltung mit wahlfreiem Zugriff (RAM) gehört, die als ”zuerst hinein, zuerst heraus-”(FIFO)-Speicher mit geeigneter Steuerschaltung ausgebildet ist. Obwohl das Speichersystem 12 als erster und zweiter Speicher 16 und 18 gezeigt ist, können separate Speicher oder ein einheitliches Speichersystem, das in den ersten und in den zweiten Speicherbereich 16 bzw. 18 unterteilt ist, vorgesehen sein. Ferner können ein oder beide Speicher 16 und 18 separate Speicherschaltungen zur Handhabung eintreffender und abgehender Daten aufweisen, oder diese können alternativ einzelne Speicherschaltungen sein, die zur Speicherung eintreffender und abgehender Daten und für Steuerungsinformationen (beispielsweise statisch oder dynamisch) partitioniert sind.
  • Das Sicherheitssystem 14 ist ausgebildet oder konfigurierbar, um selektiv Sicherheitsverarbeitung für eintreffende und/oder abgehende Daten in dem Netzwerkschnittstellensystem 2 auszuführen. Das Sicherheitssystem 14 kann unter Anwendung geeigneter elektronischer Einrichtungen, etwa analoger Schaltungen und Logikschaltungen, aufgebaut werden, die ausgebildet sind oder konfigurierbar sind, um eine Sicherheitsverarbeitung für eintreffende und/oder abgehende Daten in dem Schnittstellensystem 2 auszuführen. In einer Ausführungsform ist das Sicherheitssystem 14 ein IPsec-System, das ausgebildet ist, in selektiver Weise eine Authentifizierung, eine Verschlüsselung und eine Entschlüsselung für eintreffende und abgehende Daten bereitzustellen, wie dies nachfolgend dargestellt und beschrieben ist. Jedoch liegen auch andere Formen von Sicherheitssystem und andere Arten von Sicherheitsverarbeitung innerhalb des Schutzbereichs der Erfindung.
  • Die Systeme 4, 10, 12 und 14 in dem Netzwerkschnittstellensystem 2 können optional mittels Software und/oder Firmware konfigurierbar oder programmierbar sein. Beispielsweise kann eines, einige oder alle Systeme 4, 10, 12 und 14 des Netzwerkschnittstelle 2 durch Software in dem Host-System 6 und/oder über Firmware, etwa ein codiertes EEPROM in dem System 2 oder ein externes EEPROM oder eine andere Speichereinrichtung außerhalb des Systems 2 über eine EEPROM-Schnittstelle, konfiguriert sein.
  • Die diversen Systems 4, 10, 12 und 14 können selektiv gemäß einer Steuerungsinformation oder einer anderen Art der Information, die von dem Host-System 6 erhalten wird, betrieben werden, wobei derartige Informationen mit einem oder mehreren Datenbereichen verknüpft sind, die verarbeitet werden und/oder zwischen dem Host-System 6 und dem Netzwerk 8 ausgetauscht werden. Beispielsweise kann das Netzwerkschnittstellensystem 2 Steuerfunktionen von dem Host-System 6 erhalten, die mit einem abgehenden Datenblock verknüpft ist, der an das Netzwerk 8 zu senden ist. Des Weiteren können die Systeme 4, 10, 12 und 14 Steuerungs-, Status- oder andere Arten an Informationen für das Host-System 6 bereitstellen.
  • Das Sicherheitssystem 14 umfasst einen Empfangs-IPsec-Prozessor 22, eine Sende-/IPsec-Eingangsdatenflusssteuerung 28, zwei Sende-/IPsec-Prozessoren 20 und 21 mit entsprechenden Eingangspuffern 26 und 27 und Ausgangspuffern 24 und 25, und eine Sende-/IPsec-Ausgangsdatenflusssteuerung 30. Die Eingangsdatenflusssteuerung 28 liest Daten aus dem Speicher 16 aus und sendet Datenpakete abwechselnd zu den Eingangspuffern 26 und 27. Die Sende-/IPsec-Prozessoren 20 und 21, die im Wesentlichen parallel arbeiten, lesen Daten von ihren entsprechenden Eingangspuffern 26 und 27 aus, führen eine Sicherheitsverarbeitung an den Daten aus und schreiben die verarbeiteten Daten in ihre entsprechenden Ausgangspuffer 24 und 25. Die Ausgangsflusssteuerung 30 liest die verarbeiteten Daten abwechselnd aus den Ausgangspuffern 24 und 25 aus und schreibt die verarbeiteten Daten in den Speicher 18, wobei die Pakete in der gleichen Reihenfolge vorliegen, in der sie aus dem Speicher 16 ausgelesen wurden.
  • Die zwei Sende-/IPsec-Prozessoren sind an dem einzelnen Empfangs-IPsec-Prozessor in dem beispielhaften Netzwerkschnittstellensystem 2 angepasst, da, wenn Daten verschlüsselt werden, konventionell eine Authentifizierung an den verschlüsselten Daten ausgeführt wird. Beim Empfang ermöglicht dies, dass die Entschlüsselung und die Authentifizierung parallel ausgeführt werden. Beim Senden müssen jedoch die verschlüsselten Daten vor dem Beginn der Authentifizierung verfügbar sein. Konventionelle Authentifizierungs- und Verschlüsselungsalgorithmen, etwa die unten angegebenen Beispiele, sind rekursiv. Aufgrund der rekursiven Natur besteht ein zusätzlicher Aufwand, der jeweils mit Authentifizierung und der Verschlüsselung für jedes Datenpaket verknüpft ist, der zu dem zusätzlichen Aufwand der pro-Byte-Verarbeitungszeit hinzukommt. Der Aufwand für die Verschlüsselung und die Authentifizierung sind auf der Sendeseite additiv, selbst wenn die Authentifizierungs- und Verschlüsselungsoperationen in Pipeline-Verarbeitung bzw. überlappend ausgeführt werden. Dieser zusätzliche Verarbeitungsaufwand erhöht deutlich die Verarbeitungszeit insbesondere für kleine Datenpakete. Die vorliegende Erfindung verringert die IPsec-Verarbeitungszeit auf der Senderseite durch die Verwendung zweier oder mehrerer Sende-IPsec-Prozessoren, die parallel arbeiten, und bietet damit eine bessere Anpassung an die Verarbeitungsgeschwindigkeit auf der Empfängerseite.
  • 1B ist eine schematische Darstellung eines beispielhaften Sende-IPsec-Prozessors 50. Der beispielhafte IPsec-Prozessor 50 umfasst ein Sendersicherheitsverarbeitungssteuermodul 54, eine ESP-Authentifizierungsmaschine 56, eine AH-Authentifizierungsmaschine 58 und eine ESP-Verschlüsselungsmaschine 60. Das Sendersicherheitsverarbeitungssteuermodul 54 leitet selektiv Datenpakete von einem Eingangspuffer 52 über keine, eine oder mehrere der folgenden Komponenten weiter: die ESP-Authentifizierungsmaschine 56, die AH-Authentifizierungsmaschine 58 und die ESP-Verschlüsselungsmaschine 60. Wenn eine Verschlüsselung und eine Authentifizierung erforderlich sind, wird der Ausgang der ESP-Verschlüsselungsmaschine zu einer oder mehreren der Authentifizierungsmaschinen weitergeleitet. Der beispielhafte IPsec-Prozessor 50 kann sowohl eine ESP- als auch eine AH-Authentifizierung an einem Paket ausführen und wenn beide auszuführen sind, werden beide Operationen parallel durchgeführt. Sobald die Verarbeitung abgeschlossen ist, werden die verarbeiteten Daten in einem Ausgangspuffer 62 angeordnet.
  • Ein Verarbeitungsmechanismus bzw. eine Maschine umfasst eine zugeordnete Hardware für jede ihrer Funktionen. Ferner umfasst eine Maschine mehrere Stufen in einer Reihe angeordnet, wobei jede davon Daten mit der gleichen Rate verarbeitet. Eine Sequenz aus Daten, die einer Maschine zugeleitet wird, läuft durch die Reihe aus Stufen vom Anfang der Maschine bis zu ihrem Ende, und somit kann in gewissem Sinne diese Maschine als eine Pipeline betrachtet werden. Die in Reihe geschalteten Stufen sind möglicherweise alle gleichzeitig in Funktion, wobei separate Datenblöcke verarbeitet werden. Pipelines liefern eine wesentlich schnellere Datenverarbeitung im Vergleich zur Verwendung eines zentralen Prozessors.
  • Die Eingangspuffer 26 und 27 und die Ausgangspuffer 24 und 25 aus 1A können von beliebiger Größe und Konfiguration sein. Beispielsweise können die Puffer ungefähr 32 Bytes bis ungefähr 1024 Bytes aufweisen, wobei 256 Bytes eine bevorzugte Große sind. Diese können zwei separate Speicher sein oder ein einzelner unterteilter Speicher. Vorzugsweise besitzen die Puffer eine ausreichende Große, wodurch die Sende-IPsec-Prozessoren 20 und 21 beide in kontinuierlichem Betrieb bleiben, wenn das Netzwerkschnittstellensystem 12 eine Serie kurzer Datenpakete sendet, für die der zusätzliche Aufwand in der IPsec-Verarbeitung wesentlich ist.
  • Die Eingangsdatenflusssteuerung 28 liest Datenpakete für die Sendung aus dem Speicher 16 aus und leitet die Pakete abwechseln zu den Eingangspuffern 26 und 27 der beiden IPsec-Prozessoren 20 und 21 weiter. 1C ist ein Flussdiagramm, das eine beispielhafte Betriebsprozedur 70 für die Eingangsdatenflusssteuerung 28 zeigt. Die Flusssteuerung 28 wechselt zwischen den Eingangspuffern 26 und 27 hin und her, wodurch zu einer gegebenen Zeit lediglich einer der ”aktuelle” Puffer ist. Beginnend im Block 71 prüft die Flusssteuerung 28 im Hinblick darauf, ob Daten in den Speicher 16 zu senden sind. Wenn keine Daten vorhanden sind, wartet die Steuerung 28 im Block 72 und prüft dann erneut. Alternativ kann ein weiterer Prozessor oder eine Schaltung der Steuerung 28 anzeigen, wenn Daten für das Senden verfügbar sind.
  • Wenn große Datenpakete übertragen werden, ist es möglich, dass ein Eingangspuffer voll wird. Daher überprüft die Steuerung 28 im Block 73, ob in dem aktuellen Puffer Platz ist, bevor ein Block aus Daten aus dem 16 Speicher im Block 75 ausgelesen wird und Daten in den aktuellen Puffer im Block 76 geschrieben werden. Wenn der Eingangspuffer voll ist, wartet die Steuerung 28 im Block 74, bevor erneut im Hinblick auf verfügbaren Platz im Block 73 geprüft wird. Nach dem Schreiben der Daten in den aktuellen Puffer im Block 76 prüft die Steuerung 28 im Block 77, ob das Ende des Pakets erreicht ist. Wenn das Ende des Pakets erreicht ist, wird im Block 78 der aktuelle Puffer umgeschaltet und die Steuerung 28 geht zum Block 71 weiter, in welchem nach dem nächsten Datenpaket gesucht wird. Wenn nicht, geht die Steuerung zum Block 73 zurück und bereitet sich auf das Auslesen eines weiteren Blocks aus Daten aus dem Speicher 16 vor. Die beispielhafte Betriebsprozedur 70 bewirkt, dass ein gesamtes Paket zu dem aktuellen Puffer gesendet wird, bevor auf den anderen Puffer umgeschaltet wird.
  • Die Ausgangsdatenflusssteuerung 30 liest verarbeitete Daten aus den Ausgangspuffern 24 und 25 aus und schreibt die verarbeiteten Daten in den Speicher 18. 1D ist ein Flussdiagramm, das eine beispielhafte Betriebsprozedur 80 für die Ausgangsdatenflusssteuerung 30 zeigt. Die Flusssteuerung 30 schaltet zwischen den Ausgangspuffern 24 und 25 hin und her, wodurch zu einer gegebenen Zeit lediglich einer der Puffer der ”aktuelle” Puffer ist.
  • Die Ausgangsflusssteuerung 30 kann schneller als die Sende-IPsec-Prozessoren 24 und 25 arbeiten, und daher beginnt die Ausgangsflusssteuerung 30 damit, im Block 81 nach Daten in dem aktuellen Ausgangspuffer zu suchen. Wenn Daten vorhanden sind, liest die Steuerung 30 einen Block aus Daten aus dem aktuellen Ausgangspuffer im Block 83 aus und schreibt im Block 84 die Daten in den Speicher 18. Die Steuerung 30 prüft dann im Block 85, ob das Ende des Pakets erreicht ist. Wenn das Ende des Pakets erreicht ist, schaltet die Steuerung 30 im Block 86 den aktuellen Ausgangspuffer um und bereitet sich zum Auslesen weiterer Daten im Block 81 vor. Wenn dies nicht der Fall ist, liest die Steuerung 30 weiterhin Daten aus dem aktuellen Ausgangspuffer im Block 81 aus. Die Betriebsprozedur 80 bewirkt, dass ein gesamtes Paket von einem einzelnen Ausgangspuffer ausgelesen und in den Speicher 18 geschrieben wird, bevor das nächste Paket aus dem anderen Ausgangspuffer ausgelesen wird.
  • Die Erfindung ermöglicht damit, eine effiziente Übertragung und Verarbeitung eintreffender und abgehender Daten zwischen dem Netzwerk 8 und dem Host-System 6 mittels der Auslagerung der Sicherheitsverarbeitung. Ferner beschleunigt das Vorsehen zweier Sende-IPsec-Prozessoren die IPsec-Verarbeitung. Ein struktureller/funktioneller Überblick und ein Überblick über das Arbeitsverhalten einer beispielhaften Netzwerksteuerung gemäß der vorliegenden Erfindung wird nachfolgend in Verbindung mit den 2–4 angegeben, um damit ein gründliches Verständnis der vorliegenden Erfindung zu ermöglichen. Gemäß einem beispielhaften Aspekt der Erfindung ermöglichen die obenstehenden Merkmale vor teilhafterweise den Betrieb der Netzwerkschnittstellenfunktion mit einer Sicherheitserarbeitung bei einer Übertragungsrate im Gigabit-Bereich.
  • 2 zeigt eine Netzwerkschnittstellenperipherie- oder Netzwerksteuerung 102 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung, und 3 und 4 zeigen eine beispielhafte Einzelchip-Implementierung 102a der Netzwerksteuerung 102. Die beispielhafte Einzelchip-Netzwerksteuerung 102a umfasst die gesamten Funktionen und Komponenten, wie sie hierin in Bezug auf das Netzwerkschnittstellensystem 102 beschrieben sind. Die diversen Blöcke, Systeme, Module, Maschinen, etc., die hierin beschrieben sind, können unter Anwendung geeigneter analoger und/oder dititaler Schaltungen eingerichtet werden, wobei ein oder mehrere der Blöcke etc., die hierin beschrieben sind, mit anderen Schaltungen, können erfindungsgemäß kombiniert werden.
  • Die Netzwerksteuerung 102 umfasst eine 64-Bit-PCI-X-Bus-Schnittstelle 104 zur Verbindung mit einem Host-PCI- oder PCI-X-Bus 106, der bei einer Taktgeschwindigkeit bis zu 133 MHz in dem PCI-X-Modus oder bis zu 66 MHz in dem Standard-PCI-Modus arbeitet. Die Netzwerksteuerung 102 kann als eine übergeordnete Einrichtung für den Bus bzw. als ein Master oder eine untergeordnete Einrichtung für den Bus bzw. als ein Slave betrieben werden. Ein wesentlicher Teil der Initialisierung kann automatisch von der Netzwerksteuerung 102 ausgeführt werden, wenn diese ein optionales EEPROM (nicht gezeigt) beispielsweise über eine EEPROM-Schnittstelle 114 (3) ausliest. Die Netzwerksteuerung 102 kann mit einem IEEE 802.3 oder einem speziell gestalteten Netzwerk 108 über eine mit dem IEEE 802.3 kompatiblen Netzwerk-unabhängigen Schnittstelle (MII) oder einer Gigabit-Medium-unabhängigen Schnittstelle (GMII) 110 verbunden sein, um eine Verbindung mit der Steuerung 102 mit dem Netzwerk 108 über eine externe Sender-/Empfängereinrichtung 111 herzustellen. Für einen Betrieb bei 1000 Mb/s unterstützt die Steuerung 102 die Byte-Breite IEEE 802.3 Gigabit-Medium-unabhängige Schnittstelle (GMII) für 1000BASE-T-PHY-Einrichtungen 111 oder die IEEE 802.3 Zehn-Bit-Schnittstelle (TBI) für 1000BASE-X-Einrichtungen 111. Die Netzwerksteuerung 102 unterstützt sowohl Halb-Duplex-, als auch Voll-Duplex-Betrieb bei 10 und 100 Mb/s-Raten und einen Voll-Duplex-Betrieb bei 1000 Mb/s.
  • Eine Host-Einrichtung, etwa ein Host-Prozessor 112, auf dem Host-PCI-X-Bus 106 in einem Host-System 180 kann als Schnittstelle für die Netzwerksteuerung 102 über den Bus 106 und eine Host-Brücke 117 dienen. Der Host-Prozessor 112 umfasst einen oder mehrere Prozessoren, die in einer koordinierten Weise arbeiten. Es sei auch auf 4 verwiesen; die Einzel-Chip-Netzwerksteuerung 102a kann ein einer Netzwerkschnittstellenkarte oder Schaltungsplatine 182 zusammen mit einem PHY-Sender/Empfänger 111 zur Verbindung des Host-Prozessors 112 mit dem Netzwerk 108 über die Host-Brücke 117, den Host-Bus 106 und den Sender/Empfänger 111 vorgesehen sein. Die PCI-X-Bus-Schnittstelle 104 umfasst PCI-Konfigurationsregister, die zur Identifizierung der Netzwerksteuerung 102a für andere Einrichtungen auf dem PCI-Bus und zur Konfigurierung der Einrichtung dienen. Wenn die Initialisierung abgeschlossen ist, hat der Host-Prozessor 112 einen direkten Zugriff auf die I/O-Register der Netzwerksteuerung 102 für die Einstellung des Leistungsverhaltens, die Auswahl von Optionen, das Sammeln von statistischen Daten und das Beginnen von Übertragungen über die Host-Brücke 117 und den Bus 106. Der Host-Prozessor 112 ist funktionsmäßig mit dem Host-Systemspeicher 128 und einem Cache- bzw. schnellen Zwischenspeicher 115 über eine Speicher-/Cash-Steuerung 113 verbunden. Es können ein oder mehrere Anwendungs-Softwareprogramme 184, die in dem Host-Prozessor 112 ausgeführt werden, mit einem Netzwerkdienst über die Schicht 4-(beispielsweise Transportschicht-)Software versehen sein, etwa einer Sendesteuerprotokoll-(TCP)-Schichtsoftware 186, der Schicht 3-(beispielsweise Netzwerkschicht)Software 188, etwa eine Internetprotokoll-(IP)-Software 188 und einen Software-Netzwerktreiber 190, der ebenfalls auf dem Host-Prozessor 112 abgearbeitet wird. Wie nachfolgend erläutert ist, interagiert die Netzwerktreibersoftware 190 mit dem Host-Speicher 128 und der Netzwerksteuerung 102, um den Datentransfer zwischen der Anwendersoftware 184 und dem Netzwerk 108 zu ermöglichen.
  • Wie in 2 gezeigt ist, umfasst die beispielhafte Netzwerksteuerung 102 einen ersten und einen zweiten internen Speicher ”Speicher A” 116 und ”Speicher B” 118 mit wahlfreiem Zugriff, die als ”zuerst hinein, zuerst heraus” (FIFO)-Speicher zur Speicherung von Datenblöcken organisiert sind. Eine Speichersteuerungseinheit 120 ist für die Steuerung und den Betrieb der Speicher 116 und 118 vorgesehen. Die Netzwerksteuerung 102 umfasst ferner eine Medienzugriffssteuer-(MAC)-Maschine 122, die die Anforderungen für den Betrieb als ein Ethemet/IEEE802.3 kompatibler Knoten erfüllt und die Schnittstelle zwischen dem Speicher 118 und der GMII 110 bereitstellt. Die MAC-Maschine 122 kann im Voll-Duplexmodus oder Halb-Duplexmodus betrieben werden. Eine Internetprotokollsicherheits(IPsec)-Maschine 124, die mit den Speichern 116 und 118 verbunden ist, stellt die Authentifizierungs- und/oder Verschlüsselungsfunktionen bereit.
  • Die PCI-X-Bus-Schnittstelle 104 umfasst eine Steuerung für direkten Speicherzugriff (DMA) 126, die automatisch Netzwerkdaten zwischen der Netzwerksteuerung 102 und den Puffer in dem Host-Systemspeicher 128 über den Host-Bus 106 überträgt. Der Betrieb der DMA-Steuerung 126 wird von einer Deskriptorverwaltungseinheit 130 gemäß den Datenstrukturen, die als Deskriptoren 192 bezeichnet sind, gesteuert, die Zeiger zu einem oder mehreren Datenpuffern 194 in den Systemspeicher 128 sowie Steuerinformationen enthalten. Die Deskriptoren 192 sind in dem Host-Systemspeicher 128 in Reihenfolgen oder Warteschlangen gespeichert, die als Deskriptorringe bezeichnet werden. Vier Senderdeskriptorringe sind für das Senden von Blöcken vorgesehen, und vier Empfangsdeskriptorringe sind für das Empfangen von Blöcken vorgesehen, was den vier Prioritäten des Netzwerk-Datenverkehrs in der dargestellten Steuerung 102 entspricht. Ferner sind vier Empfangsstatusringe vorgesehen, d. h. einer für jede Prioritätsebene, die die Synchronisierung zwischen der Netzwerksteuerung 102 und dem Host-System ermöglichen. Sendedeskriptoren 192 steuern den Transfer von Blockdaten von dem Systemspeicher 128 zu der Steuerung 102 und die Empfangsdeskriptoren 192 steuern das Übertragen der Blockdaten in der anderen Richtung. In der beispielhaften Steuerung 102 entspricht jeder Sendedeskriptor 192 einem Netzwerkblock, wohingegen jeder Empfangsdeskriptor 192 einem oder mehreren Host-Speicherpuffern entspricht, in welchem Blöcke, die aus dem Netzwerk 108 empfangen werden, gespeichert werden können.
  • Die Softwareschnittstelle reserviert zusammenhängende Speicherblöcke für die Deskriptoren 192, für den Empfängerstatus und die Datenpuffer 194. Diese Speicherblöcke werden von der Software (beispielsweise dem Netzwerktreiber 190) und der Netzwerksteuerung 102 während normaler Netzwerkoperationen gemeinsam benutzt. Der Deskriptorraum enthält Zeiger zu Netzwerk-Blockdaten in den Puffer 194, der Empfängerstatusraum enthält Informationen, die von der Steuerung 102 zu der Software in dem Host 112 weitergeleitet wird, und die Datenpufferbereiche 194 dienen zum Speichern von Blockdaten, die zu senden sind (beispielsweise abgehende Daten) und für Blockdaten, die empfangen wurden (beispielsweise eintreffende Daten).
  • Die Synchronisierung zwischen der Steuerung 102 und dem Host-Prozessor 112 wird durch die Zeiger gewahrt, die in Hardwareregistern 132 in der Steuerung 102 gespeichert sind, durch Zeiger, die in einem Steuerungsstatusblock (CSB) 196 in dem Host-Systemspeicher 128 gespeichert sind, und durch Interrupts. Der CSB 196 ist ein Block des Host-Systemspeichers 128, der Zeiger zu dem Deskriptor und zu Statusringen enthält und eine Kopie des Inhalts des Interruptregisters der Steuerung enthält. Der CSB 196 wird von der Netz Werksteuerung 102 beschrieben und von dem Host-Prozessor 112 ausgelesen. Jedesmal, wenn der Softwaretreiber 190 in den Host 112 einen Deskriptor oder einen Satz aus Deskriptoren 192 in einen Deskriptorring schreibt, schreibt er auch in ein Deskriptorschreibzeigerregister in der Steuerung 102. Das Speichern in dieses Register bewirkt, dass die Steuerung 102 den Sendeprozess beginnt, wenn eine Sendung nicht bereits im Gange ist. Sobald die Steuerung die Verarbeitung eines Senderdeskriptors 192 beendet hat, schreibt diese die Information in den CSB 196. Nach dem Empfangen von Netzwerkblöcken und dem Speichern dieser Blöcke in den Empfangspuffern 194 in dem Host-Systemspeicher 128, schreibt die Steuerung 102 in den Empfangsstatusring und in einen Schreibzeiger, die die Treibersoftware 190 verwendet, um zu bestimmen, welche Empfangspuffer 194 gefüllt sind. Fehler in empfangenen Blöcken werden an den Host-Speicher 128 über einen Statusgenerator 134 berichtet.
  • Das IPsec-Modul oder die Maschine 124 liefert eine standardmäßige Authentifizierung, Verschlüsselung und Entschlüsselung für gesendete und empfangene Blöcke. Für die Authentifizierung implementiert das IPsec-Modul 124 den HMAC-MD5-96-Algorithmus, der in RFC 2403 definiert ist (eine Spezifizierung, die von der Internet Engineering Task Force festgelegt ist), und den HMAC-SHA-1-96-Algorithmus, der in RFC 2404 definiert ist. Für die Verschlüsselung implementiert das Modul den ESP DES-CBC (RFC 2406), den 3DES-CBC und den AES-CBC-Verschlüsselungsalgorithmus. Für gesendete Blöcke wendet die Steuerung 102 die IPsec-Authentifizierung und/oder Verschlüsselung an, wie dies durch Sicherheitsassoziationen bzw. Verknüpfungen (SA) spezifiziert ist, die in dem privaten lokalen SA-Speicher 140 abgelegt sind, auf die von dem IPsec-System 124 über eine SA-Speicherschnittstelle 142 zugegriffen wird. SA werden von dem Host-Prozessor 112 verhandelt und festgelegt. Zu SAs gehören IPsec-Schlüssel, die für die diversen Authentifizierungs-, Verschlüsselungs- und Entschlüsselungsalgorithmen erforderlich sind. IPsec-Schlüsselaustauschprozesse werden von dem Host-Prozessor 112 ausgeführt. Der Host 112 verhandelt SAs mit entfernten Stationen und schreibt SA-Daten in den SA-Speicher 140. Der Host 112 bewahrt ferner eine IPsec-Sicherheits-Politik-Datenbank (SPD) in dem Host-Systemspeicher 128.
  • Ein Empfangs-(RX)-Analysierer 144, der mit der MAC-Maschine 122 verknüpft ist, untersucht die Kopfbereiche empfangener Blöcke, um zu bestimmen, welche Verarbeitung auszuführen ist. Wenn ein IPsec-Kopfbereich vorgefunden wird, wird die in dem Kopfbereich enthaltene Information verwendet, einschließlich eines Sicherheits-Parameter-Index (SPI), einer IPsec-Protokollart und einer IP-Ziel-Adresse, um den SA-Speicher 140 unter Anwendung einer SA-Suchlogik 146 abzusuchen und die anwendbare Sicherheitszuordnung abzurufen. Das Ergebnis wird in einen SA-Zeiger-FIFO-Speicher 148 geschrieben, der mit der Suchlogik 146 über die SA-Speicherschnittstelle 142 verbunden ist. Der der SA entsprechende Schlüssel wird abgerufen und in dem RX-Schlüssel-FIFO 152 gespeichert. Ein Empfangs-(RX)-IPsec-Prozessor 150 führt die durch die anwendbare SA geforderte Verarbeitung unter Anwendung des Schlüssels aus. Die Steuerung 102 berichtet, welche Sicherheitsverarbeitung ausgeführt wurde, so dass der Host 112 die SPD überprüfen kann, um damit zu verifizieren, dass der Block mit der entsprechenden „Politik” bzw. Strategie übereinstimmt. Der verarbeitete Block wird in dem Speicher 116 gespeichert.
  • Ein Empfangs-IPsec-Analysierer 154, der mit dem IPsec-Prozessor 150 verknüpft ist, führt eine Analyse aus, die nicht vor der Paketentschlüsselung ausgeführt werden kann. Ein Teil dieser Information wird von einem Empfangs-(Rx)-Prüfsummen- und Einfügeprüfsystem 156 verwendet, das Prüfsummen berechnet, die von den Kopfbereichen spezifiziert sind, die verschlüsselt worden sein können, und prüft auch die Einfügebits, die verschlüsselt wurden, um zu verifizieren, dass diese einer zuvor spezifizierten Sequenz für die Einfügebits entsprechen. Diese Funktionen werden ausgeführt, während der empfangene Block an den PCI-X-Bus 104 über den FIFO 158 weitergeleitet wird. Die Prüfsumme und die Einfügeprüfergebnisse werden an den Statusgenerator 134 berichtet.
  • In dem Sendeweg wird ein Zusammenfüge-RAM 160 vorgesehen, um Blockdaten von dem Systemspeicher 128 aufzunehmen und die Daten an den Speicher 116 weiterzugeben. Der Inhalt eines Sendeblocks kann auf viele Datenpuffer 194 in dem Host-Speicher 128 verteilt werden, wobei das Abrufen eines Blockes mehrere Anforderungen an den Systemspeicher 128 durch die Deskriptorverwaltungseinheit 130 beinhalten kann. Diese Anforderungen werden nicht immer in der gleichen Reihenfolge abgearbeitet, in der sie ausgegeben werden. Der Zusammenfüge-RAM 160 stellt sicher, dass die empfangenen Teile der Daten in geeigneten Stellen in dem Speicher 116 vorgesehen werden. Für gesendete Blöcke prüft der Host 112 die SPD (IPsec-Sicherheits-Politik-Datenbank), um zu bestimmen, ob die Sicherheitsverarbeitung benötigt wird, und gibt diese Information an die Steuerung 102 in dem Deskriptor 192 des Blocks in Form eines Zeigers zu der geeigneten SA in dem SA-Speicher 140 weiter. Die Blockdaten in dem Host-Systemspeicher 128 stellen Platz in den IPsec-Kopfbereichen und den Anhängen für Authentifizierungsdaten bereit, die die Steuerung 102 erzeugt. In ähnlicher Weise wird Platz für das Einfügen (um die Nutzdaten zu einer ganzzahligen Anzahl an Blöcken zu machen) vorgesehen, wenn der Block in den Host-Systemspeicherpuffern 194 gespeichert wird, wobei die Einfügebits aber von der Steuerung 102 geschrieben werden.
  • Wenn die Daten aus dem Zusammenfüge-RAM 160 heraus gesendet werden, werden diese auch in einen ersten Sende-(TX)-Analysator 162 weitergeleitet, der den MAC-Kopfbereich, den IP-Kopfbereich (falls vorhanden), den TCP- oder UDP-Kopfbereich ausliest und bestimmt, welche Art von Block vorliegt, und nach Steuerbits in dem zugeordneten Deskriptor sucht. Des Weiteren werden die Daten aus dem Zusammenfüge-RAM 160 einem Sendeprüfsummensystem 164 zum Berechnen des IP-Kopfbereichs und/oder der TCP-Prüfsummen zugeführt, deren Werte dann an geeigneten Stellen in den Speicher 116 eingefügt werden. Die Deskriptorverwaltungseinheit 130 sendet eine Anforderung an die SA-Speicherschnittstelle 142, einen SA-Schlüssel abzurufen, der dann einem Schlüssel-FIFO 172 zugeführt wird, der ein Paar aus TX-IPsec-Prozessoren 174a und 174b speist. Blöcke werden selektiv von einem der zwei TX-IPsec-Prozessoren 174a und 174b für die Verschlüsselung und Authentifizierung über TX-IPsec-FIFOs 176a bzw. 176b bereitgestellt, wobei ein Sende-IPsec-Analysator 170 selektiv Blockdaten aus dem Speicher 116 zu einem ausgewählten Prozessor der Prozessoren 174 zuführt. Die beiden Sende-IPsec-Prozessoren 174 werden parallel vorgesehen, da die Authentifizierungsverarbeitung nicht beginnen kann, bevor die Verschlüsselungsverarbeitung begonnen hat. Durch Verwenden der beiden Prozessoren 174 kann die Geschwindigkeit vergleichbar zur Senderseite sein, in der diese beiden Prozesse gleichzeitig ausgeführt werden können.
  • Die Authentifizierung deckt deakivierbare bzw. verdeckbare Felder ab, wie sie in IP-Kopfbereichen auftreten können. Der Sende-IPsec-Analysator 170 sucht daher nach deaktivierbaren Feldern in den Blockdaten und berichtet diese Felder an die Prozessoren 174a und 174b. Die Ausgabe der Prozessoren 174a und 174b wird dem zweiten Speicher 118 über FIFOs 178a bzw. 178b zugeführt. Ein Integritätsprüfwert (ICV), der sich aus der Authentifizierungsverarbeitung ergibt, wird in den geeigneten IPsec-Kopfbereich durch eine Einfügeeinheit 179 eingefügt, wenn die Blockdaten von dem Speicher 118 an die MAC-Maschine 122 zum Senden zu dem Netzwerk 108 weitergeleitet werden.
  • In der Einzelchip-Ausführung aus 3 umfasst die Steuerung 102a einen Netzwerkanschluss- bzw. Portverwalter 182, der automatisch mit einem externen physikalischen (PHY) Sender/Empfänger über Verwaltungsdatentakt-(MDC) und Verwaltungsdaten-I/O (MDIO) Signale verhandelt. Der Netzwerkportverwalter 182 kann auch die MAC-Maschine 122 initialisieren, so dass diese mit der verhandelten Konfiguration konsistent ist. Eine Leiterplattenschnittstelle für LED-Indikatoren ist mittels einer LED-Steuerung 171 vorgesehen, die LED-Ansteuersignale LED0'–LED3' für das Anzeigen diverser Netzwerkstatusinformationen erzeugt, etwa aktive Verbindung, Empfangs- oder Sendeaktivität auf dem Netzwerk, Netzwerk-Bit-Rate und Netzwerkkollisionen. Eine Taktsteuerlogik 173 empfängt ein freilaufendes 125 MHz Eingangstaktsignal als Zeitreferenz und stellt diverse Taktsignale für die interne Logik der Steuerung 102a bereit.
  • Eine Leistungsverwaltungseinheit 175, die mit der Deskriptorverwaltungseinheit 130 und der MAC-Maschine 122 verbunden ist, kann verwendet werden, um Energie zu sparen, wenn die Einrichtung nicht aktiv ist. Wenn ein Ereignis, das eine Änderung des Leistungspegels erfordert, erkannt wird, etwa eine Änderung in einer Verbindung über die MAC-Maschine 122, liefert die Leistungsverwaltungseinheit 175 ein Signal PME', das anzeigt, dass ein Leistungsverwaltungsereignis eingetreten ist. Die externe serielle EEPROM-Schnittstelle 114 implementiert eine standardmäßige EEPROM-Schnittstelle, beispielsweise das 93Cxx EEPROM-Schnittstellenprotokoll. Die Anschlüsse der externen seriellen EEPROM-Schnittstelle 114 enthalten einen EEPROM-Chipauswahl(EECS)-Anschluss, EEPROM-Dateneingangs- und Datenausgangs-(EEDI bzw. EEDO)-Anschlüsse und einen EEPROM-serieller Takt(EESK)-Anschluss.
  • In der Bus-Schnittstelleneinheit 104 werden Adressen und Daten auf den Bus-Schnittstellenanschlüssen AD[63:0] gebündelt. Ein Rücksetzeingang RST' kann gesetzt werden, um die Netzwerksteuerung 102a zu veranlassen, eine interne Systemrücksetzung auszuführen. Ein Zyklusblock-I/O-Signal FRAME' wird von der Netzwerksteuerung bereitgestellt, wenn diese der Bus-Master ist, um den Beginn und die Dauer einer Transaktion anzuzeigen, und es wird ein PCI-Takteingangssignal PCI_CLK verwendet, um die System-Bus-Schnittstelle über einen Frequenzbereich von 15 bis 133 MHz auf dem PCI-Bus anzusteuern (beispielsweise der Host-Bus 106). Die Netzwerksteuerung 102a unterstützt ferner duale Adressenzyklen (DAC) für Systeme mit 64-Bit-Adressierung, wobei niederwertige Adressenbits auf dem AD[31:0]-Bus während eines ersten Taktzyklus auftreten und höherwertige Bits auf dem AD[63:32]-Bus während des zweiten Taktzyklus auftreten. Ein REQ64'-Signal wird von der Einrichtung, die als ein Bus-Master dient, gesetzt, wenn diese einen 64-Bit-Datentransfer initiieren will, und das Ziel für den Datenübertrag setzt ein 64-Bit-Transfer-Bestätigungssignal ACK64', um anzuzeigen, dass diese bereit ist, Daten unter Anwendung von 64 Bits auszutauschen. Ein Paritätssignal PAR64 ist ein gerades 8-Byte-Paritätssignal, das den AD[63:32]-Bus schützt. Der Bus-Master steuert das Signal PAR64 für Adressen- und Schreibdatenphasen und das Ziel steuert das Signal PAR64 für Lesedatenphasen.
  • Die Netzwerksteuerung 102a setzt ein Bus-Anforderungssignal REQ', um anzuzeigen, dass sie Bus-Master werden will, und ein Bus-Gewährungseingangssignal GNT' zeigt an, dass der Zugriff auf den Bus für die Netzwerksteuerung gewährt ist. Ein Initialisierungsgeräteauswahleingangssignal IDSEL wird als eine Chipauswahl für die Netzwerksteuerung während der Konfigurationslese- und Schreibtransaktionen verwendet. Busbefehls- und Byte-Freigabesignale C/BE[7:0] werden verwendet, um Bus-Befehle zu übertragen und anzuzeigen, welche physikalischen Bytes von Datenleitungen AD[63:0] zu verwendende Daten übertragen. Ein Paritäts-I/O-Signal PAR zeigt an und verifiziert eine gerade Parität über AD[31:0] und C/BE[3:0].
  • Die Netzwerksteuerung gibt ein Ansteuerauswahl-I/O-Signal DEVSEL' aus, wenn sie eine Transaktion erkennt, die die Netzwerksteuerung 102a als ein Ziel auswählt. Die Netzwerksteuerung 102a prüft das Signal DEVSEL', um zu erkennen, ob ein Ziel eine Transaktion beansprucht, die die Netzwerksteuerung initiiert hat. Ein Signal TRDY' wird verwendet, um die Fähigkeit des Ziels der Transaktion anzuzeigen, die aktuelle Datenphase abzuschließen, und das Signal IRDY' zeigt die Fähigkeit des Initiators der Transaktion an, die aktuelle Datenphase abzuschließen. Ein Interrupt-Anforderungsausgangssignal INTA' gibt an, dass ein oder mehrere aktivierte Interrupt-Marken- bzw. Flaggen-Bits gesetzt sind. Die Netzwerksteuerung 102a setzt ein Paritätsfehler-I/O-Signal PERR', wenn sie einen Daten-Paritätsfehler erkennt, und setzt ein Systemfehlerausgangssignal SERR', wenn sie einen Adressenparitätsfehler erkennt. Des Weiteren setzt die Steuerung 102a ein Stop-I/O-Signal STOP', um den Bus-Master zu informieren, die aktuelle Transaktion zu beenden.
  • In der MAC-Maschine 122 wird ein physikalisches Schnittstellenrücksetzsignal PHY_RST verwendet, um die externe PHY 111 (MII, GMII, TBI) zurückzusetzen, ein PHY-Rücksprungausgangssignal PHY_LPBK wird verwendet, um eine externe PHY-Einrichtung 111 in einen Rücksprungschleifenmodus für Systemprüfung zu zwingen, und ein Flusssteuerungseingangssignal FC übernimmt die Steuerung, wenn die MAC einen Ablaufsteuerblock sendet. Die Netzwerksteuerung 102a stellt eine externe PHY-Schnittstelle 110 bereit, die kompatibel ist mit der Medium-unabhängigen Schnittstelle (MII), der Gigabit-Medium-unabhängigen Schnittstelle (GMII) oder der Zehn-Bit-Schnittstelle (TBI) über den IEEE Stanard 802.3. Empfangsdateneingangssignale RXD[7:0] und Ausgangssignale TXD[7:0] werden für den Empfangsdaten- bzw. Sendedatenaustausch verwendet. Wenn die Netzwerksteuerung 102a im GMII- oder MII-Modus arbeitet, wird TX_EN/TXD[8] als ein Sendefreigabesignal verwendet. Im TBI-Modus ist dieses Signal das Bit 8 des Sendedatenbusses. Das Signal RX_DV/RXD[8] ist ein Eingangssignal, das verwendet wird, um anzuzeigen, dass gültige Empfangsdaten auf den RX-Anschlüssen bereitgestellt werden. Im TBI-Modus ist dieses Signal das Bit 8 auf dem Empfangsdatenbus.
  • Wenn die Netzwerksteuerung 102a im GMII- oder MII-Modus arbeitet, wird das Signal RX_ER/RXD[9] als ein Eingangssignal verwendet, das anzeigt, dass die externe Sender-/Empfängereinrichtung einen Codierungsfehler in dem Empfangsblock erkannt hat, der aktuell auf den RXD-Anschlüssen übertragen wird. Im TBI-Modus ist dieses Signal das Bit 9 des Empfangsdatenbusses. Das MII-Sendetakteingangssignal TX_CLK ist ein kontinuierliches Takteingangssignal, das die Zeitreferenz für das Übertragen der TX_EN- und TXD[3:0]-Signale der Netzwerksteuerung 102a im MII-Modus bereitstellt. Das GTX_CLK ist ein kontinuierliches 125 MHz Taktausgangssignal, das die Zeitferenz für die TX_EN- und TXD-Signale von der Netzwerksteuerung bereitstellt, wenn die Einrichtung im GMII- oder TBI-Modus arbeitet. Das RX_CLK ist ein Takteingangssignal, das die Zeitreferenz für das Übertragen von Signalen in die Netzwerksteuerung bereitstellt, wenn das Gerät im MII- oder GMII-Modus arbeitet. COL ist ein Eingangssignal, das anzeigt, dass eine Kollision auf dem Netzwerkmedium erkannt wurde, und ein Trägererfassungseingangssignal CRS zeigt an, dass ein besetztes Medium aufgrund einer Sende- oder Empfangsaktivität erkannt wurde (CRS wird ignoriert, wenn das Gerät im Voll-Duplex-Modus arbeitet). Im TBI-Modus repräsentieren 10-Bit-Cocierungsgruppen 8-Bit-Datenpakete. Einige 10-Bit-Codierungsgruppen werden verwendet, um Befehle zu repräsentieren. Das Auftreten von geradzahligen und nicht geradzahligen Codierungsgruppen und speziellen Sequenzen, die als Kommata bezeichnet werden, werden verwendet, um eine Synchronisierung mit der PHY 110 herzustellen und beizubehalten. RBCLK[0] ist ein 62,5 MHz-Takteingangssignal, das verwendet wird, um ungeradzahlige Codierungsgruppen aus der PHY-Einrichtung zu speichern und RBCLK[1] wird verwendet, um geradzahlige Codierungsgruppen zwischenzuspeichern. RBCLK[1] ist stets um 180 Grad phasenverschoben in Bezug auf RBCLK[0]. Das Signal COM_DET wird von einer externen PHY 111 gesetzt, um anzuzeigen, dass die Codierungsgruppe an den RXD[9:0]-Eingängen ein gültiges Komma enthält.
  • Das IPsec-Modul 124 umfasst eine externe RAM-Schnittstelle für die Speicher 116 und 118. Wenn das CKE auf hochpegelig gesteuert wird, wird ein internes RAM-Taktsignal verwendet, um eine Synchronisierung zu gewährleisten, während ansonsten die differenziellen Takteingangssignale CK und CK_L verwendet werden. Die RAM's besitzen einen Befehlsdecodierer, der aktiviert wird, wenn ein Chipauswahlausgangssignal CS_L auf tiefpegelig gesetzt wird. Das Muster an den WE_L-, RAS_L- und CAS_L-Anschlüssen definiert den Befehl, der an den RAM ausgegeben wird. Es werden Bankadressenausgangssignale BA[1:0] verwendet, um den Speicher auszuwählen, an dem der Befehl auszuführen ist, und es wird eine Adresse, die von den RAM-Adressenausgangsanschlüssen A[10:0] geliefert wird, zur Auswahl des RAM-Worts verwendet, auf das zuzugreifen ist. Ein RAM-Datenzeitablauf-I/O-Signal DQS liefert den Zeitablauf, der anzeigt, wenn Daten zu lesen oder zu schreiben sind, und Daten an den RAM-Daten-I/O-Anschlüssen DQ[31:0] werden in den Speicher 116 oder den Speicher 118 geschrieben oder daraus ausgelesen.
  • Es sei wieder auf 2 verwiesen; im Folgenden wird eine Erläuterung der Funktion für Empfangs- und Sendeoperationen der Netzwerksteuerung 102 angegeben. Beginnend mit dem Empfang eines Datenblocks aus dem Netzwerkmedium 108 (beispielsweise einer Glasfaser) wird dieser Block an die GMII 110 geliefert (die Gigabit-Medium-unabhängige Schnittstelle), beispielsweise in Form einer Reihe aus Bytes oder Wörtern, die parallel bereitgestellt werden. Die GMII 110 leitet den Block an die MAC 122 gemäß einem Schnittstellenprotokoll weiter und die MAC 122 stellt einige der Blockverwaltungsfunktionen bereit. Beispielsweise erkennt die MAC 122 Lücken zwischen Blöcken, handhabt Probleme beim Halbduplexbetrieb, behandelt Kollisionen und Wiederholungsversuche und führt andere standardmäßige Ethernetfunktionen aus, etwa die Adressenanpassung und einige Prüfsummenberechnungen. Die MAC 122 filtert auch Blöcke heraus, überprüft ihre Zieladresse und akzeptiert oder weist den Block in Abhängigkeit eines Satzes an etablierten Regeln zurück.
  • Die MAC 122 kann mehrere Kopfbereichsformate akzeptieren und analysieren, wozu beispielsweise IPv4- und IPv6-Kopfbereiche gehören. Die MAC 122 extrahiert gewisse Informationen aus den Blockkopfbereichen. Auf der Grundlage der herausgezogenen Information bestimmt die MAC 122, welche von mehreren Prioritätssequenzen (nicht gezeigt) zum Einfügen des Blocks zu verwenden ist. Die MAC ordnet gewisse Informationen, etwa die Blocklänge und die Prioritätsinformation, in gewissen Steuerwörtern am Anfang des Blockes an, und andere Informationen, etwa ob Prüfsummen richtig sind, in Statuswörtern am Ende des Blockes. Der Block durchläuft die MAC 122 und wird in dem Speicher 118 gespeichert (beispielsweise ein 32 KB RAM). In diesem Beispiel wird der gesamte Block in dem Speicher 118 gespeichert. Der Block wird nachfolgend in den Systemspeicher 128 an einer Stelle eingeladen, die durch die Deskriptorverwaltungseinheit 130 gemäß den Deskriptoren 192 in dem Host-Speicher 128 bestimmt ist (4), wobei jeder Empfangsdeskriptor 192 einen Zeiger zu einem Datenpuffer 194 in dem Systemspeicher 128 enthält. Die Senderdeskriptoren enthalten einen Zeiger oder eine Liste aus Zeigern, wie dies nachfolgend detaillierter erläutert ist. Die Zeigerverwaltungseinheit 130 verwendet den DMA 126, um den Empfangsdeskriptor 192 auszulesen und den Zeiger in den Puffer 194 abzurufen. Nachdem der Block in den Systemspeicher 128 geschrieben ist, erzeugt der Statusgenerator 134 ein Statuswort und schreibt das Statuswort in einen weiteren Bereich des Systemspeichers 128, der in diesem vorliegenden Beispiel ein Statusring ist. Der Statusgenerator 134 gibt dann einen Interrupt an den Prozessor 112 aus. Die Systemsoftware (beispielsweise der Netzwerktreiber 190 aus 4) prüft dann die Statusinformation, die bereits in dem Systemspeicher 128 vorhanden ist. Die Statusinformation umfasst beispielsweise die Länge des Blocks, welche Verarbeitung ausgeführt wurde, und ob diverse Prüfsummen wichtig waren oder nicht.
  • Beim Sendevorgang initiiert der Host-Prozessor 112 anfänglich eine Blockübertragung in dem Netzwerk 108, und die TCP-Schicht 186 des Betriebssystems (OS) in dem Host-Prozessor 112 wird initiiert und baut eine Verbindung zum Ziel auf. Die TCP-Schicht 186 erzeugt dann einen TCP-Block, der relativ groß sein kann, und der das Datenpaket und einen TCP-Kopfbereich umfasst. Die IP-Schicht 188 erzeugt einen IP-Kopfbereich, und es wird auch ein Ethernet-(MAC)-Kopfbereich erzeugt, wobei das Datenpaket, der TCP-, IP- und der MAC-Kopfbereich in den diversen Plätzen in dem Host-Speicher 128 gespeichert werden. Der Netzwerktreiber 190 in dem Host-Prozessor 112 kann dann das Datenpaket und die Kopfbereiche in einem Sendeblock zusammenfassen, und der Block wird in einem oder mehreren Datenpuffern 194 in dem Host-Speicher 128 gespeichert. Beispielsweise kann ein typischer Sendeblock in vier Puffer 194 liegen: der Erste enthält den Ethernet- oder MAC-Kopfbereich, der Zweite enthält den IP-Kopfbereich, der Dritte enthält den TCP-Kopfbereich und der vierte Puffer enthält die Daten. Der Netzwerktreiber 190 erzeugt einen Sendedeskriptor 192, der eine Liste aus Zeigern zu all diesen Datenpuffern 194 enthält.
  • Der Datenblock wird von den Puffern 194 in die Steuerung 102 eingelesen. Um diesen Lesevorgang auszuführen, liest die Deskriptorverwaltungseinheit 130 den Senderdeskriptor 192 aus und gibt eine Reihe aus Leseanforderungen an den Host-Bus 106 unter Anwendung der DMA-Steuerung 126 aus. Jedoch treffen unter Umständen die angeforderten Datenbereiche nicht in der gleichen Reihenfolge ein, in der sie angefordert wurden, wobei die PCI-X-Schnittstelle 104 der DMU 130 die Anforderung angibt, mit der die Daten verknüpft sind. Unter Anwendung einer derartigen Information organisiert die Zusammenfüge-RAM-Logik 160 die Daten in geeigneter Weise und ordnet diese geeignet an, um den Block zu rekonstruieren, und diese Logik kann ferner gewisse Paketoperationen ausführen, um diverse Datenteile anzupassen und um Lücken zu verhindern. Nach dem Zusammenfügen in dem Zusammenfüge-RAM 160 wird der Block zu dem Speicher 116 weitergeleitet (beispielsweise in dem dargestellten Beispiel ein 32 KB-RAM). Wenn die Daten von dem Zusammenfüge-RAM 160 weitergeleitet werden, werden die Daten auch zu dem TX-Analysator 162 geleitet. Der TX-Analysator 162 liest die Kopfbereiche aus, beispielsweise die MAC-Kopfbereiche, die IP-Kopfbereiche, (wenn welche vorhanden sind), den TCP- oder UDP-Kopfbereich und bestimmt, welche Art eines Blockes vorliegt, und sucht auch nach Steuer-Bits, die in dem zugeordneten Sendedeskriptor 192 vorhanden waren. Der Datenblock wird auch an das Sendeprüfsummensystem 164 zur Berechnung von TCP- und/oder IP-Schicht-Prüfsummen weitergeleitet.
  • Der Sendedeskriptor 192 umfasst Steuerinformationen, zu denen Bits gehören, die das Sendeprüfsummensystem 164 anweisen, eine IP-Kopfbereichprüfsumme und/oder eine TCP-Prüfsumme zu berechnen. Wenn diese Steuer-Bits gesetzt sind, identifiziert der Analysator 162 die Kopfbereiche oder erkennt diese, anschließend teilt der Analysator 162 dem Sendeprüfsummensystem 164 mit, die Prüfsummenberechnungen auszuführen, und die Ergebnisse werden an einer geeigneten Stelle in dem Block im Speicher 116 abgelegt. Nachdem der gesamte Block in den Speicher 116 eingeladen ist, kann die MAC 122 beginnen, den Block zu senden, oder kann eine Sicherheitsverarbeitung für abgehende Daten (beispielsweise Verschlüsselung und/oder Authentifizierung) in dem IPsec-System 124 vor dem Senden zum Netzwerk 108 durchführen.
  • Beim Auslagern der Sendeprüfsummenfunktion auf die Netzwerksteuerung 102 der vorliegenden Erfindung wird der Host-Prozessor 112 vorteilhafterweise von dieser Aufgabe entbunden. Damit der Host-Prozessor 112 die Prüfsumme ausführt, müssen merkliche Ressourcen aufgewendet werden. Obwohl die Berechnung der Prüfsumme relativ einfach ist, muss die Prüfsumme, die den gesamten Block abdeckt, zu Beginn des Blockes eingefügt werden. In konventionellen Architekturen unternimmt der Host-Computer einen Durchlauf durch den Block, um die Prüfsumme zu berechnen, und fügt dann die Prüfsumme am Anfang des Blockes ein. Die Daten werden dann ein weiteres Mal ausgelesen, wenn diese in die Steuerung eingeladen werden. Die Netzwerksteuerung 102 reduziert ferner die Belastung des Host-Prozessor 112, indem der Block unter Anwendung eines direkten Zugriffs auf den Systemspeicher 128 über die Deskriptoren 192 und die DMA-Steuerung 126 zusammengefügt wird. Somit entbindet die Netzwerksteuerung 102 den Host-Prozessor 112 von diversen zeitaufwendigen Speicherzugriffsoperationen.
  • Zusätzlich zu den Empfangs- und Sendefunktionen, die oben genannt sind, kann die Netzwerksteuerung 102 auch programmiert sein, diverse Segmentierumgsfunktionen während eines Sendevorgangs auszuführen. Beispielsweise erlaubt das TCP-Protokoll, dass ein TCP-Block bis zu 64000 Byts groß ist. Das Ethernet-Protokoll erlaubt keinen Datentransfer in dieser Größe, sondern begrenzt einen Netzwerkblock auf ungefähr 1500 Bytes plus einige Kopfbereich-Bytes. Selbst im Falle einer Option für übergroße Blöcke, wobei Netzwerkblöcke mit 16000 Bytes zulässig sind, unterstützt das Protokoll keine Blockgröße von 64 KB. Im Allgemeinen ist ein Sendeblock in einem oder mehreren der Datenpuffer 194 in dem Systemspeicher 128 abgelegt, wobei dieser Block einen MAC-Kopfbereich, einen IP-Kopfbereich und einen TCP-Kopfbereich aufweist, und ferner bis zu 64 KB Daten umfasst. Unter Anwendung der Deskriptorverwaltungseinheit 130 werden die Block-Kopfbereiche ausgelesen und es wird eine geeignete Menge an Daten (wie dies durch das Ethernet- oder Netzwerkprotokoll erlaubt ist) genommen und gesendet. Die Deskriptorverwaltungseinheit 130 überwacht die aktuelle Position in dem größeren TCP-Block und sendet die Daten segmentweise, wobei jedes Segment seinen eigenen Satz aus Kopfbereichen aufweist.
  • Wenn beispielsweise eine Datensendung folgen soll, schreibt der Host-Prozessor 112 einen Deskriptor 192 und benachrichtigt die Steuerung 102. Die Deskriptorverwaltungseinheit 130 empfängt eine vollständige Liste aus Zeigern, die die Datenpuffer 194 kennzeichnen, und bestimmt, ob die TCP-Segmentierung sichergestellt ist. Die Deskriptorverwaltungseinheit 130 liest dann die Kopfbereichspuffer aus und bestimmt, wie viele Daten gelesen werden können. Die Kopfbereiche und eine geeignete Menge aus Daten werden in den Zusammenfüge-RAM 160 eingelesen und der Block wird zusammengestellt und gesendet. Die Steuerung 102 liest dann erneut die Kopfbereiche und das nächste Segment oder den nächsten Bereich der noch nicht gesendeten Daten, modifiziert die Kopfbereiche in geeigneter Weise und bildet den nächsten Block in der Sequenz. Dieser Prozess wird dann wiederholt, bis der gesamte Block gesendet ist, wobei jeder gesendete Bereich einer ausgewählten Sicherheitsverarbeitung in dem IPsec-System 124 unterzogen wird.
  • Die Netzwerksteuerung 102 der vorliegenden Erfindung beinhaltet auch vorteilhafterweise eine IPsec-Verarbeitung. Im Gegensatz zu konventionellen Systemen, die die IPsec-Verarbeitung auslagern, wird in der vorliegenden Erfindung eine interne IPsec-Verarbeitung eingesetzt, die als eine Einzelchipeinrichtung 102a eingerichtet sein kann (3). In konventionellen Systemen führt der Host-Prozessor die IPsec-Verarbeitung durch, oder es wird ein zu der Netzwerksteuerung separater Co-Prozessor eingesetzt. Die Verwendung des Host-Prozessors ist sehr langsam und in jedem Fall wird der Block zumindest dreimal durch den Speicher-Bus geleitet. Wenn beispielsweise ein Co-Prozessor verwendet wird, durchläuft der Block den Bus einmal, wenn dieser aus dem Speicher ausgelesen und zu dem Co-Prozessor gesendet wird, und noch einmal, wenn der Block zu dem Systemspeicher zurück geleitet wird, und ein drittes Mal, wenn der Block zu der Netzwerksteuerung gesendet wird. Diese Verarbeitungsart erfordert eine große Bandbreite auf dem PCI-Bus und beeinflusst das Systemverhalten negativ. Ein ähnlicher Leistungsverlust wird in der Empfangsrichtung erzeugt.
  • Die IPsec-Verarbeitung besitzt zwei wesentliche Ziele: das erste ist, die Daten zu verschlüsseln oder so zu verschachteln, dass eine nicht autorisierte Person oder ein System die Daten nicht lesen kann. Das zweite Ziel ist die Authentifizierung, die sicherstellt, dass das Paket nicht geschädigt ist und dass das Paket von der erwarteten Person oder dem System stammt. Eine kurze Erläuterung der internen IPsec-Verarbeitung ist nachfolgend angegeben. Die Netzwerksteuerung 102 der vorliegenden Erfindung nutzt vorteilhaft Sicherheitsassoziationen bzw. Zuordnungen (SAs) unter Anwendung der SA-Speicherschnittstelle 142, der SA-Tabelle 146 und dem SA-Speicher 140. Wie zuvor kurz dargelegt ist, ist eine Sicherheitsassoziation bzw. Zuordnung eine Sammlung aus Bits, die beispielsweise ein spezielles Sicherheitsprotokoll beschreiben, ob z. B. der IPsec-Bereich 124 eine Verschlüsselung oder eine Authentifizierung oder beides ausführen soll, und beschreibt ferner, welche Algorithmen zu verwenden sind. Es gibt mehrere standardmäßige Verschlüsselungs- und Authentifizierungsalgorithmen, so dass die SA-Schnittstelle 142 und die SA-Tabelle 146 angeben, welcher für einen speziellen Block anzuwenden ist. Der SA-Speicher 140 in dem vorliegenden Beispiel ist ein privater Speicher, der die Verschlüsselungsschlüssel enthält. Die SAs werden gemäß einem IPsec-Protokoll erhalten, wodurch ausreichend Information mit einem Anwender oder einem System in dem Netzwerk ausgetauscht wird, um zu entscheiden, welche Algorithmen anzuwenden sind und es beiden Parteien ermöglichen, die gleichen Schlüssel zu erzeugen. Nachdem der Informationsaustausch abgeschlossen ist, ruft die Software den Treiber 190 auf, der die Ergebnisse in den SA-Speicher 140 schreibt.
  • Sobald der Schlüsselaustausch abgeschlossen ist, sind die geeigneten Bits, die anzeigen, welcher Schlüssel und welcher Authentifizierungsalgorithmus zu verwenden ist, sowie die eigentlichen Schlüssel in dem SA-Speicher 140 enthalten. Im Sendemodus enthält ein Teil des Deskriptors 192, der mit einem vorgegebenen abgehenden Datenblock verknüpft ist, einen Zeiger in dem SA-Speicher 140. Wenn die Deskriptorverwaltungseinheit 130 den Deskriptor 192 ausliest, sendet sie eine Anforderung an die SA-Speicherschnittstelle 142, um den Schlüssel abzurufen, die dann den Schlüssel zu dem Schlüssel-FIFO 172 sendet, der die TX-IPsec-Verarbeitungsmodule 174a bzw. 174b speist. Wenn sowohl Verschlüsselung als auch Authentifizierung beim Senden eingesetzt werden, ist der Prozess geringfügig unterschiedlich, da die Aufgaben nicht parallel ausgeführt werden können. Die Authentifizierung ist eine Kontrollsumme der verschlüsselten Daten und folglich muss die Authentifizierung warten, bis ein Teil der Verschlüsselung ausgeführt ist. Da die Verschlüsselung iterativ über eine Reihe von Datenblöcken ist, kann es eine Verzögerung zwischen dem Beginn des Verschlüsselungsprozesses und der Verfügbarkeit der ersten verschlüsselten Daten geben. Um eine Beeinflussung auf das Geräteleistungsvermögen dieser Verzögerung zu vermeiden, verwendet die beispielhafte Netzwerkschnittstelle 102 zwei TX-IPsec-Prozessmaschinen 174a und 174b, wobei eine die ungeradzahligen Blöcke und die andere die geradzahligen Blöcke in dem dargestellten Beispiel verarbeitet.
  • Vor dem Ausführen der IPsec-Verarbeitung analysiert der TX-IPsec-Analysator 170 die Block-Kopfbereiche und sucht darin nach deaktivierbaren Feldern, die Felder in den Kopfbereichen sind, die nicht authentifiziert sind, da diese beim Transport des Blockes über das Netzwerk 108 variieren. Beispielsweise variiert die Zieladresse in dem IP-Kopfbereich von Router zu Router, wenn der Block über das Internet verteilt wird. Der Sende-IPsec-Analysator 170 erkennt die veränderbaren bzw. deaktivierbaren Felder und gibt die Information an die TX-IPsec-Prozessoren 174 weiter, die selektiv die variablen Feldbereiche der Blöcke überspringen. Die verarbeitenden Blöcke werden an die FIFOs 178a und 178b gesendet und nachfolgend in dem Speicher 118 gesammelt. Das Ergebnis der Authentifizierungsverarbeitung ist ein Integritätsprüfwert (ICV), der von dem Einfügeblock 179 in den geeigneten IPsec-Kopfbereich eingefügt wird, wenn der Block von dem Speicher 118 zu dem Netzwerkmedium 108 gesendet wird.
  • Im Empfangsmodus gelangt ein empfangener Block in die MAC 122 und den RX-Analysator 144. Der RX-Analysator 144 analysiert den eintreffenden Block bis zu den IPsec-Kopfbereichen und extrahiert Information daraus. Die Felder, die für den RX-Analysator 144 wichtig sind, sind beispielsweise die Ziel-IP-Adresse in dem IP-Kopfbereich, der SPI (Sicherheitsprotokollindex) und ein Protokollbit, das anzeigt, ob ein IPsec-Kopfbereich ein Authentifizierungskopfbereich (AH) oder ein Einkapselungssicherheitsprotokoll(ESP)-Kopfbereich ist. Ein Teil der herausgelösten Information wird zu dem SA-Suchblock 146 weitergeleitet. Der SA-Suchblock 146 gibt die geeignete SA an und transportiert die Information zu der SA-Speicherschnittstelle 142, die die SA empfängt und diese in den Schlüssel-FIFO 152 schreibt.
  • Der SA-Suchblock 146 verwendet eine Chip-interne SPI-Tabelle und den Chip-externen SA-Speicher 140. Die SPI-Tabelle ist in 4096 Felder mit jeweils vier Einträgen unterteilt. Zu den Einträgen gehören der 32-Bit SPI, eine Kontrollsumme der Zieladresse (DA), ein Bit zur Kennzeichnung des Protokolls und ein Bit, um anzugeben, ob der Eintrag verwendet wird. Entsprechende Einträge in dem SA-Speicher enthalten die vollständigen DAs und die SA (zwei SAs, wenn es sowohl Authentifizierung und Verschlüsselung gibt). Das Feld für jeden Eintrag wird durch die Kontrollsumme des SPI bestimmt. Um eine SA auszulesen, wird eine Kontrollsumme des SPI aus dem empfangenen Block verwendet, um zu bestimmen, welches Feld zu durchsuchen ist. Innerhalb des Feldes sucht der SA-Suchblock 146 die Einträge im Hinblick auf eine Übereinstimmung mit dem vollständigen SPI, der Zieladressenkontrollsumme und des Protokollbits. Nach dem Absuchen schreibt der SA-Suchblock einen Eintrag in den SA-Zeiger-FIFO 148, der einen übereinstimmenden Eintrag kennzeichnet oder angibt, dass keine Übereinstimmung gefunden wurde. Eine Prüfung der DA-Adresse des SA-Speichers wird unmittelbar vor der Sicherheitsverarbeitung ausgeführt. Wenn es keine Übereinstimmung gibt, wird die Sicherheitsverarbeitung an dem betreffenden Block nicht ausgeführt. Auf der Grundlage der Einträge in dem SA-Zeiger-FIFO 148 werden die Schlüssel aus dem externen SA-Speicher 140 abgerufen und in dem Schlüssel-FIFO 152 angeordnet. Der RX-IPsec-Prozessor 150 nimmt die Schlüssel, die von dem FIFO 152 eintreffen, liest die entsprechenden Blockdaten aus dem Speicher 118 aus und beginnt mit der erforderlichen Verarbeitung des Blockes. Beim Empfang verläuft die Verarbeitung, Entschlüsselung und Authentifizierung parallel (beim Empfang sind die Entschlüsselung und die Authentifizierung keine sequenziellen Prozesse), und somit wird in diesem Beispiel lediglich ein RX-IPsec-Prozessor eingesetzt.
  • Der RX-IPsec-Analysator 154 analysiert die Kopfbereiche, die auf den ESP-Kopfbereich folgen. Ein beliebiger Kopfbereich, der auf den ESP-Kopfbereich folgt, ist verschlüsselt und kann nicht analysiert werden, bis die Entschlüsselung stattgefunden hat. Diese Analyse muss abgeschlossen sein, bevor TCP/UDP-Prüfsummen berechnet werden können und bevor Einfügebits geprüft werden können. Die entschlüsselten Daten werden in dem Speicher 116 agelegt. Um die TCP/UDP-Prüfsummen und die Einfügungen zu prüfen, ohne die Blockdaten ein weiteres Mal zu speichern, werden diese Funktionen von dem Prüfsummen- und Einfügeprüfsystem 156 durchgeführt, während die Daten von dem Speicher 116 zu dem Host-Speicher 128 übertragen werden. Zusätzlich zu der internen IPsec-Verarbeitung und der TCP-Segmentierung, die zuvor dargestellt ist, liefert die Netzwerksteuerung 102 eine Leistungssteigerung beim Ausführen von Interrupt-Ereignissen. Lesewartezeiten sind groß, wenn ein Host-Prozessor erforderlich ist, um ein Register einer Netzwerkeinrichtung auszulesen. Diese Wartezeiten beeinflussen das System-Leistungsverhalten in negativer Weise. Insbesondere wenn die Host-Prozessor-Taktgeschwindigkeiten ständig größer werden, wird auch die Diskrepanz zwischen der Taktgeschwindigkeit und der Zeit größer, die zum Erhalten einer Antwort von einer Netzwerksteuerung über einen PCI- oder einer anderen Host-Bus erforderlich ist. Wenn daher ein Host-Prozessor eine Netzwerkeinrichtung auslesen muss, muss der Prozessor eine größere Anzahl an Taktzyklen warten, wodurch sich ein Leistungsverlust ergibt.
  • Die Netzwerkschnittstelle 102 vermeidet diese Wartezeiten, indem die Leseoperationen durch Schreiboperationen ersetzt werden. Schreiboperationen sind nicht problematisch, da diese stattfinden können, ohne dass der Prozessor 112 beteiligt ist. Wenn daher eine Schreibinformation an einen FIFO gesendet wird, kann die Netzwerksteuerung 102 die notwendige Zeit zum Ausführen der Schreiboperationen aufbringen, ohne die Auslastung des Prozessors negativ zu beeinflussen, solange die Schreiboperationen in kleinen Sequenzen ausgeführt werden. Um diese Operationen während einer Sendeoperation zu vermeiden, erzeugt der Treiber einen Deskriptor 192 in der Systemspeicherung 128 und schreibt dann einen Zeiger zu diesem Deskriptor in das Register 132 der Netzwerksteuerung 102. Die DMU 130 der Steuerung 102 erkennt den Inhalt in dem Register 132 und liest die erforderlichen Daten direkt aus dem Systemspeicher 128 aus, ohne dass ein weiteres Eingreifen des Prozessors 112 erforderlich ist. Für Empfangsoperationen ermittelt die Treibersoftware 190 leere Puffer 194 in dem Systemspeicher 128 und schreibt einen entsprechenden Eintrag in das Register 132. Die Deskriptorverwaltungseinheit 130 schreibt die Zeiger in die Sendedeskriptorringe, um anzugeben, welche Sendedeskriptoren 192 verarbeitet sind und schreibt Zeiger in die Statusringe, um anzugeben, welche Empfangspuffer 194 verwendet sind.
  • Anders als in konventionellen Architekturen, die es erfordern, dass ein Host-Prozessor ein Interruptregister in der Netzwerksteuerung ausliest, erzeugt und verwendet die vorliegende Erfindung einen Steuerstatusblock (CSB) 196, der in dem vorbestimmten Gebiet des Systemspeichers 128 liegt (beispielsweise an einer Stelle, die beim Initialisieren bestimmt wird). Die Netzwerksteuerung 102 schreibt in den CSB 196 beliebige Registerwerte, die das System benötigt. Genauer gesagt, nachdem ein Block vollständig verarbeitet ist, schreibt vor dem Erzeugen eines Interrupts die Netzwerksteuerung 102 eine Kopie des Interruptregisters in den CSB 196. Anschließend setzt die Steuerung 102 den Interrupt; wenn daher der Host-Prozessor 112 den Interrupt in dem Register 132 erkennt, sind die empfangenen Daten bereits in dem Empfangsdatenpuffer 194 verfügbar.
  • Diverse funktionelle und strukturelle Details der beispielhaften Netzwerkschnittstellensteuerung 102 sind im Weiteren in Verbindung mit den Figuren dargelegt. Insbesondere sind Details der Deskriptorverwaltungsmerkmale, der Sendedatenblocksegmentierung und der Prüfsummenbildung, sowie der Sicherheitsverarbeitung nachfolgend detaillierter dargestellt und beschrieben, um ein Verständnis der vorliegenden Erfindung im Zusammenhang der beispielhaften Steuerung 102 zu verbessern.
  • DESKRIPTORVERWALTUNG
  • Mit Bezug zu den 2, 4 und 5A–5J werden nunmehr weitere Details der Deskriptoren 192 und der Funktionsweise der beispielhaften Steuerung 102 dargestellt und nachfolgend beschrieben. 5A zeigt den Host-Speicher 128 mit dem Steuerungstatusblock (CSB) 196, den Blockdatenpuffern 194, einer ganzzahligen Anzahl ”n” an Deskriptorringen DRI ... DRn für Sende- und Empfangsdeskriptoren 192, und einer ganzzahligen Anzahl ”m” an Empfangsstusringen 199 RSRI ... RSRm. Die Sende- und Empfangsdeskriptoren 192 sind in Sequenzen, die im Weiteren als Deskriptorringe DR bezeichnet sind, gespeichert, und der CSB 196 umfasst Deskriptorringzeiger DR_PNTRI ... DR_PNTRn für die Deskriptorringe DR. In der beispielhaften Steuerung 102 sind vier Sendedeskriptorringe für gesendete Blöcke und vier Empfangsdeskriptorringe für empfangene Blöcke vorgesehen, die vier Prioritäten des Netzwerkdatenverkehrs entsprechen. Jeder Deskriptorring DR in dieser Ausführungsform wird als eine kontinuierliche Ringstruktur behandelt, wobei der erste Speicherplatz in dem Ring als unmittelbar auf den letzten Speicherplatz folgend betrachtet wird. 5B zeigt die Zeiger und andere Inhalte des beispielhaften CSB 196 und 5C zeigt diverse Zeiger- und Längenregister 132 in der Steuerung 102. 5D zeigt weitere Details eines beispielhaften Sendedeskriptorrings, 5H und 51 zeigen Details, die beispielhafte Empfangsdeskriptor- und Empfangsstatusringe betreffen. 5E und 5F zeigen einen beispielhaften Sendedeskriptor, 5G zeigt einen beispielhaften Empfangsdeskriptor und 5J zeigt einen beispielhaften Empfangsstatusringeintrag.
  • Wie in 5A gezeigt ist, enthalten die Deskriptoren 192 individuell Zeiger zu einem oder mehreren Datenpuffern 194 in dem Systemspeicher 128, sowie Steuerinformation, wie dies in den 5E–5G gezeigt ist. Die Synchronisation zwischen der Steuerung 102 und dem Softwaretreiber 190 wird durch Zeiger gewährleistet, die in den Steuerungsregistern 132 gespeichert sind, durch Zeiger, die in dem CSB 196 in dem Systemspeicher 128 gespeichert sind, und durch Interruptereignisse. Während des Betriebs liest die Deskriptorverwaltungseinheit 130 in der Steuerung 102 die Deskriptoren 192 über die DMA-Steuerung 126 der Bus-Schnittstelle 104 aus, um die Speicherstelle der abgehenden Blöcke, die zu senden sind (beispielsweise in den Datenpuffern 194) zu bestimmen, und um zu bestimmen, wo die eintreffenden Blöcke, die aus dem Netzwerk 108 empfangen werden, zu speichern sind. Der CSB 196 wird von der Netzwerksteuerung 102 beschrieben und von dem Treiber 190 in dem Host-Prozessor 112 ausgelesen, und die Deskriptorverwaltungsregister 132 werden von dem Treiber 190 beschrieben und von der Deskriptorverwaltungseinheit 130 in der Steuerung 102 ausgelesen. Das beispielhafte Deskriptorsystem ermöglicht im Allgemeinen den Informationsaustausch im Hinblick auf Sende- und Empfangsoperationen zwischen dem Softwaretreiber 190 und der Steuerung 102.
  • Gemäß 5B umfasst der beispielhafte CSB 196 Zeiger in die Deskriptor- und Statusringe, sowie eine Kopie des Inhalts des Interruptregisters der Steuerung. Die Sendezeiger TX_RD_PTR0 bis TX_RD_PTR3 sind Deskriptorlesezeiger, die den Sendeprioritäten 3 bis 0 entsprechen, die genau auf unterhalb des letzten 64-Bit-quad-Wortes (QWORD) zeigen, das die Steuerung 102 aus dem entsprechenden Prioritätssendeskriptorring ausgelesen hat. Die Empfangsstatuszeiger STAT_WR_PTR0 bis STAT_WR_PTR3 sind Deskriptorschreibzeiger, die den Sendeprioritäten 3 bis 0 entsprechen, die gerade auf die Stelle nach dem letzten QWORD bzw. Q-Wort zeigen, das die Steuerung 102 in den entsprechenden Prioritätsempfangsstatusring geschrieben hat. Der CSB 196 umfasst ferner eine Interrupt-0-Register-Kopie INTO_COPY, das eine Kopie des Inhalts eines Interrupt-0-Registers in der Steuerung 102 ist.
  • 5C zeigt Register 132, die mit der Deskriptorverwaltungseinheit 130 in der Steuerung 102 verknüpft sind.
  • Sendedeskriptorbasiszeiger TX_RING[3:0]_BASE enthalten die Speicheradressen des Anfangs der Sendedeskriptorringe entsprechend der Priorität, und die Längen der Sendedeskriptorringe sind in den TX_RING[3:0]_LEN-Registem enthalten. Die Sendedeskriptorschreibspeicher sind in Registern TX_WR_PTR[3:0] abgelegt, wobei die Treibersoftware 190 diese Register so aktualisiert, dass diese gerade genau unter das letzte QWORD zeigen, das der Treiber in den entsprechenden Sendedeskriptorring geschrieben hat. Empfangsdeskriptorbasiszeiger RX_RING[3:0]_BASE enthalten die Speicheraddresse (beispielsweise in dem Host-Speicher 128) des Anfangs der Empfangsdeskriptorringe mit entsprechender Priorität, und die Längen dieser Empfangsdeskriptorringe sind in den RX_RING[3:0]_LEN-Register enthalten. Die Empfangsdeskriptorschreibzeiger RX_WR_PTR[3:0] werden von dem Treiber 190 so aktualisiert, dass diese genau unter das letzte QWORD zeigen, das der Treiber in den entsprechenden Empfangsdeskriptorring geschrieben hat. Die Empfangsstatusringbasiszeigerregister STAT_RING[3:0]_BASE geben die Speicheraddresse der Empfängerstatusringe an, und STAT_RING[3:0]_BASE gibt die Längen der entsprechenden Empfängerstatusringe 199 in dem Speicher 128 an. RX_BUF_LEN zeigt die Anzahl der QWORDS bzw. QWÖRTER der Empfangsdatenpuffer 194 an, wobei alle Empfangsdatenpuffer 194 die gleiche Länge besitzen, und CSB_ADDR zeigt die Adresse des CSB 196 in dem Host-Speicher 128 an.
  • Um die Funktionsweise der Deskriptorverwaltung beim Senden von Daten noch besser zu veranschaulichen, zeigt 5D den Host-Speicher 128 und die Deskriptorverwaltungseinheit 130, wobei diese einen beispielhaften Sendedeskriptorring in dem Host-Speicher 128 und die entsprechenden Deskriptorregister 132 in der Deskriptorverwaltungseinheit 130 der Steuerung 102 enthalten. Ferner zeigen 5E und 5F einen beispielhaften Sendedeskriptor 192a und die entsprechenden Steuermarkierungen- bzw. Flaggen. In dem Sendedeskriptor 102 aus 5E enthält BUF1_ADR[39:0] eine Adresse für den Host-Speicher 128 des ersten Datenpuffers 194, der mit dem Deskriptor 192a verknüpft ist. Der Deskriptor 192a umfasst ferner Sendemarken (TFLAGS1, 5E und 5F) 193, die ein MORE_CTRL-Bit enthalten, um den Einschluss eines zweiten 64-Bit-Steuerwortes mit Information im Hinblick auf die Funktion eines virtuellen lokalen Nahbereichnetzwerks (VLAN) und im Hinblick auf die TCP-Segmentierung anzuzeigen. Ein ADD_FCS/IVLEN1-Bit und ein IVLEN0-Bit werden verwendet, um die FCS-Erzeugung bei Fehlen der IPsec-Verarbeitung zu steuern, oder um die Länge eines Einkapselungssicherheitsprotokoll-(ESP)Initialisierungsvektors (IV) anzugeben, wenn die IPsec-Sicherheitsverarbeitung und die Schicht 4 ausgewählt sind. Ein IPCK-Bit wird verwendet, um anzuzeigen, ob die Steuerung 102 eine Schicht 3-(IP-Schicht) Prüfsumme für gesendete Blöcke erzeugt, und ein L4CK-Markierungsbit gibt an, ob die Steuerung 102 eine Schicht 4-(beispielsweise TCP, UDP, etc.)Prüfsumme erzeugt. Drei Pufferzahlbits BUF_CNT geben die Anzahl der Datenpuffer 194 an, die mit dem Deskriptor 192a verknüpft sind, wenn diese kleiner als 8 ist. Wenn mehr als 8 Datenpuffer 194 mit dem Deskriptor 192a verknüpft sind, wird die Pufferzahl in dem BUF_CNT[7:0]-Feld des Deskriptors 192a vorgesehen.
  • Ein BYTECOUNT1[15:0]-Feld in dem Deskriptor 192a zeigt die Länge des ersten Datenpuffers 194 in Bytes an. Ein PAD_LEN-Feld enthält einen Einfügelängenwert von einem ESP-Anhang, der mit dem Block verknüpft ist, und ein NXT_HDR-Feld liefert die nächste Kopfbereichinformation (Protokolldaten für IPv4) von dem ESP-Anhang, wenn das MORE_CTRL-Bit gesetzt ist. Im Anschluss an das NXT_HDR-Feld zeigt ein ESP_AUTH-Bit 195 an, ob der Block ein Authentifizierungsdatenfeld in dem ESP-Anhang enthält, und ein Sicherheitsassoziations- bzw. Zuordnungs-(SA)Zeigerfeld SA_PTR[14:0] zeigt auf einen Eintrag in dem externen SA-Speicher 140 (2), der dem Block entspricht. Ein Zwei-Bit-VLAN-Markierungssteuerbefehlsfeld TCC[1:0] 197 enthält einen Befehl, der die Steuerung 102 veranlasst, eine VLAN-Markierung hinzuzufügen, zu modifizieren oder zu löschen oder um den Block ungeändert zu senden, und ein Maximumsegmentgrößefeld MSS[13:0] spezifiziert die maximale Segmentgröße, die die TCP-Segmentierungs-Hardware der Steuerung 102 für den mit dem Deskriptor 192a verknüpften Block erzeugt. Wenn der Inhalt des TCC-Feldes 10 oder 11 ist, sendet die Steuerung 102 den Inhalt eines Markierungssteuerinformationsfeldes TCI[15:0] als Bytes 15 und 16 des abgehenden Datenblocks. Wenn die Blockdaten mehr als einen Datenpuffer 194 einnehmen, werden ein oder mehrere zusätzliche Pufferadressierfelder BUF_ADR[39:0] verwendet, um deren Adressen anzugeben, und zugeordnete BYTECOUNT[15:0]-Felder werden verwendet, um die Anzahl der Bytes in den zusätzlichen Blockpuffern 194 anzugeben.
  • Wenn der Netzwerksoftwaretreiber 190 einen Deskriptor 192 in einen Deskriptorring schreibt, schreibt er auch in ein Deskriptorschreibzeigeregister 132 in den Deskriptorverwaltungseinheitsregistern 132, um die Steuerung 102 darüber zu informieren, dass neue Deskriptoren 192 verfügbar sind. Der Wert, den dieser Treiber in ein vorgegebenes Deskriptorverwaltungsregister 132 schreibt, ist ein Zeiger zu einem 64-Bit-Wort (QWORD) in dem Host-Speicher 128, genau hinter dem Deskriptor 192, der gerade geschrieben wurde, wobei der Zeiger ein Offset zu dem Anfang des Deskriptorringes ist, wobei dieser Offset in QWÖRTERN gemessen wird. Die Steuerung 102 liest nicht von diesem Offset oder von unterhalb dieses Offsets. Wenn ein Sendedeskriptorschreibzeigeregister (beispielsweise das DMU-Register 132, etwa TX_WR_PTR1 in 50) beschrieben wurde, beginnt die Steuerung 102 einen Sendeprozess, wenn nicht bereits ein Sendevorgang abläuft. Wenn der Sendevorgang beginnt, geht dieser weiter, bis keine unverarbeiteten Sendedeskriptoren 192 in den Sendedeskriptorringen verbleiben. Wenn die Steuerung 102 einen vorgegebenen Sendedeskriptor 192 beendet, schreibt die Steuerung 102 einen Deskriptorlesezeiger (beispielsweise Zeiger TX_RD_PTR1 in 5D) für den CSB 196.
  • Dabei zeigt der Deskriptorlesezeiger TX_RD_PTR1 auf den Beginn des Deskriptors 192, den die Steuerung 102 als Nächstes lesen wird. Der Wert des Deskriptors 192 ist der Offset in QWÖRTERN des QWORTES, das genau unterhalb des Endes des zuletzt gelesenen Deskriptors ist. Dieser Zeiger TX_RD_PTR1 zeigt somit dem Treiber 190 an, welcher Teil des Deskriptorraumes wieder verwendet werden kann. Der Treiber 190 schreibt nicht in die Stelle in dem Deskriptorraum, auf den der Lesezeiger zeigt, oder zwischen diese Position und einem QWORT vor der Stelle, auf die der Deskriptorschreibzeiger TX_WR_PTR1 zeigt. Wenn der Deskriptorlesezeiger TX_RD_PTR1 gleich dem entsprechenden Deskriptorschreibzeiger TX_WR_PTR1 ist, ist der Deskriptorring leer. Um zwischen der Bedingung eines leeren Ringes und eines vollen Ringes zu unterscheiden, stellt der Treiber 190 sicher, dass stets mindestens ein nicht benutztes QWORT in dem Ring ist. Auf diese Weise ist der Sendedeskriptorring voll, wenn der Schreibzeiger TX_WR_PTR1 kleiner ist als der Lesezeiger TX_RD_PTR1 modulo der Ringgröße.
  • In 5G ist ein beispielhafter Empfangsdeskriptor 192b gezeigt, der einen Zeiger BUF_ADR[39:0] zu einem Block aus Empfangspuffern 194 in dem Host-Systemspeicher 128 und ein Zahlfeld BUF_MULT[7:0], das die Anzahl der Puffer 194 in dem Block angibt, aufweist, wobei alle Empfangspuffer 194 die gleiche Länge besitzen und lediglich ein Puffer für jeden empfangenen Block in dem dargestellten Beispiel verwendet wird. Wenn der empfangene Block für den Puffer 104 zu groß ist, wird der Block unterteilt, und es wird ein TRUNC-Bit bzw. Trennbit in den entsprechenden Empfangsstatusringeintrag 199 gesetzt. 5H zeigt einen beispielhaften Empfangsdeskriptorring mit einer ganzzahligen Anzahl n an Empfangsdeskriptoren 192b zum Speichern von Adressen, die auf n Empfangsdatenpuffer 194 in dem Host-Speicher 128 zeigen. Die Register 132 in der Deskriptorverwaltungseinheit 130 der Steuerung 102 enthalten Ringbasis- und Längenregistern (RX_RING1_BASE und RX_RING1_LEN), die dem Empfangsdeskriptorring entsprechen, sowie ein Empfangsschreibzeigerregister (RX_WR_PTR1) mit einer Adresse des nächsten unbenutzten Empfangsdeskriptors 192b in dem dargestellten Deskriptorring, und ein Empfangspufferlängenregister (RX_BUF_LEN), das die Länge aller Puffer 194 enthält. Die Deskriptorverwaltungseinheit 130 besitzt auch Register 132 (STAT_RING1_BASE und STAT_RING1_LEN), die sich auf die Stelle des Empfangsstatusrings mit den Einträgen 199 beziehen, die den empfangenen Daten in einem oder mehreren der Puffer 194 entsprechen. Der Steuerstatusblock 196 in dem Host-Speicher 128 enthält ferner ein Register STAT_WR_PTR1, dessen Inhalt die Adresse in dem Empfangsstatusring der nächsten unbenutzten Statusringspeicherstelle liefert, wobei der Empfangsstatusring als leer betrachtet wird, wenn STAT_WR_PTR1 gleich RX_WR_PTR1 ist.
  • 5I und 5J zeigen weitere Details eines beispielhaften Empfangsstatusringes 199 und eines Eintrags davon. Der beispielhafte Empfangsstatusringeintrag aus 5J enthält eine VLAN-Markierungssteuerinformation TCI[15:0], die von dem Empfangsblock kopieri ist, und enthält ein Nachrichtenzahlfeld MCNT[15:0], das die Anzahl an empfangenen Bytes angibt, die in den Empfangsdatenpuffer 194 kopiert werden. Ein Drei-Bit-IPSEC_STAT1[2:0] zeigt den Codierungsstatus des IPsec-Sicherheitssystems 124 an, und ein TUNNEL_FOUND-Bit zeigt an, dass ein zweiter IP-Kopfbereich in dem empfangenen Datenblock gefunden wurde. Ein AH_ERR-Bit zeigt einen Fehler in dem Authentifizierungskopfbereich (AH) an, ein ESPAH_ERR-Bit zeigt einen ESP-Authentifizierungsfehler an, und ein PAD_ERR-Bit zeigt einen ESP-Einfügefehler in dem empfangenen Datenblock an. Ein CRC-Bit zeigt ein FCS oder einen Zuordnungsfehler an, und ein TRUNC-Bit zeigt an, dass der empfangene Block länger als der Wert des RX_BUF_LEN-Registers 132 (5C oben) ist, und dass dieser unterteilt wurde. Ein VLAN-Markierungstypenfeld TT[1:0] zeigt an, ob der empfangene Block unmarkiert ist, mit Priorität markiert ist oder VLAN-markiert ist, und ein RX_MATCH[2:0] Feld zeigt eine Empfangsadressenübereinstimmungsart an. Ein IP_CK_ERR-Bit zeigt einen IPv4-Kopfbereichprüfsummenfehler an, und ein IP-Kopfbereichdetektionsfeld IP_HEADER[1:0] zeigt an, ob ein IP-Kopfbereich erkannt wird, und wenn dies der Fall ist, welche Art (beispielsweise IPv4 oder IPv6). Ein L4_CK_ERR-Bit zeigt einen Schicht 4-(beispielsweise TCP oder UDP)Prüfsummenfehler in dem empfangenen Block an, und ein Schicht-4-Kopfbereichdetektionsfeld L4_HEADER zeigt die Art des erkannten Schicht-4-Kopfbereiches an, falls dieser vorhanden ist. Ferner stellt ein Empfangszuordnungslängenfeld RCV_ALIGN_LEN[5:0] die Länge von Einfügedaten bzw. Fülldaten bereit, die vor dem Beginn des MAC-Kopfbereichs zur Anpassung eingefügt wurden.
  • Wie in den 5H und 5I gezeigt ist, schreibt beim Empfangsvorgang die Steuerung 102 Empfangsstatusringschreibzeiger STAT_WR_PTR[3:0] (5B) für den CSB 196. Die Netzwerktreibersoftware 190 verwendet diese Schreibzeiger, um zu bestimmen, welche Empfangspuffer 194 in dem Host-Speicher 128 gefüllt sind. Die Empfangsstatusringe 199 werden verwendet, um Statusinformation über empfangene Blöcke zu übermitteln, etwa die Anzahl der empfangenen Bytes und die Fehlerinformation, wobei das beispielhafte System vier Empfängerstatusringe 199, einen für jede Priorität, vorsieht. Wenn die Steuerung 102 einen eintreffenden Block auf dem Netzwerk 108 empfängt, verwendet die Steuerung 102 den nächsten Empfangsdeskriptor 192 aus dem geeigneten Empfangsdeskriptorring, um zu bestimmen, wo der Block in dem Host-Speicher 128 zu speichern ist. Sobald der empfangene Block in den Systemspeicher 128 kopiert ist, schreibt die Steuerung 102 Empfangsstatusinformationen in den entsprechenden Empfangsstatusring 199. Die Synchronisation zwischen der Steuerung 102 und der Treibersoftware 190 wird durch die Empfangsstatusschreibzeiger (STAT_WR_PTR[3:0]) für den CSB 196 gewährleistet. Diese Zeiger STAT_WR_PTR[3:0] sind Offset-Werte in QWÖRTERN in Bezug auf den Beginn des entsprechenden Rings.
  • Wenn die Steuerung 102 den Empfang eines Blockes aus dem Netzwerk 108 beendet, schreibt sie die Statusinformation in die nächste verfügbare Speicherstelle in dem geeigneten Empfangsstatusring 199 und aktualisiert den entsprechenden Empfangsstatusschreibzeiger STAT_WR_PTR. Der Wert, den die Steuerung 102 an diese Speicherstelle schreibt, ist ein Zeiger zu dem Statuseintrag in dem Ring, der als Nächstes zu beschreiben ist. Der Softwaretreiber 190 liest diesen Eintrag nicht oder liest auch nicht einen Eintrag hinter diesem Eintrag. Die beispielhafte Steuerung 102 besitzt keine Register, die auf den ersten nicht verarbeiteten Empfangsstatuseintrag in jedem Ring zeigen. Vielmehr wird diese Information indirekt aus den Empfangsdeskriptorzeigern RX_WR_PTR abgeleitet. Wenn daher der Softwaretreiber 190 in einem der RX_WR_PTR-Register 132 (5C) in der Steuerung 102 schreibt, stellt der Treiber 190 sicher, dass ausreichend Speicherplatz in dem Empfangsstatusring 199 für den Eintrag, der diesem Puffer 104 entspricht, verfügbar ist.
  • SENDEDATENBLÖCKE
  • Es sei nun auf die 2–4 und 6A–6E verwiesen; die Steuerung 102 sendet Blöcke 200 von den Datenpuffern 194 in den Host-Speicher 128 unter Anwendung der zuvor beschriebenen Sendedeskriptoren 192. Wenn ein Anwendungssoftwareprogramm 184, das in dem Host-Prozessor 112 abgearbeitet wird, ein Paket aus Daten oder Information zu einem anderen Computer oder einer Einrichtung in dem Netzwerk 108 senden will, wird das Paket der Betriebssystemsoftware der Schicht 4 und 3 zugeführt (beispielsweise Software der TCP-Schicht 186 und der IP-Schicht 188 in 4). Diese Softwareschichten bilden diverse Kopfbereiche und Anhänge, um einen Sendeblock 200 zu bilden. Die Netzwerkschnittstellentreibersoftware 190 fügt dann den Block 200 zusammen, der einen oder mehrere Kopfbereiche und das Datenpaket enthält, wobei das Zusammenfügen in den Host-Speicher-Datenpuffern 194 erfolgt, und aktualisiert die Deskriptoren und die Deskriptorverwaltungseinheitsregister 132 in der Steuerung 102 entsprechend. Der in den Datenpuffern 194 zusammengefügte Block enthält Kopfbereiche der Schicht 3 und der Schicht 4 und entsprechende Prüfsummen (beispielsweise IP- und TCP-Kopfbereiche und Prüfsummen), sowie einen MAC-Kopfbereich, wie in den 7A und 7B. Fig. gezeigt ist. 6A und 6C zeigen schematisch die Herstellung von Sendeblöcken 200a und 200c unter Anwendung der Schicht 4 TCP und der Schicht 3 mit der Internet-Protokollversion 4 (IPv4) für Transport- bzw. Tunnelmodi, und die 6B und 6D zeigen schematisch die Bildung von Sendeblöcken 200b und 200d unter Anwendung der IPv6 für den Transport- bzw. den Tunnelmodus. Jedoch ist die Erfindung nicht auf TCP/IP-Implementierungen beschränkt, und es können andere Protokolle verwendet werden. Beispielsweise kann die vorliegende Steuerung 102 auch für das Senden und Empfangen von Daten unter Anwendung eines Anwenderdatagrammprotokolls (UDP) Software der Schicht 4 eingesetzt werden.
  • In den 6A–6D wird das ursprüngliche Datenpaket von der Anwendungssoftware 184 der TCP-Schicht 186 als TCP-Daten 202 zugeführt. Die TCP-Schicht 186 speichert die TCP-Daten 202 in den Host-Speicher 128 und erzeugt einen TCP-Kopfbereich 204. Die für das TCP beispielhaften TCP-Kopfbereiche sind im Folgenden mit Bezug zu den 7A und 7B dargestellt und beschrieben. Die TCP-Daten 202 und der TCP-Kopfbereich (z. B., oder Zeiger dazu) werden der Schicht 3-Software zugeführt (beispielsweise in dieser Ausführung die IP-Schicht 188). Die IP-Schicht 188 erzeugt einen IP-Kopfbereich 206 (beispielsweise IPv4-Kopfbereiche 206a in den 6A und 6C, oder IPv6-Kopfbereiche 206b in den 6B und 6D). Für die IPv6 (6B und 6D) kann die IP-Schicht 188 auch optionale Erweiterungskopfbereiche 208 erzeugen.
  • Wenn eine Sendesicherheitsverarbeitung einzusetzen ist, einschließlich einer ESP-Verschlüsselung und Authentifizierung, erzeugt die IP-Schicht 188 auch einen ESP-Kopfbereich 210, einen ESP-Anhang 212 und ein ESP-Authentifizierungsfeld 214 für die IPv4 (6A und 6C). Für die IPv6 im Transportmodus (6B) werden ein Punkt-zu-Punkt-Zielroutenfeld 216 und ein Zieloptionsfeld 218 von der IP-Schicht 188 erzeugt. Für die IPv4 in dem Tunnelmodus erzeugt die IP-Schicht 188 ferner einen neuen IPv4-Kopfbereich 220. Für die IPv6 in dem Tunnelmodus (6D) erzeugt die IP-Schicht 188 ferner einen neuen IPv6-Kopfbereich 222 und neue Erweiterungskopfbereiche 224, die dem ESP-Kopfbereich 210 vorausgehen.
  • Für den Block 200a aus 6A werden der TCP-Kopfbereich 204, die TCP-Daten 202 und der ESP-Anhang 212 verschlüsselt, wobei die Host-Software die Verschlüsselung vornehmen kann oder die beispielhafte Netzwerkschnittstellensteuerung 102 kann ausgebildet sein, die Verschlüsselung durchzuführen. Die Authentifizierung wird für den ESP-Kopfbereich 210 und den verschlüsselten TCP-Kopfbereich 204, die TCP-Daten 202 und den ESP-Anhang 212 durchgeführt. Für den Block 200b in dem Transportmodus nach IPv6 aus 6B werden die Zieloption 218, der TCP-Kopfbereich 204, die TCP-Daten 202 und der ESP-Anhang 212 verschlüsselt, und der ESP-Kopfbereich 210 wird zusammen mit dem verschlüsselten TCP-Kopfbereich 204, den TCP-Daten 202 und dem ESP-Anhang 212 authentifiziert. In den Beispielen mit dem Tunnelmodus nach IPv4 aus 6C werden der TCP-Kopfbereich 204, die TCP-Daten 202, der ursprüngliche IPv4-Kopfbereich 206a und der ESP-Anhang 212 verschlüsselt und können dann zusammen mit dem ESP-Kopfbereich 210 authentifiziert werden. Für das Beispiel im Tunnelmodus nach IPv6 in 6D werden der TCP-Kopfbereich 204, die TCP-Daten 202, der ESP-Anhang 212 und die ursprünglichen Erweiterungskopfbereiche 208 und der ursprüngliche IPv6-Kopfbereich 206b verschlüsselt, wobei diese und der ESP-Kopfbereich 210 authentifiziert werden.
  • 6E zeigt einen beispielhaften Sendeblock 200a nach dem Erzeugen des ESP-Kopfbereichs 210 und des Anhangs 212, wobei weitere Details eines beispielhaften ESP-Kopfbereichs 210 dargestellt sind. Der ESP-Kopfbereich 210 umfasst einen Sicherheitsparameterindex (SPI), der in Kombination mit der Ziel-IP-Adresse des IP-Kopfbereichs 206a und dem ESP-Sicherheitsprotokoll in einzigartiger Weise die Sicherheitsassoziation bzw. Zuordnung (SA) für den Block 200a kennzeichnet. Der ESP-Kopfbereich 210 umfasst ferner ein Sequenzzahlfeld, das einen Zahlenwert angibt, der von dem Sender und dem Empfänger verwendet wird, um einzelne Blöcke zu kenneichnen, wobei die Sender- und Empfängerwerte mit null initialisiert werden, wenn eine Sicherheitszuordnung eingerichtet ist. Die Nutzdaten des Blocks 200a enthalten einen Initialisierungsvektor (IV) 226, wenn der Verschlüsselungsalgorithmus kryptografische Synchronisationsdaten erfordert, und es sind ferner TCP-Daten 202 und TCP- oder ein anderer Schicht 4-Kopfbereich 204 enthalten.
  • Einfügebytes 230 werden hinzugefügt, um die reinen Textdaten so aufzufüllen, dass diese ein Vielfaches der Anzahl der Bytes eines Chiffrierblocks für einen Verschlüsselungsalgorithmus sind, und/oder um in korrekter Weise die nachfolgenden PAD LENGTH- bzw. „Fülllänge” und NEXT-Header- bzw. „nächster Kopfbereich”-Felder 232 und 234 in dem ESP-Anhang 212 innerhalb eines 4-Byte-Wortes einzustellen, wodurch sichergestellt wird, dass die ESP-Authentifizierungsdaten 214, die auf den Anhang 212 folgen, entsprechend einer 4-Byte-Grenze ausgerichtet sind. In dem ESP-Anhang 212 zeigt das PAD LENGTH-Feld 232 die Anzahl an Einfüge-Bytes 230 an, und das NEXT-Header-Feld 234 gibt die Art der Daten in den geschützten Nutzdaten an, etwa einen Erweiterungskopfbereich in der IPv6 oder eine Kennung für ein oberes Schichtprotokoll an (beispielsweise TCP, UDP, etc.). Wenn eine Sicherheitsverarbeitung für den Block 200a angegeben ist, modifiziert die IP-Schicht 188 den Protokoll-Kopfbereich, der unmittelbar dem ESP-Kopfbereich 210 vorausgeht (beispielsweise der IPv4-Kopfbereich 206a in dem dargestellten Block 200a), so dass dieser einen Wert (beispielsweise ”50”) in dem Protokoll-Feld besitzt (beispielsweise ”NEXT-Header”-Feld für die IPv6), wodurch angezeigt wird, dass der nachfolgende Kopfbereich 210 ein ESP-Kopfbereich ist.
  • 7A und 7B zeigen beispielhafte TCP-Blockformate 200e und 200f für die IPv4 bzw. IPv6, um den Inhalt diverser Kopfbereiche zu zeigen. In 7A ist der beispielhafte Block 200e so dargestellt, dass dieser ein TCP-Datenpaket 202, einen TCP-Kopfbereich 204, einen IPv4-Kopfbereich 206a und einen MAC-Kopfbereich 240 sowie ein 4-Byte-FCS-Feld für eine Blockprüfsequenz enthält. In 7B enthält in ähnlicher Weise der Block 200f ein TCP-Datenpaket 202, einen TCP-Kopfbereich 204 und einen MAC-Kopfbereich 240 sowie ein 4-Byte-FCS-Feld und einen IPv6-Kopfbereich 206b. In beiden Fällen wird die TCP-Prüfsumme über die TCP-Daten 202 und den TCP-Kopfbereich 204 gebildet. In dem IPv4-Beispiel 200e wird die IPv4-Kopfbereichprüfsumme über den IPv4-Kopfbereich 206a (Kopfbereich-Prüfsummenfeld des IPv4-Kopfbereichs 206a) berechnet, die IP-Gesamtlänge wird über den IPv4-Kopfbereich 206a, den TCP-Kopfbereich 204 und die TCP-Daten 202 berechnet (Gesamtlängenfeld in dem IPv4-Kopfbereich 206a) und die IEEE 802.3-Länge ist die IP-Gesamtlänge plus 0–8 Bytes in dem optionalen LLC & SNAP-Feld des MAC-Kopfbereichs 240 (802.3 Längen-/Typ-Feld in dem MAC-Kopfbereich). In dem IPv6-Beispiel 2006 aus 7B ist die IEEE 802.3-Länge die Länge der TCP-Daten 202 plus dem TCP-Kopfbereich 204 und möglicher optionaler Erweiterungs-Kopfbereiche (die in dem IPv6-Kopfbereich in 7B als das letzte Feld gezeigt sind), deren Wert in das Längen-/Typ-Feld des MAC-Kopfbereichs 240 eingeht, und die IP-Nutzdatenlänge ist die Länge der TCP-Daten 202 plus die Länge des TCP-Kopfbereichs 204 und möglicher optionaler Erweiterungs-Kopfbereiche (Nutzdatenlängenfeld des IPv6-Kopfbereichs 206b).
  • TCP-SEGMENTIERUNG
  • Es wird nun auf die 8A–8D und 9 Bezug genommen. Die Steuerung 102 kann optional eine Prüfsummenbildung senden für die TCP- und/oder IP-Schicht, eine TCP-Segmentierung und/oder eine IPsec-Sicherheitsverarbeitung durchführen. Wenn eine oder mehrere dieser Funktionen aus dem Host-Prozessor 112 an die Steuerung 102 ausgelagert werden, kann die Software 186 der Schicht 3 gewisse Felder in dem Block 200 (beispielsweise Prüfsummen, Längen, etc.) mit Pseudowerten füllen. Im Hinblick auf die TCP-Schichtsegmentierung kann die Steuerung 102 programmiert werden, um in automatischer Weise einen Sendeblock aus dem Host-Speicher 128 abzurufen, und wenn der Block groß ist, diesen großen Block in kleinere Blöcke oder kleinere Segmente zu unterteilen, die die Erfordernisse einer maximalen Sendeeinheitsgröße (MTU) des Netzwerkes 108 füllen, wobei ein TCP-Segementierungssystem 260 verwendet wird. Das Segmentierungssystem 260 umfasst eine geeignete Schaltung, die funktionsmäßig mit der Deskriptorverwaltungseinheit 130 verbunden ist, die ausgebildet ist, die Segmentierungsaufgaben auszuführen, wie sie hierin beschrieben sind. Die Steuerung 102 sendet dann diese Segmente mit dem geeigneten MAC-, IP- und TCP-Kopfbereichen. In dem dargestellten Beispiel ist der ursprüngliche TCP-Block 200 in dem Host-Systemspeicher 128 in Form eines (möglicherweise übergroßen) IEEE 802.3 oder eines Ethernet-Blockes zusammen mit MAC-, IP- und TCP-Kopfbereichen vorhanden. In der beispielhaften Steuerung 102 könnn die IP-Kopfbereiche 206 entweder die Version 4 oder die Version 6 aufweisen, und die IP- und TCP-Kopfbereiche können Optionsfelder oder Erweiterungskopfbereiche beinhalten. Die Netzwerksteuerung 102 verwendet geeignete modifizierte Versionen dieser Kopfbereiche in jedem segmentierten Block, den sie automatisch erzeugt. In der beispielhaften Vorrichtung 102 kann der ursprüngliche TCP-Block in dem Host-Systemspeicher 128 in einer beliebigen Anzahl der Puffer 194 gespeichert werden, wobei alle Kopfbereiche vom Beginn des Blockes bis zu dem TCP-Kopfbereich 204 in dem ersten Puffer 194 gespeichert werden.
  • Es sei nun auch auf die 7A und 7B verwiesen; die gleichen Felder 802.3 Länge/Typ, Gesamtlänge, Identifizierung, Kopfbereichprüfsumme, Sequenznummer, PSH, FIN und TCP-Prüfsumme des IPv4-Blocks 200e (7A) werden von der Steuerung 102 modifiziert, und die anderen werden direkt aus dem Originalblock kopiert. In 7B werden die Felder Länge/Typ, Nutzdatenlänge, Sequenznummer, PSH, FIN und TCP-Prüfsumme in dem Block 200f in der Steuerung 102 für jeden erzeugten (beispielsweise segmentierten) Block modifiziert. Um eine automatische TCP-Segmentierung für den Block 200 durch die Steuerung 102 automatisch zu ermöglichen, setzt der Treiber 190 in dem Host 112 die Bits in dem Feld MORE_CTRL (5F) des entsprechenden Sendedeskriptors 192, und beinhaltet ferner einen Gültigkeitswert für das Feld maximale Segmentgröße (MSS[13:0]) des Deskriptors 192. Für alle entsprechend erzeugten Blöcke mit Ausnahme des letzten Blockes ist die Länge des Werts des Feldes MSS[13:0] plus die Längen von MAC, IP und TCP-Kopfbereichen 240, 206 und 204 plus vier Bytes für die FCS. Die Länge des letzten erzeugten Blockes kann kürzer sein, abhängig von der Länge der ursprünglichen unsegmentierten Daten.
  • 8A zeigt eine Tabelle 250, die Blockfelder zeigt, die von der Ausgangs-ESP-Verarbeitung modifiziert werden, und 8B zeigt eine Tabelle 252 mit den Blockfeldern, die durch die Authentifizierungs-Kopfbereich-(AH)Verarbeitung modifiziert werden, wobei die Tabellen 250 und 252 ferner angeben, welche Blockfelder von der Host-Prozessorsoftware erzeugt werden, und diese werden von er Steuerung 102 hinzugefügt. Durch Abschicken eines Sendeblockes zu der Steuerung 102 für die automatische TCP-Segmentierung liefert die IP-Schicht 188 eine justierte Pseudo-Kopfbereichs-Prüfsumme in dem TCP-Prüfsummenfeld des TCP-Kopfbereichs 204. 8C und 8D stellen Tabellen 254 und 256 bereit, die Berechnungen für die Pseudokopfbereichprüfsumme für die IPv4 und IPv6 darstellen, die von der IP-Schicht-Software 188 beim Erzeugen der Sendeblöcke 200 ausgeführt werden. Der Wert dieser Prüfsumme ist eine standardmäßige TCP-Pseudo-Kopfbereichsprüfsumme, die in der Spezifizierung der Sendesteuerprotokollfunktion (RFC 793), Abschnitt 3.1 für IPv4-Blöcke und in dem Internetprotokoll, Version 6 Spezifizierung (RFC 2460), Abschnitt 8.1 für IPv6-Blocke beschrieben ist, mit der Ausnahme, dass der Wert null für die TCP-Länge in der Berechnung verwendet wird. Die Steuerung 102 addiert die TCP-Länge, die für jedes erzeugte Segment geeignet ist.
  • Für IPv4-Blöcke enthält der Pseudo-Kopfbereich 254 in 8C die 32-Bit-IP-Quellenadresse, die 32-Bit-IP-Zieladresse, ein 16-Bit-Wort, bestehend aus dem 8-Bit-Protokollfeld aus dem IP-Kopfbereich, der links mit Nullen aufgefüllt ist, und die TCP-Länge (die in diesem Fall als 0 betrachtet wird). Für IPv6-Blöcke enthält der Pseudo-Kopfbereich 256 in 8D die 128-Bit IPv6-Quellenadresse, die 128-Bit-IPv6-Zieladresse, die 16-Bit-TCP-Länge (die als null betrachtet wird), und ein 16-Bit-Wort, das aus der 8-Bit-Protokollkennung besteht, die nach links mit Nullen aufgefüllt ist. Die 8-Bit-Protokollkennung ist der Inhalt des Feldes „nächster Kopfbereich” des IPv6-Kopfbereichs oder ist der letzte IPv6-Erweiterungskopfbereich, wenn Erweiterungskopfbereiche vorhanden sind, wobei für TCP der Wert 6 ist. Wenn die Erzeugung der TCP- oder UDP-Prüfsumme ohne TCP-Segmentierung aktiviert ist, enthält die in der Pseudo-Kopfbereichprüfsumme verwendete TCP-Länge die Felder für den TCP-Kopfbereich plus die TCP-Daten. Wenn jedoch die TCP-Segmentierung aktiviert ist, stellt die Steuerung 102 automatisch die Pseudo-Kopfbereichprüfsumme so ein, dass diese die geeignete Länge für jeden erzeugten Block enthält.
  • Wenn die Steuerung 102 so programmiert ist, dass eine TCP-Segmentierung ausgeführt wird, werden die Werte der diversen modifizierten Felder in der nachfolgend beschriebenen Weise berechnet. Das Feld „Länge/Typ” bzw. LENGTH/TYPE in dem MAC-Kopfbereich 240 wird als eine Länge oder als ein Ethernettyp interpretiert, abhängig davon, ob dessen Wert kleiner als 600h ist. Wenn der Wert des Feldes 600h oder größer ist, wird das Feld als ein Ethernettyp betrachtet, in welchem Fall der Wert für das Feld „Länge/Typ” für alle erzeugten Blöcke verwendet wird. Wenn jedoch der Wert kleiner als 600h ist, wird das Feld als eine IEEE 802.3-Länge eines Feldes interpretiert, wobei dann ein geeigneter Längenwert in der Steuerung 102 für jeden erzeugten Block berechnet wird. Der für das Längenfeld erzeugte Wert gibt die Länge in Bytes des LLC-Datenbereichs des gesendeten Blockes an, wobei alle Byts nach dem Feld Länge/Typ mit Ausnahme des FCS enthalten sind, und enthält keine Auffüllbytes, die hinzugefügt werden, um den Block auf die minimale Blockgröße auszuweiten. Der Tx-Analysator 162 in der Steuerung 102 analysiert die Kopfbereiche der Sendeblöcke 200, um die IP-Version (IPv4 oder IPv6) und die Position der diversen Kopfbereiche zu bestimmen. Die IPv4-Gesamtlänge ist die Länge in Bytes des IPv4-Datagramms, das den IPv4-Kopfbereich 206a (7A), den TCP-Kopfbereich 204 und die TCP-Daten 202 enthält, und den MAC-Kopfbereich 240 oder das FCS nicht enthält. Wenn die IP-Version die Version 4 ist, verwendet die Hardware diese Information, um das Feld „Gesamtlänge” bzw. TOTAL LENGTH für jeden erzeugten Block zu korrigieren. Für die IPv6 wird das Feld „Nutzdatenlänge” bzw. PAYLOAD LENGTH als die Anzahl an Bytes des Blocks 200f zwischen dem ersten IPv6-Kopfbereich und dem FCS einschließlich jeglicher IPv6-Erweiterungskopfbereiche berechnet. Sowohl für die IPv4 als auch die IPv6 erzeugt der Tx-Analysator 162 die entsprechenden Feldwerte für Gesamtlänge” oder „Nutzdatenlänge” für jeden erzeugten Sendeblock, wobei die TCP-Segmentierung aktiviert ist.
  • Da jedes erzeugte TCP-Segment als ein separater IP-Block erzeugt wird, ist das Feld „Kennung” bzw. IDENTIFICATION in dem IPv4-Kopfbereich jedes Segmentblockes einzigartig. In dem ersten derartigen Segmentblock wird das Feld IDENTIFICATION von dem Eingangsblock durch den Tx-Analysator 162 in die geeignete Stelle in dem ersten Speicher 116 beim Aufbau des ersten Segmentblockes kopiert. Der Analysator 162 erzeugt die Felder IDENTIFICATION für nachfolgende Segmentblöcke, indem dem Wert, der für den vorhergehenden Block verwendet wurde, der Wert eins hinzugefügt wird. Für das Feld SEQUENZZAHL bzw. SEQUENCE NUMBER in dem TCP-Kopfbereich 204 erzeugt die TCP-Protokollsoftware 186 eine logische Verbindung zwischen den zwei Netzwerkknoten und behandelt alle TCP-Anwenderdaten, die über diese Verbindung in einer einzelnen Richtung gesendet werden, als einen kontinuierlichen Strom aus Bytes, wobei jeder derartige Block eine Sequenznummer zugewiesen erhält. Das TCP-Feld SEQUENZZAHL bzw. SEQUENCE NUMBER des ersten TCP-Pakets enthält die Sequenznummer des ersten Bytes in dem TCP-Datenfeld 202. Das Feld SEQUENCE NUMBER des nächsten TCP-Pakets, das über diese gleiche logische Verbindung gesendet wird, ist die Sequenznummer des vorhergehenden Pakets plus die Länge in Bytes des TCP-Datenfeldes 202 des vorhergehenden Pakets. Wenn die automatische TCP-Segmentierung aktiviert ist, verwendet der Tx-Analysator 162 der Steuerung 102 das Feld TCP-SEQUENCE NUMBER des ursprünglichen Blockes für die Sequenznummer des ersten Segmentblockes 200, und die SEQUENZNUMMER für nachfolgende Blöcke 200 wird erhalten, indem die Länge des TCP-Datenfeldes 202 des vorhergehenden Blockes 200 dem Wert des Feldes SEQUENCE NUMBER des vorhergehenden Segmentblockes 200 hinzugefügt wird.
  • Die TCP-Verschiebe-(PSH)-Markierung ist eine Angabe für den Empfänger, dass er den empfangenen Block sofort verarbeiten sollte, ohne darauf zu warten, dass beispielsweise der Eingangspuffer des Empfängers gefüllt ist, wenn der Eingangspuffer Platz für mehr als einen empfangenen Block aufweist. Wenn automatische TCP-Segmentierung angefordert wird, setzt der Analysator 162 in der Steuerung 102 das PSH-Bit auf 0 für alle erzeugten Blöcke 200 mit Ausnahme des letzten Blockes 200, der auf den Wert des PSH-Bits aus dem ursprünglichen Eingangsblock gesetzt wird, wie dieser von der TCP-Schichtsoftware 186 festgelegt ist. Die TCP-Ende-(FIN)Markierung ist eine Angabe für den Empfänger, dass der Sender keine weiteren Daten zum Senden aufweist. Wenn die automatische TCP-Segmentierung angefordert wird, setzt der Analysator 162 das FIN-Bit für alle erzeugten Segmentblöcke 200 mit Ausnahme des letzten Blockes 200 auf 0. Der Analysator 162 setzt den Wert des FIN-Bits aus dem ursprünglichen Eingangsblock (beispielsweise von der TCP-Schichtsoftware 186) für den Wert des FIN-Bits in dem letzten erzeugten Segmentblock 200 ein.
  • PRÜFSUMMENERZEUGUNG UND VERIFIZIERUNG
  • Die beispielhafte Steuerung 102 kann so programmiert oder konfiguriert sein, dass Schicht 3-(beispielsweise IP) und/oder Schicht 4-(beispielsweise TCP, UDP etc.)Prüfsummen für gesendete Blöcke 200 erzeugt werden, und dass automatisch derartige Prüfsummen für eintreffende (beispielsweise empfangene) Blöcke 200 verifiziert werden. Die beispielhafte Steuerung 102 umfasst IP-Prüfsummen, definiert nach RFC 791 (Internet Protokoll), TCP-Prüfsummen, definiert nach RFC 793 (Sende-Steuer-Protokoll) für IPv4-Blöcke 200e, UDP-Prüfsummen, definiert nach RFC 768 (Anwender-Datagramm-Protokoll) für IPv4-Blöcke, sowie TCP- und UDP-Prüfsummen für IPv6-Blöcke 200f gemäß dem RFC 2460 (Internetprotokoll, Version 6 Spezifizierung). Mit Bezug zu IP-Prüfsummen wird der Wert des Feldes „Kopfbereich”- bzw HEADER CHECKSUM in den IPv4-Kopfbereich 206a in dem Sende-Prüfsummen-System 164 als ein 16-Bit-einser-Komplement einer Einser-Komplementsumme aller Daten in dem IP-Kopfbereich 206a, der als eine Serie von 16-Bit-Wörtern gehandelt wird, berechnet. Da die Felder GESAMTLÄNGE bzw. TOTAL LENGTH und KENNUNG bzw. IDENTIFICATION für jeden erzeugten Segmentblock 200e unterschiedlich sind, berechnet das Sende-Prüfsummensystem 164 einen Wert des Feldes HEADER CHECKSUM für jeden erzeugten Segmentblock, den die Steuerung 102 erzeugt.
  • Das Sende-Prüfsummensystem 164 kann ferner TCP-Schicht-Prüfsummen für abgehende Blöcke 200 berechnen. Der Wert für das Feld TCP-CHECKSUM in dem TCP-Kopfbereich 204 wird als ein 16-Bit Einer Komplement einer Einer-Komplementsumme des Inhalts des TCP-Kopfbereichs 204, der TCP-Daten 202 und eines Pseudo-Kopfbereichs berechnet, der Information auf dem IP-Kopfbereich enthält. Die Kopfbereiche und das Datenfeld werden als eine Sequenz aus 16-Bit-Zahlen behandelt. Beim Berechnen der Prüfsumme wird das Prüfsummenfeld selbst durch Nullen ersetzt. Die Prüfsumme deckt auch einen 96 Bit-Pseudo-Kopfbereich (8C oder 8D) ab, der konzeptionell dem TCP-Kopfbereich als Präfix vorausgeht. Dieser Pseudo-Kopfbereich enthält die Quellenadresse, die Zieladresse, das Protokoll und die TCP-Länge. Wenn das TCP-Datenfeld eine ungeradzahlige Anzahl an Bytes enthält, wird das letzte Byte auf der rechten Seite zum Zwecke der Prüfsummenberechnung mit Nullen aufgefüllt. (Dieses aufgefüllte Byte wird nicht gesendet). Um die TCP-Prüfsumme für einen Segmentblock 200 zu erzeugen, aktualisiert das Sende-Prüfsummensystem 164 das Feld TCP-SEQUENCE NUMBER bzw. SEQUENZNUMMER und die PSH- und FIN-Bits des TCP-Kopfbereichs 204 und setzt das Feld TCP-CHECK-SUM bzw. PRÜFSUMME auf den Wert des Feldes TCP-PRÜFSUMME aus dem ursprünglichen Eingangsblock 200. Ferner initialisiert das Sende-Prüfsummensystem 164 einen internen 16-Bit-Prüfsummenakkumulator mit der Länge in Bytes des TCP-Kopfbereichs 204 plus des TCP-Datenfeldes 202 und addiert die Einer-Komplementsumme aller 16-Bit-Wörter, die den modifizierten TCP-Kopfbereich 204 bilden, gefolgt von den TCP-Daten 202 für das Segment, zu dem Akkumulator und speichert das Einer-Komplement des Ergebnisses in dem Feld TCP-PRÜFSUMME des Segmentblocks 200.
  • Die Bits IPCK und L4CK in dem Sendedeskriptor 192a (5F) steuern das automatische Erzeugen der Prüfsummen für gesendete Blöcke 200 in der Steuerung 102. Das Setzen des IPCK-Bits veranlasst, dass die IP-Kopfbereichprüfsumme erzeugt und an die geeignete Stelle in dem IPv4-Block 200e aus 7A eingesetzt wird. In ähnlicher Weise verursacht das Setzen des L4CK-Bits, dass die TCP-PRÜFSUMME oder eine UDP-Prüfsumme erzeugt wird, abhängig davon, welche Art an Schicht 4-Kopfbereich in dem abgehenden Block 200 vorgefunden wird. Da ein IPv6-Kopfbereich 206b (7B) kein Kopfbereichprüfsummenfeld aufweist, wird das IPCK-Bit in dem Deskriptor für IPv6-Blöcke 200f ignoriert. Wenn für einen abgehenden Block 200 eine TCP- oder UDP-Prüfsummenerzeugung erforderlich ist, setzt die Schicht 4-Software 186 auch die Pseudo-Kopfbereichprüfsumme in das TCP- oder UDP-Prüfsummenfeld. Die Steuerung 102 ersetzt dann diesen Wert durch die Prüfsumme, die sie über das gesamte TCP- oder UDP-Segment berechnet, wobei die Werte der erzeugten TCP- oder UDP-Prüfsummen sich unterscheiden, wenn die TCP-Segmentierung aktiviert ist. Für TCP-Segmentierung wird der Wert 0 für die TCP-GE-SAMTLÄNGE bei der Berechnung der Pseudo-Kopfbereichprüfsumme verwendet. Für die TCP- oder UDP-Prüfsummenerzeugung ist der Wert TCP-GESAMTLÄNGE die Länge des TCP-Kopfbereichs 204 plus die Länge der TCP-Daten 202, wie dies in den zuvor genannten RFCs beschrieben ist.
  • Die Steuerung 102 kann ferner durch den Host 112 konfiguriert oder programmiert sein, um Prüfsummen für empfangene Blöcke mittels des Prüfsummen- und Einfügeprüfsystems 156 zu verifizieren. Wenn die Steuerung 102 so aktiviert ist oder wenn eine Sicherheits-(beispielsweise IPsec-)Verarbeitung erforderlich ist, prüft sie eintreffende (beispielsweise empfangene) Blöcke, um IPv4-, IPv6-, TCP- und UDP-Kopfbereiche zu erkennen, und schreibt die entsprechenden Codierungen in die Felder IP_HEADER bzw. IP_KOPFBEREICH und L4_HEADER bzw. L4_KOPFBEREICH des Empfangsstatusrings 199 (5J), um anzugeben, welche Schicht 3- und/oder Schicht 4-Kopfbereiche erkannt wurden. Wenn die Vorrichtung einen Kopfbereich mit einer Prüfsumme erkennt, berechnet das Empfangsprüfsummen- und Einfügeprüfsystem 156 die geeignete Prüfsumme, wie sie beschrieben ist in RFC 791, RFC 793, RFC 768 oder RFC 2460 und vergleicht das Ergebnis mit der in dem empfangenen Block ermittelten Prüfsumme. Wenn die Prüfsummen nicht übereinstimmen, setzt die Vorrichtung das Bit IP_CK_ERR und/oder L4_CK_ERR in dem entsprechenden Eintrag des Empfangsstatusrings 199.
  • Gemäß den 12, 13A und 13B werden nunmehr weitere Details der Sendeprüfsummenerzeugung dargestellt und beschrieben. In 12 ist ein Teil der Steuerung 102 in Bezug auf das Erzeugen eines TCP-Prüfsummenwerts 290 für einen abgehenden Datenblock 200 mit einem ESP-Sicherheitskopfbereich 210 dargestellt. 13A und 13B zeigen ein beispielhaftes Sendeprüfsummenverarbeitungsverfahren 300, das in der Netzwerkschnittstellensteuerung 102 eingerichtet sein kann. Die TCP-Prüfsummenverarbeitung für abgehende Daten beginnt bei 302 in 13A, wobei der Schicht-3-Kopfbereich (beispielsweise IP-Kopfbereich) bei 303 analysiert wird, um die Art des nachfolgenden Kopfbereichs zu bestimmen und es wird eine Festlegung bei 304 getroffen, ob ein Sicherheitskopfbereich in dem abgehenden Datenblock vorhanden ist. Wie in 12 zu erkennen ist, enthält der beispielhafte Block 200 in dem Zusammenfüge-RAM 160 einen IP-Kopfbereich 206, an den sich ein ESP-Sicherheitsbereich 210 anschließt. In dieser Situation besitzt der IP-Kopfbereich 206 einen Wert von 50 in seinem Feld PROTOKOLL (IPv4) oder in seinem Feld NEXT-HEADER bzw. nächster Kopfbereich (IPv6), wodurch angegeben wird, dass der nachfolgende Kopfbereich 210 ein ESP-Sicherheitskopfbereich ist. In Der Steuerung 102 analysiert der Sendeprüfsummenanalysator 162 den IP-Kopfbereich 206, wenn dieser gleichzeitig dem TX-Prüfsummensystem 164 und dem ersten Speicher 216 zugeführt wird, um den Wert dieses Feldes festzustellen. Wenn das Feld PROTOKOLL/NEXT HEADER des IP-Kopfbereichs einen Wert von 50 aufweist, enthält der Block 200 einen Sicherheitskopfbereich (JA im Schritt 304) und das Verfahren 300 geht zu 306 weiter. Ansonsten geht das Verfahren zu 340 in 13B weiter, wie dies nachfolgend erläutert ist.
  • Bei 306 erhält die Deskriptorverwaltungseinheit 130 einen Sendedeskriptor 192a von dem Host-Treiber 190 (beispielsweise über dem Host-Speicher 106) und erhält eine Sendeprüfsummeninformation von dem Deskriptor bei 308. Um einen TCP-Prüfsummenwert 290 über den gesamten TCP-Prüfsummenbereich in dem Block 200 zu berechnen, muss der Sendeanalysator 162 Anfangs- und Endpunkte 292 und 294 für den TCP-Prüfsummenbereich bestimmen (beispielsweise einschließlich des TCP-Kopfbereichs 204 und des TCP-Datenpakets 202). Dies kann unter Anwendung der Prüfsummeninformation bewerkstelligt werden, die in dem Sendedeskriptor 192a bereitgestellt wird, die die Felder TFLAGS1, PAD_LEN und NXT_HDR (5E und 5F) enthält. Bei 310 wird das L4CK-Bit des Feldes TFLAGS1 geprüft. Wenn der Wert 0 beträgt (NEIN bei 310), geht das Verfahren 300 zu 312 weiter, da dieser Wert angibt, dass die TCP-Prüfsummenbildung für diesen Block 200 nicht gefordert ist. Beispielsweise kann das Host-System 180 für das Berechnen von Prüfsummen der Schicht 4 verantwortlich sein, in welchem Falle der TCP-Kopfbereich 214 einen geeigneten Prüfsummenwert enthält, bevor der Block 200 zur Steuerung 102 für das Senden weitergeleitet wird.
  • Wenn das L4CK-Bit gleich 1 ist (JA bei 310), geht das Verfahren 300 zu 313 weiter, wobei der Sendeanalysator 162 die Art des Kopfbereichs, der auf den Sicherheitskopfbereich folgt, durch Analysieren bestimmt. Es wird dann bei 314 bestimmt, ob der auf den Sicherheitskopfbereich folgende Kopfbereich ein Kopfbereich der Schicht 4 ist (beispielsweise TCP in diesem Fall). Wenn nicht (NEIN bei 314), fährt der Sendeanalysator 162 mit der Analyse dazwischen liegender Kopfbereiche fort (beispielsweise Eerweiterungs-Kopfbereiche, wie sie in 6D gezeigt sind), bis ein Kopfbereich der Schicht 4 angetroffen wird. Sobald der Kopfbereich der Schicht 4 angetroffen wird, wird bei 316 und 318 bestimmt, ob die Information des Kopfbereichs der Schicht 4 aus dem Deskriptor 192a TCP oder UDP ist. In dem gezeigten Beispiel nimmt die Steuerung 102 an, wenn die Information des nächsten Kopfbereichs aus dem Deskriptor 192a weder TCP noch UDP ist (NEIN sowohl in 316 und 318), dass eine Diskrepanz besteht, und das Verfahren 300 geht zu 312 weiter (es wird kein Prüfsummenwert für die Schicht 4 berechnet). Wenn die Information des nächsten Kopfbereichs aus dem Deskriptor 192a angibt, dass ein UDP- oder TCP-Kopfbereich auf den Sicherheitskopfbereich folgt (JA bei 316 oder 318), geht das Verfahren 300 zu 320 und 322 weiter, wo die Prüfsummenberechnung der Schicht 4 gemäß der Sendeprüfsummeninformation und der analysierten Information des Kopfbereichs der Schicht 3 beginnt bzw. endet.
  • Insbesondere wird die Information des nächsten Kopfbereichs NXT_HDR von dem Sendedeskriptor 192a bei 320 verwendet, um den Startpunkt für die Prüfsummenberechnung der Schicht 4 zu bestimmen, und die Fülllänge PAD_LEN und die IV-Längeninformation von dem Deskriptor 192a werden bei 322 verwendet. Der Analysator 162 stellt die Lage des Endes des TCP-Datenfeldes 202 fest, indem die IP-Gesamtlänge oder Nutzdatenlängeninformation von dem analysierten Kopfbereich der Schicht 3 (IPv4 oder IPv6 in den 7A und 7B) verwendet wird, und die Summe der Längen des Sicherheitskopfbereichs (der bei 303 analysiert wird) und anderer dazwischen liegender Kopfbereiche (die bei 315 analysiert werden) subtrahiert wird, und indem ferner die Längen des ESP-Anhangs 212 und des ESP-Authentifizierungsfeldes 214 subtrahiert werden. Der ESP-Anhang 212 enthält die Füllbytes 230 (6E), deren Länge aus der PAD_LEN-Information des Sendedeskriptors 192a bekannt ist, und die Länge des ESP-Authentifizierungsfeldes 214 ist aus den Bits IV-LEN1 und IVLEN0 in dem TFLAGS1-Bereich 193 des Sendedeskriptors 192a bekannt. Der resultierende Wert dieser Berechnung ist die Länge des TCP-Kopfbereichs 204 und der TCP-Daten 202, der bei 322 zur Beendigung der TCP-Prüfsummenberechnung verwendet wird.
  • Der Sendeanalysator 162 steuert das Sendeprüfsummensystem 162 so, dass die Prüfsummen der Rechnung gemäß den Start- und Endpunkten 292 und 294 begonnen wird, und das System 164 erzeugt den Prüfsummenwert 290 (beispielsweise einen TCP-Prüfsummenwert in diesem Fall) in entsprechender Weise. Sobald die Berechnung des Prüfsummenwertes abgeschlossen ist, geht das Verfahren 300 zu 324 weiter, wo das Sendeprüfsummensystem 164 den Prüfsummenwert 290 in die geeignete Stelle in dem ersten Speicher 116 einfügt (beispielsweise in den TCP-Kopfbereich 204), wonach der Vorgang der Prüfsumme der Schicht 4 bei 326 endet. Danach wird bei 328 eine beliebige ausgewählte Sicherheitsverarbeitung ausgeführt (beispielsweise unter Verwendung des IPsec-Systems 124), und der abgehende Block wird bei 330 in das Netzwerk 108 gesendet. Wenn keine Prüfsumme der Schicht 4 ausgeführt wird, geht das Verfahren 300 von 312 direkt zu 328 für eine erforderliche Sicherheitsverarbeitung weiter, bevor der Block bei 330 gesendet wird.
  • Wenn gemäß 13B kein Sicherheitskopfbereich in dem abgehenden Datenblock 200 vorhanden ist (ein NEIN bei 304), geht das Verfahren 300 zu 340 in 13B weiter, wo bestimmt wird, ob das L4CK-Bit aus dem Sendedeskriptor 192a gleich 1 ist. Wenn nicht (NEIN in 340), geht das Verfahren 300 zu 342 weiter, und es wird keine Prüfsummenberechnung der Schicht 4 für den Block 200 ausgeführt. Wenn das L4CK-Bit gleich 1 ist (JA in 340), wird in 346 und 348 bestimmt, ob der Kopfbereich der Schicht 4 TCP oder UDP ist. Wenn die Information über den nächsten Kopfbereich aus dem IP-Kopfbereich 206 weder TCP noch UDP ist (NEIN sowohl in 346 als auch 348), nimmt die Steuerung 102 an, dass eine Diskrepanz besteht, und das Verfahren 300 geht zu 342 weiter (es wird kein Prüfsummenwert für die Schicht 4 berechnet). Wenn die Information für den nächsten Kopfbereich angibt, dass ein TCP- oder UDP-Kopfbereich auf den IP-Kopfbereich 206 folgt (ein JA bei 346 oder 348), beginnt die Prüfsummenwertberechnung bei 350 und endet bei 352 gemäß der analysierten Information. Sobald die Berechnung der Prüfsumme der Schicht 4 bei 352 abgeschlossen ist, wird der Prüfsummenwert 290 in den Block 200 in den Speicher 116 eingefügt, die Vorgänge für die Sendeprüfsumme werden bei 356 beendet und das IPsec-System 124 leitet den Block 200 zu dem zweiten Speicher 118 weiter (beispielsweise wird in diesem Falle keine Sicherheitsverarbeitung ausgeführt). Das Verfahren 300 kehrt dann zu 330 zurück (13A), und der Block 200 wird in das Netzwerk 108 gesendet.
  • SICHERHEITSVERARBEITUNG
  • Es wird auf die 2–4, 9, 10 und 11A–11E verwiesen; das beispielhafte IPsec-Sicherheitssystem 124 ist konfigurierbar, so dass Internetprotokoll-Sicherheits-(IPsec)Authentifizierungs- und/oder Verschlüsselungs-/Entschlüsselungsdienste für gesendete und empfangene Blöcke 200 gemäß RFC 2401 bereitgestellt werden. Für eine Verarbeitung mit Authentifizierungs-Kopfbereich (AH) implementiert das Modul den HMAC-MD5-96-Algorithmus, der in RFC 2403 definiert ist, und den HMAC-SHA-1-96, der in RFC 2404 definiert ist. Die HMAC-MD5-96-Implementierung stellt einen 128-Bit Schlüssel, eine 512-Bit Blockgröße und einen 128-Bit Nachrichten-Authentifizierungscode (MAC), der auf 96 Bits aufgeteilt ist, bereit. Die Implementierung des HMAC-SHA-1-96-Algorithmus stellt einen 160-Bit Schlüssel, eine 512-Bit Blockgröße und eine 160-Bit Nachrichten-Authentifizierungscodierung (MAC), die auf 96 Bits unterteilt ist, bereit. Für eine einkapselnde Sicherheitsnutzdaten-(ESP)Verarbeitung enthält das IPsec-Modul 124 ferner die HMAC-MD5-96- und HMAC-SHA-1-96-Algorithmen für die Authentifizierung und die ESP DES-CBC (RFC 2406), die 3DES-CBC und die AES-CBC (draft-ietf-IPsec-ciph-aes-cbc-01) Verschlüsselungsalgorithmen. Der DES-CBC-Algorithmus in dem IPsec-Modul 124 stellt einen 64-Bit-Schlüssel (einschließlich 8 Paritätsbits), eine 64-Bit-Blockgröße und eine Chiffrierblockverkettung (CBC) mit explizitem Initialisierungsvektor (IV) bereit. Der 3DES-CBC-Algorithmus stellt einen 192-Bit Schlüssel (mit 24 Paritätsbits), eine 64-Bit Blockgröße und einen CBC mit explizitem IV bereit. Der AES-CBC-Algorithmus stellt einen 128-, 192- oder 256-Bit Schlüssel mit Rundung 10, 12 oder 14, abhängig von der Schlüsselgröße, eine 128-Bit Blockgröße und einen CBC mit explizitem IV bereit.
  • Das beispielhafte Sicherheitssystem 124 bietet kryptografisch basierte IPsec-Sicherheitsdienste für die IPv4 und IPv6 einschließlich einer Zugriffssteuerung, einer verbindungslosen Integrität, einer Datenursprungsauthentifizierung, einem Schutz gegen Wiederholung (einer Form einer teilweisen Sequenzintegrität), Vertraulichkeit (Verschlüsselung) und einer begrenzten Datenverkehrstromvertraulichkeit. Diese Dienste werden von der Schicht 3 (IP-Schicht) bereitgestellt, wodurch Schutz für IP-Schichten und/oder weiter oben liegende Schichtprotokolle durch die Verwendung zweier Verkehrssicherheitsprotokolle durch den Authentifizierungs-Kopfbereich (AH) und die eingekapselten Sicherheitsnutzdaten (ESP) und durch die Verwendung von Verfahren zur kryptografischen Schlüsselverwaltung und entsprechenden Protokollen geboten wird. Der IP-Authentifizierungs-Kopfbereich (AH) bietet verbindungslose Integrität, Datenursprungs-Authentifizierung und einen optionalen Anti-Wiederholungsdienst, und das ESP-Protokoll bietet Vertraulichkeit (Verschlüsselung) und eine begrenzte Datenverkehrsstromvertraulichkeit und kann verbindungslose Integrität, Datenursprungs-Authentifizierung und Anti-Wiederholungsdienste bieten. Die AH- und ESP-Sicherheitsmerkmale können alleine oder in Kombination angewendet werden, um einen gewünschten Satz an Sicherheitsdiensten in der IPv4 und IPv6 bereitzustellen, wobei beide Protokolle einen Transportmodus und einen Tunnelmodus unterstützen. Im Transportmodus bieten die Protokolle hauptsächlich Schutz für obere Schichtprotokolle und in dem Tunnelmodus werden die Protokolle auf im Tunnelmodus verarbeitete IP-Pakete angewendet.
  • Für abgehende Blöcke 200 stellt die Steuerung 102 selektiv die IPsec-Authentifizierungsverarbeitung und/oder die Verschlüsselungsverarbeitung gemäß den Sicherheitsassoziationen bzw. Zuordnungen (SAs) bereit, die in dem SA-Speicher 140 abgelegt sind. Wenn ein abgehender Block 200 eine IPsec-Authentifizierung erfordert, berechnet die IPsec-Einheit 124 einen Integritätsprüfwert (ICV) und fügt den ICV in den AH-Kopfbereich oder den ESP-Anhang 212 (6A–6D) ein. Wenn der Block 200 eine Verschlüsselung erfordert, ersetzt die Einheit 124 die ursprünglichen Nutzdaten durch eine verschlüsselte Version. Für eintreffende (beispielsweise empfangene) Blöcke analysiert die IPsec-Einheit 124 IPsec-Kopfbereiche, um zu bestimmen, welche Verarbeitung erforderlich ist. Wenn ein IPsec-Kopfbereich angetroffen wird, verwendet das IPsec-System 124 den Sicherheitsparameterindex (SPI) aus dem Kopfbereich plus die IPsec-Protokollart und die IP-Zieladresse, um den SA-Speicher 140 abzusuchen, um eine Sicherheitszuordnung entsprechend dem empfangenen Block abzurufen. Zu akzeptablen Kombinationen aus IPsec-Kopfbereichen für die beispielhafte Steuerung 102 gehören ein AH-Kopfbereich, ein ESP-Kopfbereich und ein AH-Kopfbereich mit einem anschließenden ESP-Kopfbereich.
  • Für einen IPsec-Schlüsselaustausch verhandelt der Host 112 SAs mit entfernten Stationen und schreibt SA-Daten in den SA-Speicher 140. Ferner hält der Host 112 ferner eine IPsec-Sicherheitspolitikdatenbank (SPD) in dem Systemspeicher 128 aufrecht. Für jeden gesendeten Block 200 prüft der Host-Prozessor 112 die SPD, um zu bestimmen, welche Sicherheitsverarbeitung erforderlich ist, und gibt diese Information an die Steuerung 102 in dem Sendedeskriptor 192a (5E) als einen Zeiger SA_PTR[14:0] auf die geeignete SA in dem SA-Speicher 140 weiter. Für eintreffende empfangene Blöcke 200 berichtet die Steuerung 102, welche Sicherheitsverarbeitung sie in dem Empfangsstatusringeintrag 199 ausgeführt hat (5J), und der Host-Prozessor 112 überprüft die SPD, um zu verifizieren, dass der Block 200 mit der ausgehandelten Politik bzw. Strategie übereinstimmt. Die SAs enthalten Informationen, die die Art der Sicherheitsverarbeitung beschreiben, die ausgeführt werden muss, und über die Verschlüsselungsschlüssel, die zu verwenden sind. Einzelne Sicherheitszuordnungen beschreiben eine Ein-Wege-Verbindung zwischen zwei Netzwerkeinheiten, wobei eine bidirektionale Verbindung zwei SAs für den eingehenden und den abgehenden Datenverkehr erfordert. SAs für eintreffenden Datenverkehr werden teilweise in einer internen SPI-Tabelle oder einem Speicher 270 (10) und teilweise in dem externen SA-Speicher 140 abgelegt. Diese SA-Tabellen werden von dem Host-Prozessor 112 unterhalten, der indirekt in die SPI-Tabelle 270 und in den SA-Speicher 140 schreibt, indem zunächst in einen SA-Datenpuffer in dem Host-Speicher 128 und anschließend ein Befehl für das SA-Adressenregister geschrieben wird. Dies veranlasst die Steuerung 102, die Daten in den externen SA-Speicher 140 und in den internen SPI-Tabellenspeicher 270 zu kopieren.
  • Eines der Felder in einem SPI-Tabelleneintrag ist eine Kontrollsummencodierung, die von dem Host 112 gemäß der IP-Zieladresse berechnet wird. Des Weiteren berechnet der Host 112 eine Kontrollsummencodierung auf der Grundlage des SPI, um zu bestimmen, wohin in eine SPI-Tabelle zu schreiben ist. Wenn eine eintreffende oder abgehende SA eine Authentifizierung erfordert, berechnet die Host-CPU die Werte H(K XOR ipad) und H(K XOR opad), wie sie definiert sind in RFC 2104, HMAC: Schlüssel-basierte Kontrollsummenbildung für Nachrichten-Authentifizierung, wobei der Host 112 die beiden 128- oder 160-Bit-Werte in dem SA-Speicher 140 ablegt. Bei Bedarf kann während der Initialisierung die Host-CPU die Initialisierungsvektor-(IV)Register, die für die Chiffrierungsblockverkettung in jeder von vier Verschlüsselungsmaschinen in dem IPsec-System 124 verwendet sind, indirekt initialisieren.
  • Es sei auf die 2 und 9 verwiesen; um einen Sendeprozess zu beginnen, bereitet der Host-Prozessor 112 einen Sendeblock 200 in einem oder mehreren Datenpuffern 194 in dem Host-Speicher 128 vor, schreibt einen Sendedeskriptor 192a (beispielsweise 5E) in einen der Sendedeskriptorringe und aktualisiert den entsprechenden Sendedeskriptorschreibzeiger (TX_WR_PTR[x]). Die Blockdaten in den Datenpuffern 194 enthalten Platz in den IPsec-Kopfbereichen für Authentifizierungsdaten 214, für einen Initialisierungsvektor (IV) 226 und für einen ESP-Anhang 212, wenn dies erforderlich ist (beispielsweise 6E). Der Inhalt dieser Felder wird von dem IPsec-System 124 in der Steuerung 102 erzeugt. Wenn in ähnlicher Weise eine Auffüllung erforderlich ist, (beispielsweise zur Anpassung, oder um die ESP-Nutzdaten zu einem ganzzahligen Vielfachen der Verschlüsselungsblöcke zu modifizieren), wird das Auffüllen bzw. Einfügen in den Host-Speicherpuffern 194 ausgeführt, und die Sequenzzahlen für die Felder AH und ESP-SEQUENZZAHL werden in den Datenpuffern 194 von dem Host 112 bereitgestellt. Das IPsec-System 124 modifiziert diese Felder nicht, sofern nicht die automatische TCP-Segmentierung ebenso ausgewählt ist, in welchem Falle das IPsec-System 124 die Sequenznummern aus den Puffer 194 für den ersten erzeugten Block 200 verwendet und diese Zahlen in geeigneter Weise für den Rest der erzeugten segmentierten Blöcke inkrementiert. Wenn eine IPsec-Verarbeitung für einen speziellen abgehenden Block 200 erforderlich ist, enthält der entsprechende Sendedeskriptor 192a einen Zeiger in das SA_PTR-Feld zu dem geeigneten SA-Eintrag in dem externen SA-Speicher 140, und das IPsec-System 124 verwendet Information aus dem SA, um zu bestimmen, wie der Block 200 zu verarbeiten ist. Der Sendeanalysator 162 untersucht den Block 200, um den Start- und Endpunkt für die Authentifizierung und/oder Verschlüsselung zu bestimmen, und um zu erkennen, wo bei Bedarf die Authentifizierungsdaten 214 einzufügen sind.
  • Wenn eine ESP-Verschlüsselung erforderlich ist, verschlüsselt das IPsec-System 124 die Nutzdaten unter Anwendung des Algorithmus und des Schlüssels, wie sie in der SA spezifiziert sind. Wenn eine ESP-Authentifizierung erforderlich ist, verwendet das System 124 den Authentifizierungsalgorithmus und die IPAD/OPAD-Information, die in dem SA spezifiziert ist, um den Authentifizierungsdatenintegritatsprüfwert (ICV) zu berechnen und speichert das Ergebnis in dem Authentifizierungsdatenfeld 214. Wenn sowohl ESP-Verschlüsselung als auch Authentifizierung erforderlich sind, wird zunächst die Verschlüsselung ausgeführt, und die verschlüsselten Nutzdaten werden dann bei den Authentifizierungsberechnungen verwendet. Die Verschlüsselung und die Authentifizierungsprozesse werden in Pipelineart ausgeführt, so dass die Verschlüsselungsmaschine in einem der IPsec-Prozessoren 174 einen Block aus Daten verarbeitet, während die Authentifizierungsmaschine den vorhergehenden Block verarbeitet. Das IPsec-System 124 hängt keine Auffülldaten an das Nutzdatenfeld an, sofern nicht die automatische TCP-Segmentierung ebenso aktiviert ist. Der Host-Prozessor 112 versorgt den ESP-Anhang 212 mit einer geeigneten Auffüllung in den Blockdatenpuffern 194 in dem Systemspeicher 128, und stellt ferner den geeigneten Wert für das Feld ESP SEQUENZNUMMER in dem ESP-Kopfbereich 210 bereit (6E).
  • Wenn die ESP-Verarbeitung mit der automatischen TCP-Segmentierung kombiniert wird, fügt das IPsec-System 124 eine erforderliche Anzahl an Füll-Bytes hinzu, um die verschlüsselte Datenlänge zu einem mehrfachen der Blocklänge zu machen, die für den ausgewählten Verschlüsselungsalgorithmus spezifiziert ist. Wenn eine ESP-Verarbeitung mit einer TCP- oder einer UDP-Prüfsummenerzeugung kombiniert wird, stellt der Host 112 korrekte Werte für NEXT HEADER bzw. nächster Kopfbereich und PAD LENGTH bzw. AUFFÜLLÄNGE für den ESP-Anhang 212 und den Sendedeskriptor 192a (5E) bereit. Wenn die ESP-Verarbeitung mit der automatischen TCP-Segmentierung kombiniert wird, stellt der Host 112 Werte für die Felder NEXT HEADER und PAD LENGTH für den Sendedeskriptor 192a bereit, die mit den entsprechenden Blockdatenpuffern 194 konsistent sind. In dieser Kombination kopiert die Steuerung 102 das Feld NEXT HEADER von dem Sendedeskriptor 192a in den ESP-Anhang 212 jedes erzeugten Blocks 200 und verwendet das Feld PAD LENGTH des Deskriptors 192a, um das Ende des TCP-Datenfelds 202 in dem Blockdatenpuffer 194 zu erkennen. Des Weiteren wird das Feld für die maximale Segmentgröße MSS[13:0] des Sendedeskriptors 192a vermindert, um eine Kompensation im Hinblick auf den oder die IPsec-Kopfbereiche, die ESP-Auffüllung und den ICV zu erhalten.
  • Wenn eine ESP-Verarbeitung mit der TCP-Segmentierung oder mit der TCP- oder UDP-Prüfsummenerzeugung kombiniert wird, setzt der Softwaretreiber 190 die Bits ESP AH, IVLEN0 und IVLEN1 des Sendedeskriptors 192a in entsprechender Weise. Der Sendeanalysator 162 verwendet diese Information, um den TCP- oder UDP-Kopfbereich 204 aufzufinden, und wenn keine TCP- oder UDP-Verarbeitung erforderlich ist, werden diese Bits ignoriert. Für Blöcke 200, die eine ESP-Verarbeitung erfordern, zeigt 8A, welche Felder von dem Host 112 erzeugt und in die Puffer 194 eingefügt werden, und zeigt jene Felder, die von der ESP-Verarbeitungshardware in dem Sicherheitssystem 124 modifiziert werden.
  • Die Verschlüsselungsalgorithmen, die von dem IPsec-System 124 unterstützt werden, verwenden einen Modus mit Chiffrierblockverkettung (CBC) mit expliziten Initialisierungsvektoren (IVs 226, 6E). Um ein gewisses Maß an paralleler Verarbeitung zu ermöglichen, enthält das IPsec-System 124 zwei TX-IPSEC-Prozessorsysteme 174a und 174b, wovon jedes ein DES/3DES-(Datenverschlüsselungsstandard) Verschlüsselungssystem und eine erweiterte Verschlüsselungsstandard(AES)-Verschlüsselungsmaschine aufweist. Jede der vier Verschlüsselungsmaschinen in den TX IPSEC-Prozessoren 174 umfasst ein IV-Register, die beim Rücksetzen auf null gesetzt werden. Wenn die Steuerung 102 aktiviert wird, wird der Inhalt der IV-Register, die einer Verschlüsselungsmaschine zugeordnet sind, als der Initialisierungsvektor 226 für den ersten Sendeblock 200 verwendet, der von dieser Maschine verschlüsselt wird. Danach wird der letzte verschlüsselte Datenblock aus einem Block 200 als der IV 226 für den folgenden Block 200 verwendet. Der Host-Prozessor 112 kann die IV-Register in dem IPsec-System 124 beispielsweise mit Zufallsdaten initialisieren, indem z. B. Blöcke 200 mit Zufallsdaten in den Nutzdatenfeldern gesendet werden. In einem Beispiel kann der Host 112 die externe PHY-Einrichtung in einen isolierten Modus versetzen, um zu verhindern, dass diese Zufallsdatenblöcke 200 das Netzwerk 108 erreichen. Das IPsec-System 124 fügt den IV-Wert 226 zu Beginn des Nutzdatenfeldes ein. Der Host 112 stellt Platz in dem Blockdatenpuffer 194 für dieses Feld 226 bereit. Die Länge des IV 226 ist die gleiche wie die Verschlüsselungsblockgröße, die in den TX IPSEC-Prozessoren 174 verwendet wird, beispielsweise 64 Bits für DES- und 3DES-Algorithmen und 128 Bits für den AES-Algorithmus.
  • Wenn eine Verarbeitung mit Authentifizierungskopfbereich (AH) ausgewählt ist, verwendet das Sicherheitssystem 124 einen Authentifizierungsalgorithmus und Authentifizierungsipad- und opad-Daten, die in der SA spezifiziert sind, um den Authentifiziermgsdatenintegritätsprüfwert (ICV) zu berechnen, und speichert die Ergebnisse in dem Authentifizierungsdatenfeld 214 ab. Der Sende-IPsec-Analysator 170 erkennt deaktivierbar Felder (wie sie durch die AH-Spezifizierung RFC 2402 definiert sind) und stellt sicher, dass der Inhalt dieser Felder und das Authentifizierungsdatenfeld 214 als null für die Berechnung der ICV behandelt wird. Bei der ICV-Berechnung verwendet das IPsec-System 124 die Zieladresse aus dem SA anstelle der Zieladresse aus dem IP-Kopfbereich 206 des Pakets, um sicherzustellen, dass wenn Quellen-Signalführungsoptionen oder Erweiterungen vorhanden sind, die Adresse des letzten Ziels in der Berechnung verwendet wird. Für Sendeblöcke 200, die eine AH-Verarbeitung erfordern, zeigt 8B die Felder, die von dem Host 112 erzeugt werden und in die Puffer 194 eingefügt werden, sowie jene Felder, die von der AH-Verarbeitungshardware in dem IPsec-System 124 modifiziert werden.
  • Gemäß den 2 und 10 stellt das IPsec-System 124 eine Sicherheitsverarbeitung für eintreffende (beispielsweise empfangene) Blöcke 200 aus dem Netzwerk 108 bereit. Der RX-Analysator 144 untersucht eintreffende Blöcke 200, um IPsec-Kopfbereiche aufzufinden, und liest die entsprechende SA in den SA-Speicher 140 aus. Der RX IPSEC-Prozessor 150 führt dann die erforderliche IPsec-Authentifizierung und/oder Entschlüsselung gemäß der SA durch. Wenn eine Entschlüsselung erforderlich ist, ersetzt der Prozessor 150 die ursprünglichen Chiffrierdaten in dem Block 200 durch unchiffrierte Daten in dem Speicher 116. Die Deskriptorverwaltungseinheit 130 setzt die Statusbits in dem entsprechenden Empfangsstatusringeintrag 199 (5J), um anzugeben, welche Verarbeitung ausgeführt wurde und welche Fehler vorgefunden wurden.
  • 10 zeigt den Ablauf für eintreffende Daten in dem IPsec-System 124. Der Empfangsanalysator 144 untersucht die Kopfbereiche eintreffender Blöcke 200, die von der MAC-Maschine 122 stammen, während der eintreffende Block 200 aus dem Netzwerk 108 empfangen wird. Der Analysator 144 gibt die Ergebnisse seiner Analyse an die SA-Suchlogik 146 weiter. Diese Information wird auf dem Speicher 118 in Form eines Steuerblocks zugeführt, der zwischen den Blöcken 200 eingefügt wird. Der Steuerblock enthält Informationen über die Art und Lagen in den Kopfbereichen in dem eintreffenden Block 200. Wenn der Analysator 144 erkennt, dass ein Block 200 ein IP-Paketteil enthält, wird eine IPsec-Verarbeitung umgangen, und der Block 200 wird zu dem Host-Speicher 128 weitergeleitet, wobei das IP-Fragment-Bit in dem Feld IPSEC_STAT1 in den entsprechenden Empfangsstatusringeintrag 199 gesetzt wird. Für IPv4-Blöcke wird ein Fragment durch ein Feld im Fragment-Offset, das nicht null ist, oder durch ein Bit für mehrere Fragmente mit nicht null in dem IPv4-Kopfbereich angegeben. Für IPv6-Pakete wird ein Fragment durch das Vorhandensein eines Fragmenterweiterungskopfbereichs angezeigt.
  • Wenn der Analysator 144 einen IPsec-Kopfbereich oder eine zulässige Kombination aus Kopfbereichen antrifft, gibt er den SPI, die IP-Zieladresse und ein Bit, das das IPsec-Protokoll (AH oder ESP) angibt, an die SA-Tabellenmaschine 146 weiter. Die SA-Suchmaschine 146 verwendet den SPI, das Protokollbit und eine Kontrollsumme der Zieladresse, um einen internen SPI-Speicher 270 (10) zu durchsuchen. Die Ergebnisse dieser Suche werden in den SA-Zeiger-FIFO 148 geschrieben, wobei ein Zeiger zu einem Eintrag in dem externen SA-Speicher 140, ein Bit, das angibt, ob eine IPsec-Verarbeitung erforderlich ist, und zwei Bits, die den Erfolg oder Nicht-Erfolg der SA-Suche angeben, enthalten sind. Der SA-Zeiger-FIFO 148 enthält einen Eintrag entsprechend zu jedem eintreffenden Block 200 in dem Speicher 118. Wenn der SA-Zeiger-FIFO 148 keinen Platz für einen neuen Eintrag zu dem Zeitpunkt aufweist, in welchem ein eintreffender Block 200 aus dem Netzwerk 108 eintrifft, oder wenn der empfangene Block 200 einen Überlauf des Empfangsbereichs des Speichers 118 hervorrufen würde, wird der Block 200 verworfen, und es wird ein Zähler für empfangene verpasste Pakete (nicht gezeigt) erhöht.
  • Eine Sendeschlüsselabhol- bzw. RX KEY FETCH-Zustandsmaschine 262 (10) ruft den entsprechenden Eintrag aus dem SA-Zeiger FIFO 148 ab und bestimmt, ob eine Verarbeitung erforderlich ist. Wenn die Steuer-Bits anzeigen, dass eine Verarbeitung erforderlich ist, verwendet die Zustandsmaschine 262 den Inhalt des Zeigerfeldes, um die SA-Information aus dem externen SA-Speicher 140 abzuholen. Wenn ein DA-Feld der SA nicht mit dem DA-Feld des IP-Kopfbereichs in dem Block 200 übereinstimmt, bewirkt der IPsec-Prozessor 150, dass ein Fehlercode in den Empfangsstatusring 199 geschrieben wird und leitet den Block 200 zu dem Speicher 118 unmodifiziert weiter. Wenn das DA-Feld der SA mit dem DA-Feld des IP-Kopfbereichs übereinstimmt, entschlüsselt der Prozessor 150 den Nutzdatenbereich des empfangenen Blockes 200 und/oder prüft die Authentifizierungsdaten, wie dies durch die SA erforderlich ist.
  • Es sei nun auch auf die 11A–11D verwiesen; das Sicherheitsassoziations- bzw. Zuordnungssystem, das bei der abgehenden IPsec-Verarbeitung in der beispielhaften Steuerung 102 eingesetzt wird, wird in Bezug dazu im Weiteren beschrieben. 11A zeigt eine beispielhafte Sicherheitszuordnungstabelle mit Schreibzugriff, 11B zeigt ein beispielhaftes SA-Adressenregisterformat, 11C zeigt einen beispielhaften SPI-Tabelleneintrag in dem SPI-Speicher 270 und 11D zeigt einen beispielhaften SA-Speichereintrag in dem SA-Speicher 140. Die SA-Suchmaschine 146 verwendet den SPI-Speicher 270 und den externen SA-Speicher 140, die beide von dem Host-Prozessor 112 bewahrt werden, wobei der beispielhafte SPI-Speicher 270 als eine Ansammlung aus 4096 Fächern unterteilt ist, wobei jedes Fach bis zu 4 Einträge aufweist. Die Adresse eines Eintrags in dem SPI-Speicher 270 ist 14 Bit lang, wobei die 12 Bits höherer Ordnung eine Fachnummer angeben. Wie in 11C gezeigt ist, enthält jeder SPI-Tabelleneintrag 272 in dem SPI-Speicher 270 einen 32 Bit-Sicherheitsparameter Index SPI[31:0], einen Kontrollsumme der Zieladresse DA_HASH[39:32], ein Protokoll Bit PROTO, das das Sicherheitsprotokoll angibt (beispielsweise AH oder ESP) und ein Gültigkeits-Bit bzw. VALID-Bit, das angibt, ob der Eintrag gültig oder unverwendet ist.
  • 11D zeigt einen beispielhaften Eintrag 274 in dem SA-Speicher 140, wobei der SA-Speicher 140 einen Eintrag entsprechend jedem Eintrag 272 in dem SPI-Speicher 270 enthält, wobei Einträge 274 und 272 in den beiden Speichern 140 und 270 in der gleichen Reihenfolge vorliegen. Der Eintrag 274 enthält ein drei Bit langes ESP-Verschlüsselungsalgorithmusfeld ESP_ALG, das angibt, welche ESP-Verschlüsselung erforderlich ist, und wenn dies der Fall ist, welcher Algorithmus zu verwenden ist (beispielsweise DES; 3DES; AES-128, Rundung 10; AES-192, Rundung 12; AES-256, Rundung 14; etc.). Ein elektronisches Codierungsbuch Bit ECB zeigt an, ob der ECB-Modus für die Verschlüsselung verwendet wird, und ein zwei Bit langes ESP-Authentifizierungsfeld ESPAH_ALG zeigt an, ob die ESP-Authentifizierung erforderlich ist, und wenn dies der Fall ist, welcher Algorithmus zu verwenden ist (beispielsweise MD5, SHA-1, etc.). Ein zwei Bit langes AH-Feld AH_ALG zeigt an, ob die AH-Verarbeitung erforderlich ist, und wenn dies der Fall ist, welcher Algorithmus anzuwenden ist (beispielsweise MD5, SHA-1, etc.). Ein Protokoll Bit-PROTOKOLL zeigt an, ob der erste IPsec-Kopfbereich ein ESP-Kopfbereich oder ein AH-Kopfbereich ist, und ein IPv6-Bit zeigt an, ob die SA für die IPv4- oder IPv6-Blöke definiert ist.
  • Ein BÜNDEL-Bit bzw. BUNDLE-Bit zeigt ein Bündel aus zwei SAs an, die einen AH, gefolgt von ESP spezifizieren, und ein 32 Bit langes SPI-Feld gibt einen SPI an, der mit der zweiten SA (beispielsweise ESP) in einem Bündel aus 2 SAs verknüpft ist, das jedoch für SAs ignoriert wird, die nicht Teil von Bündeln sind. Ein IP-Zieladressenfeld IPDA[127:0] zeigt die Adresse an, auf die die SA anwendbar ist, wobei die SA nur Pakete betrifft, die diese Zieladresse enthalten. Ein AH_IPAD-Feld enthält einen Wert, der durch Anwenden der geeigneten Authentifizierungskontrollsummenfunktion (beispielsweise MD5 oder SHA-1) auf die exklusiv-ODER-Funktion des AH-Authentifizierungsschlüssels und der HMAC-ipad-Zeichenfolge erhalten wird, wie dies in der RFC 2104 beschrieben ist. Wenn die Authentifizierungsfunktion MD5 ist, sind das Ergebnis 16 Bytes, die als aufeinanderfolgende Bytes, beginnend beim Offset 24 gespeichert werden. Wenn die Authentifizierungsfunktion SHA-1 ist, sind das Ergebnis 20 Bytes, die das gesamte AH_IPAD-Feld einnehmen. Ein AH_OPAD-Feld enthält einen Wert, der durch Anwenden der geeigneten Authentifizierungskontrollsummenfunktion (beispielsweise MD5 oder SHA-1) auf die exklusiv-ODER-Funktion des AH-Authentifizierungsschlüssels und der HMAC-opad-Zeichenfolge erhalten wird, wie dies in RFC 2104 beschrieben ist. Wenn die Authentifizierungsfunktion MD5 ist, sind das Ergebnis 16 Bytes, die in aufeinanderfolgenden Bytes, beginnend beim Offset 44, gespeichert werden. Wenn die Authentifizierungsfunktion SHA-1 ist, sind das Ergebnis 20 Bytes, die das gesamte AH_OPAD-Feld einnehmen. Der SA-Speichereintrag 274 enthält ferner ein ESP_IPAD-Feld mit einem Wert, der durch Anwenden der Authentifizierungskontrollsummenfunktion (MD5 oder SHA-1) auf die exklusiv-ODER-Funktion mit dem ESP-Authentifizierungsschlüssel und der HMAC-ipad-Zeichenfolge erhalten wird, wie dies in RFC 2104 beschrieben ist, und enthält ferner ein ESP_OPAD-Feld mit einem Wert, der durch Anwenden der Authentifizierungskontrollsummenfunktion (MD5 oder SHA-1) auf die exklusiv-ODER-Funktion mit dem ESP-Authentifizierungsschlüssel und der HMAC-opad-Zeichenfolge erhalten wird, wie dies in RFC 2104 beschrieben ist. Ein Verschlüsselungsschlüsselfeld ENC_KEY enthält einen Verschlüsselungs-/Entschlüsselungsschlüssel, der für die ESP-Verarbeitung verwendet wird.
  • Das IPsec-System 124 liest aus den SA- und SPI-Speichern 140 und 270 aus, beschreibt diese jedoch nicht. Um die Zugriffszeit zu minimieren, ist der SPI-Speicher 270 als eine Kontrollsummentabelle angeordnet, in der die Fachnummer eines Eintrags 272 durch eine Kontrollsummenfunktion des SPI bestimmt ist. Die Suchlogik bzw. Abruflogik 146 verwendet den SPI und das IPsec-Protokoll (AH oder ESP), um den SPI-Speicher 270 zu durchsuchen, in dem ein Kontrollsummenwert auf der Grundlage der SPI berechnet wird und in dem das Ergebnis zur Adressierung eines Faches in dem SPI-Speicher 270 verwendet wird. Ein zweiter Kontrollsummenwert wird für die IP-C-Adresse berechnet, und die Suchlogik 146 vergleicht den SPI, das Protokoll und die Zieladressenkontrollsummen mit den Einträgen in dem ausgewählten Fach, bis sie eine Übereinstimmung findet oder keine weiteren Facheinträge vorhanden sind. Die Suchlogik 146 schreibt dann einen Eintrag in den SA-Zeiger-FIFO 148, der die Adresse des übereinstimmenden Eintrags in dem SPI-Speicher 270 und eine interne Statuscodierung enthält, die angibt, ob eine IPsec-Verarbeitung erforderlich ist oder nicht und ob die SA-Abrufung erfolgreich war oder nicht. Die Rx-Schlüsselabhollogik 262 holt die DA (Zieladresse) aus dem SA-Speicher 140 ab, um diese mit der DA in dem IP-Paketkopfbereich zu vergleichen. Wenn die DA aus dem SA-Speicher 140 nicht mit der DA aus dem empfangenen Block 200 übereinstimmt, wird der Block 200 zu dem Host-Speicher 128 über den Speicher 116 und die Bus-Schnittstelle 106 ohne IPsec-Verarbeitung weitergeleitet, und der entsprechende Empfangsstatusringeintrag 199 zeigt an, dass keine IPsec-Verarbeitung ausgeführt wurde.
  • Es sei nun auch auf 11A verwiesen; der SA-Speicher 140 und der SPI-Speicher 270 werden von dem Host-Prozessor 112 verwaltet. Während des normalen Betriebs verwendet der Host 112 Schreib- und Löschzugriffe, um Tabelleneinträge 274, 272 hinzuzufügen oder zu entfernen. Der beispielhafte SA-Speicher 140 ist in zwei Gebiete aufgeteilt, eines für eintreffende SAs und eines für abgehende SAs, wobei jedes Gebiet einen Speicherplatz von 16 K Einträgen bereitstellt. Ein Zugreifen auf den SA- und SPI-Speicher 140 bzw. 270 durch den Host 112 wird unter Anwendung eines SA-Adressenregisters SA_ADDR 280 und einem 144-Byte SA-Puffer 282 ausgeführt. Der SA-Puffer 282 enthält einen 136-Byte SA-Speichereintrag 274 gefolgt von einem entsprechenden 8-Byte SPI-Tabelleneintrag 272. Für abgehende SAs wird der SPI-Tabelleneintragsabschnitt 272 des Puffers 282 nicht verwendet. Um einen SA-Tabelleneintrag zu schreiben, erzeugt der Host 112 einen 136 Byte oder einen 144 Byte Eintrag in dem Host-Speicher 128 und schreibt die Zieladresse für den SA-Speicher 140 in das SA_ADDR-Register 280. Die Steuerung 102 verwendet einen DMA, um die SA-Information zuerst in den internen SA-Puffer 282 und dann in geeignete Steilen in den SA-Speicher 140 und den SPI-Speicher 270 zu kopieren. Der Host 112 schreibt die physikalische Adresse eines SA-Eintragspuffers 284 für den Host-Speicher 128 in ein SA_DMA_ADDR-Register 286. Wenn der Softwaretreiber 190 den gleichen Puffer 284 in dem Host-Speicher 128 zum Einladen aller SA-Tabelleneinträge verwendet, muss er lediglich einmal das SA_DMA_ADDR-Register 286 beschreiben.
  • Eintreffende Sicherheitszuordnungen (SA) werden an Speicherplätzen abgelegt, die durch den Kontrollsummenalgorithmus bestimmt sind. Für abgehende (Sende-)Blöcke 200 enthält die Treibersoftware 190 einen Zeiger zu der geeigneten SA in dem Sendedeskriptor 192a (beispielsweise SA_PTR-Feld in 5E). Daher muss die Steuerung 102 nicht den SA-Speicher 140 nach abgehenden SAs durchsuchen und Sende-SAs können in einer beliebigen Reihenfolge gespeichert werden. Es wird keine abgehende SA beim Offset 0 gespeichert, da der Wert 0 in dem SA_PTR-Feld des Deskriptors 192a verwendet wird, um anzuzeigen, dass keine IPsec-Verarbeitung erforderlich ist.
  • Es sei nun auch auf 11B verwiesen; das SA-Adressrenregister 280 enthält die Adresse der SA-Tabelleneinträge 274, auf die zuzugreifen ist, plus sechs SA-Zugriffsbefehlsbits. Diese Befehlsbits enthalten SA-Lese-, Schreib-, Lösch- und Rücksetzbits (SA_RD, SA_WR, SA_DEL und SA_CLEAR), und ein SA-Richtungsbit SA_DIR, und ein Befehlsaktivierungsbit SA_ACTIVE. Das Nur-Lese-SA_ACTIV-Bit ist 1, während die interne Zustandsmaschine 262 Daten in oder aus dem SA-Puffer 282 kopiert, wobei in dieser Zeit der Host 112 nicht auf den SA-Puffer 282 zugreift. Die Auswahl zwischen dem Gebiet für eintreffende bzw. abgehende Blöcke des externen SA-Speichers 140 wird durch das SA_DIR-Bit gesteuert, das als ein Adressenbit höherer Ordnung dient. Dieses Bit wird auf 1 gesetzt für eine eintreffende SA oder auf 0 für eine abgehende SA. Wenn dieses Bit auf 1 gesetzt ist, werden Daten zu oder aus dem internen SPI-Speicher 270 sowie zu oder aus dem externen SA-Speicher 140 übertragen. Zugriffe für die abgehende SA-Tabelle betreffen lediglich den externen SA-Speicher 140. Wenn der Host 112 das SA_RD in dem SA-Adressenregister 280 setzt, kopiert eine Zustandsmaschine Daten aus dem externen SA-Speicher 140 in den SA-Puffer 282. Wenn das Richtungs-Bit SA_DIR 1 ist, wird der entsprechende Eintrag 272 aus dem internen SPI-Speicher 270 ebenso in den SA-Puffer 282 kopiert. Ein SA-Adressenfeld SA_ADR[13:0] des SA-Adressenregisters 280 zeigt auf die Einträge 272 und/oder 274, die zu kopieren sind.
  • Wenn der Host 112 das SA_WR-Bit in dem SA_ADDR-Register 280 setzt, hängt die sich ergebende Aktion von dem Wert des SA_DIR-Bit ab. Wenn dieses Bit 1 ist (um beispielsweise eine eintreffende SA anzuzeigen), kopiert die Zustandsmaschine die Daten zuerst aus dem Puffer 284 im Host-Speicher 128 in den internen SA-Puffer 282 und dann von dem SA-Puffer 282 in den externen SA-Speicher 140 und auch in den entsprechenden internen SPI-Speicher 270. Wenn das SA_DIR-Bit 0 ist (um beispielsweise eine Sende-SA anzugeben), wird, wenn der Zugriffsbefehl ”Schreiben” ist, lediglich das SA-Feld des SA-Puffers 282 in den Eintrag des SA-Speichers 140 kopiert, der von dem SA-Adressenregister 280 angegeben ist, und das SPI-Feld wird nicht kopiert. Für eine Bündelverarbeitung wird ein BUNDLE-Bit in den SA entsprechend dem ersten IPsec-Kopfbereich in dem Block 200 gesetzt, wodurch angegeben wird, dass der Block 200 der Erwartung nach einen AH-Kopfbereich aufweist, auf den ein ESP-Kopfbereich folgt. Der entsprechende Eintrag in dem externen SA-Speicher 140 enthält Informationen für diese beiden Kopfbereiche einschließlich der erwarteten SPI des zweiten IPsec-Kopfbereichs.
  • Für die Empfangs-AH-Verarbeitung ist der Wert des AH_ALG-Feldes in dem SA-Speichereintrag 274 nicht null, wodurch angezeigt wird, dass die AH-Verarbeitung für den empfangenen Block 200 erforderlich ist. Der Rx-Analysator 144 durchsucht den Block-IP-Kopfbereich (und z. B. IPv6-Erweiterungskopfbereiche, falls vorhanden), um die Stellen der verdeckbaren Felder zu bestimmen, wie dies im RFC 2402 dargelegt ist). Der Analysator 144 fügt eine Liste dieser verdeckbaren Feldspeicherplätze in den Steuerblock in dem Speicher 118 ein. Wenn eine AH-Verarbeitung aktiviert ist, ersetzt der IPsec-Prozessor 150 die deaktivierbaren bzw. verdeckbaren Felder und das ICV-Feld des AH-Kopfbereichs mit Nullen, um den erwarteten ICV zu berechnen (die Blockdaten, die in den Host-Speicher 128 kopiert werden, werden nicht geändert). Das Zieladressenfeld des IP-Kopfbereichs wird als verdeckbar bzw. deaktivierbar aber vorhersagbar betrachtet, da zwischengeschaltete Verteiler dieses Feld ändern können, wenn eine Quellenweiterleitung verwendet wird. Da jedoch der Quellenknoten die endgültige Zieladresse für die ICV-Berechnung verwendet, behandelt der Empfänger dieses Feld als nicht verdeckbar für seine ICV-Prüfung.
  • Der Steuerblock in dem Speicher 118 enthält Zeiger zu den Anfangs- und Endpunkten des Bereichs des empfangenen Blockes 200, der durch AH-Authentifizierung abgedeckt ist. Der IPsec-Prozessor 150 verwendet diese Steuerblockinformation, um zu bestimmen, wo die Authentifizierungsberechnungen zu beginnen und zu beenden sind. Das AH_ALG-Feld in dem SA-Speichereintrag 274v zeigt an, welcher Authentifizierungsalgorithmus zu verwenden ist. Das beispielhafte IPsec-System 124 bietet HMAC-SHA-1-96, wie es in RFC 2404 definiert ist, und HMAC-MD5-96, wie es in RFC 2403 definiert ist, um eine AH-Verarbeitung bereitzustellen. In jedem Falle verwendet der Rx-IPsec-Prozessor 150 vorverarbeitete Daten aus den AH_IPAD- und AH_OPAD-Feldern des SA-Eintrags 274 zusammen mit den Blockdaten, um den schlüsselgestützten HMAC-Kontrollsummenalgorithmus anzuwenden, wie er in RFC 2104 beschrieben ist. Wenn die Ergebnisse dieser Berechnung nicht mit dem Inhalt des Authentifizierungsdatenfeldes des AH-Kopfbereichs übereinstimmen, wird das AH_ERR-Bit in den entsprechenden Empfangsstatusringeintrag 199 gesetzt (5J).
  • Für die Empfangs-ESP-Verarbeitung ist das ESPAH_ALG-Feld des SA-Speichereintrags 274 nicht null, wodurch angezeigt wird, dass die ESP-Authentifizierung erforderlich ist, und der Wert ungleich null zeigt an, welcher Authentifizierungsalgorithmus verwendet wird (beispielsweise MD5, SHA-1, etc.). Der Rx-IPsec-Prozessor 150 verwendet die vorverarbeiteten ipad- und opad-Daten aus den ESP_IPAD- und ESP_OPAD-Feldern des SA-Eintrags 274 zusammen mit Blockdaten, um den schlüsselgestützten HMAC-Kontrollsummenalgorithmus durchzuführen, wie er in RFC 2104 beschrieben ist. Es werden Zeiger verwendet, die aus dem Steuerblock des Speichers 118 ermittelt werden, um zu bestimmen, welcher Teil des Blockes in der ICV-Berechnung zu verwenden ist. Die bei der Berechnung verwendeten Daten beginnen am Anfang des ESP-Kopfbereichs und enden unmittelbar vor dem Authentifizierungsdatenfeld des ESP-Anhangs, wobei keines der Felder in diesem Bereich verdeckbar ist. Wenn die Ergebnisse dieser ICV-Berechnung nicht mit dem Inhalt des Authentifizierungsdatenfelds in dem ESP-Anhang übereinstimmen, wird das ESP_ICV_ERR-Bit in den entsprechenden Empfangsstatusringeintrag 199 gesetzt.
  • Wenn das ESP_ALG-Feld des SA-Speichereintrags 274 nicht null ist, ist eine ESP-Entschlüsselung erforderlich, und der Empfangs-IPsec-Prozessor 150 verwendet die ESP_ALG- und ECB-Felder des Eintrags 274, um zu bestimmen, welcher Entschlüsselungsalgorithmus und Modus zu verwenden ist (beispielsweise DES; 3DES; AES-128, Rundung 10; AES-192, Rundung 12; AES-256, Rundung 14; etc.). Der Rx-IPsec-Prozessor 150 ruft den Entschlüsselungsschlüssel aus dem ENC_KEY-Feld des Eintrags 274 ab und verwendet die Information aus dem Steuerblock in dem Speicher 118, um zu bestimmen, welcher Teil des Blocks verschlüsselt ist (beispielsweise der Bereich, der unmittelbar nach dem ESP-Kopfbereich beginnt und unmittelbar vor dem Authentifizierungsdatenfeld in dem ESP-Anhang endet). Wenn die SA angibt, dass keine ESP-Authentifizierung auszuführen ist, ist die Länge des Authentifizierungsdatenfeldes null und die verschlüsselten Daten enden unmittelbar vor dem FCS-Feld.
  • Sobald die Nutzdaten entschlüsselt sind, überprüft der IPsec-Prozessor 150 das Fülldatenlängenfeld des ESP-Anhangs, um zu erkennen, ob Fülldaten-Bytes vorhanden sind. Wenn das Fülldatenlängenfeld nicht null ist, untersucht der Prozessor 150 die Fülldaten-Bytes und setzt das PAD_ERR-Bit in dem Empfangsstatusringeintrag 199, wenn die Fülldaten-Bytes nicht aus einer ansteigenden Reihe aus Ganzzahlen, beginnend mit 1 (beispielsweise 1, 2, 3, ...) bestehen. Der IPsec-Prozessor 150 ersetzt die verschlüsselten Blockdaten durch (entschlüsselte) Reindaten in dem Speicher 118. Der beispielhafte Prozessor 150 stellt das ursprüngliche IP-Paket nicht wieder her (beispielsweise entfernt der Prozessor 150 nicht den ESP-Kopfbereich und den Anhang und ersetzt nicht das Feld nächster Kopfbereich durch den vorhergehenden umverschlüsselten Kopfbereich). Wenn die Verschlüsselung unter Anwendung des CBC-Modus erfolgt, enthalten die ersten 8 oder 16 Bytes des ESP-Nutzdatenfeldes den unverschlüsselten IV, den der IPsec-Prozessor 150 nicht ändert. Die verschlüsselten Daten, die auf dem IV folgen, werden durch ihre entschlüsselte Version ersetzt.
  • In dem beispielhaften IPsec-System 124 werden die Nummer des SPI-Tabellenfaches und die IP-Zieladressenkontrollsummencodierungen jeweils unter Anwendung eines einzelnen 12-Bit-Kontrollsummenalgorithmus berechnet. Die Fachnummer wird berechnet, indem der SPI über die Kontrollsummenlogik in den IPsec-Prozessor 150 verschoben wird. Für die Zieladressen-(DA)Kontrollsumme wird die 32-Bit IPv4-Zieladresse oder die 128-Bit IPv6-Zieladresse mittels der Kontrollsummenlogik verschoben, die 12 Ausgangsbits bereitstellt, die für die Fachnummer verwendet werden, wobei lediglich die 8 am wenigsten signifikanten Bits für die DA-Kontrollsumme verwendet werden. Die Kontrollsummenfunktion ist durch ein programmierbares 12-Bit Polynom in einem Konfigurationsregister der Steuerung 102 definiert, wobei jedes Bit in dem Polynom einen UND/exklusive-ODER-Abgriff in der Kontrollsummenlogik des Prozessors 150 definiert. Der eintreffende Bitstrom wird exklusiv ODER-verknüpft mit dem Ausgang des letzten Flip-Flops in der Kontrollsummenfunktion. Das Ergebnis wird bitweise UND-verknüpft mit dem Polynom, exklusiv-ODER-verknüpft mit dem Ausgang des vorhergehenden Registers und wird dann verschoben. Die Kontrollsummenfunktions-Bits werden mit null initialisiert. Der Suchschlüssel wird dann durch die Kontrollsummenfunktion weitergegeben. Nachdem der Eingangs-Bitstrom in die Kontrollsummenfunktionslogik verschoben ist, ist der 12-Bit-Ausgang der Kontrollsummenschlüssel.
  • Obwohl die Erfindung in Bezug auf eine oder mehrere Implementationen dargestellt und beschrieben ist, können Änderungen und/oder Modifizierungen in den dargestellten Beispielen durchgeführt werden, ohne von dem Grundgedanken und Schutzbereich der angefügten Patentansprüche abzuweichen. Insbesondere im Hinblick auf die diversen Funktionen, die von den zuvor beschriebenen Komponenten oder Strukturen (Blöcken, Einheiten, Maschinen, Anordnungen, Vorrichtungen, Schaltungen, Systemen, etc.) durchgeführt werden, sollen die Begriffe (einschließlich einer Bezugnahme auf ”Mittel bzw. eine Einrichtung”), die zum Beschreiben derartiger Komponenten verwendet werden, sich nicht auf eine beliebige Komponente oder Struktur beziehen, sofern dies nicht anderweitig angegeben ist, die die spezifizierte Funktion der beschriebenen Komponente ausführt (beispielsweise funktionsmäßig äquivalent ist), obwohl diese strukturell nicht mit der offenbarten Struktur äquivalent ist, die die Funktion in den hierin beispielhaft dargestellten Implementierungen der Erfindung ausführt. Obwohl ferner ein spezielles Merkmal der Erfindung in Bezug auf lediglich eine von mehreren Ausführungsformen offenbart ist, kann ein derartiges Merkmal mit einem oder mehreren anderen Merkmalen der anderen Ausführungsformen kombiniert werden, wie dies für eine gegebene oder spezielle Anwendung erwünscht oder vorteilhaft ist. Des Weiteren sollen, in dem Maße wie Begriffe ”mit”, ”umfasst”, ”besitzt”, ”mit”, ”einschließlich”, oder Variationen davon, in der detaillierten Beschreibung und in den Ansprüchen verwendet werden, diese einschließend in einer Weise sein, wie der Begriff ”umfassend” bzw. ”mit”.
  • INDUSTRIELLE ANWENDBARKEIT
  • Die vorliegende Erfindung kann verwendet werden, um sichere Hochgeschwindigkeitsschnittstellen zwischen Netzwerken und Computer zu schaffen.

Claims (9)

  1. Netzwerkschnittstellensystem (2) zur Verbindung eines Host-Systems (6) mit einem Netzwerk (8), um von dem Host-System (6) abgehende Daten dem Netzwerk (8) zuzuführen und um aus dem Netzwerk (8) eingehende Daten dem Host-System (6) zuzuführen, wobei das Netzwerkschnittstellensystem (2) umfasst: ein Bus-Schnittstellensystem (4), das ausgebildet ist, mit einem Host-Bus (106) in dem Host-System (6) verbunden zu werden und um Daten zwischen dem Netzwerksystem (8) und dem Host-System (6) auszutauschen; ein Mediumzugriffssteuerungssystem (10), das ausgebildet ist, mit dem Netzwerk (8) verbunden zu werden und um Daten zwischen dem Netzwerkschnittstellensystem (2) und dem Netzwerk (8) auszutauschen; ein Speichersystem (12), das mit dem Bus-Schnittstellensystem (4) und dem Mediumzugriffssteuerungssystem (10) verbunden ist, wobei das Speichersystem (12) ausgebildet ist, eingehende und abgehende Daten, die zwischen dem Netzwerk (8) und dem Host-System (6) ausgetauscht werden, zu speichern; ein Sicherheitssystem (14), das mit dem Speichersystem (12) verbunden ist, wobei das Sicherheitssystem (14) ausgebildet ist, selektiv abgehende Daten zu verschlüsseln und selektiv eingehende Daten zu entschlüsseln; wobei das Sicherheitssystem (14) zwei Prozessoren (20, 21) zum Verschlüsseln der abgehenden Daten aufweist, wobei die zwei Prozessoren (20, 21) jeweils unabhängig voneinander betrieben werden können, um die abgehenden Daten zu verschlüsseln, wobei das Sicherheitssystem (14) konfiguriert oder konfigurierbar ist, um abgehende Datenpakete abwechselnd zu einem oder zu dem anderen Prozessor (20, 21) für die Verschlüsselung zu senden, und wobei das Sicherheitssystem (14) ferner einen weiteren Prozessor (22) umfasst, um selektiv eingehende Daten zu entschlüsseln, und wobei das Sicherheitssystem (14) mehr Prozessoren zum Verschlüsseln abgehender Daten als zur Entschlüsselung eingehender Daten umfasst; wobei das Sicherheitssystem (14) weiterhin eine Eingangsdatenflusssteuerung (28) und eine Ausgangsdatenflusssteuerung (30) umfasst, wobei die Eingangsdatenflusssteuerung (28) dazu ausgebildet ist, Daten aus dem Speichersystem (12) auszulesen und die Ausgangsdatenflusssteuerung (30) dazu ausgebildet ist, verschlüsselte Daten, die sie von den zwei Prozessoren (20, 21) empfängt, in das Speichersystem (12) zu schreiben, wobei die Datenpakete in derselben Reihenfolge vorliegen, in der sie aus dem Speichersystem (12) ausgelesen wurden; wobei jeder der zwei Prozessoren (20, 21) eine Einkapselungssicherheitsprotokoll-, ESP-, Authentifizierungsmaschine (56), eine Authentifizierungskopfbereich-, AH-, Authentifizierungsmaschine (58) und eine ESP-Verschlüsselungsmaschine (60) umfasst.
  2. Netzwerkschnittstellensystem nach Anspruch 1, wobei die beiden Prozessoren (20, 21) auch betrieben werden können, um die abgehenden Daten zu authentifizieren.
  3. Netzwerkschnittstellensystem nach Anspruch 1, wobei die beiden Prozessoren (20, 21) funktionsmäßig identisch sind.
  4. Netzwerkschnittstellensystem nach Anspruch 1, wobei das Sicherheitssystem (14) ferner zwei Eingangspuffer (26, 27) aufweist, die mit dem Systemspeicher (12) verbunden sind, wobei jeder Eingangspuffer (26, 27) mit einem der Prozessoren (20, 21) verbunden ist, und wobei das Sicherheitssystem (14) ausgebildet ist, abgehende Datenpakete, die aus dem Speichersystem (12) ausgelesen werden, abwechselnd zu einem oder zu dem anderen Eingangspuffer (26, 27) zu leiten.
  5. Netzwerkschnittstellensystem nach Anspruch 1, wobei das Sicherheitssystem (14) ferner zwei Ausgangspuffer (24, 25), die mit dem Speichersystem (12) verbunden sind, aufweist, wobei jeder Ausgangspuffer (24, 25) mit einem der Prozessoren (20, 21) verbunden ist, wobei die Prozessoren (20, 21) ausgebildet sind, verarbeitete Datenpakete in die Ausgangspuffer (24, 25) zu schreiben, und wobei das Sicherheitssystem (14) ausgebildet ist, die verarbeiteten Datenpakete aus den Ausgangspuffern (24, 25) in das Speichersystem (12) in der gleichen Reihenfolge zu übertragen, in der die Datenpakete aus dem Speichersystem (12) vor der Verarbeitung ausgelesen wurden.
  6. Integrierte Einzelschaltung mit: einem Sicherheitssystem (14), das ausgebildet ist, eine Sende-IPsec-Verarbeitung an Daten zur Übertragung zu einem Netzwerk (8) auszuführen, wobei das Sicherheitssystem (14) zwei Prozessoren (20, 21) parallel zum Ausführen der Sende-IPsec-Verarbeitung umfasst, und wobei das Sicherheitssystem (14) ferner einen weiteren Prozessor (22) umfasst, um selektiv eingehende Daten zu entschlüsseln und wobei das Sicherheitssystem (14) mehr Prozessoren zum Verschlüsseln abgehender Daten als zum Entschlüsseln eingehender Daten aufweist; wobei das Sicherheitssystem (14) weiterhin eine Eingangsdatenflusssteuerung (28) und eine Ausgangsdatenflusssteuerung (30) umfasst, wobei die Eingangsdatenflusssteuerung (28) dazu ausgebildet ist, Daten aus dem Speichersystem (12) auszulesen und die Ausgangsdatenflusssteuerung (30) dazu ausgebildet ist, verschlüsselte Daten, die sie von den zwei Prozessoren (20, 21) empfängt, in das Speichersystem (12) zu schreiben, wobei die Datenpakete in derselben Reihenfolge vorliegen, in der sie aus dem Speichersystem (12) ausgelesen wurden; wobei jeder der zwei Prozessoren (20, 21) eine ESP-Authentifizierungsmaschine (56), eine AH-Authentifizierungsmaschine (58) und eine ESP-Verschlüsselungsmaschine (60) umfasst.
  7. Integrierte Einzelschaltung nach Anspruch 6, wobei die zwei Prozessoren (20, 21) funktional identisch sind.
  8. Integrierte Einzelschaltung nach Anspruch 6, wobei das Sicherheitssystem (14) ferner zwei Eingangspuffer (26, 27) aufweist, wovon jeder mit einem der Prozessoren verbunden ist, und wobei das Sicherheitssystem (14) ausgebildet ist, abgehende Datenpakete abwechselnd zu einem oder zu dem anderen Eingangspuffer (26, 27) zu lenken.
  9. Integrierte Einzelschaltung nach Anspruch 6, wobei das Sicherheitssystem (14) ferner zwei Ausgangspuffer (24, 25) aufweist, wobei jeder Ausgangspuffer (24, 25) mit einem der Prozessoren (20, 21) verbunden ist, wobei die Prozessoren ausgebildet sind, verarbeitete Datenpakete in die Ausgangspuffer (24, 25) zu schreiben, und wobei das Sicherheitssystem (14) ausgebildet ist, die verarbeiteten Datenpakete aus den Ausgangspuffern (24, 25) in der gleichen Reihenfolge zu senden, in der die Datenpakete in das Sicherheitssystem (14) vor der Verarbeitung eingelesen wurden.
DE112005000523T 2004-03-02 2005-02-26 Zwei parallele Maschinen für Hochgeschwindigkeitssende-IPSEC-Verarbeitung Active DE112005000523B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/791,557 2004-03-02
US10/791,557 US7685434B2 (en) 2004-03-02 2004-03-02 Two parallel engines for high speed transmit IPsec processing
PCT/US2005/005902 WO2005086461A1 (en) 2004-03-02 2005-02-26 Two parallel engines for high speed transmit ipsec processing

Publications (2)

Publication Number Publication Date
DE112005000523T5 DE112005000523T5 (de) 2007-05-16
DE112005000523B4 true DE112005000523B4 (de) 2012-02-16

Family

ID=34911667

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112005000523T Active DE112005000523B4 (de) 2004-03-02 2005-02-26 Zwei parallele Maschinen für Hochgeschwindigkeitssende-IPSEC-Verarbeitung

Country Status (8)

Country Link
US (2) US7685434B2 (de)
JP (1) JP4685855B2 (de)
KR (1) KR101110289B1 (de)
CN (1) CN1926839B (de)
DE (1) DE112005000523B4 (de)
GB (1) GB2427806B (de)
TW (1) TWI380662B (de)
WO (1) WO2005086461A1 (de)

Families Citing this family (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512780B1 (en) * 2001-08-31 2009-03-31 Verizon Corporate Services Group, Inc. Packet-parallel high performance cryptography systems and methods
US7356711B1 (en) * 2002-05-30 2008-04-08 Microsoft Corporation Secure registration
US8146160B2 (en) 2004-03-24 2012-03-27 Arbor Networks, Inc. Method and system for authentication event security policy generation
US7620041B2 (en) * 2004-04-15 2009-11-17 Alcatel-Lucent Usa Inc. Authentication mechanisms for call control message integrity and origin verification
US7502474B2 (en) * 2004-05-06 2009-03-10 Advanced Micro Devices, Inc. Network interface with security association data prefetch for high speed offloaded security processing
US7885405B1 (en) * 2004-06-04 2011-02-08 GlobalFoundries, Inc. Multi-gigabit per second concurrent encryption in block cipher modes
KR100735577B1 (ko) * 2004-08-12 2007-07-04 삼성전자주식회사 무선 네트워크의 적응형 키검색장치 및 방법
US7409558B2 (en) * 2004-09-02 2008-08-05 International Business Machines Corporation Low-latency data decryption interface
US7496753B2 (en) * 2004-09-02 2009-02-24 International Business Machines Corporation Data encryption interface for reducing encrypt latency impact on standard traffic
US7624263B1 (en) * 2004-09-21 2009-11-24 Advanced Micro Devices, Inc. Security association table lookup architecture and method of operation
US7783880B2 (en) * 2004-11-12 2010-08-24 Microsoft Corporation Method and apparatus for secure internet protocol (IPSEC) offloading with integrated host protocol stack management
CN100414929C (zh) * 2005-03-15 2008-08-27 华为技术有限公司 一种移动互联网协议网络中的报文传送方法
US7876758B2 (en) * 2005-04-08 2011-01-25 Agere Systems Inc. Method and apparatus for improved voice over Internet protocol (VoIP) transmission in a digital network
US7979692B1 (en) * 2005-06-01 2011-07-12 Teleport Systems, Inc. Device-to-device and client server based video monitoring and video teleconferencing/server networking technology for remote monitoring
US8447898B2 (en) * 2005-10-28 2013-05-21 Microsoft Corporation Task offload to a peripheral device
US20070101023A1 (en) * 2005-10-28 2007-05-03 Microsoft Corporation Multiple task offload to a peripheral device
US7920473B1 (en) * 2005-12-01 2011-04-05 Qlogic, Corporation Method and system for managing transmit descriptors in a networking system
US7730209B2 (en) * 2006-01-18 2010-06-01 Microsoft Corporation Efficient dispatch of messages based on message headers
US20070266233A1 (en) * 2006-05-12 2007-11-15 Mahesh Jethanandani Method and apparatus to minimize latency by avoiding small tcp segments in a ssl offload environment
US8555057B2 (en) * 2006-07-21 2013-10-08 At&T Intellectual Property I, L.P. System and method for securing a network
DE102007003634B3 (de) * 2006-09-14 2008-04-24 IHP GmbH - Innovations for High Performance Microelectronics/Institut für innovative Mikroelektronik Hardware-Protokollbeschleuniger für eine Verbindungssicherungs-Protokollebene eines Senderempfängers
KR100946697B1 (ko) 2006-11-13 2010-03-12 한국전자통신연구원 소형 패킷 데이터를 고속으로 암호화할 수 있는 ＩＰｓｅｃ암호화 장치 및 방법
US7886143B2 (en) * 2006-11-30 2011-02-08 Broadcom Corporation Multi-data rate cryptography architecture for network security
US8010801B2 (en) * 2006-11-30 2011-08-30 Broadcom Corporation Multi-data rate security architecture for network security
US8112622B2 (en) * 2006-12-08 2012-02-07 Broadcom Corporation Chaining port scheme for network security
US8467390B2 (en) * 2006-12-14 2013-06-18 Oracle America, Inc. Method and system for network stack tuning
US8467527B2 (en) * 2008-12-03 2013-06-18 Intel Corporation Efficient key derivation for end-to-end network security with traffic visibility
US7765336B2 (en) * 2007-06-11 2010-07-27 Emulex Design & Manufacturing Corporation Autonomous mapping of protected data streams to fibre channel frames
US8942112B2 (en) * 2008-02-15 2015-01-27 Cisco Technology, Inc. System and method for providing selective mobility invocation in a network environment
US8121073B2 (en) * 2008-06-13 2012-02-21 International Business Machines Corporation Future forwarding zones in a network
WO2010020151A1 (zh) 2008-08-18 2010-02-25 成都市华为赛门铁克科技有限公司 报文处理方法、装置和系统
JP5500923B2 (ja) * 2008-11-27 2014-05-21 キヤノン株式会社 情報処理装置
US8355499B2 (en) 2008-12-12 2013-01-15 Micron Technology, Inc. Parallel encryption/decryption
JP5460085B2 (ja) * 2009-03-13 2014-04-02 キヤノン株式会社 情報処理装置、通信システム、それらの制御方法、及びプログラム
CN101997834B (zh) * 2009-08-10 2015-01-07 北京多思科技发展有限公司 支持高性能安全协议的装置
KR101614331B1 (ko) 2009-10-09 2016-04-21 삼성전자주식회사 이동 통신 시스템에서 ａｅｓ 알고리즘을 이용한 암호화 장치 및 방법
US8255702B1 (en) * 2009-12-03 2012-08-28 Altera Corporation Programmable logic device with improved security
US8352618B2 (en) * 2009-12-30 2013-01-08 Konica Minolta Laboratory U.S.A., Inc. Method and system for resolving conflicts between IPsec and IPv6 neighbor solicitation
US8307111B1 (en) 2010-04-13 2012-11-06 Qlogic, Corporation Systems and methods for bandwidth scavenging among a plurality of applications in a network
WO2011139440A2 (en) * 2010-04-29 2011-11-10 Sonus Networks, Inc. Loosely-coupled encryption functionality for operating systems
US9215588B2 (en) * 2010-04-30 2015-12-15 Cisco Technology, Inc. System and method for providing selective bearer security in a network environment
KR101141919B1 (ko) * 2010-10-26 2012-05-07 주식회사 윈스테크넷 에스에스엘/티엘에스 트래픽의 다중 복호화 구성에 따른 고성능 네트워크장비 및 고성능 네트워크 데이터 처리방법
US10873613B2 (en) * 2010-12-09 2020-12-22 Xilinx, Inc. TCP processing for devices
US9674318B2 (en) 2010-12-09 2017-06-06 Solarflare Communications, Inc. TCP processing for devices
US8583818B2 (en) * 2011-01-31 2013-11-12 Cbs Interactive Inc. System and method for custom segmentation for streaming video
CN102752797A (zh) * 2011-03-31 2012-10-24 北京新岸线无线技术有限公司 一种无线通信方法、发送装置及接收装置
US8793358B1 (en) * 2011-04-27 2014-07-29 Juniper Networks, Inc. Flexible packet processing for network devices
US8774208B2 (en) * 2011-09-14 2014-07-08 Qualcomm Incorporated Management of TCP/IP messaging in wireless networks
US8745381B2 (en) * 2011-10-19 2014-06-03 Ixia Methods, systems, and computer readable media for performing encapsulating security payload (ESP) rehashing
CN103095511A (zh) * 2011-10-28 2013-05-08 华为技术有限公司 一种在IPsec机制下的网络测试方法，装置及系统
US9026784B2 (en) * 2012-01-26 2015-05-05 Mcafee, Inc. System and method for innovative management of transport layer security session tickets in a network environment
US9652174B2 (en) * 2012-06-04 2017-05-16 Hewlett Packard Enterprise Development Lp Managing an analytic function to be performed on data stored in an input block
US8848741B2 (en) * 2012-06-21 2014-09-30 Breakingpoint Systems, Inc. High-speed CLD-based TCP segmentation offload
US8824508B2 (en) 2012-06-21 2014-09-02 Breakingpoint Systems, Inc. High-speed CLD-based TCP assembly offload
US10102390B2 (en) 2012-06-28 2018-10-16 Honeywell International Inc. Memory authentication with redundant encryption
KR102056438B1 (ko) * 2012-10-12 2019-12-16 삼성전자주식회사 복합 멀티미디어 데이터를 전송하기 위한 데이터 패킷을 송수신하는 방법 및 장치
US9176838B2 (en) 2012-10-19 2015-11-03 Intel Corporation Encrypted data inspection in a network environment
TWI480761B (zh) * 2012-12-27 2015-04-11 Chunghwa Telecom Co Ltd Security and Trusted Network Entity Isolation System and Method
TW201436519A (zh) * 2013-03-01 2014-09-16 Gash Plus Taiwan Company Ltd 利用身份代碼於不同伺服器間進行安全交易之方法
CN104063793B (zh) * 2013-03-19 2017-04-12 乐点卡数位科技股份有限公司 利用身份代码于不同服务器间进行安全交易的方法
KR101964229B1 (ko) 2013-07-26 2019-04-01 한화테크윈 주식회사 감시 서버, 감시 서버의 데이터 처리 방법, 및 감시 시스템
BR112016011256B1 (pt) * 2013-12-23 2022-07-05 Intel Corporation Método de processamento de dados desalinhados, meio legível por máquina, sistema e dispositivo informático
JP6248663B2 (ja) * 2014-02-06 2017-12-20 富士通株式会社 伝送システム、および伝送方法
US10015048B2 (en) 2014-12-27 2018-07-03 Intel Corporation Programmable protocol parser for NIC classification and queue assignments
US10013363B2 (en) 2015-02-09 2018-07-03 Honeywell International Inc. Encryption using entropy-based key derivation
US10051000B2 (en) 2015-07-28 2018-08-14 Citrix Systems, Inc. Efficient use of IPsec tunnels in multi-path environment
US9826071B2 (en) 2015-08-26 2017-11-21 Barefoot Networks, Inc. Configuring a switch for extracting packet header fields
US9825862B2 (en) 2015-08-26 2017-11-21 Barefoot Networks, Inc. Packet header field extraction
US9606959B1 (en) * 2015-11-12 2017-03-28 International Business Machines Corporation Indicating a sending buffer and receiving buffer in a message to use to validate the message in the receiving buffer
JP6600241B2 (ja) * 2015-12-11 2019-10-30 キヤノン株式会社 演算装置及び演算方法、通信装置
TWI580199B (zh) * 2015-12-18 2017-04-21 瑞昱半導體股份有限公司 接收裝置及其封包處理方法
US9912774B2 (en) 2015-12-22 2018-03-06 Intel Corporation Accelerated network packet processing
US10708073B2 (en) 2016-11-08 2020-07-07 Honeywell International Inc. Configuration based cryptographic key generation
EP3535895A1 (de) * 2016-12-19 2019-09-11 Huawei Technologies Co., Ltd. Netzwerkknoten und client-vorrichtung zur messung von kanalstatusinformationen
US11245572B1 (en) 2017-01-31 2022-02-08 Barefoot Networks, Inc. Messaging between remote controller and forwarding element
US10757028B1 (en) 2017-04-23 2020-08-25 Barefoot Networks, Inc. Configurable forwarding element deparser
US10911377B1 (en) 2017-07-23 2021-02-02 Barefoot Networks, Inc. Using stateful traffic management data to perform packet processing
US10498708B2 (en) * 2017-07-31 2019-12-03 Nicira, Inc. Scaling IPSEC processing on a virtual machine
US10594630B1 (en) 2017-09-28 2020-03-17 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
US11095617B2 (en) 2017-12-04 2021-08-17 Nicira, Inc. Scaling gateway to gateway traffic using flow hash
KR102128832B1 (ko) * 2018-04-04 2020-07-01 윤흥수 네트워크 인터페이스 장치 및 그 네트워크 인터페이스 장치의 데이터 처리 방법
US11347561B1 (en) 2018-04-30 2022-05-31 Vmware, Inc. Core to resource mapping and resource to core mapping
US10419408B1 (en) 2018-09-24 2019-09-17 Karamba Security In-place authentication scheme for securing intra-vehicle communication
US10659437B1 (en) * 2018-09-27 2020-05-19 Xilinx, Inc. Cryptographic system
US11184113B2 (en) * 2019-05-24 2021-11-23 International Business Machines Corporation Packet replay in response to checksum error
US11509638B2 (en) 2019-12-16 2022-11-22 Vmware, Inc. Receive-side processing for encapsulated encrypted packets
US20220416996A1 (en) * 2021-06-25 2022-12-29 Graphcore Limited Block Cipher Encryption Pipeline
TWI769111B (zh) * 2021-11-17 2022-06-21 瑞昱半導體股份有限公司 基本儲存單元管理電路以及基本儲存單元管理方法
US11863514B2 (en) 2022-01-14 2024-01-02 Vmware, Inc. Performance improvement of IPsec traffic using SA-groups and mixed-mode SAs
US11956213B2 (en) 2022-05-18 2024-04-09 VMware LLC Using firewall policies to map data messages to secure tunnels

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040039936A1 (en) * 2002-08-21 2004-02-26 Yi-Sern Lai Apparatus and method for high speed IPSec processing

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590339A (en) * 1993-08-23 1996-12-31 Macronix International Co., Ltd. Input device interface with power connect state and serial data channel enabling power to the device from time to time
US20030014627A1 (en) * 1999-07-08 2003-01-16 Broadcom Corporation Distributed processing in a cryptography acceleration chip
US7996670B1 (en) 1999-07-08 2011-08-09 Broadcom Corporation Classification engine in a cryptography acceleration chip
US7181629B1 (en) * 1999-08-27 2007-02-20 Fujitsu Limited Data distribution system as well as data supply device terminal device and recording device for the same
JP4558879B2 (ja) * 2000-02-15 2010-10-06 富士通株式会社 テーブルを用いたデータ処理装置および処理システム
US7913261B2 (en) 2001-05-02 2011-03-22 nCipher Corporation, Ltd. Application-specific information-processing method, system, and apparatus
US7194766B2 (en) 2001-06-12 2007-03-20 Corrent Corporation Method and system for high-speed processing IPSec security protocol packets
US7394823B2 (en) 2001-11-20 2008-07-01 Broadcom Corporation System having configurable interfaces for flexible system configurations
US20030115447A1 (en) * 2001-12-18 2003-06-19 Duc Pham Network media access architecture and methods for secure storage
US20030135616A1 (en) 2002-01-11 2003-07-17 Carrico Sandra Lynn IPSec Through L2TP
TWI230532B (en) * 2002-03-05 2005-04-01 Admtek Inc Pipelined engine for encryption/authentication in IPSEC
US7535913B2 (en) * 2002-03-06 2009-05-19 Nvidia Corporation Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols
US7159242B2 (en) 2002-05-09 2007-01-02 International Business Machines Corporation Secure IPsec tunnels with a background system accessible via a gateway implementing NAT
JP4159328B2 (ja) * 2002-09-11 2008-10-01 Ｎｅｃインフロンティア株式会社 ネットワーク、ＩＰｓｅｃ設定サーバ装置、ＩＰｓｅｃ処理装置及びそれらに用いるＩＰｓｅｃ設定方法
US7454610B2 (en) * 2002-12-31 2008-11-18 Broadcom Corporation Security association updates in a packet load-balanced system
US7636804B2 (en) * 2003-04-28 2009-12-22 Quantum Corporation Data storage and protection apparatus and methods of data storage and protection
US7620179B2 (en) * 2004-01-29 2009-11-17 Comcast Cable Holdings, Llc System and method for security processing media streams

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040039936A1 (en) * 2002-08-21 2004-02-26 Yi-Sern Lai Apparatus and method for high speed IPSec processing

Also Published As

Publication number Publication date
GB2427806A (en) 2007-01-03
US20100071055A1 (en) 2010-03-18
GB2427806B (en) 2007-11-21
US20050198531A1 (en) 2005-09-08
US9106625B2 (en) 2015-08-11
TW200537888A (en) 2005-11-16
WO2005086461A1 (en) 2005-09-15
KR101110289B1 (ko) 2012-02-15
CN1926839A (zh) 2007-03-07
US7685434B2 (en) 2010-03-23
TWI380662B (en) 2012-12-21
KR20060130201A (ko) 2006-12-18
CN1926839B (zh) 2010-12-08
JP2007526718A (ja) 2007-09-13
DE112005000523T5 (de) 2007-05-16
GB0615760D0 (en) 2006-09-27
JP4685855B2 (ja) 2011-05-18

Similar Documents

Publication Publication Date Title
DE112005000523B4 (de) Zwei parallele Maschinen für Hochgeschwindigkeitssende-IPSEC-Verarbeitung
US7398386B2 (en) Transparent IPSec processing inline between a framer and a network component
US7676814B2 (en) Four layer architecture for network device drivers
US7502474B2 (en) Network interface with security association data prefetch for high speed offloaded security processing
US7826614B1 (en) Methods and apparatus for passing initialization vector information from software to hardware to perform IPsec encryption operation
US7885405B1 (en) Multi-gigabit per second concurrent encryption in block cipher modes
US7412726B1 (en) Method and apparatus for out of order writing of status fields for receive IPsec processing
US8468337B2 (en) Secure data transfer over a network
US9015467B2 (en) Tagging mechanism for data path security processing
US6076168A (en) Simplified method of configuring internet protocol security tunnels
DE60036284T2 (de) Vorrichtung zur klassifizierung in einem kryptographischen beschleunigungschip
US7526085B1 (en) Throughput and latency of inbound and outbound IPsec processing
US9094375B2 (en) WAN transport of frames with MAC security
US20050198498A1 (en) System and method for performing cryptographic operations on network data
US7580519B1 (en) Triple DES gigabit/s performance using single DES engine
US7818563B1 (en) Method to maximize hardware utilization in flow-thru IPsec processing
US7545928B1 (en) Triple DES critical timing path improvement
US7624263B1 (en) Security association table lookup architecture and method of operation
US8160089B1 (en) Dynamic inter packet gap generation system and method
US7958255B1 (en) Partial coalescing of transmit buffers
US7564976B2 (en) System and method for performing security operations on network data
US7787481B1 (en) Prefetch scheme to minimize interpacket gap
US7512787B1 (en) Receive IPSEC in-line processing of mutable fields for AH algorithm
EP4014424B1 (de) Verfahren zum verarbeiten von telegrammen in einem automatisierungsnetzwerk, automatisierungsnetzwerk, masterteilnehmer und slaveteilnehmer

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20120517

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000