DE112016001193T5

DE112016001193T5 - Protokollunabhängiger, programmierbarer Schalter für durch Software definierte Datenzentrumsnetzwerke

Info

Publication number: DE112016001193T5
Application number: DE112016001193.8T
Authority: DE
Inventors: Guy Townsend Hutchison; Sachin Gandhi; Tsahi Daniel; Gerald Schmidt; Albert Fishman; Martin Leslie White; Zubin Shah
Original assignee: Cavium LLC
Current assignee: Marvell Asia Pte Ltd
Priority date: 2015-03-13
Filing date: 2016-03-11
Publication date: 2017-11-30
Also published as: TW201707418A; WO2016149121A1; CN107529352B; CN107529352A

Abstract

Ein durch Software definiertes Netzwerksystem bzw. SDN-System (SDN = Software-Defined Network), -vorrichtung und -verfahren weisen einen oder mehrere Eingangsanschlüsse, einen programmierbaren Syntaxanalysator bzw. Parser, eine Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines), programmierbare Suchspeicher, programmierbare Zählvorrichtungen, einen programmierbaren Umschreibblock und einen oder mehrere Ausgangsanschlüsse auf. Die Programmierbarkeit des Parsers, der LDEs, der Suchspeicher, der Zählvorrichtungen und des Umschreibblocks ermöglichen es einem Nutzer, jeden Mikrochip innerhalb des Systems individuell an bestimme Paketumgebungen, Datenanalyseanforderungen, Paketverarbeitungsfunktionen und andere Funktionen wunschgemäß anzupassen. Ferner ist der gleiche Mikrochip imstande für andere Zwecke und/oder Optimierungen dynamisch umprogrammiert zu werden.

Description

Verwandte Anmeldungen
Diese Anmeldung beansprucht die Priorität unter 35 U. S. C. § 119(e) der vorläufigen U. S. Patentanmeldung Nr. 62/133,166, betitelt „PIPS: PROTOCOL INDEPENDENT PROGRAMMABE SWITCH (PIPS) FOR SOFTWARE DEFINED DATA CENTER NETWORKS”, eingereicht am 13. März 2015, und ist eine Continuationin-Part der ebenfalls anhängigen U. S. Patentanmeldung Nr. 14/144,270, betitelt „APPARATUS AND METHOD OF GENERATING LOOKUPS AND MAKING DECISIONS FOR PACKET MODIFYING AND FORWARDING IN A SOFTWARE-DEFINED NETWORK ENGINE” und eingereicht am 30. Dezember 2013, die beide hierin durch Bezugnahme enthalten sind.
Gebiet der Erfindung
Die Erfindung bezieht sich auf das Gebiet von Netzwerkvorrichtungen. Insbesondere bezieht sich die Erfindung auf durch Software definierte Datenzentrumsvorrichtungen, -systeme und -verfahren.
Hintergrund der Erfindung
Das Paradigma der durch Software definierten Netzwerke bzw. SDNs (SDNs = Software-Defined Networks) verspricht die Anforderungen moderner Datenzentren mit einer feinmaschigen Steuerung über das Netzwerk zu adressieren. Feste Pipeline-Switches sehen jedoch nicht den Grad an Flexibilität und Programmierbarkeit vor, der für durch Software definierte Datenzentrenarchitekturen bzw. SDDC-Architekturen (SDDC = Software Defined Data Centers) erforderlich sind, um die zugrundeliegenden Netzwerke zu optimieren. Insbesondere, obwohl SDDC-Architekturen Anwendungen in das Zentrum der Innovation setzen, wird das vollständige Leistungsvermögen dieser Anwendungen durch feste Leitungen bzw. Pipelines vereitelt, die durch Netzwerkausrüstungen diktiert werden. Beispielsweise werden die Anwendungen gezwungen für die Verwendung existierender Protokolle ausgelegt zu werden, was die Innovation abschwächt.
Zusammenfassung der Erfindung
Ausführungsbeispiele der Erfindung sind auf ein durch Software definiertes Netzwerksystem bzw. SDN-System (SDN = Software-Defined Network), -Vorrichtung und -Verfahren gerichtet, die eine oder mehrere Eingabeanschlüsse, einen programmierbaren Syntaxanalysator bzw. Parser, eine Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines), programmierbare Suchspeicher, programmierbare Zählvorrichtungen bzw. Zähler, einen programmierbaren Umschreibblock und eine oder mehrere Ausgabeanschlüsse aufweisen. Die Programmierbarkeit des Parsers, der LDEs, der Suchspeicher, Zählvorrichtungen und des Umschreibblocks ermöglichen es einem Nutzer, jeden Mikrochip innerhalb des Systems individuell an bestimmte Paketumgebungen, Datenanalyseanforderungen, Paketverarbeitungsfunktionen und andere Funktionen, wie gewünscht, anzupassen. Ferner ist der gleiche Mikrochip imstande für andere Zwecke und/oder Optimierungen dynamisch angepasst zu werden. Darüber hinaus ermöglicht durch Vorsehen einer programmierbaren Pipeline mit flexiblem Tabellenmanagement, das PIPS ein durch Software definiertes Verfahren zur Adressierung zahlreicher Paketverarbeitungsanforderungen.
Ein erster Aspekt ist auf einen Switch-Mikrochip für ein SDN gerichtet. Der Mikrochip weist Folgendes auf: einen programmierbaren Syntaxanalysator bzw. Parser, der erwünschte Paketkontextdaten aus Headern bzw. Kopfteilen einer Vielzahl von eingehenden Paketen analysiert, wobei die Kopfteile, die durch den Parser erkannt werden, auf einem durch Software definierten Analysediagramm des Parsers basieren, eine oder mehrere Suchspeicher mit einer Vielzahl von Tabellen, wobei die Suchspeicher als eine logische Überlagerung bzw. Overlay konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch Software durch einen Nutzer definiert werden, eine Leitung bzw. Pipeline einer Vielzahl von programmierbaren LDEs (LDEs = Lookup and Decision Engines), die die Paketkontextdaten basierend auf Daten empfangen und modifizieren, die in den Suchspeichern gespeichert sind, sowie auf einer durch Software definierten Logik, die in die Maschinen durch den Nutzer programmiert ist, einen programmierbaren Umschreibblock, der basierend auf den Paketkontextdaten, die von einer der Maschinen empfangen wurden, die Paketkopfteile neu aufbaut und vorbereitet, und zwar so wie sie innerhalb des Switchs für die Ausgabe verarbeitet werden, sowie einen programmierbaren Zählerblock, der für die Zählvorgänge der LDEs verwendet wird, wobei der Betrieb, der durch den Zählerblock gezählt wird, durch Software durch den Nutzer definiert wird. In einigen Ausführungsbeispielen, beginnend bei dem gleichen Anfangsknoten des Analysediagramms, repräsentiert jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile, der imstande ist durch den Syntaxanalysator bzw. Parser erkannt zu werden. In einigen Ausführungsbeispielen überlappen sich Teile der Pfade. In einigen Ausführungsbeispielen expandiert der Umschreibblock jede Schicht von jedem der Kopfteil, die durch den Parser analysiert wird, um einen expandierten Schichttyp einer generischen Größe basierend auf einem Protokoll zu bilden, das mit der Schicht assoziiert ist. In einigen Ausführungsbeispielen erzeugt der Umschreibblock einen Bitvektor, der anzeigt, welche Teile des expandierten Schichttyps valide Daten enthalten und welche Teile des expandierten Schichttyps Daten enthalten, die während der Expansion durch den Umschreibblock hinzugefügt wurden. In einigen Ausführungsbeispielen sind die Tabellen der Suchspeicher jeweils imstande, in unabhängiger Weise in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi eingestellt zu werden. In einigen Ausführungsbeispielen sind die Tabellen der Suchspeicher imstande in dynamischer Weise durch den Nutzer neu formatiert und neu konfiguriert zu werden, so dass eine Anzahl der Kacheln der Suchspeicher, die für die Suchpfade partitioniert und zugewiesen sind, die mit den Suchspeichern gekoppelt sind, auf der Speicherkapazität basiert, die für jeden der Suchpfade erforderlich ist. In einigen Ausführungsbeispielen weist jede der Such- und Entscheidungsmaschinen einen Schlüsselgenerator bzw. Key-Generator auf, der konfiguriert ist, um einen Satz von Suchschlüsseln für jedes Eingabezeichen bzw. jeden Eingabetoken zu erzeugen, und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um einen Ausgabetoken durch Modifizieren des Eingabetokens basierend auf dem Inhalt der Suchergebnisse zu erzeugen, die mit dem Satz der Suchschlüssel assoziiert sind. In einigen Ausführungsbeispielen weist jede der Such- und Entscheidungsmaschinen einen Eingabepuffer zur temporären Speicherung der Eingabetoken, bevor die Eingabetoken durch die Such- und Entscheidungsmaschine verarbeitet werden, eine Profiltabelle zur Identifizierung von Feldpositionen in jedem der Eingabetoken, eine Suchergebniszusammenführungsvorrichtung zum Verbinden des Eingabetokens mit dem Suchergebnis und zum Senden des verbundenen Eingabetokens mit dem Suchergebnis an den Ausgabegenerator; eine Loopback- bzw. Schleifenschaltungsüberprüfungsvorrichtung zum Bestimmen, ob der Ausgabetoken zurück zu der aktuellen Such- und Entscheidungsmaschine oder zu einer anderen Such- und Entscheidungsmaschine gesendet werden soll; und einen Loopback- bzw. Schleifenschaltungspuffer zum Speichern von Loopback-Wertmerkmalen bzw. -Zeichen. In einigen Ausführungsbeispielen sind die Steuerpfade von sowohl dem Schlüsselgenerator als auch dem Ausgabegenerator so programmierbar, dass Nutzer imstande sind, die Such- und Entscheidungsmaschine so zu konfigurieren, dass sie unterschiedliche Netzwerkmerkmale und -protokolle unterstützt. In einigen Ausführungsbeispielen weist der Zählerblock N Wrap-around- bzw. Umschaltzähler, wobei jeder der N Umschaltzähler mit einer Zählerkennung assoziiert ist; und einen Überlauf-FIFO auf, der von den N Umschaltzählern verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen.
Ein zweiter Aspekt ist auf ein Verfahren zum Betätigen eines Switch-Mikrochips für ein durch Software definiertes Netzwerk gerichtet. Das Verfahren weist Folgendes auf: Analysieren bzw. Parsen erwünschter Paketkontextdaten aus Kopfteilen einer Vielzahl von eingehenden Paketen mit einem programmierbaren Syntaxanalysierer bzw. Parser auf, wobei die Kopfteile durch den Parser basierend auf einem durch Software definierten Analysediagramm des Parsers erkannt werden; Empfangen und Modifizieren der Paketkontextdaten mit einer Leitung bzw. Pipeline einer Vielzahl von programmierbaren Such- und Entscheidungsmaschinen basierend auf Daten, die in Suchspeichern gespeichert sind, die eine Vielzahl von Tabellen und eine durch Software definierte Logik aufweisen, die in die Maschinen durch einen Nutzer programmiert werden; Übertragen von einer oder mehreren Datensuchanfragen an und Empfangen von Verarbeitungsdaten basierend auf den Anfragen von den Suchspeichern durch die Such- und Entscheidungsmaschinen, wobei die Suchspeicher als logische Überlagerung konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch den Nutzer durch Software definiert werden; Ausführen von Zählvorgängen basierend auf Aktionen der Such- und Entscheidungsmaschinen mit einem programmierbaren Zählblock, wobei die Zählvorgänge, die durch den Zählblock gezählt werden, durch den Nutzer durch Software definiert werden; und Neuaufbauen der Paketkopfteile, wie sie innerhalb des Switchs verarbeitet werden, mit einem programmierbaren Umschreibblock zur Ausgabe, wobei die Umschreibung auf den Paketkontextdaten basiert, die von einer der Such- und Entscheidungsmaschinen empfangen werden. In einigen Ausführungsbeispielen, beginnend von dem gleichen Anfangsknoten des Analysediagramms, repräsentiert jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile, der imstande ist, durch den Parser erkannt zu werden. In einigen Ausführungsbeispielen überlappen sich Teile der Pfade. In einigen Ausführungsbeispielen expandiert der Umschreibblock jede Schicht von jedem Kopfteil, der durch den Parser analysiert wird, um einen expandierten Schichttyp einer generischen Größe basierend auf einem Protokoll, das mit der Schicht assoziiert ist, zu bilden. In einigen Ausführungsbeispielen erzeugt der Umschreibblock einen Bitvektor, der anzeigt, welche Teile des expandierten Schichttyps valide bzw. gültige Daten enthalten und welche Teile des expandierten Schichttyps Daten enthalten, die während des Expandierens durch den Umschreibblock hinzugefügt wurden. In einigen Ausführungsbeispielen sind die Tabellen der Suchspeicher jeweils imstande, in unabhängiger Weise in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi eingestellt zu werden. In einigen Ausführungsbeispielen sind die Tabellen der Suchspeicher imstande, dynamisch durch den Nutzer neu formatiert und neu konfiguriert zu werden, so dass eine Anzahl von Tiles bzw. Kacheln der Suchspeicher, die für Suchpfade partitioniert und zugewiesen werden, die mit den Suchspeichern gekoppelt sind, auf Speicherkapazität basiert, die für jeden der Suchpfade erforderlich ist. In einigen Ausführungsbeispielen weist jede der Such- und Entscheidungsmaschinen Folgendes auf: einen Schlüsselgenerator bzw. Key-Generator, der konfiguriert ist, um einen Satz von Suchschlüsseln für jeden Eingabetoken zu erzeugen; und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um ein Ausgabezeichen bzw. einen Ausgabetoken zu erzeugen, und zwar durch Modifizieren des Eingabetokens basierend auf Inhalt der Suchergebnisse, die mit dem Satz der Suchschlüssel assoziiert sind. In einigen Ausführungsbeispielen weist jede der Such- und Entscheidungsmaschinen Folgendes auf: einen Eingabepuffer zum temporären Speichern von Eingabetoken bevor die Eingabetoken durch die Such- und Entscheidungsmaschine verarbeitet werden; eine Profiltabelle zum Identifizieren von Positionen der Felder in jedem der Eingabetoken; eine Suchergebniszusammenführungsvorrichtung zum Verbinden des Eingabetokens mit dem Suchergebnis und zum Senden des verbundenen Eingabetokens mit dem Suchergebnis an den Ausgabegenerator; eine Loopback- bzw. Schleifenschaltungsüberprüfungsvorrichtung zum Bestimmen, ob der Ausgabetoken zurück zu der aktuellen Such- und Entscheidungsmaschine oder zu einer anderen Such- und Entscheidungsmaschine gesendet werden soll; und einen Loopback- bzw. Schleifenschaltungspuffer zum Speichern von Loopback-Wertmerkmalen bzw. -Zeichen. In einigen Ausführungsbeispielen sind die Steuerpfade von sowohl dem Schlüsselgenerator als auch dem Ausgabegenerator so programmierbar sind, dass Nutzer imstande sind, die Such- und Entscheidungsmaschine so zu konfigurieren, dass sie unterschiedliche Netzwerkmerkmale und -protokolle unterstützt. In einigen Ausführungsbeispielen weist der Zählerblock Folgendes auf: N Wrap-around- bzw. Umschaltzähler, wobei jeder der N Umschaltzähler mit einer Zählerkennung assoziiert ist; und einen Überlauf-FIFO, der von den N Umschaltzählern verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen.
Ein dritter Aspekt ist auf einen Top-of-Rack-Switch-Mikrochip gerichtet. Der Mikrochip weist Folgendes auf: einen programmierbaren Syntaxanalysator bzw. Parser, der erwünschte Paketkontextdaten aus Headern bzw. Kopfteil einer Vielzahl von eingehenden Paketen analysiert, wobei die Kopfteile durch den Parser basierend auf einem durch Software definierten Syntax- bzw. Analysediagramm des Parsers erkannt werden und wobei, beginnend mit dem gleichen Anfangsknoten des Analysediagramms, jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile repräsentiert, die durch den Parser erkannt werden können; eine oder mehrere Suchspeicher mit einer Vielzahl von Tabellen, einen Schlüsselgenerator bzw. Key-Generator, der konfiguriert ist, um einen Satz von Suchschlüsseln für jeden Eingabetoken zu erzeugen, und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um einen Ausgabetoken durch Modifizieren des Eingabetokens basierend auf einem Inhalt der Suchergebnisse zu erzeugen, die mit dem Satz der Suchschlüssel assoziiert sind, wobei die Suchspeicher als logische Überlagerung bzw. Overlay konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch einen Nutzer durch Software definiert werden, und ferner wobei jeder der Suchspeicher konfiguriert ist, um selektiv in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi zu arbeiten; eine Leitung bzw. Pipeline einer Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines), die die Paketkontextdaten basierend auf Daten empfangen und modifizieren, die in den Suchspeichern gespeichert sind, sowie eine durch Software definierten Logik, die in die Maschinen durch den Nutzer programmiert ist; einen programmierbaren Umschreibblock, der basierend auf den Paketkontextdaten, die von einer der Maschinen empfangen werden, die Paketkopfteile umbaut und vorbereitet, und zwar so wie sie innerhalb des Schalters bzw. Switch zur Ausgabe verarbeitet werden, wobei der Umschreibblock jede Schicht von jedem der Kopfteile expandiert, die durch den Parser analysiert werden, um einen expandierten Schichttyp einer generischen Größe zu bilden, und zwar basierend auf einem Protokoll, das mit der Schicht assoziiert ist; und einen programmierbaren Zählerblock, der für Zählvorgänge der Such- und Entscheidungsmaschinen verwendet wird, wobei der Zählerblock N Wrap-around- bzw. Umschaltzähler aufweist, wobei jeder der N Zeilenübertragsähler mit einer Zählerkennung assoziiert ist und einem Überlauf-FIFO, der durch die N Umschaltzähler verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen, und ferner wobei die Betriebe bzw. Vorgänge, die durch den Zählerblock ausgeführt werden, durch den Nutzer durch Software definiert werden.
Kurze Beschreibung der Zeichnungen
1 stellt ein durch Software definiertes Netzwerk- bzw. SDN-System gemäß einigen Ausführungsbeispielen dar.
2 stellt eine Syntaxanalysator- bzw. Parsermaschine des Parsers gemäß einigen Ausführungsbeispielen dar.
3 stellt ein beispielhaftes, direkt verbundenes, zyklisches Diagramm oder einen Syntaxanalysator- bzw. Parseverzeichnisbaum gemäß einigen Ausführungsbeispielen dar.
4 stellt ein Verfahren zum Betätigen eines Parseprogrammierungswerkzeugs bzw. -tools gemäß einigen Ausführungsbeispielen dar.
5 stellt einen beispielhaften Aufbau einer lokalen Parsekarte oder -tabelle gemäß einigen Ausführungsbeispielen dar.
6 stellt ein beispielhaftes Verfahren eines Netzwerk-Switchs gemäß einigen Ausführungsbeispielen dar.
7 stellt ein weiteres, beispielhaftes Verfahren des Netzwerk-Switchs gemäß einigen Ausführungsbeispielen dar.
8 stellt ein Blockdiagramm einer Such- und Entscheidungsmaschine bzw.
LDE zum Erzeugen von Suchschlüsseln und zum Modifizieren von Wertmerkmalen bzw. Token gemäß einem Ausführungsbeispiel dar.
9 stellt ein Suchspeichersystem gemäß einem Ausführungsbeispiel dar.
10 stellt ein Verfahren zum Konfigurieren und Programmieren eines Parallelsuchspeichersystems gemäß einem Ausführungsbeispiel dar.
11 stellt ein Blockdiagramm eines Zählerblocks gemäß einem Ausführungsbeispiel dar.
12 stellt ein Verfahren eines Zählerblocks, wie beispielsweise des Zählerblocks in 11, gemäß einem Ausführungsbeispiel dar.
13 stellt ein Verfahren zum Betätigen des SDN-Systems gemäß einigen Ausführungsbeispielen dar.
Detaillierte Beschreibung der vorliegenden Erfindung
Ausführungsbeispiele des durch Software definierten Netzwerk- bzw. SDN-Systems, der SDN-Vorrichtung und des SDN-Verfahrens weisen einen oder mehrere Eingabeanschlüsse, einen programmierbaren Syntaxanalysator bzw. Parser, eine Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines), programmierbare Suchspeicher, programmierbare Zählvorrichtungen, einen programmierbaren Umschreibblock und eine oder mehrere Ausgabeanschlüsse auf. Die Programmierbarkeit des Parsers, der LDEs, der Suchspeicher, der Zählvorrichtungen und des Umschreibblocks ermöglichen es einem Nutzer, jeden Mikrochip innerhalb des Systems individuell an bestimmte Paketumgebungen, Datenanalyseanforderungen, Paketverarbeitungsfunktionen und andere Funktionen, wie erwünscht, anzupassen. Ferner ist der gleiche Mikrochip imstande, für andere Zwecke und/oder Optimierungen dynamisch neu programmiert zu werden. Infolgedessen sieht das System die Fähigkeit vor, programmatisch die Leistung des Systems individuell anzupassen, wodurch eine vereinheitlichte Hardware und Software bzw. Unified Hardware and Software erzeugt wird, die in verschiedenen Einsatzmöglichkeiten verwendet werden kann. Ferner ermöglicht es den auf Optimierung zugeschnittenen Einsatz für anwendungsspezifische Anforderungen. Mit anderen Worten sieht die durch Systemsoftware definierte Flexibilität die Möglichkeit vor, den gleichen Switch-Mikrochip individuell anzupassen, so dass dieser die gleiche, hohe Bandbreite und hohe Anschlussdichte vorsieht, obwohl er an mehreren unterschiedlichen Orten innerhalb eines Netzwerks positioniert ist.
1 stellt ein Blockdiagramm eines durch Software definierten Netzwerksystems bzw. SDN-Systems (SDN = Software-Defined Network) 100 gemäß einigen Ausführungsbeispielen dar. In einigen Ausführungsbeispielen ist das System 100 imstande einen einzelnen, vollintegrierten Switch-Mikrochip (z. B. einen Top-of-Rack-Switch) aufzuweisen. Alternativ ist das System 100 imstande, eine Vielzahl von kommunikativ gekoppelten Switch-Mikrochips aufzuweisen, die gemeinsam und/oder einzeln das System 100 aufweisen. Das System 100 (oder jeder Mikrochip innerhalb des Systems) weist einen oder mehrere Eingabeanschlüsse 102, einen Parser 104, eine Vielzahl von Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines) 106 (die eine Pipeline bzw. Leitung und/oder ein Netz bilden), Suchspeicher 108, Zählvorrichtungen 110, einen Umschreibblock 112 und einen oder mehrere Ausgabeanschlüsse 114 auf. Die Anschlüsse 102, 114 dienen dem Empfangen und Übertragen von Paketen in und aus dem System 100. Der Parser 104 ist ein programmierbarer Paketkopfteilklassifizierer, der eine durch Software definierte Protokollsyntaxanalyse bzw. -parsing implementiert. Genauer gesagt, ist der Parser 104 imstande, anstatt fest auf spezifische Protokolle codiert zu sein, eingehende Kopfteile basierend auf einem durch Software definierten Syntaxbaum zu analysieren. Folglich ist der Parser imstande, die notwendigen Daten aus sämtlichen erwünschten Kopfteilen zu erkennen und zu extrahieren. Die Suchspeicher 108 sind imstande Direktzugriffsspeicher, Hash-Speicher, Longest-Prefix-Match- bzw. LPM-Speicher, ternäre Assoziativspeicher bzw. TCAM-Speicher (TCAM = Ternary Content-Adressable Memory), statische Zufallszugriffs- bzw. SRAM-Speicher (SRAM = Static Random Access Memory) und/oder andere Typen/Allokationen von Speichern aufzuweisen, die für den Betrieb des Systems (z. B. als Paketspeicher, Pufferspeicher) verwendet werden. Insbesondere sind die Suchspeicher 108 imstande, einen Pool aus On-Chip-Speichern aufzuweisen, die als logische Überlagerung konfiguriert sind, die eine durch Software definierte variable Skalierung und Breite vorsieht. Infolgedessen sind die Tabellen des Speichers 108 imstande in logisch unabhängiger Art und Weise in Hash-, LPM-, Direktzugriffs- oder andere Betriebsmodi eingestellt und basierend auf den Softwareanforderungen dynamisch neu formatiert zu werden.
13 stellt ein Verfahren zum Betreiben des SDN-Systems gemäß einigen Ausführungsbeispielen dar. Wie in 13 gezeigt, wird ein Netzwerkpaket bei dem Parser 104 über einen oder mehrere Eingabeanschlüsse 102 bei dem Schritt 1302 empfangen. Der Parser 104 erkennt und analysiert Kopfteile des Netzwerkpakets, um Daten aus den relevanten Feldern basierend auf einem programmierbaren Syntaxbaum zu extrahieren und setzt Steuerbits und die analysierten Kopfteile in einen Token bei Schritt 1304. Der Parser 104 sendet den Token an die eine oder die Vielzahl der LDEs 106 und die originale Paketnutzlast/-daten an den Paketspeicher der Suchspeicher 108 bei Schritt 1306. Jede LDE 106 innerhalb der Pipeline von LDEs führt durch den Nutzer programmierte Verarbeitungsentscheidungen basierend auf den Daten, die in den Suchspeichern 108 gespeichert sind, und dem Token-/Paketkontext aus, der von dem Parser 104 (oder der vorangehenden LDE 106) innerhalb der Pipeline bei Schritt 1308 aus. Gleichzeitig überwachen/empfangen die Zählvorrichtungen 110 Aktualisierungsdaten für die Ereignisse des Weiterleitungs-/Pipelineprozesses, an den sie basierend auf der Benutzerprogrammierung gebunden sind, bei Schritt 1310. Dann am Ende der Pipeline leitet die letzte LDE 106 den Paket/Paket-Kontext an den Umschreibblock 112 bei Schritt 1312 weiter. Der Umschreibblock 112 formatiert die ausgehenden Paketkopfteile und baut diese auf bzw. neu auf, und zwar basierend auf den empfangenen Paketdaten und leitet diese an den Ausgabeanschluss weiter, wo sie imstande sind, gemeinsam mit den entsprechenden Paketdaten, die aus dem Paketspeicher der Suchspeicher 108 abgefragt wurden, bei Schritt 1314 ausgegeben zu werden. Mit anderen Worten ist das Umschreiben 112 imstande, die Modifikationen zu beschließen, die an den Paketen für die Verarbeitung (für die Einkapselung und Auskapselung) erforderlich sind, und baut die ausgehenden Pakete neu auf und bereitet diese vor. Infolgedessen ist das ausgegebene Paket imstande an andere Komponenten des SDN-Systems zur weiteren Verarbeitung gesendet zu werden, oder an eine andere Vorrichtung in dem Netzwerk weitergeleitet zu werden, oder kann zurück an den Parser gesendet werden (Loopback), um imstande zu sein, mehr Suchen durchzuführen, wenn dies bei Schritt 1316 erwünscht ist.
Parser/Umschreiben
Der Parser 104 kann ebenfalls eine oder mehrere Parsermaschinen aufweisen, um Inhalte der Netzwerkpakete zu identifizieren und die Umschreibvorrichtung 112 kann eine oder mehrere Umschreibmaschinen aufweisen, um die Pakete zu modifizieren bevor sie von dem Netzwerk-Switch ausgesendet werden. Die Parsermaschine(n) und die Umschreibmaschine(n) sind flexibel und arbeiten auf einer programmierbaren Basis. Insbesondere ist der Parser 104 imstande, Pakete zu decodieren und interne, programmierbare Schichtinformation (wie im Detail nachfolgend beschrieben) zu extrahieren, wobei die interne Schichtinformation durch das System 100 verwendet wird, um vorwärts gerichtete Entscheidungen für dieses Paket durch die Pipeline zu treffen. Zusätzlich, wie nachfolgend beschrieben, führt die Umschreibvorrichtung 112 Transformationen an dieser internen Schichtinformation aus, um das Paket, wie erforderlich, zu modifizieren. Wie vorangehend beschrieben, weist das System 100 ebenfalls einen Speicher (z. B. Suchspeicher 108) auf, um Daten zu speichern, die durch das System 100 verwendet werden. Beispielsweise ist der Speicher imstande, einen Satz von generischen Befehlen zu speichern, die verwendet werden, um die Protokollkopfteile zu modifizieren. Als ein weiteres Beispiel ist der Speicher imstande, ebenfalls durch Software definierte Abbildungen bzw. Mappings generischer Formate von Protokollen in der Form einer Parse- bzw. Syntaxabbildung (oder -tabelle) zu speichern, wobei jeder Protokollkopfteil gemäß einer der durch Software definierten Abbildungen repräsentiert ist, die für eine entsprechendes Protokoll spezifisch ist. Wie offensichtlich werden wird, sind diese Abbildungen imstande, verwendet zu werden, um unterschiedliche Variationen eines Protokolls ebenso wie auf unterschiedlichen Protokollen zu identifizieren, und zwar einschließlich neuen Protokollen, die zuvor nicht bekannt waren. In einigen Ausführungsbeispielen weist die Syntaxabbildung Schichtinformation jeder Protokollschicht von jeder Protokollschichtkombination auf, die in die Syntaxabbildung (oder -tabelle) programmiert ist.
Im Ethernet weisen Pakete mehrere Protokollschichten auf. Jede Protokollschicht trägt unterschiedliche Informationen. Einige Beispiel gut bekannter Schichten sind Ethernet; PBB-Ethernet; ARP IPV4; IPV6; MPLS; FCOE; TCP; UDP; ICMP; IGMP; GRE; ICMPv6; VxLAN; TRILL und CNM. Theoretisch können die Protokollschichten in irgendeiner Reihenfolge auftreten. Es können jedoch nur gut bekannte Kombinationen dieser Schichten auftreten. Einige Beispiele gültiger Kombinationen dieser Schichten sind Ethernet; Ethernet, ARP; Ethernet, CNM; Ethernet, FcoE; Ethernet, IPV4; Ethernet, IPV4, ICMP; und Ethernet, IPV4, IGMP.
In einigen Ausführungsbeispielen unterstützt das Netzwerk-Switch 17 Protokolle und acht Protokollschichten. Es gibt daher 8¹⁷ mögliche Protokollschichtkombinationen. Ein Paket kann eine Kombination aus drei Protokollschichten, wie beispielsweise Ethernet, IPv4 und ICMP aufweisen. Als ein weiteres Beispiel kann ein Paket eine Kombination aus sieben Protokollschichten aufweisen, wie beispielsweise Ethernet, IPv4, UDP, VxLAN, Ethernet und ARP. Obwohl es 8¹⁷ mögliche Kombinationen von Protokollschichten gibt, treten nur einige gut bekannte Kombinationen dieser Schichten auf. In einigen Ausführungsbeispielen sind sämtliche bekannten Kombinationen von Protokollschichten eindeutig identifiziert und in eine eindeutige Zahl übersetzt, die als die Paketkennung bzw. PktID (PktID = Packet Identifier) bezeichnet wird. Eine Syntaxtabelle, die in den Speicher des Netzwerk-Switchs gespeichert ist, kann so programmiert sein, dass sie Schichtinformation jeder Schicht jeder bekannten Protokollschichtkombination aufweist. In der Praxis weist diese lokale Syntaxtabelle weniger als 256 Protokollschichtkombinationen auf. In einigen Ausführungsbeispielen weist die lokale Tabelle 212 bekannte Kombinationen von Protokollschichten auf. Die Lokale Tabelle kann dynamisch neu programmiert werden, um mehr oder weniger Kombinationen von Protokollschichten aufzuweisen.
In einigen Ausführungsbeispielen können der Parser und/oder die Umschreibvorrichtung hierin die gleichen sein, wie der Parser und/oder die Umschreibvorrichtung, die in der US-Patentanmeldung Nr. 14/309,603 beschrieben sind, die betitelt ist „Method of modifying packets to generate format for enabling programmable modifications and an apparatus thereof”, und die am 19. Juni 2014 eingereicht wurde, die hierin durch Bezugnahme aufgenommen ist. In einigen Ausführungsbeispielen können die hierin beschriebenen Parser die gleichen sein, wie die Parser, die in der US-Patentanmeldung Nr. 14/675,667 beschrieben sind, die betitelt ist „A parser engine programming tool for programmable network devices”, die am 31. März 2015 eingereicht wurde und hierin durch Bezugnahme aufgenommen ist.
Parser
2 stellt eine Parsermaschine 99 des Parsers 104 gemäß einigen Ausführungsbeispielen dar. Wie in 2 gezeigt, weist die Parsermaschine 99 eine oder mehrere Kangaroo-Parser-Einheiten bzw. KPUs (KPUs = Kangaroo Parser Units) 202 auf, die mit einer Feldextraktionseinheit 208 und einen TCAM-Speicher 204 auf, der mit dem statischen Zufallszugriffsspeicher bzw. SRAM 206 gepaart ist, wobei jeder SRAM 206 von einer Stufe der Maschine 99 kommunikativ mit einem bestimmten Zustand/Kontext (der mit einem Subjektpaketkopfteil assoziiert ist) gekoppelt ist und diesen beschickt, und zwar von dieser Stufe zu der KPU 202 der nächsten Stufe, so dass es möglich ist, einem Syntaxbaum/-diagramm 300 (nachfolgend beschrieben) zu folgen, wenn ein Paketkopfteil analysiert wird. Alternativ können der TCAM 204 und/oder der SRAM 206 andere Arten von Speichern sein, wie sie in der Technik bekannt sind. Zusätzlich, obwohl die TCAM 204, 204 und SRAM 206, 206' Speicherpaare separat für jede der KPUs 202, 202' gezeigt sind, können sie einen einzelnen TCAM-Speicher und/oder SRAM Speicher aufweisen, wobei jede KPU 202, 202' mit einem Teil des Speichers assoziiert ist. Im Betrieb empfangen die KPUs 202, 202' eingehende Pakete 200 und parsen bzw. analysieren die Kopfteildaten 202 des Pakets 200 basierend auf den Parsingdaten, die in dem TCAM 204 und dem SRAM 206 gespeichert sind. Insbesondere können die Kopfteildaten 202 durch die TCAM 204 identifiziert werden und ein Index oder andere Kennung des TCAM 204 kann verwendet werden, um die korrekten Daten innerhalb des SRAM 206 zu finden, die anzeigen, welche Handlungen für das Paket 200 erfolgen müssen. Zusätzlich können die Daten, die mit dem Paket 200 innerhalb des SRAM 206 von irgendeiner der KPU-Stufen assoziiert sind Zustands-/Kontextinformation über das Paket 200/Kopfteildaten 202 aufweisen, die dann an eine KPU 202' einer nachfolgenden Stufe gesendet werden, so dass sie in dem Syntaxbaum/-diagramm 300 berücksichtigt werden, wodurch ermöglicht wird, dass das Syntaxdiagramm/-baum einen Übergang erfährt oder aktualisiert wird (z. B. zu einem nächsten Knoten innerhalb des Diagramms/Baums), basierend auf den Zustands-/Kontextdaten für das Paket 200/die Kopfteildaten 202, wie nachfolgend beschrieben. Basierend auf dem Parsing der Kopfteildaten 202 ist die Feldextraktionseinheit 208 imstande, die erforderlichen Daten aus dem Paket 200 zur Ausgabe aus der Parsingmaschine 99 zu extrahieren, so dass das Paket 200 in geeigneter Weise verarbeitet werden kann.
Damit die Parsingmaschine 99 imstande ist, die obigen Parsingfunktionen auszuführen, kann sie durch ein Parseprogrammierungswerkzeug bzw. -tool programmiert werden, so dass irgendeine Art von Kopfteildaten (z. B. einen Kopfteil, der eine oder mehrere Kopfteiltypen aufweisen), innerhalb eines Bereichs von möglichen Kopfteildaten spezifiziert ist, in geeigneter Weise durch die Parsingmaschine 99 analysiert werden kann. Infolgedessen ist das Programmierungswerkzeug so konfiguriert, dass es die eingegebene Konfigurationsdatei ausliest und automatisch (basierend auf den Daten innerhalb der Datei) einen Satz von Werten erzeugt, der notwendig ist, um die Parsingmaschine 99 zu programmieren, um sämtliche der möglichen Kopfteildaten zu bearbeiten, die durch die Konfigurationsdatei repräsentiert werden.
Die Konfigurationsdatei zeigt den Bereich der möglichen Kopfteildaten an, die die Parsingmaschine 99 imstande sein muss zu analysieren, indem ein direkt verbundenes, zyklisches Diagramm oder Syntaxbaum der möglichen Kopfteildaten beschrieben wird. 3 stellt ein beispielhaftes, direkt verbundenes, zyklisches Diagramm oder Syntaxbaum 300 gemäß einigen Ausführungsbeispielen dar. Wie in 3 gezeigt, weist das zyklische Diagramm 300 einen oder mehrere Knoten oder Blätter 302 auf, die jeweils miteinander durch unidirektionale Zweige oder Kanten 304 gekoppelt sind. Insbesondere ist das zyklische Diagramm oder der Baum 300 imstande, einen Wurzelknoten 302' als Startpunkt aufzuweisen, eine Vielzahl von Blätter- bzw. Laubknoten 302 und eine Vielzahl von Übergängen/Zweigen 304 zwischen den Knoten 302. Die Knoten 302, 302' sind imstande jeweils einen Kopfteiltyp oder Schichtnamen (z. B. ipv4, arp, ptp), einen Vorwärts- oder Pakethinweisabstandswert für die angezeigte Kopfteilschicht (nicht gezeigt), eine Schichttypkennung (nicht gezeigt) und einen Zustandswert innerhalb der Schicht (nicht gezeigt) aufzuweisen. Obwohl, wie in 3 gezeigt, das Diagramm 300 zwölf Verzweigungen 304 und sechs Knote 302, 302' mit beispielhaften Typen aufweist, die miteinander gemäß einer beispielhaften Struktur gekoppelt sind, werden oder weniger Knoten 302, 302' der gleichen oder unterschiedlichen Typen, die miteinander durch mehr oder weniger Zweige bzw. Verzweigungen 304 gekoppelt sind, erwogen. In einigen Ausführungsbeispielen stimmt der Schichttyp mit den sieben Schichten des offenen Systemzwischenverbindungs- bzw. OSI-Modells (OSI = Open System Interconnection) überein. Alternativ sind eine oder mehrere der Schichttypen imstande, von dem OSI-Modell abzuweichen, so dass Kopfteile, die sich in unterschiedlichen Schichten gemäß OSI befinden würden, der gleiche Schichttypwert gegeben wird, oder umgekehrt. Zusätzlich sind die Knoten 302, 302' imstande, die Kopfteilnamen irgendwelcher verbundener Knoten 302 aufzuweisen. Die Übergänge/Zweige 304 sind imstande, einen Anpassungs- bzw. Verknüpfungswert (z. B. 8100) und einen Maskenwert (z. B. ffff) aufzuweisen, die mit dem Übergang zwischen den zwei assoziierten Knoten 302 assoziiert sind. Auf diese Weise sind die Verknüpfungs- und Maskenwerte imstande den Übergang zwischen den zwei Knoten 302 zu repräsentieren. Infolgedessen können die Permutationen von Pfaden (zwischen den Knoten 302 über die Zweige 304) durch das Diagramm oder den Baum 300 einen Satz von Kopfteildaten 202 repräsentieren, wobei die Kombination der Paketkopfteile durch die Knoten 302 innerhalb des Pfads repräsentiert werden. Diese Pfade repräsentieren den Bereich, der durch die KPUs 202 der programmierbaren Parsermaschine 99 analysiert werden muss.
Um sämtliche möglichen Pfade durch das zyklische Diagramm 300 zu bestimmen, ist das Tool bzw. Hilfsprogramm imstande, sich entlang des Diagramms oder des Baums 300 unter Verwendung einer ersten Suche mit modifizierter Tiefe fortzubewegen. Insbesondere bewegt sich das Programmierungstool beginnen bei einem der Knoten 302 entlang eines der möglichen Pfade durch das Diagramm oder den Baum 300 (wie durch die Richtungsverbindungen gestattet) bis das Tool einen Endknoten (z. B. einen Knoten ohne abgehende Zweige 304) oder den Startknoten (z. B. wenn eine Schleife absolviert worden ist) erreicht. Alternativ ist das Programmierungstool in einigen Ausführungsbeispielen imstande, selbst wenn der Startknoten erreicht wurde, fortzufahren bis ein Endknoten erreicht worden ist oder der Startknoten ein zweites oder weiteres Mal erreicht worden ist. In jedem Fall ist das Tool während der Fortbewegung imstande, sequentiell Daten, die mit jedem überquerten Knoten 302 und Zweig 304 assoziiert sind, einem Stapel hinzuzufügen, so dass der Stapel ein Protokoll oder eine Liste des genommenen Pfads aufweist. Wenn der Endknoten oder der Startknoten 302 erreicht ist, wird der aktuelle Stapel bzw. Stack bestimmt und als ein vollständiger Pfad gespeichert und der Prozess wird wiederholt, um einen neuen vollständigen Pfad zu finden, bis sämtliche der möglichen Pfade und ihre assoziierten Stapel bzw. Stacks bestimmt worden sind. Auf diese Weise wird jede der Kombinationen von Kopfteilen, die imstande sind die Kopfteildaten 202 eines Pakets 200 zu bilden, durch einen der Pfade repräsentiert, so dass das Programmierungstool den Vorteil der automatischen Identifizierung sämtlicher der möglichen Kopfteildaten 202 basierend auf der eingegebenen Konfigurationsdatei vorsieht. In einigen Ausführungsbeispielen können eine oder mehrere der Kopfteilkombinationen oder -pfade, die durch das Tool bzw. Hilfsprogramm bestimmt werden, weggelassen werden. Alternativ können sämtliche der Kopfteile, die innerhalb des Diagramms oder Baums 300 möglich sind, enthalten sein.
Schließlich ist das Parserprogrammierungstool imstande die TCAM- und SRAM-Werte in den zugewiesenen Paaren der TCAMs 204 und SRAMs 206 von jeder der KPUs 202 des Parsers 104 zu speichern, so dass der Parser 104 imstande ist, sämtliche der möglichen Kopfteile 202 zu analysieren, die innerhalb des Diagramms oder Baums 300 der eingegebenen Konfigurationsdatei angezeigt sind.
4 stellt ein Verfahren zum Bedienen des Parserprogrammierungstools gemäß einigen Ausführungsbeispielen dar. Wie in 4 gezeigt, gibt eine Parservorrichtung, die das Parserprogrammierungstool speichert, die Parserkonfigurationsdatei mit dem Tool bzw. Hilfsprogramm bei Schritt 402 ein. In einigen Ausführungsbeispielen weist das Programmierungstool eine graphische Benutzerschnittstelle mit einem Eingabemerkmal auf, dass die Eingabe der Parserkonfigurationsdatei ermöglicht. Alternativ ist das Programmierungstool imstande, die Parsingvorrichtung nach der Konfigurationsdatei zu durchsuchen. Das Parsing- bzw. Syntaxanalyseprogrammierungstool erzeugt Programmierungswerte für die Parsermaschine basierend auf der Konfigurationsdatei beim Schritt 404. Die Werte können, bei Programmierung in einen Speicher (z. B. TCAM 204, SRAM 206), der mit jeder einer Vielzahl von Parsingmaschinen (z. B. KPUs 202) assoziiert ist, imstande sein, es den Parsingmaschinen zu ermöglichen, jede eines Satzes von unterschiedlichen Kombinationen der Paketkopfteile (z. B. Kopfteildaten 202) zu identifizieren, die durch die Konfigurationsdatei repräsentiert werden. In einigen Ausführungsbeispielen basiert das Erzeugen des Werts auf einer oder mehreren der möglichen Pfade innerhalb eines Diagramms 300 der Parserkonfigurationsdatei, wobei jeder der Pfade einer separaten Kombination der Paketkopfteile 202 (z. B. Stapel oder abgeflachter Stapel) entspricht. In einigen Ausführungsbeispielen weist das Erzeugen der Werte auf, dass das Parserprogrammierungstool automatisch sämtliche der Pfade des direkt verbundenen zyklischen Diagramms 300 berechnet. Beispielsweise ist das Tool imstande, jeden der Pfade zu bestimmen, der entweder bei dem gleichen Knoten 302 innerhalb des Diagramms endet oder startet oder bei einem Endknoten 302 innerhalb des Diagramms 300 endet, der keine abgehenden Zweige 304 aufweist. In einigen Ausführungsbeispielen weist das Verfahren ferner auf, dass das Tool einen ersten Teil der Werte innerhalb von Einträgen des TCAM 204 speichert, so dass die Daten, die mit Kopfteiltypen mit unterschiedlichen Schichttypen assoziiert sind, nicht den TCAM-Eintrag belegen. In einigen Ausführungsbeispielen weist das Verfahren ferner auf, dass das Werkzeug automatisch doppelte Einträge des TCAM 204 entfernt. Infolgedessen sieht das Verfahren den Vorteil der automatischen Programmierung von einer oder mehreren Parsingmaschinen vor, so dass sie imstande sind, irgendeine Kombination von Kopfteiltypen zu analysieren, die die Kopfteildaten 202 eines Pakets 200 bilden, wie sie durch eine Konfigurationsdatei repräsentiert sind.
Umschreiben
5 stellt einen beispielhaften Aufbau der lokalen Syntaxanalyse- bzw. Syntaxtabelle 500 gemäß einigen Ausführungsbeispielen dar. Das Parseabbild 500 kann durch Software definiert werden, um das Parsing/Umschreiben für bekannte und unbekannte, eintreffende Paketkopfteile individuell anzupassen. Mit anderen Worten ermöglicht es das Paketgeneralisierungsschema Software, einen kleinen Satz von generischen Befehlen zu definieren, der vollständig auf einer gegeben Protokollschicht basiert und unabhängig von Schichten ist, der dieser Protokollschicht vorgelagert sind oder folgen. Dies hat den zusätzlichen Vorteil des Vorsehens von Hardware-Flexibilität, um sich zukunftssicher gegenüber Protokollveränderungen und -hinzufügungen zu machen. Jede Protokollschichtkombination in der Syntaxtabelle 500, die unter Verwendung von PktID indexiert ist, weist Information für jede Protokollschicht dieser Protokollschichtkombination auf, die als Layer0-Information, Layer1-Information und LayerN-Information gezeigt ist. Durch Indexieren der PktID-Information kann auf sämtliche der N Schichten eines Pakets zugegriffen werden oder diese abgefragt werden.
Die Information für jede Protokollschicht kann das Folgende aufweisen: Schichttyp, Schichtdatenabstand bzw. Layer Data Offset und Sonstige Information. Mehr Information kann jedoch in der lokalen Tabelle 500 gespeichert werden. Kurz gesagt, bezeichnet der Schichttyp ein assoziiertes Protokoll (z. B. IP/TCP/UDP/Ethernet) der Protokollschicht, Layer Data Offset sieht eine Startposition der Schichtdaten in der Protokollschicht vor und die Sonstige bzw. Miscellaneous Information weist Daten, wie beispielsweise Prüfsummen- und Längendaten auf. Bei der Syntaxanalyse bzw. dem Parsing eines eintreffenden Pakets, ist die Parsingmaschine imstande die PktID des eintreffenden Pakets basierend auf der Syntaxtabelle zu identifizieren. Genauer gesagt, weist jede Kombination von Schichttypen, die einen Paketkopfteil ausmachen, eine eindeutige PktID auf. Die Umschreibmaschine verwendet die PktID als Schlüssel zur Syntaxtabelle, der der Umschreibmaschine sämtliche Information gibt, die erforderlich ist, um jede Protokollschicht des Pakets zur Modifikation zu generalisieren. Mit anderen Worten verwendet die Umschreibmaschine die PktID um auf Information aus der Syntaxtabelle zuzugreifen oder diese abzurufen, und zwar für jede der Protokollschichten in dem Paket, anstatt analysierte Ergebnisse von der Parsingmaschine zu empfangen.
Schichttyp bzw. Layer Type. Die eindeutige Kombination des Schichttyps und eines Hash von einem oder mehreren Feldern des Pakets liefert der Umschreibmaschine ein „generisches Format” für jede Protokollschicht. In einigen Ausführungsbeispielen spezifiziert diese eindeutige Kombination eine der durch Software definierten Abbildungen der generischen Formate der Protokolle, die in dem Speicher gespeichert sind. Das generische Format wird durch die Umschreibmaschine verwendet, um die Protokollschichten zu expandieren und um die Protokollschichten unter Verwendung von Softwarebefehlen zu modifizieren. Diese Information sagt der Umschreibmaschine ebenfalls, wo jede Protokollschicht innerhalb des Pakets beginnt.
Schichtdatenabstand bzw. Layer Data Offset. Die Umschreibmaschine verwendet Daten zum Modifizieren einer eintreffenden Kopfteilschicht. Diese Daten können irgendwo in dem Paket verteilt sein. Da Schichtgrößen variieren können, so können dies auch die Abstände bzw. Offsets zu den Daten, die die Umschreibmaschine während der Modifikationen verwenden muss, was die Hardwareflexibilität begrenzt, dahingehend welche Daten die Umschreibmaschine aufnehmen kann und von wo.
Extrahierte Daten von eintreffenden Paketkopfteilen werden in einer geschichteten Art und Weise angeordnet. Die extrahierte Datenstruktur wird so angeordnet, dass die Startabstände der Schicht-Daten-Struktur pro PktID eindeutig sind. Der Schichtdatenabstand jeder Schicht wird verwendet, um den Ort bzw. die Position der extrahierten Daten für die Modifikationen zu identifizieren. Da die Struktur der Schichten innerhalb eines Pakets und die Positionen der extrahierten Daten aus den Schichten durch die PktID des Pakets identifiziert werden, verwenden Software und Hardware die gleiche eindeutige Kennung, um die extrahierten Daten zu verwalten, was die Befehle in der Umschreibmaschine vereinfacht.
Sonstige Information bzw. Miscellaneous Information. Information, wie beispielsweise Prüfsumme und Längendaten informieren die Umschreibmaschine über spezielle Handhabungsanforderungen, wie beispielsweise die Prüfsummenneuberechnung und Kopfteillängenaktualisierung für die assoziierte Protokollschicht.
6 stellt ein beispielhaftes Verfahren 600 des Netzwerk-Switchs gemäß einigen Ausführungsbeispielen dar. Bei einem Schritt 605 prüft die Parsingmaschine ein eintreffendes Paket, um eine PktID des Pakets zu identifizieren. In einigen Ausführungsbeispielen leitet die Parsingmaschine die PktID an die Umschreibmaschine weiter anstatt analysierte Daten des Pakets an die Umschreibmaschine weiterzuleiten. Bei einem Schritt 610 referenziert die Umschreibmaschine eine Syntaxtabelle, die unterschiedliche Paketstrukturen der Pakete definiert, die durch das Netzwerk-Switch empfangen werden. Die Umschreibmaschine verwendet die PktID als einen Schlüssel zu der Syntaxtabelle, um Informationen für jede Protokollschicht des Pakets zu extrahieren, die notwendig für die Modifikation ist. Bei einem Schritt 615 modifiziert die Umschreibmaschine das Paket basierend auf Daten, die in der Syntaxtabelle gespeichert sind. Typischerweise expandiert die Umschreibmaschine jede Protokollschicht des Pakets vor dem Modifizieren des Pakets. Die Protokollschichtexpansion und -modifizierung werden an anderer Stelle diskutiert.
7 stellt ein weiteres beispielhaftes Verfahren 700 des Netzwerk-Switchs gemäß einigen Ausführungsbeispielen dar. Bei einem Schritt 705 wird eine Syntaxtabelle gespeichert und/oder in den Speicher (z. B. Nachschlag- bzw. Suchspeicher 108) programmiert. Die Syntaxtabelle definiert unterschiedliche Paketstrukturen der Pakete. Jede der Paketstrukturen wird durch eine PktID indexiert. Jede der Paketstrukturen repräsentiert eine Protokollschichtkombination und weist Schichtinformation für jede Protokollschicht der Protokollschichtkombination auf. Die Syntaxtabelle kann aktualisiert werden, um eine neue Paketstruktur hinzuzufügen, die repräsentativ für ein neues Protokoll ist. Die Syntaxtabelle kann ebenfalls aktualisiert werden, um eine Paketstruktur ansprechend auf eine Veränderung in einem Protokoll zu modifizieren. Folglich ist die Parsingabbildung imstande dynamisch über Software verändert zu werden. Bei einem Schritt 710 wird ein Paket von dem Eingangsanschluss empfangen. Bei einem Schritt 715 wird die PktID des Pakets identifiziert. In einigen Ausführungsbeispielen identifiziert ein Parser die PktID des Pakets. Bei einem Schritt 720 wird auf Information (z. B. Generalisierungsinformation) für jede Protokollschicht des Pakets zugegriffen. Die Information ist in der Syntaxtabelle angeordnet. Die Information kann dann verwendet werden, um jede Schicht der Protokollkopfteile des Pakets gemäß einem generischen Format für ein entsprechendes Protokoll zu generalisieren. Das generische Format wird durch Software in dem Speicher definiert (z. B. kann wie gewünscht durch den Nutzer über Programmierung/Neuprogrammierung angepasst werden). Mit anderen Worten kann jede Protokollschicht eines Kopfteils so expandiert werden, dass irgendein fehlendes, optionales oder anderes Feld aus einer Schicht des Kopfteils imstande ist, zurück in die Schicht als Nullen hinzugefügt zu werden. Folglich, wird nachdem sie expandiert wurde, jede Schicht des Kopfteils Werte für sämtliche möglichen Felder aufweisen, selbst wenn sie in der Schicht des Kopfteils, so wie sie empfangen wurde, fehlen. Ein Bitvektor kann dann gespeichert werden, der anzeigt welche der Felder gültige Daten sind und welche der Felder zum Zweck der Generalisierung hinzugefügt wurden.
Der generalisierte Protokollkopfteil kann durch Anwenden von zumindest einem Befehl auf der generalisierten Protokollkopfteil modifiziert werden. In einigen Ausführungsbeispielen wird der generalisierte Protokollkopfteil verwendet, um einen Bitvektor zu erzeugen, und zwar unter Verwendung der Information, um eine Position der Daten zu bestimmen, die verwendet wird, um den generalisierte Protokollkopfteil zu modifizieren. Insbesondere repräsentiert jedes Bit des Bitvektors, ob ein Byte des Headers bzw. Kopfteils gültig ist oder hinzugefügt worden ist (während der Expansion/Generalisierung), um ein fehlendes Feld auszufüllen (z. B. ein optionales Feld des Kopfteilprotokolls, das nicht verwendet worden ist). Die Umschreibmaschine generalisiert den Protokollkopfteil und modifiziert den generalisierten Protokollkopfteil. Jede Protokollschicht weist ein entsprechendes Protokoll auf. Mehr oder weniger Protokollschichten als oben angezeigt, sind möglich. Die Umschreibmaschine kann fehlende Felder aus irgendeinem der Protokollkopfteile detektieren und jeden Protokollkopfteil in ihr generisches Format expandieren. Eine generalisierte/kanonische Schicht bezeichnet eine Protokollschicht, die auf ihr generisches Format expandiert worden ist. Kurz gesagt weist jede kanonische Schicht einen Bitvektor mit Bits auf, die als 0 für ungültige Felder markiert sind, sowie Bits, die als 1 für gültige Felder markiert sind.
Die Umschreibmaschine verwendet nicht nur den Bitvektor für jede Protokollkopfteil, um die Expansion des Protokollkopfteils basierend auf einem generischen Format zur Modifikation zu ermöglichen, die Umschreibmaschine verwendet ebenfalls den Bitvektor um ein Zusammenschieben des Protokollkopfteils von dem generischen Format zu einem „gewöhnlichen” bzw. „regulären” Kopfteil zu ermöglichen. Typischerweise repräsentiert jedes Bit in dem Bitvektor ein Byte des generalisierten Protokollkopfteils. Ein Bit, das als eine 0 in dem Bitvektor markiert ist, entspricht einem ungültigen Byte, während ein Bit, das mit einer 1 in dem Bitvektor markiert ist, einem gültigen Byte entspricht. Die Umschreibmaschine verwendet den Bitvektor, um sämtliche ungültigen Bytes zu entfernen, nachdem sämtliche Befehle für den generalisierten Protokollkopfteil abgewickelt wurden, um dadurch einen neuen Protokollkopfteil zu bilden. Die Umschreibmaschine verwendet daher Bitvektoren, um die Expansion und das Zusammenschieben der Protokollkopfteile der Pakete zu ermöglichen, wodurch die flexible Modifikation der Pakete unter Verwendung eines Satzes von generischen Befehlen ermöglicht wird. Folglich sieht das Umschreiben den Vorteil vor, programmierbar zu sein, so dass ein Nutzer imstande ist, eine Modifikation des Pakets einzubauen, die seinen Anforderungen entspricht (z. B. Expansion, Zusammenschieben oder andere durch Software definierte Paketmodifikationen durch das Umschreiben).
Such- und Entscheidungsmaschinen bzw. LDEs
Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines) 106 sind imstande Suchschlüssel für Eingabetokens zu erzeugen und die Eingabetokens basierend auf den Suchergebnissen zu modifizieren, so dass entsprechende Netzwerkpakete korrekt verarbeitet und durch andere Komponenten in dem System weitergeleitet werden können. Die Bedingungen und Regeln zum Erzeugen von Schlüsseln und zum Modifizieren von Tokens sind vollständig durch Software programmierbar und basieren auf Netzwerkmerkmalen und -protokollen, die für die LDE 106 konfiguriert sind. Die LDE 106 weist zwei Hauptblöcke auf: einen Schlüsselgenerator bzw. Key-Generator und eine Ausgabegenerator bzw. Output-Generator. Wie bezeichnet, erzeugt der Key-Generator einen Satz von Suchschlüsseln für jeden Eingabetoken, und der Output-Generator erzeugt einen Ausgabetoken, der eine modifizierte Version des Eingabetokens ist, und zwar basierend auf den Suchergebnissen. Der Key-Generator und der Output-Generator weisen eine ähnliche Aufbauarchitektur auf, die einen Steuerpfad bzw. Control-Path und einen Datenpfad bzw. Data-Path aufweist. Der Control-Path prüft, ob spezifische Felder und Bits in seiner Eingabe Bedingungen der konfigurierten Protokolle erfüllen. Basierend auf den Prüfergebnissen erzeugt er demgemäß Anweisungen. Der Data-Path führt sämtliche Anweisungen aus, die durch den Control-Path erzeugt werden, um den Satz der Suchschlüssel in dem Key-Generator zu erzeugen, oder um den Ausgabetoken in dem Output-Generator zu erzeugen. Die Bedingungen und Regeln für die Schlüssel- und Ausgabeerzeugungen sind in den Steuerpfaden bzw. Control-Paths des Key-Generators und des Output-Generators vollständig programmierbar. Mit anderen Worten ist die LDE 106 imstande die programmierbare Bildung eines Eingabeschlüssels bzw. Input-Key, der zur Abstimmung des Suchspeichers verwendet wird, und einer programmierbaren Bildung des Ausgabeschlüssels bzw. Output-Key für Ergebnisse, die aus dem Suchspeicher zurückkommen, zu ermöglichen, und zwar gemeinsam mit dem Zusammenführen des Eingabetokens mit dem Suchtabellenergebnis, um den Ausgabetoken zu bilden, der zu der nächsten adressierbaren LDE weitergeleitet wird.
Die LDE 106 weist ebenfalls einen Eingabe-FIFO zur temporären Speicherung der Eingabetokens auf, eine Suchergebnissammelvorrichtung/-zusammenführungsvorrichtung bzw. Lookup-Result-Collector/Merger zum Sammeln der Suchergebnisse für die Suchschlüssel, eine Loopback- bzw. Schleifenschaltungsprüfvorrichtung zum Senden eines Ausgabetokens zurück zu der LDE 106 in dem Fall, wo mehrere Seriensuchen für diesen Token bei der gleichen LDE 106 erforderlich sind, und einen Loopback-FIFO zum Speichern der Loopback-Tokens. Der Loopback- bzw. Schleifenschaltungspfad weist eine höhere Priorität als ein Eingabepfad auf, um eine Freiheit vor einer Systemblockade zu garantieren.
In einigen Ausführungsbeispielen können die hierin beschriebenen LDEs die gleichen LDEs sein, wie sie in der US-Patentanmeldung Nr. 14/144,270, betitelt „Apparatus and Method of Generating Lookups and Making Decisions for Packet Modifying and Forwarding in a Software-Defined Network Engine”, und eingereicht am 30. Dezember 2013, beschrieben sind, die hierin durch Bezugnahme aufgenommen ist. Zusätzlich sind der Schlüsselgenerator bzw. Key-Generator und der Ausgabegenerator bzw. Output-Generator ähnlich konfiguriert wie eine SDN-Verarbeitungsmaschine, die in der US-Patentanmeldung Nr. 14/144,260, betitelt „Method and Apparatus for Parallel and Conditional Data Manipulation in a Software-Defined Network Processing Engine” und eingereicht am 30. Dezember 2013 diskutiert ist, die hierin durch Bezugnahme enthalten ist.
8 stellt ein Blockdiagramm einer LDE 106 zum Erzeugen von Suchschlüsseln und zum Modifizieren von Tokens gemäß einem Ausführungsbeispiel dar. Wie vorangehend beschrieben, wird die SDN-Maschine 106 als eine Such- und Entscheidungsmaschine bzw. LDE bezeichnet. Die LDE 106 erzeugt Suchschlüssel und modifiziert Eingabetokens basierend auf Suchergebnissen und Inhalt der Eingabetokens. Die Bedingungen und Regeln zum Erzeugen von Suchschlüsseln und zum Modifizieren der Eingabetokens sind durch die Nutzer programmierbar.
Die LDE 106 kann die Eingabetokens von einem Syntaxanalysator bzw. Parser empfangen. Der Parser analysiert Kopfteile jedes Netzwerkpakets und gibt einen Eingabetoken für jedes Netzwerkpaket aus. Ein Eingabetoken weist ein vordefiniertes Format auf, so dass die LDE 106 imstande sein wird, den Eingabetoken zu verarbeiten. Die LDE 106 kann ebenfalls die Eingabetokens von einer vorangehenden LDE empfangen, wenn mehrere LDEs in einer Kette gekoppelt sind, um in Reihe mehrere Such- und Tokenmodifizierungsschritte auszuführen.
Die Eingabetoken, die bei der LDE 106 von einem vorgelagerten Parser oder einer vorgelagerten LDE empfangen werden, werden zunächst innerhalb eines Eingabe-FIFO 805 gepuffert. Die Eingabetoken warten innerhalb des Eingabe-FIFO 805 bis die LDE bereit ist, sie zu verarbeiten. Wenn der Eingabe-FIFO 805 voll ist, unterrichtet die LDE 106 die Quelle der Eingabetoken (d. h. einen vorgelagerten Parser oder eine vorgelagerte LDE), um das Senden neuer Token anzuhalten.
Die Positionen der Felder in jedem Eingabetoken werden durch Nachschauen in einer Tabelle, und zwar dem Vorlagensuchblock bzw. Template-Lookup-Block 810 identifiziert. Die Eingabetoken werden als nächstes an einen Key-Generator 815 gesendet. Der Key-Generator 815 ist konfiguriert, um spezifische Daten in den Eingabetoken zum Aufbauen von Suchschlüsseln aufzunehmen. Die Konfiguration des Key-Generators 815 ist benutzerdefiniert und hängt von Netzwerkmerkmalen und -protokollen ab, von denen die Nutzer wollen, dass sie die LDE 106 ausführt.
Ein Suchschlüssel (oder Satz von Suchschlüsseln) für jeden Eingabetoken wird von dem Key-Generator 815 ausgegeben und wird an eine entfernte Suchmaschine bzw. Search-Engine (nicht dargestellt) gesendet. Die entfernte Suchmaschine kann mehrere konfigurierbare Suchvorgänge, wie beispielsweise TCAM-, Direktzugriffs- bzw. Direct-Access-, Hash-basierte und Longest-Prefix-Matching-Suchen ausführen. Für jeden Suchschlüssel, der an die entfernte Suchmaschine gesendet wird, wird ein Suchergebnis zu der LDE 106 bei einer Suchergebnissammelvorrichtung/-zusammenführungsvorrichtung bzw. Lookup-Result-Collector/Merger 820 zurück gesendet.
Während des Erzeugens eines Suchschlüssels (oder eines Satzes von Suchschlüsseln) für jeden Eingabetoken, leitet der Key-Generator 815 ebenfalls den Eingabetoken an die Suchergebnissammelvorrichtung/-zusammenführungsvorrichtung bzw. Lookup-Result-Collector/Merger 820 weiter. Der Eingabetoken wartet innerhalb der Suchergebnissammelvorrichtung/-zusammenführungsvorrichtung bzw. Lookup-Result-Collector/Merger 820 bis das Suchergebnis durch die entfernte Suchmaschine zurück gesendet wird. Sobald das Suchergebnis verfügbar ist, wird der Eingabetoken gemeinsam mit dem Suchergebnis an einen Ausgabegenerator bzw. Output-Generator 825 gesendet.
Basierend auf dem Suchergebnis und dem Inhalt des Eingabetokens modifiziert der Output-Generator 825 eines oder mehrere Felder des Eingabetokens, bevor der modifizierte Token zur Ausgabe gesendet wird. Ähnlich dem Key-Generator 815 ist die Konfiguration des Output-Generators 825 bezüglich beispielsweise Bedingungen und Regeln für die Tokenmodifikation benutzerdefiniert und hängt von Netzwerkmerkmalen und -protokollen ab, von denen der Benutzer will, dass sie die LDE 106 ausführt.
Nachdem der Token modifiziert worden ist, wird der modifizierte Token an eine Loopback- bzw. Schleifenschaltungsprüfvorrichtung 830 gesendet. Die Schleifenschaltungsprüfvorrichtung 830 bestimmt, ob der modifizierte Token entweder zurück zu der aktuellen LDE gesendet werden soll, um eine weitere Suche vorzunehmen oder zu einer anderen Maschine in dem assoziierten SDN-System gesendet werden soll. Diese Loopback- bzw. Schleifenschaltungsprüfung ist eine Aufbauoption, die es vorteilhafter Weise ermöglicht, dass eine einzelne LDE mehrere Suchen in Reihe für den gleichen Token ausführt, anstatt mehrere Maschinen zu verwenden, die das Gleiche tun. Diese Aufbauoption ist nützlich in einem System mit einer begrenzten Anzahl von LDEs aufgrund von Beschränkungen, wie beispielsweise einem Chipbereichsbudget. Tokens, due zurück zu der aktuellen LDE gesendet werden, werden innerhalb eines Loopback-FIFO 835 über einen Loopback- bzw. Schleifenschaltungspfad 840 gepuffert. Der Schleifenschaltungspfad 840 weist immer eine höhere Priorität als der Eingabepfad auf (z. B. von dem Eingabe-FIFO 805), um eine Systemblockade zu vermeiden. Obwohl 8 unter Verwendung von FIFO-Puffern beschrieben wurde, sind andere Pufferarten möglich.
Lookup- bzw. Suchspeicher
Wenn Datenanfragen/-suchen an die Suchspeicher 108 durch die LDEs 106 oder andere Komponenten des Systems 100 gestellt werden, unterstützt das System 100 mehrere parallele Suchen, die einen Pool der Suchspeicher 108 teilen. Die Anzahl der Speicher 108, die für jede Suche reserviert ist, ist programmierbar/neu konfigurierbar, und zwar basierend auf der Speicherkapazität, die durch diese Suche erforderlich ist. Mit anderen Worten können die Suchspeicher 108 dynamisch bezüglich Kapazität und logischer Funktionalität neu konfiguriert werden. Zusätzlich kann jede Suche so konfiguriert werden, dass sie als eine Hash-basierte Suche oder eine Direktzugriffssuche ausführt. Die geteilten Speicher werden in homogene Kacheln gruppiert. Jede Suche wird einem Satz von Kacheln zugewiesen. Die Kacheln in dem Satz werden nicht mit anderen Sätzen geteilt, so dass sämtliche Suchen imstande sind, parallel ohne Kollision ausgeführt zu werden. Das System 100 weist ebenfalls neu konfigurierbare Verbindungsnetzwerke auf, die basierend darauf programmiert sind, wie die Kacheln für jede Suche zugewiesen werden.
9 stellt ein Suchspeichersystem 900 gemäß einem Ausführungsbeispiel dar. Das System 900 ist für N simultane oder parallele Suchpfade konfiguriert, ohne Kollision und unter Verwendung einer Vielzahl von geteilten Speichern. Das System 900 führt n-Bit-Daten für jeden k-Bit-Eingabeschlüssel pro Suchpfad zurück. Das System 900 weist Blöcke 905–930 auf. Der Pool aus geteilten Suchspeichern 108 bei dem Block 915 wird in T geteilte bzw. gemeinsam genutzte, homogene Kacheln gruppiert. Jede Kachel enthält M Speicher. Jedem Suchpfad wird eine Anzahl von Kacheln aus diesen T Kacheln zugewiesen. Die Kachelallokation für jeden Suchpfad ist durch Software konfigurierbar, so dass beispielsweise die Skalierung und Breite angepasst werden kann.
Bei Block 905 wird ein Eingabeschlüssel jedes Suchpfads in eine Vielzahl von Suchindizes umgewandelt. Information zum Auslesen von Suchdaten, wie beispielsweise Kachel-IDs entsprechender Kacheln, auf die der Suchpfad zugreifen wird, und Adressen von Speichern in diesen Kacheln aus denen Daten ausgelesen werden, werden Teil der Suchindizes. Die Kachel-IDs und die Speicheradressen von jedem Eingabeschlüssel werden an ihre entsprechenden Kacheln durch den Block 910 gesendet, der ein zentrales Neukonfigurationsverbindungsgewebe ist. Das zentrale Neukonfigurationsverbindungsgewebe 910 weist eine Vielzahl von konfigurierbaren zentralen Netzwerken auf. Diese zentralen Netzwerke werden basierend auf Positionen der Kacheln konfiguriert, die für die entsprechenden Suchpfade reserviert sind.
In jeder Kachel werden bei Block 920 vorprogrammierte Schlüssel und Daten aus den Speichern bei den Adressen ausgelesen, die zuvor aus den entsprechenden Eingabeschlüsseln (z. B. Umwandlung bei Block 910) umgewandelt wurden. Diese vorprogrammierten Schlüssel, die in den Speichern gelegen sind, werden mit dem Eingabeschlüssel für den entsprechenden Suchpfad verglichen. Wenn ist irgendeine Übereinstimmung zwischen diesen vorprogrammierten Schlüsseln und dem Eingabeschlüssel gibt, dann sendet die Kachel Trefferdaten und eine Trefferadresse. Die Trefferinformation jeder Kachel wird durch den entsprechenden Suchpfad gesammelt, den diese Kachel durch den Block 925 besitzt, welches ein Ausgabeneukonfigurationsverbindungsnetzwerk bzw. -gewebe ist. Jeder Suchpfad führt eine weitere Auswahlrunde zwischen der Trefferinformation sämtlicher Kacheln, die er besitzt, bei dem Block 930 aus, bevor ein finales Suchergebnis für den Suchpfad zurück gesendet wird.
10 stellt ein Verfahren zur Konfiguration und Programmierung eines Parallelsuchspeichersystems 1000 gemäß einem Ausführungsbeispiel dar. Das Parallelsuchspeichersystem 900 weist N parallel Suchpfade mit T gemeinsam genutzten Kacheln auf. Jede Kachel weist M Speicher auf. Jeder Speicher weist eine Speicheradresse mit einer Breite von m-Bit auf. Jeder Speichereintrag enthält P Paare von {Schlüssel, Daten}, die durch Software programmierbar sind. Jede Such in dem System 900 ist eine D-LEFT-Suche mit M Wegen und P Gefäßen pro Weg. Das Verfahren 1000 beginnt bei einem Schritt 1005, wo ein Nutzer Kacheln für jeden Suchpfad zuweist. Die Anzahl der Kacheln, die jedem Suchpfad zugewiesen wird, muss eine Potenz von 2 sein. Diese Kachelpartition muss ebenfalls garantieren, dass es keine Kachelüberlappung zwischen den Suchpfaden gibt. Bei einem Schritt 1010 wird die Hash-Größe jedes Suchpfads berechnet. Die Hash-Größe für jeden Suchpfad basiert auf der Anzahl der Kacheln, die für den Suchpfad zugewiesen wird. Wenn einem Suchpfad q Kacheln zugewiesen sind, dann entspricht seine Hash-Größe log₂(q) + m.
Nachdem die Hash-Größe jeder Suche bekannt ist, werden bei einem Schritt 1015 die Register cfg_hash_sel und cfg_tile_offsets in den Indexkonvertern demgemäß konfiguriert. Das cfg_hash_sel-Register wählt eine Funktion für den Suchpfad aus. Das cfg_tile_offset-Register passt die Tile- bzw. Kachel-ID eines Suchindex für den Suchpfad an. Unterdessen werden bei einem Schritt 1020 zentrale und Ausgabeverbindungsnetzwerke konfiguriert, um die Suchpfade mit ihren reservierten Kacheln zu verbinden. Sämtliche Konfigurationsbits für die Indexkonverter und Netzwerke können automatisch durch ein Skript gemäß den hierin beschriebenen Prinzipien erzeugt werden. Bei einem Schritt 1025 werden die Speicher, die jedem Suchpfad zugewiesen sind, programmiert. Die Programmierungstechnik basiert auf einer D-LEFT-Suchtechnik mit M Wegen pro Suche und P Gefäßen pro Weg. Nachdem sämtliche zugewiesenen Speicher programmiert sind, ist bei einem Schritt 1030 das Parallelsuchsystem 100 bereit, um Eingabeschlüssel zu empfangen und N Suchen parallel auszuführen.
Die Ausführungsbeispiele beziehen sich auf mehrere parallele Suchen unter Verwendung eines Pools von gemeinsam genutzten Suchspeichern 108 durch geeignete Konfiguration der Verbindungsnetzwerke. Die Anzahl der gemeinsam genutzten bzw. geteilten Speicher 108, die für jede Suche reserviert sind, ist basierend auf der Speicherkapazität neu konfigurierbar, die durch diese Suche erforderlich ist. Die gemeinsam genutzten Speicher 108 werden in homogene Kacheln gruppiert. Jede Suche wird einem Satz von Kacheln zugewiesen, und war basierend auf der Speicherkapazität, die durch diese Suche erforderlich ist. Die Kacheln, die für jede Suche zugewiesen werden, überlappen sich nicht mit anderen Suchen, so dass sämtliche Suchen parallel ohne Kollision ausgeführt werden können. Jede Suche ist neu konfigurierbar, so dass sie entweder Hash-basiert oder direktzugriffsbasiert ist. Die Verbindungsnetzwerke werden basierend darauf programmiert, wie die Kacheln für jede Suche zugewiesen werden. In einigen Ausführungsbeispielen können die Suchspeicher und/oder das Suchspeichersystem, das hierin beschrieben ist, die gleichen wie die Suchspeicher und/oder das Suchspeichersystem sein, die in der US-Patentanmeldung Nr. 14/142,511, betitelt „Method and system for reconfigurable parallel lookups using multiple shared memories”, eingereicht am 27. Dezember 2013, die hierin durch Bezugnahme aufgenommen ist, beschrieben sind.
Zählvorrichtungen bzw. Zähler
Der Zählerblock 110 kann eine Vielzahl von Zählern aufweisen, die so programmiert werden können, dass sie an eines oder mehrere Ereignisse innerhalb der Paketverarbeitung innerhalb des Systems 100 gebunden sind, um Daten zu diesen ausgewählten Ereignissen zu verfolgen. In der Tat kann der Zählerblock 110 so konfiguriert werden, dass er simultan ein Paket zählen, überwachen und/oder prüfen kann. Mit anderen Worten kann jeder Zähler (oder Subeinheit des Zählerblocks 110) konfiguriert sein, um zu zählen, prüfen und/oder zu überwachen. Beispielsweise kann eine LDE 106 imstande sein anzufordern dass gleichlaufende Aktivität durch den Zählerblock 110 überwacht wird, so dass ein Paket gleichzeitig oder simultan durch den Block sein, für einen Durchschnittsfall vorgehalten zu sein und ein Überlaufen über einen Überlauf-FIFO und eine Unterbrechung einer Prozessüberwachung durch die Zähler bearbeiten. Diese Zählerblockarchitektur adressiert ein generelles Optimierungsproblem, das bezeichnet werden kann als: gegeben N Zähler, für ein bestimmtes CPU-Leseintervall T, wie kann die Anzahl der Speicherbits minimiert werden, die für das Speichern erforderlich ist und diese N Zählvorrichtungen bedienen. Entsprechend kann dieses allgemeine Optimierungsproblem auch als bezeichnet werden als: gegeben N Zähler und eine bestimmte Anzahl von Speicherbits, wie kann das CPU-Leseintervall T optimiert und erhöht werden. Diese Zählerblockarchitektur verlängert das Zähler-CPU-Leseintervall linear mit der Tiefe des Überlauf-FIFO.
11 stellt ein Blockdiagramm eines Zählerblocks gemäß einem Ausführungsbeispiel dar. Der Zählerblock 1100 ist in einer Hochgeschwindigkeitsnetzwerkvorrichtung, wie beispielsweise einem Netzwerk-Switch implementiert. Die Architektur 1100 weist N Zeilenübertragszähler 1105 und einen Überlauf-FIFO 1110 auf. Jeder der N Zähler weist eine Breite von w-Bits auf und ist mit einer Zählerkennung assoziiert. Typischerweise ist die Zählerkennung eine eindeutige Identifikation dieses Zählers. In einigen Ausführungsbeispielen sind die Zähler in einem On-Chip-SRAM-Speicher gespeichert, der zwei Bänke des Speichers verwendet. Beispielhafte Zähler und Speicherbanken werden in der U. S. Patentanmeldung Nr. 14/289,533, betitelt „Method and Apparatus for Flexible and Efficient Analytics in a Network Switch”, eingereicht am 28. Mai 2014, die hierin in ihrer Gesamtheit durch Bezugnahme aufgenommen ist, diskutiert. Der Überlauf-FIFO kann in einem SRAM-Speicher gespeichert sein. Alternativ ist der Überlauf-FIFO eine Hardware mit fester Funktion. Der Überlauf-FIFO wird typischerweise geteilt bzw. gemeinsam genutzt und durch sämtliche N Zähler verwendet.
Der Überlauf-FIFO speichert die assoziierten Zählerkennungen sämtlicher Zähler, die überlaufen. Typischerweise sobald irgendeiner der N Zähler 1105 zu überlaufen beginnt, wird die assoziierte Zählerkennung des überlaufenden Zählers in dem Überlauf-FIFO 1110 gespeichert. Eine Unterbrechung wird an eine CPU gesendet, um den Überlauf-FIFO 1110 und den überlaufenden Zähler auszulesen. Nachdem der überlaufende Zähler ausgelesen wurde, wird er überlaufende Zähler geleert und zurückgesetzt.
In einem Timing- bzw. Zeitsteuerungsintervall T beträgt die Anzahl des Zählerüberlaufs M = Obergrenze(PPS·T/2^w), wobei PPS die Pakete pro Sekunde sind, und w die Bitbreite jedes Zählers ist. Die Gesamtzahl der Pakete während des Intervalls T beträgt PPS·T. Angenommen, dass PPS bis zu 654,8 MPPS beträgt, T = 1, w = 17 und N = 16 k. Basierend auf diesen Annahmen gibt es bis zu 4.995 Überlaufereignisse pro Sekunde.
Der Überlauf-FIFO ist typischerweise M-Bits tief und log₂N-Bits breit, um sämtliche Zählerüberlaufe zu erfassen. Folglich erfordert der Zählerblock 1100w·N + M·log₂N Gesamtspeicherbits, wobei M = Obergrenze(PPS·T/2^w).
12 stellt ein Verfahren 1200 eines Zählerblocks dar, wie beispielsweise des Zählerblocks 100 der 11 gemäß einem Ausführungsbeispiel. Bei einem Schritt 1205 wird eine Zählung in zumindest einem Zähler inkrementiert. Wie oben diskutiert, ist jeder Zähler mit einer eindeutigen Identifikation assoziiert. Typischerweise sind sämtliche Zähler Zeilenübertragszähler und wiesen die gleiche Breite af. Beispielsweise wenn w = 17, dann ist der größte Wert, den jeder Zähler repräsentiert, 131.071. Als ein weiteres Beispiel, wenn w = 18, dann ist der größte Wert, den jeder Zähler repräsentiert, 262.143. Als noch ein weiteres Beispiel, wenn w = 19 dann ist der größte Wert, den jeder Zähler repräsentiert, 524.287. Ein Überlaufen tritt auf, wenn ein arithmetischer Vorgang versucht, einen numerischen Wert zu erzeugen, der zu groß ist, um innerhalb eines verfügbaren Zählers repräsentiert zu werden.
Bei einem Schritt 1210 wird beim Überlaufen von einem der zumindest einen Zähler die Zählerkennung des überlaufenden Zählers in einer Warteschlange gespeichert. In einigen Ausführungsbeispielen ist die Warteschlange ein FIFO-Puffer. Die Warteschlange wird typischerweise geteilt und durch sämtliche Zähler in dem Zählerblock 1100 verwendet. In einigen Ausführungsbeispielen sendet das Speichern der Zählerkennung in der Warteschlange eine Unterbrechung an die CPU, um Werte aus der Warteschlange und dem überlaufenden Zähler auszulesen. Es ist möglich, dann den tatsächlichen Wert des überlaufenden Zählers aus den ausgelesenen Werten zu berechnen. Nachdem der überlaufende Zähler durch die CPU ausgelesen wird, wird der überlaufende Zähler typischerweise geleert oder zurückgesetzt.
Beispielsweise ist ein Zähler mit 5 als seiner Zählerkennung der erste Zähler der während arithmetischen bzw. Rechenvorgängen überläuft. Die Zählerkennung (d. h. 5) wird dann in der Warteschlange gespeichert, mutmaßlich am Kopf der Warteschlange, da der Zähler #5 der erste Zähler ist, der überläuft. In der Zwischenzeit kann die Zählung in dem Zähler #5 weiterhin inkrementiert werden. In der Zwischenzeit können ebenfalls andere Zähler überlaufen, wobei die Zählerkennung dieser Zähler in der Warteschlange gespeichert wird.
Eine Unterbrechung wird an die CPU gesendet, um die Werte am Kopf der Warteschlange (d. h. 5) auszulesen. Die CPU liest dann den aktuellen Wert aus, der in dem Zähler gespeichert wird, der mit der Zählerkennung (d. h. dem Zähler #5) assoziiert ist. Da die Zählerbreite bekannt ist, kann der tatsächliche Wert des Zählers berechnet werden. Genauer gesagt ist der tatsächliche Wert des Zählers 2^w plus dem aktuellen Wert, der in dem Zähler gespeichert ist. Der tatsächliche Wert des Zählers #5 ist 131.074 (= 2¹⁷ + 2). Solange die Warteschlange nicht leer ist, liest die CPU kontinuierlich aus und leert die Werte aus der Warteschlange und den Zählern.
Die finale Gesamtzählung eines bestimmten Zählers ist: die Anzahl der Male, die die Zählerkennung in der Warteschlange erscheint * 2^w plus dem Zählerrestwert.
Obwohl die Zähler als Pakete zählend beschrieben worden sind, sollte bemerkt sein, dass die Zähler verwendet werden können, um irgendetwas zu zählen, zum Beispiel Bytes. Im Allgemeinen wird eine erwartete Gesamtzahl während T als EPS·T berechnet, wobei EPS Ereignisse pro Sekunde sind. Eine Obergrenze dieser maximalen Gesamtzahl während des Zeitintervalls T kann eingerichtet oder berechnet werden, da das Netzwerk-Switch typischerweise mit einer bestimmten Bandbreite ausgelegt ist, aus der die Ereignisrate berechnet werden kann. In einigen Ausführungsbeispielen können die hierin beschriebenen Zähler die gleichen wie die Zähler sein, die in der US-Patentanmeldung Nr. 14/302,343, betitelt „Counter with overflow FIFO and a method thereof” und eingereicht am 11. Juni 2014, die hierin durch Bezugnahme enthalten ist, beschrieben sind.
Das SDN-System, die -Vorrichtung und das -Verfahren, die hierin beschrieben sind, weisen zahlreiche Vorteile auf. Insbesondere, wie vorangehend beschrieben, sieht dieses den Vorteil des Nutzens einer generischen Paketweiterleitungspipeline vor, die vollständig programmierbar ist, so dass die Weiterleitungsintelligenz verschiedener Netzwerkprotokollpakete auf die LDEs durch Software weitergeben wird. Zusätzlich sieht das System den Vorteil der Ermöglichung einer vollständig durch Software definierten Kontrolle über die Ressourcenverwaltung für Weiterleitungstabellen innerhalb des Systems vor, wodurch das System in die Lage versetzt wird, so konfiguriert zu werden, dass es mit den Skalierungsprofilen übereinstimmt, wie sie durch verschiedene Orte innerhalb des Netzwerks erforderlich sind. Ferner sieht das System die Fähigkeit vor, programmatisch die Leistung des Systems individuell anzupassen, was eine vereinheitliche Hardware und Software erzeugt, die in verschiedenen Einsatzbereichen verwendet werden kann. Ferner ermöglicht es den auf Optimierung zugeschnittenen Einsatz für anwendungsspezifische Bedürfnisse. Mit anderen Worten sieht die durch Systemsoftware definierte Flexibilität die Fähigkeit vor, den gleichen Switch-Mikrochip individuell so anzupassen, dass er die gleiche hohe Bandbreite und hohe Anschlussdichte vorsieht und zwar obwohl er an mehreren unterschiedlichen Orte innerhalb eines Netzwerks positioniert ist. Folglich weist das Informationsverarbeitungssystem, die -vorrichtung und das -verfahren viele Vorteile vor.
Die vorliegende Erfindung wurde im Sinne von spezifischen Ausführungsbeispielen beschrieben, die Details beinhalten, um das Verständnis der Prinzipien des Aufbaus und des Betriebs der Erfindung zu erleichtern bzw. zu ermöglichen. Eine derartige Bezugnahme hierin auf spezifische Ausführungsbeispiele und Details von diesen soll nicht den Umfang der beigefügten Ansprüche begrenzen. Es wird Fachleuten des Gebiets offensichtlich sein, dass Modifikationen an den Ausführungsbeispielen vorgenommen werden können, die zu Darstellung gewählt wird, und zwar ohne den Umfang und Rahmen der Erfindung zu verlassen.

Claims

Switch-Mikrochip für ein durch Software definiertes Netzwerk, wobei der Mikrochip Folgendes aufweist: einen programmierbaren Syntaxanalysator bzw. Parser, der erwünschte Paketkontextdaten aus Headern bzw. Kopfteilen einer Vielzahl von eingehenden Paketen analysiert bzw. parst, wobei die Kopfteile durch den Parser basierend auf einem durch Software definierten Syntax- bzw. Analysediagramm des Parsers erkannt werden; einen oder mehrere Suchspeicher mit einer Vielzahl von Tabellen, wobei die Suchspeicher als eine logische Überlagerung bzw. Overlay konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch einen Nutzer durch Software definiert werden; eine Hauptleitung bzw. Pipeline einer Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs, die die Paketkontextdaten empfangen und modifizieren, und zwar basierend auf Daten, die in den Suchspeichern gespeichert sind und einer durch Software definierten Logik, die in die Maschinen durch den Nutzer programmiert ist; einen programmierbaren Umschreibblock, der basierend auf den Paketkontextdaten, die von einer der Maschinen empfangen werden, die Paketkopfteile neu aufbaut und vorbereitet, so wie sie innerhalb des Switchs für die Ausgabe verarbeitet werden; und einen programmierbaren Zählerblock, der für Zählvorgänge der Such- und Entscheidungsmaschinen verwendet wird, wobei die Vorgänge, die durch den Zählerblock gezählt werden, durch Software durch den Nutzer definiert werden.
Mikrochip gemäß Anspruch 1, wobei beginnend von dem gleichen Anfangsknoten des Analysediagramms, jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile repräsentiert, der imstande ist, durch den Parser erkannt zu werden.
Mikrochip gemäß Anspruch 2, wobei sich Teile der Pfade überlappen.
Mikrochip gemäß Anspruch 1, wobei der Umschreibblock jede Schicht von jedem Kopfteil expandiert, der durch den Parser analysiert wird, um einen expandierten Schichttyp einer generischen Größe basierend auf einem Protokoll, das mit der Schicht assoziiert ist, zu bilden.
Mikrochip gemäß Anspruch 4, wobei der Umschreibblock einen Bitvektor erzeugt, der anzeigt, welche Teile des expandierten Schichttyps valide bzw. gültige Daten enthalten und welche Teile des expandierten Schichttyps Daten enthalten, die während des Expandierens durch den Umschreibblock hinzugefügt wurden.
Mikrochip gemäß Anspruch 1, wobei die Tabellen der Suchspeicher jeweils imstande sind, in unabhängiger Weise in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi eingestellt zu werden.
Mikrochip gemäß Anspruch 6, wobei die Tabellen der Suchspeicher imstande sind, dynamisch durch den Nutzer neu formatiert und neu konfiguriert zu werden, so dass eine Anzahl von Tiles bzw. Kacheln der Suchspeicher, die für Suchpfade partitioniert und zugewiesen werden, die mit den Suchspeichern gekoppelt sind, auf Speicherkapazität basiert, die für jeden der Suchpfade erforderlich ist.
Mikrochip gemäß Anspruch 1, wobei jede der Such- und Entscheidungsmaschinen Folgendes aufweist: einen Schlüsselgenerator bzw. Key-Generator, der konfiguriert ist, um einen Satz von Suchschlüsseln für jedes Eingabezeichen bzw. jeden Eingabetoken zu erzeugen; und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um ein Ausgabezeichen bzw. einen Ausgabetoken zu erzeugen, und zwar durch Modifizieren des Eingabetokens basierend auf Inhalt der Suchergebnisse, die mit dem Satz der Suchschlüssel assoziiert sind.
Mikrochip gemäß Anspruch 8, wobei jede der Such- und Entscheidungsmaschinen Folgendes aufweist: einen Eingabepuffer zum temporären Speichern von Eingabetoken bevor die Eingabetoken durch die Such- und Entscheidungsmaschine verarbeitet werden; eine Profiltabelle zum Identifizieren von Positionen der Felder in jedem der Eingabetoken; eine Suchergebniszusammenführungsvorrichtung zum Verbinden des Eingabetokens mit dem Suchergebnis und zum Senden des verbundenen Eingabetokens mit dem Suchergebnis an den Ausgabegenerator; eine Loopback- bzw. Schleifenschaltungsüberprüfungsvorrichtung zum Bestimmen, ob der Ausgabetoken zurück zu der aktuellen Such- und Entscheidungsmaschine oder zu einer anderen Such- und Entscheidungsmaschine gesendet werden soll; und einen Loopback- bzw. Schleifenschaltungspuffer zum Speichern von Loopback-Wertmerkmalen bzw. -Token.
Mikrochip gemäß Anspruch 9, wobei Steuerpfade von sowohl dem Schlüsselgenerator als auch dem Ausgabegenerator so programmierbar sind, dass Nutzer imstande sind, die Such- und Entscheidungsmaschine so zu konfigurieren, dass sie unterschiedliche Netzwerkmerkmale und -protokolle unterstützt.
Mikrochip gemäß Anspruch 1, wobei der Zählerblock Folgendes aufweist: N Wrap-around- bzw. Umschaltzähler, wobei jeder der N Umschaltzähler mit einer Zählerkennung assoziiert ist; und einen Überlauf-FIFO, der von den N Umschaltzählern verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen.
Verfahren zum Betätigen eines Switch-Mikrochips für ein durch Software definiertes Netzwerk, wobei das Verfahren Folgendes aufweist: Analysieren bzw. Parsen erwünschter Paketkontextdaten aus Kopfteilen einer Vielzahl von eingehenden Paketen mit einem programmierbaren Syntaxanalysator bzw. Parser, wobei die Kopfteile durch den Parser basierend auf einem durch Software definierten Analysediagramm des Parsers erkannt werden; Empfangen und Modifizieren der Paketkontextdaten mit einer Leitung bzw. Pipeline einer Vielzahl von programmierbaren Such- und Entscheidungsmaschinen basierend auf Daten, die in Suchspeichern gespeichert sind, die eine Vielzahl von Tabellen und eine durch Software definierte Logik aufweisen, die in die Maschinen durch einen Nutzer programmiert werden; Übertragen von einer oder mehreren Datensuchanfragen an und Empfangen von Verarbeitungsdaten basierend auf den Anfragen von den Suchspeichern durch die Such- und Entscheidungsmaschinen, wobei die Suchspeicher als logische Überlagerung konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch den Nutzer durch Software definiert werden; Ausführen von Zählvorgängen basierend auf Aktionen der Such- und Entscheidungsmaschinen mit einem programmierbaren Zählblock, wobei die Zählvorgänge, die durch den Zählblock gezählt werden, durch den Nutzer durch Software definiert werden; und Neuaufbauen der Paketkopfteile, wie sie innerhalb des Switchs verarbeitet werden, mit einem programmierbaren Umschreibblock zur Ausgabe, wobei die Umschreibung auf den Paketkontextdaten basiert, die von einer der Such- und Entscheidungsmaschinen empfangen werden.
Verfahren gemäß Anspruch 12, wobei beginnend von dem gleichen Anfangsknoten des Analysediagramms, jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile repräsentiert, der durch den Parser erkannt werden kann.
Verfahren gemäß Anspruch 13, wobei sich Teile der Pfade überlappen.
Verfahren gemäß Anspruch 12, wobei der Umschreibblock jede Schicht von jedem Kopfteil expandiert, der durch den Parser analysiert wird, um einen expandierten Schichttyp einer generischen Größe basierend auf einem Protokoll, das mit der Schicht assoziiert ist, zu bilden.
Verfahren gemäß Anspruch 15, wobei der Umschreibblock einen Bitvektor erzeugt, der anzeigt, welche Teile des expandierten Schichttyps valide bzw. gültige Daten enthalten und welche Teile des expandierten Schichttyps Daten enthalten, die während des Expandierens durch den Umschreibblock hinzugefügt wurden.
Verfahren gemäß Anspruch 12, wobei die Tabellen der Suchspeicher jeweils imstande sind, in unabhängiger Weise in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi eingestellt zu werden.
Verfahren gemäß Anspruch 17, wobei die Tabellen der Suchspeicher imstande sind, dynamisch durch den Nutzer neu formatiert und neu konfiguriert zu werden, so dass eine Anzahl von Tiles bzw. Kacheln der Suchspeicher, die für Suchpfade partitioniert und zugewiesen werden, die mit den Suchspeichern gekoppelt sind, auf Speicherkapazität basiert, die für jeden der Suchpfade erforderlich ist.
Verfahren gemäß Anspruch 12, wobei jede der Such- und Entscheidungsmaschinen Folgendes aufweist: einen Schlüsselgenerator bzw. Key-Generator, der konfiguriert ist, um einen Satz von Suchschlüsseln für jedes Eingabezeichen bzw. jeden eingegeben Token zu erzeugen; und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um ein Ausgabezeichen bzw. einen ausgegebenen Token zu erzeugen, und zwar durch Modifizieren des Eingabetokens basierend auf Inhalt der Suchergebnisse, die mit dem Satz der Suchschlüssel assoziiert sind.
Verfahren gemäß Anspruch 19, wobei jede der Such- und Entscheidungsmaschinen Folgendes aufweist: einen Eingabepuffer zum temporären Speichern von Eingabetoken bevor die Eingabetoken durch die Such- und Entscheidungsmaschine verarbeitet werden; eine Profiltabelle zum Identifizieren von Positionen der Felder in jedem der Eingabetoken; eine Suchergebniszusammenführungsvorrichtung zum Verbinden des Eingabetokens mit dem Suchergebnis und zum Senden des verbundenen Eingabetokens mit dem Suchergebnis an den Ausgabegenerator; eine Loopback- bzw. Schleifenschaltungsüberprüfungsvorrichtung zum Bestimmen, ob der Ausgabetoken zurück zu der aktuellen Such- und Entscheidungsmaschine oder zu einer anderen Such- und Entscheidungsmaschine gesendet werden soll; und einen Loopback- bzw. Schleifenschaltungspuffer zum Speichern von Loopback-Wertmerkmalen bzw. -Zeichen.
Verfahren gemäß Anspruch 20, wobei Steuerpfade von sowohl dem Schlüsselgenerator als auch dem Ausgabegenerator so programmierbar sind, dass Nutzer imstande sind, die Such- und Entscheidungsmaschine so zu konfigurieren, dass sie unterschiedliche Netzwerkmerkmale und -protokolle unterstützt.
Verfahren gemäß Anspruch 12, wobei der Zählerblock Folgendes aufweist: N Wrap-around- bzw. Umschaltzähler, wobei jeder der N Umschaltzähler mit einer Zählerkennung assoziiert ist; und einen Überlauf-FIFO, der von den N Umschaltzählern verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen.
Top-of-Rack-Switch-Mikrochip, der Folgendes aufweist: einen programmierbaren Syntaxanalysator bzw. Parser, der erwünschte Paketkontextdaten aus Kopfteilen einer Vielzahl von eingehenden Paketen analysiert, wobei die Kopfteile durch den Parser basierend auf einem durch Software definierten Syntax- bzw. Analysediagramm des Parsers erkannt werden und wobei, beginnend mit dem gleichen Anfangsknoten des Analysediagramms, jeder Pfad durch das Analysediagramm eine Kombination von Schichttypen von einem der Kopfteile repräsentiert, der durch den Parser erkannt werden kann; eine oder mehrere Suchspeicher mit einer Vielzahl von Tabellen, einem Schlüsselgenerator bzw. Key-Generator, der konfiguriert ist, um einen Satz von Suchschlüsseln für jeden Eingabetoken zu erzeugen, und einen Ausgabegenerator bzw. Output-Generator, der konfiguriert ist, um einen Ausgabetoken durch Modifizieren des Eingabetokens basierend auf einem Inhalt der Suchergebnisse zu erzeugen, die mit dem Satz der Suchschlüssel assoziiert sind, wobei die Suchspeicher als logische Überlagerung bzw. Overlay konfiguriert sind, so dass die Skalierung und Breite der Suchspeicher durch einen Nutzer durch Software definiert werden, und ferner wobei jeder der Suchspeicher konfiguriert ist, um selektive in Hash-, Direktzugriffs- oder Longest-Prefix-Match-Betriebsmodi zu arbeiten; eine Leitung bzw. Pipeline einer Vielzahl von programmierbaren Such- und Entscheidungsmaschinen bzw. LDEs (LDEs = Lookup and Decision Engines), die die Paketkontextdaten basierend auf Daten empfangen und modifizieren, die in den Suchspeichern gespeichert sind, sowie einer durch Software definierten Logik, die in die Maschinen durch den Nutzer programmiert ist; einen programmierbaren Umschreibblock, der basierend auf den Paketkontextdaten, die von einer der Maschinen empfangen werden, die Paketkopfteile umbaut und vorbereitet, und zwar so wie sie innerhalb des Schalters bzw. Switch zur Ausgabe verarbeitet werden, wobei der Umschreibblock jede Schicht von jedem der Kopfteile expandiert, die durch den Parser analysiert werden, um einen expandierten Schichttyp einer generischen Größe zu bilden, und zwar basierend auf einem Protokoll, das mit der Schicht assoziiert ist; und einen programmierbaren Zählerblock, der für Zählvorgänge der Such- und Entscheidungsmaschinen verwendet wird, wobei der Zählerblock N Wrap-around- bzw. Umschaltzähler aufweist, wobei jeder der N Umschaltzähler mit einer Zählerkennung assoziiert ist und einem Überlauf-FIFO, der durch die N Umschaltzähler verwendet und gemeinsam genutzt wird, wobei der Überlauf-FIFO die assoziierten Zählerkennungen sämtlicher Zähler speichert, die überlaufen, und ferner wobei die Betriebe bzw. Vorgänge, die durch den Zählerblock ausgeführt werden, durch den Nutzer durch Software definiert werden.