DE602004012210T2

DE602004012210T2 - Verfahren and System für eine beschleunigte Paketverarbeitung

Info

Publication number: DE602004012210T2
Application number: DE602004012210T
Authority: DE
Inventors: David James K0A 1L0 WILSON
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2003-10-24
Filing date: 2004-10-22
Publication date: 2009-03-12
Anticipated expiration: 2024-10-23
Also published as: CN1610338B; ATE388567T1; JP2005130502A; EP1526699A1; EP1526699B1; US20050089030A1; US7571242B2; CN1610338A; DE602004012210D1

Description

Gebiet der Erfindung
Die Erfindung betrifft Kommunikationssysteme und konkret ein Paketverarbeitungskonzept, bei dem ein Cache-Speicher verwendet wird für den schnellen Zugriff der Header der oberen Schicht im Paketfluss.
Hintergrund der Erfindung
In der folgenden Beschreibung wird konkret auf das Internet-Protokoll Version 6 (IPv6) und auf die Mehrfeld-Klassifizierung („Multi-Field Classification", MFC) verwiesen. Dabei sollte jedoch klar sein, dass das Prinzip der vorliegenden Erfindung nicht auf IPv6 und MFC begrenzt ist, sondern dass die beschriebene Implementierung lediglich als Beispiel zu verstehen ist.
IPv6 stellt eine Weiterentwicklung dar, um bestimmte Einschränkungen von IPv4 zu überwinden. Insbesondere die Einschränkungen hinsichtlich der Weiterleitung und Adressierung bei IPv4 stellen eine reale Begrenzung der Adresskonfigurationen dar, die mit einer Feldbegrenzung von 32 Bit erzielt werden können. Bei IPv6 wurde das Adressfeld auf 128 Bit erweitert. Dadurch werden mehr Stufen einer Adressierungshierarchie sowie eine höhere Anzahl adressierbarer Knoten unterstützt. Darüber hinaus wurden einige IPv4 Header-Felder gelöscht, um die Paketverarbeitungskosten zu senken und die Kosten für die Bandbreite bei IPv6-Kopfdaten („Header") zu begrenzen. IPv6 wurde um eine neue Möglichkeit erweitert, die die Beschriftung von Paketen ermöglicht, die zu einem bestimmten Datenverkehrsablauf gehören, für den der Absender eine spezielle Verarbeitung anfordert auf der Basis der Dienstgüte oder der Echtzeitverarbeitung. Darüber hinaus wurde der Mechanismus zum Hinzu fügen optionaler Informationen zu einem Paket auf der Internet-Schicht geändert. In IPv4 wird dies über das Optionsfeld, das Teil des IPv4-Headers ist, erreicht. Das IHL-Feld ("Internet Header Length", Internet-Kopfdatenlänge) in den IPv4-Kopfdaten gibt die Länge dieser zusätzlichen Felder sowie des Basis-Headers an. Wegen der Länge des IHL-Felds kann einem Paket jedoch nur eine begrenzte Anzahl von Optionen hinzugefügt werden. In IPv6 werden Informationen auf der Internet-Schicht über die Erweiterungs-Header hinzugefügt. Diese Header werden einem IPv6-Paket zwischen dem IPv6-Header und den Headern der oberen Schicht hinzugefügt. Jeder Erweiterungs-Header umfasst ein Feld, das den Typ des nächsten Headers angibt, und statt ein Feld wie IHL in IPv4 zu verwenden, gibt IPv6 die Länge des nächsten Erweiterungs-Headers direkt in den Erweiterungs-Headern an. Dies ermöglicht das Hinzufügen einer unbegrenzten Anzahl von Erweiterungs-Headern zu einem IPv6-Paket.
1 zeigt das Format der IPv6-Header einschließlich des Felds „Flow Label" (Ablaufbeschriftung).
Die reguläre Paketverarbeitung erfordert normalerweise Felder aus Headern der oberen Schicht. Die Mehrfeldklassifizierung („Multi-Field Classification", MFC), eines der vielen Beispiele zur Verarbeitung solcher Daten, klassifiziert normalerweise Pakete auf der Basis der 5 Tupel (<Quellen-IP, Ziel-IP, Quellen-Port, Ziel-Port, Protokoll>. Wenn Optionen oder Erweiterungs-Header verwendet werden, kann es schwierig und kostenintensiv sein, den Header der oberen Schicht zu erreichen, um die für die Paketverarbeitung erforderlichen Daten abzurufen.
Für IPv4 ist die Verarbeitung von Paketen einfach, da das zuvor erwähnte IHL-Feld zum Überspringen des gesamten IPv4-Headers einschließlich aller daran angehängten Optionen verwendet werden kann, um den Header der oberen Schicht zu erreichen.
Für IPv6 ist das Erreichen des Headers der oberen Schicht erheblich schwieriger bei Paketen, die Erweiterungs-Header enthalten, da der IPv6-Header kein Feld wie IHL in IPv4 umfasst, über das der Header der oberen Schicht direkt erreicht werden könnte. Eine Lösung gemäß dem Stand der Technik ist das serielle Durchlaufen der Erweiterungs-Header. Da die Länge der einzelnen Erweiterungs-Header direkt im Erweiterungs-Header gespeichert wird, erscheint dies die offensichtlichste Lösung. Die IPv6-Paketverarbeitung wird dadurch kostenintensiv, wenn eine Reihe von Erweiterungs-Headern durchlaufen werden muss, bevor der Header der oberen Schicht erreicht und eine reguläre Paketverarbeitung durchgeführt werden kann. Diese Kosten erscheinen um so unnötiger, als die Präsenz von IPv6-Erweiterungs-Headern nicht notwendigerweise bedeutet, dass der Knoten eine spezielle Verarbeitung durchführen muss. Einige Erweiterungs-Header umfassen Informationen, die nur für den Zielknoten relevant sind und die von allen anderen Knoten auf dem Weg bis zum Ziel ignoriert werden können. Tatsächlich sind nur die Hop-für-Hop- und die Router-Erweiterungs-Header für alle Knoten relevant, und Letzterer ist nur relevant, wenn das ankommende Paket für den Knoten bestimmt ist. Glücklicherweise gibt RFC2460 an, dass Hop-für-Hop-Erweiterungs-Header die ersten Erweiterungs-Header nach dem IPv6-Header sind. Somit kann ein Knoten schnell feststellen, ob das Paket eine spezielle Verarbeitung erfordert, indem er einfach die Zieladresse und das Feld „hext Header" des IPv6-Headers prüft.
Eine Alternative zum vorigen Ansatz ist es, einfach die in einer Paketklassifizierung verwendeten Felder auf diejenigen aus dem IP-Header zu begrenzen, so dass der Header der oberen Schicht nicht untersucht zu werden braucht. Für MFC reduziert dies die Standard 5-Tupel-Klassifizierung auf eine 3-Tupel-Klassifizierung. Dies ist keine sehr gängige Option, da das Begrenzen der im MFC-Schlüssel für IPv6 verwendeten Felder bedeutet, dass die Kontrolle über die Sicherheit des Knotens geändert werden muss. Somit muss ein neues Set von Regeln für IPv6 entwickelt werden, da es manchmal sehr aufwändig ist, alle Felder aus dem Header der oberen Schicht zu lesen. Die Begrenzung der in einer Paketklassifizierung verwendeten Felder wird daher nicht als eine aussichtsreiche Lösung betrachtet.
XP001054898, Huang N-F et al: „Design of multi-field IPv6 packet classifiers using ternary cams" („Konzeption von Mehrfeld-IPv6-Paketklassifizierungen mithilfe ternärer CAM-Speicher), Globecom '01, 2001 IEEE Global Telecommunications Conference, San Antonio, TX, 25.–29. Nov 2001, Seite 1877–1881, ISBN 0-7803-7206-9, beschreibt, wie diese High-End-Router ein Paket klassifizieren, indem sie nach mehreren Feldern der IP/TCP-Headers suchen und erkennen, zu welchem Ablauf das Paket gehört. Verschiedene Paketklassifizierungs-Algorithmen zur Beschleunigung der Paketverarbeitung und zur Reduzierung der Speicheranforderung wurden bereits vorgeschlagen. Es ist nicht einfach, diese Algorithmen in der Hardware zu implementieren, um diese vielen Felder gleichzeitig zu durchsuchen. XP001054898 neigt zur Konzeption eines neuen Paketklassifizierungssystems, das ein gleichzeitiges Durchsuchen mehrerer Felder ermöglicht, insbesondere für die IPv6-Pakete mit längeren Adressen. Zum Klassifizieren der IPv6-Pakete mit Kabelgeschwindigkeit wird die CAM-ähnliche speicherorientierte Hardwarearchitektur in Betracht gezogen, und fünf Felder werden als Suchschlüssel festgelegt.
XP002317313, A. Conta et al: „A proposal for the IPv6 flow label, draft-conta-ipvo-flow-label-02.txt" (Ein Vorschlag zur IPv6-Ablaufbeschriftung), Internet Draft, 1. Juli 2001, IETF, IPNG Working Group, beschreibt eine Analyse der IPv6-Definition der Ablaufbeschriftung, die Regeln zu ihrer Verwendung und ihre Auswirkungen. XP002317313 macht anschließend einen Vorschlag zum Hinzufügen/Ändern dieser Regeln, die die Nutzbarkeit der IPv6-Ablaufbeschriftung verbessern, insbesondere mit Diffserv und seiner Annahme als Standardmechanismus.
XP010636142, Van Lunteren J et al.: „Dynamic multi-field packet classification" ("Dynamische Mehrfeld-Paketklassifizierung"), Globecom '02, 2002 – IEEE Global Telecommunications Conference, Tapei, Taiwan, 17.–21. Nov. 2002, Seite 2215–2219, ISBN 0-7803-7632-3, untersucht die Mechanismen, die die Leistung der Mehrfeld-Klassifizierungsverfahren gemäß dem Stand der Technik bestimmen, und schlägt ein neues Konzept unter dem Namen P²C für die Paketklassifizierung bei OC-192- und OC-768-Geschwindigkeiten vor. P²C verbindet die Stärken des integrierten Speichers und der ternären CAM-Technologien und erzielt damit eine sehr hohe Speichereffizienz unter Beibehaltung schneller inkrementeller Aktualisierungen.
Zusammenfassung der Erfindung
Vereinfacht gesagt, betrifft die vorliegende Erfindung das Caching von Informationen zur Länge der innerhalb eines Paketablaufs verwendeten Erweiterungs-Header, um die Verarbeitung der folgenden Pakete in dem Ablauf zu beschleunigen. In einer exemplarischen Ausführungsform umfasst der Paketablauf IPv6-Pakete.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird daher ein Verfahren bereitgestellt für den Zugriff auf Header der oberen Schicht in einem Paketablauf, das die fol genden Schritte umfasst: als Reaktion auf ein Paket, das Erweiterungs-Header umfasst, den Aufbau eines Cache-Schlüssels auf der Basis der Felder in dem Header und die Durchführung einer Cache-Suche nach einem Cache-Eintrag; und als Reaktion auf das Finden eines entsprechenden Cache-Eintrags das parallele Lesen der Erweiterungs-Header mithilfe des Cache-Eintrags, um die Felder in dem Header der oberen Schicht zu erreichen und zu lesen.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein System bereitgestellt zur Durchführung der MFC für die Filterung eines Paketablaufs, die Folgendes umfasst: Mittel als Reaktion auf ein IPv6-Paket, das Erweiterungs-Header umfasst, zum Aufbau eines Cache-Schlüssels auf der Basis der Felder in dem Header und Durchführung einer Cache-Suche nach einem Cache-Eintrag; und Mittel als Reaktion auf das Finden eines entsprechenden Cache-Eintrags zum parallelen Lesen der Erweiterungs-Header mithilfe des Cache-Eintrags, um die Felder in dem Header der oberen Schicht zu erreichen und zu lesen.
Kurzbeschreibung der Zeichnungen
Die Erfindung ist nachfolgend ausführlich beschrieben mit Bezug auf die beigefügten Zeichnungen, wobei gilt:
1 zeigt das IPv6-Header-Format;
2 zeigt die Folge der erforderlichen Operationen zum Erreichen des Headers der oberen Schicht eines IPv6-Pakets;
die 3A und 3B zeigen einen Vergleich der Speicherzugriffe mit serieller und pluraler Verarbeitung, und
die 4A bis 4G zeigen die Zeitlinien der Suchvorgänge bei Erweiterungs-Headern mithilfe von Optionen.
Ausführliche Beschreibung der Erfindung
Wenn ein Knoten ein Paket empfängt, wird der IPv6-Header untersucht. Pakete, die keine Erweiterungs-Header enthalten, werden mit den normalen Techniken der Paketverarbeitung verarbeitet. Das bedeutet, dass die einzigen zusätzlichen Kosten für die Verarbeitung dieser Pakete durch die Prüfung der Erweiterungs-Header entstehen. Für Pakete mit dem Hop-für-Hop Erweiterungs-Header oder Pakete, die für den Knoten bestimmt sind und Weiterleitungs-Header enthalten, kann an dieser Stelle die spezielle durch den Header vorgegebene Verarbeitung eingeleitet werden.
Für Pakete mit Erweiterungs-Headern verwendet der Knoten die im IPv6-Header enthaltenen Informationen zum Aufbau eines Schlüssels für die Durchführung einer Cache-Suche. Das Format dieses Schlüssels kann für alle Pakete gleich sein, oder es könnte auf der Präsenz oder dem Wert der Felder im IPv6-Header basieren. Für Pakete mit Ablaufbeschriftungen ungleich Null könnte das Tupel <IPv6.srcIP, IPv6.flowLabel> oder <IPv6.srcIP, IPv6.flowLabel, IPv6.nextHeader> verwendet werden. Für Pakete mit Ablaufbeschriftungen gleich Null könnte das Tupel <IPv6.srcIP, IPv6.dstIP> oder <IPv6.srcIP, IPv6.dstIP, IPvG.nextHeader> verwendet werden.
Während der Ausführung der Cache-Suche können die Informationen aus dem Header zum Lesen des ersten Erweiterungs-Headers in der Liste verwendet werden. Wenn kein Eintrag im Cache gefunden wird, fährt der Knoten mit dem seriellen Durchlaufen der Liste von Erweiterungs-Headern fort unter Verwendung der Felder für die Erweiterungs-Header-Länge und den nächsten Header. Nach einem seriellen Durchlaufen werden die zum Durchlaufen der Erweiterungs-Header verwendeten Daten im Cache platziert in Erwartung weiterer Pakete im gleichen Ablauf mit ähnlichen Erweiterungs-Headern. Wird jedoch ein Cache-Eintrag gefunden, so verwendet der Knoten die Informationen aus dem ersten Erweiterungs-Header und die Cache-Daten zum parallelen Lesen der einzelnen verbleibenden Erweiterungs-Header. Auf diese Weise kann der Knoten die Erweiterungs-Header schnell durchlaufen, und er kommt entweder beim Header der oberen Schicht an oder fährt mit dem seriellen Durchlaufen der letzten Erweiterungs-Header fort, falls nicht genügend Daten im Cache abgelegt wurden. Wenn an irgend einer Stelle beim Durchlaufen der Erweiterungs-Header die Cache-Daten als falsch erkannt werden, muss der Knoten die verbleibenden Erweiterungs-Header seriell durchlaufen ab der Stelle, an der die Daten fehlerhaft waren. In diesem Fall wird der Cache aktualisiert, so dass er die Erweiterungs-Header im aktuellen Paket widerspiegelt in Erwartung zusätzlicher Pakete im gleichen Ablauf mit einem ähnlichen Format.
In 2 ist der oben beschriebene Algorithmus zusammengefasst. Es ist zu beachten, dass keine Cache-Suche durchgeführt wird, falls sich nach dem Lesen des IPv6-Headers bekanntermaßen keine Erweiterungs-Header im Paket befinden. In diesen Fällen, in denen keine Pakete mit Erweiterungs-Headern vorliegen, ergibt sich – wenn überhaupt – nur ein sehr kleiner Nachteil durch die Implementierung dieser Optimierungen.
3 zeigt den Unterschied bei den Speicherzugriffen zwischen dem Durchlaufen der verknüpften Liste der Erweiterungs-Header und dem Verwenden des beschleunigten Algorithmus. In dem gezeigten Fall wird die Latenz der Paketverarbeitung um einen Speicherzugriff reduziert. 3A zeigt die bei einem seriellen Durchlaufen der Header verwendeten Speicherzugriffe.
Wie in 3B gezeigt, umfasst die parallele Verarbeitung in Schritt 23 eine Untersuchung des Cache parallel zur Überprüfung des ersten Erweiterungs-Headers.
Es gibt verschiedene alternative Ausführungsformen der Erfindung. Die erste Ausführungsform ist die Möglichkeit zum Kennzeichnen „unvorhersehbarer" Abläufe und der Reaktion darauf. Diese Ausführungsform wird verwendet zum Erkennen von Abläufen, bei denen sich die Erweiterungs-Header ständig ändern. Wenn ein solcher Ablauf erkannt wird, ist klar, dass die Cache-Daten wahrscheinlich nicht korrekt sind und dass es effizienter wäre, die Erweiterungs-Header seriell zu durchlaufen statt des Versuchs eines parallelen Durchlaufens. Darüber hinaus wäre bei einem solchen Ablauf das Aktualisieren des Cache, um das Format des aktuellen Pakets widerzuspiegeln, nicht notwendig. Das Kennzeichnen eines Ablaufs als „nicht vorhersehbar" könnte das Ergebnis einer manuellen Konfiguration sein oder dynamisch ermittelt werden auf der Basis der Beobachtung des Ablaufs.
Die zweite Ausführungsform bietet die Möglichkeit, einen Cache-Eintrag als „klebrig" zu kennzeichnen. Dies wäre ein Hinweis darauf, dass die Mehrzahl der Pakete in einem Ablauf mit den Cache-Daten korrekt interpretiert werden sollten, und dass in dem Fall, dass die Cache-Daten nicht mit dem Paket übereinstimmen, der Cache-Speicher nicht aktualisiert werden soll. Dadurch wird verhindert, dass ein einzelnes Paket die gesamten Cache-Daten verändert. Wie bei der vorherigen Erweiterung kann dieses Merkmal manuell oder als Ergebnis der Ablaufbeobachtung aktiviert werden. Diese Erweiterung kann verbessert werden durch die Angabe, dass bei Cache-Fehlern die Daten im Cache erst nach einer bestimmten Anzahl von Fehlern aktualisiert werden sollen.
Bei einer dritten Ausführungsform wird ebenfalls ein Teil der Header-Informationen der oberen Schicht im Cache-Speicher abgelegt, beispielsweise das Protokoll und die Quellen- und Ziel-Ports. Beim Empfang der Cache-Informationen können die Protokollinformationen in Verbindung mit den im IPv6-Header enthaltenen Informationen verwendet werden, um unverzüglich mit der Paket-Klassifizierung, beispielsweise über MFC, zu beginnen. Während die Klassifizierung abgeschlossen wird, können die verbleibenden Cache-Informationen für ein schnelles Durchlaufen der Erweiterungs-Header verwendet werden und zum Verifizieren, dass die Cache-Protokollinformationen den Informationen im Paket entsprechen. Wenn die beiden Informations-Sets übereinstimmen, ist die Klassifizierung gültig. Sind jedoch die Informationen aus dem Cache-Speicher falsch, muss die Klassifizierung mit den richtigen Informationen aus dem Header der oberen Schicht wiederholt werden. Im schiechtesten Fall entstehen Kosten für eine zusätzliche Klassifizierung, im besten Fall erlaubt dieses Verfahren jedoch die Durchführung einer Paketklassifizierung parallel mit dem Durchlaufen der Erweiterungs-Header, und es kann die Gesamtlatenz der Paketverarbeitung um die für die Paketklassifizierung erforderliche Latenz reduzieren.
Eine weitere Ausführungsform ist die Möglichkeit, die Ergebnisse anderer Klassifizierungen und Suchen, die im Verlauf der regulären Paketverarbeitung durchgeführt wurden, im Cache abzulegen. Das Ergebnis der MFC und die vorausschauenden Suchen könnten beispielsweise dem Cache hinzugefügt werden. Mit dieser Ausführungsform muss nur das erste Paket in einem Ablauf vollständig klassifiziert werden, da die Folgepakete im Ablauf die Ergebnisse dieser Klassifizierung aus dem Cache verwenden können.
Die vorliegende Erfindung bietet Vorteile gegenüber zuvor beschriebenen Lösungen gemäß dem Stand der Technik. Da ein großer Teil der Erweiterungs-Header bei den meisten Knoten keine spezielle Verarbeitung erfordern, reduziert die vorliegende Erfindung die Kosten für die Verarbeitung von IPv6-Paketen, die Erweiterungs-Header enthalten. Dadurch werden die Header der oberen Schicht schnell erreicht, so dass die Paketverarbeitung fortgesetzt werden kann.
Mit Blick auf die Verwendung der vorhandenen MFC-Tupel können die bei der Paketklassifizierung verwendeten Felder gegenüber den für IPv4 verwendeten Feldern unverändert bleiben, da der Header der oberen Schicht schnell erreicht werden kann. Das bedeutet, dass die vorhandenen Sicherheitsrichtlinien auf IPv6 in der gleichen Weise angewendet werden können wie zuvor auf IPv4.
Die Kosten des parallelen Ladens von Erweiterungs-Header-Informationen können in einer geringfügigen Zunahme der Gesamt-Speicherbandbreite bestehen, da die Daten aus dem Cache-Speicher gelesen werden müssen, aber diese Zunahme tritt nur bei Paketen auf, die Erweiterungs-Header umfassen.
4 zeigt die Zeitlinien für das parallele Laden von bis zu sechs Erweiterungs-Headern. Die durchgezogenen Balken kennzeichnen das Durchlaufen der Erweiterungs-Header im günstigsten Fall. Die gestrichelten Balken kennzeichnen das Durchlaufen der Erweiterungs-Header in dem absolut schlechtesten Fall, dass die Cache-Informationen falsch sind. Aus den 4A bis 4G ist zu erkennen, dass der günstigste Fall beim Durchlaufen der Erweiterungs-Header eine erhebliche Zeitersparnis bringt gegenüber dem Prozess mit seriellen Header-Suchen, wie mit den gestrichelten Linien gezeigt.
Der Cache-Speicher kann auf beliebig viele Arten implementiert werden. Mögliche Implementierungen umfassen die Verwendung eines inhaltsadressierbaren Speichers („Context Addressable Memory", CAM) oder die Verwendung von Hash-Tabellen. Das möglicherweise offensichtlichste Verfahren ist die Verwendung eines vorhandenen CAM-Speichers. Die Verwendung des CAM als Cache-Speicher hat Vor- und Nachteile. Der Hauptvorteil liegt darin, dass mit einem CAM die meisten, wenn nicht alle Bits aus dem Schlüssel zur Durchführung einer Suche verwendet werden können, die – je nach der genauen Implementierung – nur ein sehr geringes oder kein Risiko birgt, dass bei einer Übereinstimmung mit dem Schlüssel eine Kollision auftritt. Das bedeutet, dass es nur sehr wenige Fehler bei der Übereinstimmung aufgrund des Abrufs falscher Informationen aus dem CAM geben wird. Der Nachteil bei einer CAM-Implementierung, neben der Tatsache, dass CAMs teuer und durch den Platz begrenzt sind, liegt darin, dass die CAM-Suche zwei Speicherzugriffe für die Durchführung einer Cache-Suche erfordern kann. Der erste Zugriff, ein Schreibzugriff, liefert dem CAM den Schlüssel und die Anleitungen zur Durchführung einer Suche. Der zweite Zugriff, ein Lesezugriff, ruft das Ergebnis aus dem CAM-Speicher ab.
Als eine Alternative zur Verwendung des CAM-Speichers kann eine Hash-Tabelle verwendet werden, um den Cache-Speicher zu implementieren. Diese Implementierung bietet bestimmte Vorteile, da sie keinen kostbaren und teuren CAM-Platz belegt. Wegen der Geschwindigkeit, mit der eine Hash-Suche durchgeführt werden kann, ist diese Implementierung wahrscheinlich mindestens so schnell und mit Sicherheit weniger teuer als die CAM-Implementierung. Der Nachteil bei der Hash-Implementierung liegt in der gegenüber der CAM-Implementierung höheren Wahrscheinlichkeit einer Kollision bei einer Übereinstimmung des Schlüssels.
Je nachdem, wie der Cache genau implementiert wird, kann bei einer Übereinstimmung des Schlüssels eine Kollision auftreten. Dies ist möglich, weil nicht alle Bits des Schlüssels als Index für den Cache verwendet werden. Dadurch ist eventuell eine weitere Verarbeitung erforderlich, um diese Kollision zu beheben. Es kann sein, dass die Kosten für die Behebung dieser Kollision durch falsche Cache-Informationen bei bestimmten Implementierungen höher sind als die Kosten für ein serielles Durchlaufen der Erweiterungs-Header. In diesen Fällen wäre es von Vorteil, einfach anzunehmen, dass keine Kollisionen auftreten. Das Endergebnis wäre eine Zunahme bei der Häufigkeit der Nichtübereinstimmung von Cache- und Paketdaten, aber insgesamt eine Reduzierung bei der Verarbeitungszeit. Bei Hash-Implementierungen hat dies den zusätzlichen Vorteil der Reduzierung der Größe der Hash-Tabelleneinträge, da die zur Behebung der Kollisionen erforderlichen Informationen nicht mehr benötigt würden. Die Reduzierung bei der Größe der Hash-Tabelleneinträge vergrößert effektiv die Anzahl der Einträge in der Tabelle oder erlaubt eine Einsparung von Speicherplatz.
Wie weiter oben erläutert, verwendet das Caching-Verfahren Felder aus dem Header, um einen Schlüssel zum Indexieren des Cache aufzubauen. Die im Cache gespeicherten Informationen sind eine Duplizierung der Informationen, die sich mutmaßlich im Paket befinden. Wegen dieser Duplizierung muss sorgfältig sichergestellt werden, dass die Cache-Daten mit den Daten im Paket übereinstimmen. Hierzu muss mindestens die Lange der Erweiterungs-Header im Cache abgelegt werden, damit die Erweiterungs-Header geladen werden können, um zu bestätigen, dass sie mit den Cache-Daten übereinstimmen. Würde diese Überprüfung nicht durchgeführt, so könnte ein bösartiger Host einen gültigen Ablauf einrichten, aber Folgepakete in dem Ablauf verändern, um einen Sicherheitsmechanismus zu umgehen. Als Beispiel lässt sich eine Implementierung annehmen, die einfach die gesamte Länge aller Erweiterungs-Header im Cache ablegt. Wenn das erste Paket, das zahlreiche Erweiterungs-Header umfasst, im Ablauf ankommt, werden die Erweiterungs-Header seriell durchlaufen, und dem Cache wird ein Eintrag hinzugefügt. MFC wird mit dem Paket durchgeführt, und das Paket wird akzeptiert. Ein weiteres Paket kommt im Ablauf an, und die Cache-Daten werden gelesen. Der gesamte Versatz der Erweiterungs-Header wird verwendet, um das zu lesen, was für den Header der oberen Schicht gehalten wird, wobei es sich in Wirklichkeit aber um einen gefälschten Header handelt, der mit dem des ersten Pakets identisch ist. MFC wird durchgeführt, und das Paket wird akzeptiert. Wären die Erweiterungs-Header seriell gelesen worden, so wäre klar gewesen, dass dieses zweite Paket weniger Erweiterungs-Header als das erste Paket hat und dass sich der echte Header der oberen Schicht weiter vorn im Paket befand als der, auf den die Cache-Daten verwiesen hatten.
Auch wenn bestimmte Ausführungsformen der Erfindung beschrieben und dargestellt werden können, so ist doch für den Fachmann klar, dass zahlreiche Änderungen daran vorgenommen werden können, ohne vom Grundkonzept der Erfindung abzuweichen. Es sollte jedoch klar sein, dass solche Änderungen innerhalb des Anwendungsbereichs der Erfindung gemäß der Definition in den beigefügten Patentansprüchen liegen.

Claims

Verfahren zum Zugriff auf den Transport-Header von Paketen, die kein Feld für die Länge des Internet-Headers umfassen, dadurch gekennzeichnet, dass das Verfahren die folgenden Schritte umfasst: a) Ablegen von Erweiterungs-Headern, die die Länge des Internet-Headers von Paketen angeben, im Cache-Speicher; b) als Reaktion auf einen Paket-Header, der Erweiterungs-Header umfasst, den Aufbau eines Cache-Schlüssels zu diesem Paket und die Durchführung einer Cache-Suche nach einem Cache-Eintrag zu diesem Cache-Schlüssel; und c) als Reaktion auf das Finden eines entsprechenden Cache-Eintrags das parallele Lesen dieser Erweiterungs-Header, um die Felder im Header der oberen Schicht zu erreichen und zu lesen.
Verfahren gemäß Anspruch 1, wobei es sich bei dem Paketfluss um ein IPv6-Paket handelt.
Verfahren gemäß Anspruch 1, wobei dieser Cache-Schlüssel mithilfe von zwei Feldern des Internet-Headers dieser Pakete berechnet wird.
Verfahren gemäß Anspruch 3, wobei die beiden Felder zur Berechnung dieses Cache-Speichers die IP-Ausgangsadresse und eine Ablaufbeschriftung für Pakete mit einer Ablaufbeschriftung und die IP-Ausgangs- und Zieladresse für Pakete ohne Ablaufbeschriftung sind.
Verfahren gemäß Anspruch 3, wobei die beiden Felder die Ausgangsadresse, die Ablaufbeschriftung und der nächste Header oder die Quell- und Zieladresse und der nächste Header sind.
Verfahren gemäß Anspruch 1, wobei die Cache-Suche mithilfe einer Tabelle durchgeführt wird, die die Länge der Erweiterungs-Header umfasst.
Verfahren gemäß Anspruch 1, wobei Schritt d) das Lesen des ersten Erweiterungs-Headers dieses Folgepakets umfasst, während die Cache-Suche mit den verbleibenden Erweiterungs-Headern durchgeführt wird.
Verfahren gemäß Anspruch 1, das des Weiteren Folgendes umfasst, wenn kein Cache-Eintrag zu diesem Cache-Schlüssel gefunden wird: i) Ablegen der durch serielles Durchlaufen aller Erweiterungs-Header dieses Pakets empfangenen Erweiterungs-Header-Daten im Cache-Speicher, und Zuordnen dieses Cache-Schlüssels zu einem Cache-Eintrag, der diesen Erweiterungs-Header-Daten entspricht; ii) Reagieren auf ein Folgepaket, das den gleichen Cache-Schlüssel hat; und iii) Durchführen von Schritt c) für dieses Folgepaket.
Verfahren gemäß Anspruch 7, das des Weiteren den folgenden Schritt umfasst, wenn dieses Folgepaket den gleichen Cache-Schlüssel aufweist, aber zusätzliche Options-Header umfasst neben den für diesen Eintrag im Cache abgelegten Options-Headern: iv) Aktualisieren dieser optionalen Header-Daten durch Caching zusätzlicher Erweiterungs-Header-Daten, die durch serielles Durchlaufen aller zusätzlichen Erweiterungs-Header des Folgepakets erhalten wurden.
Verfahren gemäß Anspruch 1 einschließlich des Schritts zum Erkennen von Paketen mit Hop-für-Hop- und Weiterleitungs-Erweiterungs-Headern und zum Ermitteln, ob die Durchführung der Schritte b) und c) für solche Pakete erforderlich ist.
Verfahren gemäß Anspruch 7, wobei Schritt iv) nicht durchgeführt wird, wenn dieses Folgepaket den gleichen Cache-Schlüssel hat, aber die optionalen Header-Daten zu diesem Cache-Schlüssel nicht den optionalen Headern dieses Pakets entsprechen.
Verfahren gemäß Anspruch 11, wobei die Erkennung, dass der Cache dem Paket nicht entspricht, manuell aktiviert wird.
Verfahren gemäß Anspruch 11, wobei die Erkennung, dass der Cache dem Paket nicht entspricht, auf der Basis von Ablaufbeobachtungen aktiviert wird.
Verfahren gemäß Anspruch 1, wobei Informationen aus dem Header der oberen Schicht im Cache-Speicher abgelegt werden.
Verfahren gemäß Anspruch 14, wobei die im Cache-Speicher abgelegten Informationen das Protokoll sowie die Identifikation des Quellen- und des Ziel-Ports umfassen.
Verfahren gemäß Anspruch 1, wobei die Ergebnisse der Klassifizierung und der durchgeführten Suchen im Rahmen der regulären Paketverarbeitung im Cache-Speicher abgelegt werden.
System für den Zugriff auf den Transport-Header von Paketen, die kein Feld für die Länge des Internet-Headers umfassen, dadurch gekennzeichnet, dass es Folgendes umfasst: Mittel zum Caching von Header-Daten, die die Länge der Erweiterungs-Header der Pakete angeben; Mittel als Reaktion auf einen Paket-Header mit Erweiterungs-Headern zum Aufbau eines Cache-Schlüssels für dieses Paket und zur Durchführung einer Cache-Suche für einen Cache-Eintrag entsprechend diesem Cache-Schlüssel; und Mittel, als Reaktion auf das Finden eines entsprechenden Cache-Eintrags, zum parallelen Lesen dieser Erweiterungs-Header, um die Felder des Headers der oberen Schicht zu erreichen und zu lesen.
System gemäß Anspruch 17, wobei das Paket ein IPv6-Paket ist.
System gemäß Anspruch 18, wobei die Mittel zur Durchführung einer Cache-Suche parallel Informationen aus dem Header untersucht, die zum Lesen eines ersten Erweiterungs-Headers verwendet werden.
System gemäß Anspruch 19, wobei Mittel zum Lesen der Erweiterungs-Header die Header seriell durchlaufen, wenn kein Cache-Eintrag gefunden wird.
System gemäß Anspruch 17, das Mittel umfasst zur Angabe, dass in bestimmten Situationen Daten im Cache-Speicher nicht zum Beschleunigen der Paketverarbeitung verwendet werden sollen.
System gemäß Anspruch 17, das des Weiteren Mittel umfasst zum Ablegen der Informationen aus dem Header der oberen Schicht im Cache-Speicher.
System gemäß Anspruch 22, wobei die Informationen im Header der oberen Schicht Informationen zum Protokoll sowie zu Ausgangs- und Ziel-Ports umfassen.