DE112019001214T5 - Erzeugung von Pfadausfallmeldung an Weiterleitungselement - Google Patents

Erzeugung von Pfadausfallmeldung an Weiterleitungselement Download PDF

Info

Publication number
DE112019001214T5
DE112019001214T5 DE112019001214.2T DE112019001214T DE112019001214T5 DE 112019001214 T5 DE112019001214 T5 DE 112019001214T5 DE 112019001214 T DE112019001214 T DE 112019001214T DE 112019001214 T5 DE112019001214 T5 DE 112019001214T5
Authority
DE
Germany
Prior art keywords
network
packet
path
hfe
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019001214.2T
Other languages
English (en)
Inventor
Changhoon Kim
Jeongkeun Lee
Milad Sharif
Robert Soule
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Barefoot Networks Inc
Original Assignee
Barefoot Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/948,990 external-priority patent/US10826815B2/en
Application filed by Barefoot Networks Inc filed Critical Barefoot Networks Inc
Publication of DE112019001214T5 publication Critical patent/DE112019001214T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/36—Backward learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Abstract

Einige Ausführungsformen stellen ein Verfahren für ein spezielles FE in einem Netzwerk von FEs bereit. In dem Verfahren wird eine Datenmeldung an einem ersten Anschluss des FE empfangen. Die Datenmeldung umfasst einen Kopf, welcher einen Ausgabeanschluss für jedes FE entlang einem Pfad von einer Quelle der Datenmeldung bis zu einem Ziel der Datenmeldung und einen Eingabeanschluss für zumindest jedes FE entlang dem Pfad spezifiziert, den die Datenmeldung zuvor durchlaufen hat. In dem Verfahren wird bestimmt, dass der spezielle Ausgabeanschluss, der für das FE spezifiziert ist, ein zweiter Anschluss ist, der aktuell nicht betriebsfähig ist. In dem Verfahren wird eine Pfadausfallmeldung erzeugt, welche spezifiziert, dass der zweite Anschluss aktuell nicht betriebsfähig ist, und einen Kopf umfasst, welcher die Ausgabeanschlüsse und Eingabeanschlüsse in der Datenmeldung verwendet. In dem Verfahren wird die Pfadausfallmeldung aus dem ersten Anschluss zur Übermittlung an die Quelle der Datenmeldung gesendet.

Description

  • HINTERGRUND
  • In einem typischen Netzwerk wird eine Weiterleitung (z.B. Schalten/Routing) durch die Weiterleitungselemente innerhalb des Netzwerks durchgeführt. In einem weniger begrenzten Netzwerk, wie z.B. dem Internet, macht es Sinn, diese Funktionalität in die Mitte des Netzwerks zu legen, da die Vorrichtungen am Rand des Netzwerks möglicherweise nicht die Fähigkeit aufweisen, Weiterleitungsentscheidungen zu treffen, und keine Kenntnis von der Netzwerktopologie haben, die für solche Entscheidungen erforderlich wäre.
  • 1 veranschaulicht konzeptmäßig ein Beispiel eines typischen Weiterleitungselements 100 mit einem komplexen Weiterleitungselement-Betriebssystem (OS) 105. Wie dargestellt, umfasst das Weiterleitungselement 100 eine Paketverarbeitungsplatine 110 mit einer integrierten Netzwerk-Weiterleitungsschaltung (z.B. einer Schalter-ASIC) 115 und einem Satz von Netzwerk-Schnittstellen 120. Die Netzwerk-Weiterleitungs-IC 115 handhabt eine Paketweiterleitung, wie durch das OS 105 konfiguriert, und die Netzwerk-Schnittstellen 120 sind es, wie Pakete empfangen/gesendet werden. Außerdem umfasst die Hardware des Weiterleitungselements 100 eine Zentralprozessoreinheits(CPU)-Platine 125, welche eine CPU (w/DRAM) 130 und verschiedene andere Vorrichtungen 135 umfasst. Das Weiterleitungselement-OS 105 läuft auf der CPU 130 ab und umfasst einen Kern, eine Schnittstelle (z.B. eine Befehlsleitungs-Schnittstelle, eine Grafikschnittstelle usw.), welche ermöglicht, dass der Schalter programmiert wird, eine Boot-Ladeeinheit, verschiedene Module zum Verwalten der komplexen Schalt- und Routing-Funktionalitäten der Datenebene (z.B. Routing-Protokoll-Daemons, verschiedene APIs usw.) sowie eine Datenebenenabstraktion, welche dem OS 105 ermöglicht, die komplexe Datenebene zu modellieren und somit die Netzwerk-Weiterleitungs-IC 115 zu konfigurieren.
  • Diese Funktionalitätsaufteilung ist auch zu Datencentern portiert worden, wobei Schalter und Router (sowohl physisch als auch virtuell) ein Standard-L2-Schalten und ein L3-Routing durchführen. Der Betrieb eines Datencenters würde jedoch durch Verschieben der Routing-Entscheidungen zu den Rändern verbessert. Dies würde verschiedene Änderungen daran erfordern, wie die Weiterleitungselemente arbeiten, und an den Protokollen, die zum Senden von Datenpaketen durch das Netzwerk verwendet werden.
  • KURZDARSTELLUNG
  • Einige Ausführungsformen der Erfindung stellen ein Hardware-Weiterleitungselement ohne Steuerebenenlogik in einem Netzwerk bereit, welches die Steuerebenenlogik zu den Netzwerk-Endpunkten (z.B. virtuellen Maschinen, Virtualisierungs-Software-Networking-Stapeln usw.) verschiebt. Das Hardware-Weiterleitungselement einiger Ausführungsformen umfasst eine oder mehrere integrierte Netzwerk-Weiterleitungs-Schaltungen (IC) zum Durchführen von Paket-Parsing und Ausführen von Handlungen (aber ohne die Match-Logik zum Durchführen des L2-Schaltens oder L3-Routings) und eine Minimal-CPU. Auf der CPU läuft ein Weiterleitungselement-Betriebssystem (OS) ab, um die Netzwerk-Weiterleitungs-IC zu starten (z.B. um die IC mit einer Anfangskonfiguration zu versehen), es interagiert jedoch während des Standardablaufs der Paketverarbeitung nicht mit der Netzwerk-W eiterleitungs- IC.
  • Dieses Netzwerk einiger Ausführungsformen umfasst einen Satz einer oder mehrerer Netzwerksteuerungen, zahlreiche Weiterleitungselemente (z.B. Hardware-Weiterleitungselemente, wie oben beschrieben), welche das Grundgerüst des Netzwerks bilden, und Netzwerk-Endpunkte. Die Netzwerksteuerungen speichern eine stationäre Netzwerktopologie (welche z.B. die Positionen aller Weiterleitungselemente und die Verbindungen zwischen Anschlüssen dieser Weiterleitungselemente umfasst), welche die Steuerungen zu den Netzwerk-Endpunkten verteilen, wenn diese Endpunkte erstmals zugeschaltet werden. Um Datenpakete durch das Netzwerk zu senden, erzeugen die Netzwerk-Endpunkte Paketköpfe, welche einen Pfad durch die Weiterleitungselemente sowie möglicherweise andere Handlungen spezifizieren, welche von den Weiterleitungselementen vorzunehmen sind. Die Weiterleitungselemente verwenden keine Steuerungsebene und treffen somit keine Entscheidungen für Datenpakete, die durch das Netzwerk gesendet werden. Stattdessen ist jedes Weiterleitungselement dafür konfiguriert, Datenpakete zu empfangen, an diesen Paketen ein Parsing durchzuführen, um Handlungen (Weiterleiten oder sonstiges) zu identifizieren, die von diesem Weiterleitungselement vorzunehmen sind, und diese Handlungen auszuführen, die innerhalb des Paketkopfs spezifiziert sind.
  • Die Weiterleitungselemente einiger Ausführungsformen sind dafür konfiguriert, an verschiedenen Pakettypen ein Parsing durchzuführen und sie zu verarbeiten. Datenpakete, die von den Netzwerk-Endpunkten erzeugt werden, umfassen Weiterleitungsbefehle sowie andere Handlungen, die von den Weiterleitungselementen auszuführen sind. Außerdem erzeugen die Weiterleitungselemente, um die Netzwerk-Endpunkte zu informieren, wenn eine Verbindung ausgefallen ist (z.B. weil ein Anschluss des Weiterleitungselements nicht mehr betriebsfähig ist, ein Anschluss eines anderen Weiterleitungselements oder das gesamte andere Weiterleitungselement nicht mehr betriebsfähig ist usw.), Pfadausfallpakete, die an die Netzwerk-Endpunkte gerichtet sind. In einigen Ausführungsformen erzeugt das Weiterleitungselement nach dem Empfang eines Pakets, welches spezifiziert, dass das Weiterleitungselement das Paket aus einem Anschluss zu einer Verbindung sendet, die ausgefallen ist, ein Pfadausfallpaket mit dem umgekehrten Pfad des empfangenen Pakets. Außerdem handhaben die Weiterleitungselemente Bootstrapping-Pakete von Netzwerksteuerungen und/oder Netzwerk-Endpunkten, wenn diese Einheiten dem Netzwerk hinzugefügt werden.
  • Wenn ein Netzwerk-Endpunkt zu dem Netzwerk hinzugefügt wird, sendet dieser Netzwerk-Endpunkt in einigen Ausführungsformen ein Bootstrapping-Paket an sein Fist-Hop-Weiterleitungselement (d.h. das Weiterleitungselement, mit welchem der Netzwerk-Endpunkt direkt verbunden ist). Die Bootstrapping-Pakete einiger Ausführungsformen weisen einen speziellen Kopf auf, welcher sie als solche Pakete ausweist (im Gegensatz zu Daten- oder Ausfallsicherungspaketen). Wenn ein Weiterleitungselement ein Bootstrapping-Paket empfängt, flutet das Weiterleitungselement dieses Bootstrapping-Paket in einigen Ausführungsformen an alle seine Anschlüsse (außer dem Anschluss, an welchem das Paket empfangen wurde). Außerdem zeichnet das Weiterleitungselement in einigen Ausführungsformen seine Eingabe- und Ausgabeanschlüsse in dem Paketkopf jeder Kopie des Pakets auf (der Eingabeanschluss ist für jede Kopie derselbe). Jedes Weiterleitungselement führt die gleiche Flutungsoperation durch, bis alle Netzwerk-Endpunkte und die Netzwerksteuerungen das Bootstrapping-Paket (und mit diesem den Pfad zurück zu dem neuen Netzwerk-Endpunkt) empfangen haben. In einigen Ausführungsformen führt jedes Weiterleitungselement außerdem eine Prüfung durch, um zu verifizieren, dass es dieses Bootstrapping-Paket nicht bereits zuvor empfangen hat. Wenn das Weiterleitungselement das Bootstrapping-Paket bereits zuvor empfangen hat, verwirft es diese Kopie des Pakets. Wenn eine Netzwerksteuerung das Bootstrapping-Paket empfängt, kennt die Netzwerksteuerung den Pfad zurück zu dem neuen Netzwerk-Endpunkt und kann deswegen diesem Netzwerk-Endpunkt die vollständige stationäre Netzwerktopologie senden.
  • Für Datenpakete, die von einem Netzwerk-Endpunkt zu einem anderen gesendet werden, fügt in einigen Ausführungsformen der Quellen-Netzwerk-Endpunkt dem Paket einen Paketkopf hinzu, welcher den Pfad durch die Weiterleitungselemente spezifiziert. Der Netzwerk-Endpunkt kann in einigen Ausführungsformen eine virtuelle Maschine sein, auf welcher das Paket entsteht, ein Hypervisor-Netzwerkstapel eines physischen Servers, welcher das Paket von einer virtuellen Maschine oder einem Container empfängt, der auf diesem physischen Server ausgeführt wird, usw. Außerdem können die Netzwerk-Endpunkte in einigen Ausführungsformen Netzwerk-Gateways umfassen, welche Pakete mit externen Netzwerken austauschen.
  • Jedes Datenpaket, das durch das Netzwerk gesendet wird, umfasst das innere Paket (z.B. Nutzdaten sowie herkömmliche L2-L4-Köpfe) sowie den Paketkopf, der von dem Netzwerk-Endpunkt erzeugt wird, der den Pfad für das Paket durch das Netzwerk spezifiziert. In einigen Ausführungsformen umfasst dieser Pfad ein Eingabeanschlussfeld und ein Ausgabeanschlussfeld für jedes Weiterleitungselement entlang dem Pfad des Pakets. Unter Verwendung der Netzwerktopologie bestimmt der Quellen-Endpunkt jedes Weiterleitungselement entlang dem Pfad und füllt zumindest die Ausgabeanschlussfelder (und gegebenenfalls auch die Eingabeanschlussfelder) aus. Jedes Weiterleitungselement führt ein Parsing an dem Paketkopf durch, identifiziert seinen eigenen Ausgabeanschluss in der Liste von Eingabe- und Ausgabeanschlüssen und gibt das Paket aus dem spezifizierten Ausgabeanschluss aus. Wenn die Eingabeanschlüsse nicht von dem Quellen-Endpunkt ausgefüllt worden sind, füllt jedes Weiterleitungselement, das das Paket empfängt, den Eingabeanschluss aus, an welchem es das Paket empfangen hat. In einigen Ausführungsformen bestimmen die Weiterleitungselemente, welche Gruppe von Eingabe- und Ausgabeanschlüssen zu verwenden ist, basierend auf einem Zähler in dem Paketkopf, der durch jedes Weiterleitungselement heraufgesetzt wird. In anderen Ausführungsformen umfasst jedes Einlass-/Auslassanschlusspaar in der Liste eine Weiterleitungselement-Kennung, welche die Weiterleitungselemente verwenden, um ihre Weiterleitungsbefehle durch Parsing zu ermitteln.
  • Jedes Weiterleitungselement entlang dem Pfad kennt nur seinen eigenen Status, umfassend, ob seine verschiedenen Verbindungen funktionieren. Wenn ein Anschluss eines Weiterleitungselements ausfällt (aufgrund eines Problems mit dem Anschluss selbst, mit dem Anschluss eines anderen Weiterleitungselements, mit welchem es verbunden ist, usw.), ist das Weiterleitungselement in einigen Ausführungsformen dafür konfiguriert, dies in der Datenebene zu erfassen und diesen Anschlussstatus in der datenebene zu speichern. Wenn das Weiterleitungselement ein Datenpaket empfängt, welches für das Weiterleitungselement spezifiziert, ein Paket aus einem ausgefallenen Anschluss zu senden, erzeugt das Weiterleitungselement ein Pfadausfallpaket und sendet dieses Paket zu der Quelle zurück.
  • Das Pfadausfallpaket spezifiziert, dass der ausgefallene Anschluss für zukünftige Paketpfade nicht verwendet werden sollte (zumindest, bis der Pfad wieder funktioniert), und weist einen Paketkopf auf, der auf den Eingabe- und Ausgabeanschlüssen des Weiterleitungskopfs des ursprünglichen Datenpakets basiert. Speziell bestimmt das Weiterleitungselement mit dem ausgefallenen Anschluss unter Verwendung des Paketkopfs den Pfad von dem Quellen-Endpunkt zu dem speziellen Weiterleitungselement und erzeugt ein Pfadausfallpaket mit einem Kopf, der den umgekehrten Pfad spezifiziert. Der Kopf des Pfadausfallpakets verwendet den Eingabeanschluss, an welchem das spezielle Weiterleitungselement das Datenpaket empfangen hat, als seinen anfänglichen Ausgabeanschluss (und den ausgefallenen Anschluss als den anfänglichen „Eingabeanschluss“) und vertauscht dann die Eingabeanschlüsse mit den Ausgabeanschlüssen für jedes folgende Weiterleitungselement in umgekehrter Reihenfolge zu dem Datenpaketkopf. Die Ausgangsanschlüsse (und Eingangsanschlüsse, falls durch den Quellen-Endpunkt ausgefüllt) von Weiterleitungselementen, die von dem anfänglichen Datenpaket nicht erreicht wurden, werden für den Kopf des Pfadausfallpakets verworfen.
  • In einigen Ausführungsformen erzeugt ein Paketerzeugungs-Schaltungssystem in dem Weiterleitungselement ein neues Paket mit der Pfadausfallmeldung und der umgekehrten Pfadspezifikation, während in anderen Ausführungsformen die Datenebene das Pfadausfallpaket direkt aus dem Datenpaket erzeugt. Im letzteren Fall werden in einigen Ausführungsformen die Nutzdaten und etwaige interne Paketköpfe des Datenpakets entfernt (welche von dem Weiterleitungselement alle als Nutzdaten behandelt werden, an denen kein Parsing durchgeführt wird), wobei das Pfadausfallpaket nur den Paketkopf für den Pfad und eine Meldung umfasst, dass es sich um eine Ausfallmeldung handelt.
  • Dieses Pfadausfallpaket durchläuft den umgekehrten Pfad, wobei jedes Weiterleitungselement an dem Paketkopf ein Parsing durchführt und das Paket auf dieselbe Weise weiterleitet wie ein Datenpaket. Wenn der Netzwerk-Endpunkt (die Quelle des ursprünglichen Datenpakets) das Pfadausfallpaket empfängt, aktualisiert dieser Netzwerk-Endpunkt seine Netzwerktopologie. Außerdem sendet der Netzwerk-Endpunkt in einigen Ausführungsformen eine Meldung an die Netzwerksteuerungen, um den Steuerungen den nicht-funktionsfähigen Anschluss zu melden. In anderen Ausführungsformen ist der Netzwerk-Endpunkt nicht verantwortlich dafür, die Netzwerksteuerungen zu benachrichtigen (welchen vorübergehende Netzwerkänderungen nicht gemeldet werden müssen). In solchen Ausführungsformen wird den Netzwerksteuerungen der nicht-betriebsfähige Anschluss durch einen langsameren Netzwerk-Überwachungsmechanismus gemeldet (z.B. durch Senden von Heartbeat-Meldungen).
  • Zusätzlich zu Weiterleitungsbefehlen (d.h. Eingabe- und Ausgabeanschlüssen) ist das Weiterleitungselement einiger Ausführungsformen dafür konfiguriert, ein Parsing an weiteren Typen von Befehlen durchzuführen und diese auszuführen. In einigen Ausführungsformen ist das Weiterleitungselement dafür konfiguriert, zu der Zeit, wenn die Netzwerkweiterleitungs-IC ein Bootstrapping durchläuft, eine Gruppe von Handlungskennungen zu erkennen und entsprechende Handlungen auszuführen (obwohl in einigen solchen Ausführungsformen auch Änderungen an dieser Konfiguration während der Laufzeit möglich sind). Diese Handlungen können in verschiedenen Ausführungsformen Lesen von Statuswerten und Einbetten der Statuswerte in den Paketkopf, Erzeugen und Senden eines neuen Pakets usw. umfassen.
  • In einigen Ausführungsformen umfasst ein Paketkopf Gruppen von Handlungen, die für einige oder alle der Weiterleitungselemente entlang dem Pfad des Pakets spezifiziert sind. Jede Handlung umfasst eine Handlungskennung und eine Gruppe von null oder mehr Argumenten für die Handlungen (z.B. Anschlüsse, durch welche ein Paket zu senden ist, Warteschlangen, für welche der Warteschlangenstatus zu lesen ist usw.). Jede Handlung entspricht einer Weiterleitungselement-Kennung, die anzeigt, dass ein spezielles Weiterleitungselement dafür konfiguriert ist, diese Handlung durchzuführen. In einigen Ausführungsformen ist das Ausgeben des Pakets an einen speziellen Anschluss als eine der Handlungen aufgelistet, während in anderen Ausführungsformen die Liste von Eingabe- und Ausgabeanschlüssen, welche den Paketpfad definieren, von der Liste von auszuführenden Handlungen für die Weiterleitungselemente getrennt ist. Nach dem Empfang eines Pakets führt das Weiterleitungselement einiger Ausführungsformen ein Parsing an dem Paket durch, um die Handlungen zu identifizieren, die für dieses Weiterleitungselement spezifiziert sind. Das Weiterleitungselement führt dann diese Handlungen in der Reihenfolge aus, die innerhalb des Paketkopfs spezifiziert ist (wenn z.B. die Handlungen aufeinander folgend aufgelistet sind).
  • Diese Handlungen können in verschiedenen Ausführungsformen in ihrer Komplexität variieren. Beispielsweise könnten die Handlungen Lesen von Weiterleitungselement-Zuständen (z.B. Warteschlangenzuständen) und Schreiben der Zustandswerte in den Paketkopf umfassen. Speziell könnte eine Handlungskennung einem Lesen der Datenmenge in einer Warteschlange und einem Speichern dieses Werts in dem Paketkopf entsprechen, während das Argument für diese Handlung die spezielle zu lesende Warteschlange spezifizieren würde. Komplexere Handlungen könnten ein Durchführen eines Überlastungsausgleichs zwischen einer Gruppe von spezifizierten Warteschlangen umfassen.
  • Die Fähigkeit der Weiterleitungselemente, diese Handlungen durchzuführen und den Netzwerk-Endpunkten Statusdaten bereitzustellen, ermöglicht diesen Endpunkten, diese Daten bei der Bestimmung der Pfadauswahl zu nutzen. In einigen Ausführungsformen verfolgt jeder der Netzwerk-Endpunkte die Warteschlangen-Überlastungszustände für jede Warteschlange jedes der Weiterleitungselemente in dem Netzwerk und kann Datenpakete auf andere Pfade umleiten, wenn die Warteschlangen für diese Datenpakete in einem speziellen Weiterleitungselement zu überlastet sind. Die Netzwerk-Endpunkte können im Ergebnis ein Multipathing (z.B. ECMP) für ein gegebenes Weiterleitungselement durchführen, indem sie Datenströme über mehrere verschiedene Pfade verteilen, die von diesem Weiterleitungselement weg führen. Außerdem können Netzwerk-Endpunkte als Überwachungsvorrichtungen fungieren, indem sie Daten (z.B. einen Warteschlangenstatus oder andere Daten) von Weiterleitungselementen anfordern und diese Daten evaluieren, sobald sie von dem Weiterleitungselement empfangen werden.
  • Ein mögliches Problem bei der Bereitstellung dieses Funktionalitätsniveaus für die Netzwerk-Endpunkte ist, dass ein beeinträchtigter Netzwerk-Endpunkt viel Leistung über den Betrieb des Netzwerks aufweist. In einem herkömmlichen Netzwerk weisen die Weiterleitungselemente ihre eigenen Zugangssteuerungslisten(Access Control List, ACL)-Regeln auf, mit denen geprüft werden kann, ob Pakete verworfen werden sollten. Ein Weiterleitungselement, welches nur Handlungen vornimmt, die von den Netzwerk-Endpunkten spezifiziert werden, anstatt Zuordnungsoperationen durchzuführen, weist jedoch keine solchen ACL-Regeln auf.
  • Wenn der Netzwerk-Endpunkt vollständig vertrauenswürdig ist (z.B. im Fall eines sicheren Hypervisor-Netzwerkstapels), dann ist dies kein Problem. Um jedoch in einigen Ausführungsformen sicherzustellen, dass bösartige Endpunkte ein Netzwerk nicht beeinträchtigen können, verifizieren die Weiterleitungselemente die ACL-Regeln unter Verwendung eines gemeinsamen Geheimnisses zwischen den Netzwerksteuerungen und den Weiterleitungselementen (oder separater gemeinsamer Geheimnisse zwischen den Steuerungen und jedem der Weiterleitungselemente).
  • Speziell ist der Quellen-Netzwerk-Endpunkt in einigen Ausführungsformen für ein Evaluieren jedes Pakets gegen einen Satz von ACL-Regeln verantwortlich, welchen der Netzwerk-Endpunkt von der Gruppe von Netzwerksteuerungen empfängt. Die Netzwerksteuerungen einiger Ausführungsformen stellen jedem der Netzwerk-Endpunkte den Satz von ACL-Regeln (welche für unterschiedliche Netzwerk-Endpunkte unterschiedlich sein können) sowie einen vorberechneten Hashwert für jede der ACL-Regeln bereit. Der vorberechnete Hashwert wird von der Netzwerksteuerung für jede ACL-Steuerung unter Verwendung eines geheimen Schlüssels (z.B. mit einer Hashfunktion) erzeugt, auf welchen die Netzwerk-Endpunkte keinen Zugriff haben.
  • Der Quellen-Netzwerk-Endpunkt für ein Paket evaluiert das Paket gegen den Satz von ACL-Regeln, um zu bestimmen, ob das Paket zulässig ist (z.B. basierend auf der Quellen- und/oder Zieladresse des Pakets). Wenn die passende ACL-Regel der höchsten Priorität ermöglicht, dass das Paket durch das Netzwerk gesendet wird, dann hängt der Quellen-Netzwerk-Endpunkt diese ACL-Regel an das Paket an, zusammen mit dem vorberechneten Hashwert für die ACL-Regel von den Netzwerksteuerungen.
  • Nach dem Empfang eines Pakets verifiziert das Weiterleitungselement einiger Ausführungsformen sowohl (i), dass die ACL-Regel zu dem Hashwert passt, und (ii), dass die ACL-Regel eine korrekte ACL-Regel für das Paket ist. Wenn die ACL-Regel diese beiden Prüfungen besteht, dann setzt das Weiterleitungselement die Verarbeitung des Pakets fort (z.B. durch Weiterleiten des Pakets, Durchführen weiterer Handlungen, die in dem Paketkopf spezifiziert sind). Wenn jedoch die ACL-Regel eine der Prüfungen nicht besteht, dann verwirft in einigen Ausführungsformen das Weiterleitungselement das Paket unter der Voraussetzung, dass das Paket entweder von einem beeinträchtigten Netzwerk-Endpunkt oder von einem unzulässigen Netzwerk-Endpunkt gesendet ist. In ähnlicher Weise verwirft das Weiterleitungselement in einigen Ausführungsformen ebenfalls das Paket, wenn das Paket keine angehängte ACL-Regel aufweist.
  • Um zu verifizieren, dass die ACL-Regel zu dem Hashwert passt, verwendet das Weiterleitungselement einiger Ausführungsformen den von der Netzwerksteuerung empfangenen geheimen Schlüssel, um einen neuen Hashwert aus der ACL-Regel zu berechnen. In einigen Ausführungsformen umfasst diese Berechnung Anwenden eines Hashfunktion auf die ACL-Regel mit dem geheimen Schlüssel. Das Weiterleitungselement vergleicht dann den berechneten Hashwert mit dem an das Paket angehängten Hashwert und verifiziert, dass diese zueinander passen. Wenn der Hashwert nicht passt, wird dadurch angezeigt, dass der Quellen-Netzwerk-Endpunkt die ACL-Regel nicht von der Netzwerksteuerung empfangen hat (z.B., weil der Netzwerk-Endpunkt kein verifizierter Endpunkt für das Netzwerk ist).
  • Um zu verifizieren, dass die ACL-Regel eine korrekte ACL-Regel für das Paket ist, vergleicht das Weiterleitungselement einiger Ausführungsformen die Paketkopfwerte (z.B. IP- und/oder MAC-Adressen usw.), für welche die ACL-Regel spezifiziert, dass sie für das Paket erforderlich sind, mit den tatsächlichen Kopfwerte des Pakets. Dies erfordert in einigen Ausführungsformen nicht die Verwendung einer Vergleichstabellenlogik, da das Weiterleitungselement diese Werte einfach aus der ACL-Regel entnehmen muss und die entsprechenden Werte aus dem Paketkopf entnehmen muss und die beiden Wertesätze vergleichen muss. Einige Ausführungsformen erfordern, dass die ACL-Regeln in einer speziellen Weise strukturiert sind, so dass der Parser oder andere Komponenten des Weiterleitungselements die erforderlichen Paketkopfwerte oder -wertebereiche identifizieren können. Wenn die Paketkopfwerte nicht zu denen passen, die von der ACL-Regel gefordert werden, dann zeigt dies, dass der Quellen-Netzwerk-Endpunkt eine ungültige ACL-Regel an das Paket angehängt hat (z.B., weil der Quellen-Endpunkt beeinträchtigt ist) und das Paket verworfen werden sollte.
  • Um zu verhindern, dass ein beeinträchtigter Netzwerk-Endpunkt eine Regel höherer Priorität übergeht, welche ein Paket ablehnt, und eine Regel niedrigerer Priorität verwendet, welche das Paket zulässt (was für das Weiterleitungselement wie eine gültige und korrekte ACL-Regel aussehen würde), flachen die Netzwerksteuerungen einiger Ausführungsformen den Satz von ACL-Regeln ab (wodurch sichergestellt wird, dass es keine Überlappungen in dem Regelraum gibt), bevor die ACL-Regeln und die Hashwerte den Netzwerk-Endpunkten bereitgestellt werden. In anderen Ausführungsformen kann der Satz von ACL-Regeln überlappend sein, fungiert aber im Ergebnis als eine Positivliste. Das heißt, die Netzwerksteuerung stellt Regeln (welche sich überlappen können) für alle zulässigen Pakete und eine einzelne Regel niedrigerer Priorität bereit, welche alle anderen Pakete ablehnt.
  • In einigen Ausführungsformen ist das Netzwerk so eingerichtet, dass jeder Netzwerk-Endpunkt nur mit einem der Weiterleitungselemente des Netzwerks verbunden ist (obwohl ein gegebenes Weiterleitungselement mehrere verbundene Netzwerk-Endpunkte aufweisen kann). In diesem Fall weist in einigen Ausführungsformen jedes Weiterleitungselement seinen eigenen geheimen Schlüssel auf, der nur diesem Weiterleitungselement und den Netzwerksteuerungen bekannt ist. Die Hashwerte, die einem speziellen Netzwerk-Endpunkt mit den ACL-Regeln bereitgestellt werden, werden unter Verwendung des geheimen Schlüssels des Weiterleitungselements berechnet, mit welchem der Netzwerk-Endpunkt verbunden ist, und dieses Weiterleitungselement ist dann für das Verifizieren der ACL-Regeln verantwortlich, die von diesem Netzwerk-Endpunkt gesendet werden. In einigen solchen Ausführungsformen leitet nach dem Verifizieren der ACL-Regel für ein Paket das Weiterleitungselement das Paket weiter, ohne dass die ACL-Regel angehängt ist. In anderen Ausführungsformen wird für jedes der Weiterleitungselemente derselbe geheime Schlüssel verwendet. In einigen solchen Ausführungsformen werden die ACL-Regeln durch jedes Weiterleitungselement in dem Netzwerk verifiziert, während in anderen solchen Ausführungsformen nur das First-Hop-Weiterleitungselement die ACL-Regeln verifiziert.
  • Die vorstehende Kurzdarstellung soll als eine kurze Einführung in einige Ausführungsformen der Erfindung dienen. Sie soll keine Einführung oder Übersicht über den gesamten erfinderischen Gegenstand sein, der in diesem Dokument offenbart wird. Die folgende detaillierte Beschreibung und die Zeichnungen, auf die in der detaillierten Beschreibung Bezug genommen wird, beschreiben die in der Kurzdarstellung beschriebenen Ausführungsformen weiter, ebenso wie andere Ausführungsformen. Entsprechend ist, um alle Ausführungsformen zu verstehen, die in diesem Dokument beschrieben werden, eine vollständige Durchsicht der Kurzdarstellung, der detaillierten Beschreibung und der Zeichnungen erforderlich. Außerdem soll der beanspruchte Gegenstand nicht durch die veranschaulichenden Einzelheiten in der Kurzdarstellung, der detaillierten Beschreibung und den Zeichnungen beschränkt werden, sondern soll stattdessen durch die anhängenden Patentansprüche definiert werden, da der beanspruchte Gegenstand in anderen speziellen Formen verkörpert sein kann, ohne von der Idee des Gegenstands abzuweichen.
  • Figurenliste
  • Die neuen Merkmale der Erfindung werden in den anhängenden Patentansprüchen angeführt. Zu Erläuterungszwecken werden jedoch in den folgenden Figuren verschiedene Ausführungsformen angeführt.
    • 1 veranschaulicht konzeptionell ein Beispiel eines typischen Weiterleitungselements 100 mit einem komplexen Weiterleitungselement-Betriebssystem.
    • 2 veranschaulicht konzeptionell ein Beispiel eines Hardware-Weiterleitungselements einiger Ausführungsformen.
    • 3 veranschaulicht konzeptionell ein Netzwerk einiger Ausführungsformen, welches eine Gruppe einer oder mehrerer Netzwerksteuerungen, zahlreiche Weiterleitungselemente (Forwarding Elements, FEs), welche das Grundgerüst des Netzwerks bilden, und Netzwerk-Endpunkte umfasst.
    • 4 veranschaulicht konzeptionell ein Verfahren einiger Ausführungsformen, welches zum Verarbeiten von Weiterleitungspfad-Paketköpfen durchgeführt wird.
    • 5 veranschaulicht konzeptionell ein Paket, welches durch ein Netzwerk von HFEs von einem Netzwerk-Endpunkt an einen anderen Netzwerk-Endpunkt gesendet wird.
    • 6A-B veranschaulichen konzeptionell ein Beispiel für das Erzeugen und Senden eines Pfadausfallpakets in dem Netzwerk der 5 und ein anschließendes Anpassen durch den Quellen-Netzwerk-Endpunkt.
    • 7 veranschaulicht konzeptionell ein Verfahren einiger Ausführungsformen zum Erzeugen eines Pfadausfallpakets aus einem Datenpaket, welches nicht aus seinem spezifizierten Ausgabeanschluss gesendet werden kann.
    • 8 veranschaulicht konzeptionell ein Verfahren einiger Ausführungsformen zum Durchführen eines Parsing an einem Paketkopf und zum Ausführen von Befehlen, welche in dem Paketkopf spezifiziert sind.
    • 9 und 10 veranschaulichen konzeptionell zwei verschiedene Konstruktionen für die Paketköpfe einiger Ausführungsformen.
    • 11 veranschaulicht konzeptionell ein HFE, welches eine Handlung ausführt, um einen Warteschlangen-Tiefenwert an ein Datenpaket anzuhängen.
    • 12 veranschaulicht ein Beispiel eines Abfragepakets, welches von einem Netzwerk-Endpunkt speziell gesendet wird, um einen speziellen Statuswert eines HFE zu bestimmen und diesen Status zu dem Netzwerk-Endpunkt zurücksenden zu lassen.
    • 13 veranschaulicht konzeptionell die Struktur der HFE-Datenebene einiger Ausführungsformen.
    • 14 veranschaulicht konzeptionell weitere Einzelheiten über die Paketverarbeitungsoperationen einer Paketverarbeitungs-Pipeline einiger Ausführungsformen.
    • 15 veranschaulicht konzeptionell ein Beispiel eines Netzwerks mit einer Netzwerksteuerung, welche ACL-Regeln an die Netzwerk-Endpunkte und geheime Schlüssel an die Hardware-Weiterleitungselemente verteilt.
    • 16 veranschaulicht konzeptionell ein Verfahren einiger Ausführungsformen zum Verifizieren einer ACL-Regel, die an ein Paket angehängt ist.
    • 0044] 17 veranschaulicht konzeptionell die Handlungsausführungsmaschine eines HFE, welches eine ACL-Hashwert-Verifikation durchführt.
    • 0045] 18 veranschaulicht konzeptionell die Handlungsausführungsmaschine, welche eine ACL-Regel-Verifikation für das Paket durchführt.
    • 19 veranschaulicht konzeptionell ein elektronisches System, mit welchem einige Ausführungsformen der Erfindung realisiert werden.
  • DETAILLIERTE BESCHREIBUNG
  • Einige Ausführungsformen der Erfindung stellen ein Hardware-Weiterleitungselement (HFE) ohne Steuerebenenlogik in einem Netzwerk bereit, welches die Steuerebenenlogik zu den Netzwerk-Endpunkten (z.B. virtuellen Maschinen, Virtualisierungs-Software-Netzwerkstapel usw.) schiebt. Das HFE einiger Ausführungsformen umfasst eine Netzwerk-Weiterleitungs-IC (integrierte Schaltung) zum Vornehmen eines Paket-Parsing und zur Ausführung von Handlungen (aber ohne die Übereinstimmungslogik zum Durchführen von L2-Schalten oder L3-Routing) und eine Minimal-CPU. Ein Weiterleitungselement-Betriebssystem (OS) läuft auf der CPU ab, um ein Bootstrapping an der Netzwerk-Weiterleitungs-IC durchzuführen (z.B. die IC mit einer anfänglichen Konfiguration zu versehen), interagiert jedoch während des Standardverlaufs der Paketverarbeitung nicht mit der Netzwerk-Weiterleitungs-IC.
  • 2 veranschaulicht konzeptionell ein Beispiel eines solchen HFE 200. Wie dargestellt, umfasst das HFE 200 wie das HFE 100 eine Paketverarbeitungsplatine 205 und eine CPU-Platine 210. Die Paketverarbeitungsplatine 205 umfasst eine Netzwerk-Weiterleitungs-IC 215 (oder mehrere solche ASICs) und eine Gruppe von Netzwerk-Schnittstellen 220. Die CPU-Platine 210 umfasst eine Minimal-CPU 225 (gegebenenfalls mit DRAM) sowie verschiedene andere Plattformvorrichtungen 230 (z.B. ein Gebläse, Sensoren usw.).
  • In diesem Fall jedoch ist das Weiterleitungselement-OS 235 weit mehr minimal. Da die Netzwerk-Weiterleitungs-IC 215 keine Übereinstimmungslogik benötigt (es z.B. keine Weiterleitungstabellen gibt, welche einen Ausgabeanschluss auswählen, basierend auf MAC- oder IP-Adressen), ist in dem OS 235 keine Steuerebene notwendig. Das Minimal-OS 235 umfasst immer noch einen Kern 240, eine Boot-Ladeeinheit 245, Treiber oder andere Verwaltungs-Software 250 zum Verwalten der verschiedenen Vorrichtungen 230 und eine Benutzerschnittstelle 255 zum Empfangen einer Anfangskonfiguration.
  • Anstatt eine vollständige Datenebenenabstraktion zu benötigen, welche mehrere Stufen von Übereinstimmungstabellen modelliert, ist die Datenebenen-Anfangskonfiguration 260 eine Konfiguration, welche auf die Netzwerk-Weiterleitungs-IC 215 geladen werden kann, wenn die IC 215 anfänglich bootet, und welche während der Laufzeit nicht geändert werden muss. Im Fall des Hardware-Weiterleitungselements 200 kann die Netzwerk-Weiterleitungs-IC 205 nach dem anfänglichen Bootstrapping im Wesentlichen von der CPU entkoppelt werden und ist in der Lage, allein zu arbeiten.
  • Das HFE einiger Ausführungsformen arbeitet in einem Netzwerk, welches eine Gruppe von einer oder mehreren Netzwerksteuerungen, zahlreiche Weiterleitungselemente (Fes), welche das Grundgerüst des Netzwerks bilden (in diesem Fall als HFEs dargestellt), und Netzwerk-Endpunkte umfasst. 3 veranschaulicht konzeptionell ein solches Netzwerk 300. Wie dargestellt, umfasst das Netzwerk 300 eine Gruppe von zentralisierten Netzwerksteuerungen 305, eine Gruppe von HFEs 310 und eine Gruppe von Netzwerk-Endpunkten 315.
  • Die Netzwerksteuerungen 305 speichern eine stationäre Netzwerktopologie, welche die Steuerungen an die Netzwerk-Endpunkte 315 verteilen, wen diese Endpunkte als Teil eines anfänglichen Bootstrapping-Verfahrens für die Endpunkte erstmals zugeschaltet werden. Die stationäre Netzwerktopologie umfasst in einigen Ausführungsformen jedes der HFEs 310 in dem Netzwerk und die Verbindungen zwischen den HFEs, einschließlich Anschlusskennungen für jede Verbindung zwischen HFEs. Außerdem umfasst die stationäre Netzwerktopologie in einigen Ausführungsformen die Netzwerk-Endpunkte 315 und deren Verbindungen mit den HFEs 310. Die stationäre Netzwerktopologie kann weitere Daten umfassen, z.B. die Fähigkeiten jedes der HFEs, Anschluss- und Warteschlangenabbildungen von physisch auf logisch für die HFEs usw. Die von der Netzwerksteuerung gespeicherte stationäre Topologie wird regelmäßig aktualisiert, wenn Weiterleitungselemente und/oder Netzwerk-Endpunkte zu dem Netzwerk 300 hinzukommen und dieses verlassen, berücksichtigt aber keine vorübergehenden Änderungen (z.B. Anschlüsse und/oder HFEs, welche ausfallen und schnell wieder funktionieren). Wie nachstehend weiter beschrieben, speichern die Netzwerk-Endpunkte 315 die vorübergehende Netzwerktopologie, welche auf viel schnellerer Basis aktualisiert wird als die stationäre Netzwerktopologie.
  • In einigen Ausführungsformen weisen die Netzwerksteuerungen 305 eine Master-Steuerung auf, welche für das Speichern einer Master-Kopie der stationären Netzwerktopologie verantwortlich ist. Die Master-Steuerung ist außerdem für das Verteilen der Topologie an neue Netzwerk-Endpunkte verantwortlich. In einigen solchen Ausführungsformen teilt die Master-Steuerung den Topologie-Status mit den anderen (Si-cherungs-)Netzwerksteuerungen und diese Steuerungen können außerdem dabei helfen, den Netzwerk-Status zu bewahren (z.B. durch regelmäßiges Verifizieren, dass die HFEs in dem Netzwerk vorhanden sind). In einigen Ausführungsformen ist jede der Netzwerksteuerungen 305 mit einem der Weiterleitungselemente 310 verbunden.
  • Die HFEs 310 bilden das Grundgerüst des Netzwerks 300, wobei sie die Netzwerk-Endpunkte 315 miteinander und mit den Netzwerksteuerungen 305 verbinden. In einigen Ausführungsformen ist das Netzwerk 300 ein eingegrenztes Netzwerk (z.B. innerhalb eines Datencenters) und es gibt keine zwischengeschalteten Weiterleitungselemente, welche nicht auf dieselbe (oder ähnliche) Weise konfiguriert sind. In einigen solchen Ausführungsformen handelt es sich bei einer Untergruppe der Netzwerk-Endpunkte 315 um Gateways, welche Verbindungen für das Netzwerk 300 mit externen Netzwerken (z.B. dem Internet) bereitstellen. In anderen Ausführungsformen überspannt das Netzwerk 300 mehrere Datencenter und einige der HFEs 310 sind dafür konfiguriert, Pakete über die zwischengeschalteten Netzwerke zwischen den Datencentern zu tunneln. Die HFEs 310 sind in einigen Ausführungsformen jene, die oben in Bezug auf 2 beschrieben werden, mit Minimal-CPU und ohne eine Steuerebene. Es sollte auch angemerkt werden, dass, obwohl hier und in der folgenden Beschreibung HFEs dargestellt sind (z.B. HFEs, wie unter Bezugnahme auf 2 beschrieben), in einigen Ausführungsformen andere Weiterleitungselemente (z.B. Software-Weiterleitungselemente) einige Aspekte der Erfindung ausführen können.
  • Die HFEs 310 sind dafür konfiguriert, an verschiedenen Typen von Paketen ein Parsing durchzuführen und sie zu verarbeiten. Datenpakete, die von den Netzwerk-Endpunkten 315 erzeugt werden, umfassen Weiterleitungsbefehle sowie andere Handlungen, die von den HFEs auszuführen sind. Außerdem erzeugen die HFEs 310, um die Netzwerk-Endpunkte 315 zu informieren, wenn eine Verbindung ausgefallen ist (z.B., weil ein Anschluss des HFE nicht mehr funktioniert, ein Anschluss eines anderen HFE oder das gesamte HFE nicht mehr funktioniert usw.), Pfadausfallpakete, die an die Netzwerk-Endpunkte gerichtet sind. In einigen Ausführungsformen erzeugt nach dem Empfang eines Pakets, welches für das HFE spezifiziert, das Paket aus einem Anschluss in Richtung einer Verbindung zu senden, die ausgefallen ist, dieses HFE ein Pfadausfallpaket mit dem umgekehrten Pfad des empfangenen Pakets. Außerdem handhaben die HFEs Bootstrapping-Pakete von Netzwerksteuerungen und/oder Netzwerk-Endpunkten, wenn diese Einheiten dem Netzwerk hinzugefügt werden.
  • Die Netzwerk-Endpunkte 315 betreiben in einigen Ausführungsformen die Steuerebene (anstatt dass die Steuerebene an den HFEs 310 betrieben wird) und speichem die vorübergehende Netzwerktopologie. Diese Netzwerk-Endpunkte können virtuelle Maschinen sein, welche außerdem Anwendungen ausführen, die die Quellen und Ziele für Datenverkehr sind, Hypervisor-Netzwerkstapel einer physischen Host-Maschine (welche z.B. virtuelle Maschinen und/oder Container beherbergt, welche die Quellen und Ziele für Datenverkehrt sind, usw.). Außerdem umfassen die Netzwerk-Endpunkte, wie erwähnt, in einigen Ausführungsformen Netzwerk-Gateways, welche mit externen Netzwerken Pakete austauschen.
  • Die vorübergehende Netzwerktopologie umfasst die aktuellsten Änderungen an dem tatsächlichen Netzwerk. Während die stationäre Netzwerktopologie, die von den Netzwerksteuerungen 305 gespeichert wird, den gewünschten Netzwerkstatus repräsentiert und relativ langsam aktualisiert wird, repräsentiert die vorübergehende Netzwerktopologie den aktuellsten tatsächlichen Netzwerkstatus und wird viel schneller aktualisiert (z.B. nach jedem Paket, falls möglich). Die vorübergehende Netzwerktopologie basiert auf der stationären Netzwerktopologie, die dann in einigen Ausführungsformen basierend auf Informationen von den HFEs 310 aktualisiert wird.
  • Um Datenpakete durch das Netzwerk zu senden, verwenden die Netzwerk-Endpunkte 315 die Steuerebene, um Paketköpfe zu erzeugen, welche Pfade durch die HFEs 310 für die Datenpakete gemäß der vorübergehenden Netzwerktopologie spezifizieren. Die Paketköpfe können in einigen Ausführungsformen auch andere Handlungen umfassen, die von den HFEs 310 vorzunehmen sind. Wie erwähnt, verwenden die HFEs 310 keine Steuerebene und treffen somit keine Entscheidungen für Datenpakete, die durch das Netzwerk gesendet werden. Stattdessen ist jedes HFE 310 dafür konfiguriert, Datenpakete zu empfangen, an diesen Paketen ein Parsing durchzuführen, um vorzunehmende Handlungen (Weiterleitung oder sonstiges) zu identifizieren und diese innerhalb des Paketkopfs spezifizierten Handlungen auszuführen.
  • Wie erwähnt, sind die HFEs dafür konfiguriert, an verschiedenen Typen von Paketen ein Parsing durchzuführen und sie zu verarbeiten, einschließlich Bootstrapping-Paketen zum Hinzufügen eines neuen Netzwerk-Endpunkts. Außerdem handhaben die HFEs Bootstrapping-Pakete von Netzwerksteuerungen und/oder Netzwerk-Endpunkten, wenn diese Einheiten dem Netzwerk hinzugefügt werden. Wenn ein neuer Netzwerk-Endpunkt zu dem Netzwerk hinzugefügt wird, sendet dieser Netzwerk-Endpunkt in einigen Ausführungsformen ein Bootstrapping-Paket an sein First-Hop-HFE (d.h., an das HFE, mit welchem der Netzwerk-Endpunkt direkt verbunden ist). Die Bootstrapping-Pakete einiger Ausführungsformen weisen einen speziellen Kopf auf, welcher sie als solche Pakete ausweist (im Gegensatz zu Daten- oder Ausfallsicherungspaketen). Wenn ein HFE ein Bootstrapping-Paket empfängt, flutet das HFE in einigen Ausführungsformen an alle seine Anschlüsse (außer dem Anschluss, an dem das Paket empfangen wurde) oder an eine vorab definierte Untergruppe seiner Anschlüsse. Außerdem zeichnet das HFE in einigen Ausführungsformen seine Eingabe- und Ausgabeanschlüsse in dem Paketkopf jeder Kopie des Pakets auf (der Eingabeanschluss ist für jede Kopie derselbe). Jedes HFE führt die gleiche Flutungsoperation durch, bis alle Netzwerk-Endpunkte und die Netzwerksteuerungen das Bootstrapping-Paket empfangen haben (und mit ihm den Pfad zurück zu dem Netzwerk-Endpunkt). In einigen Ausführungsformen führt jedes HFE außerdem eine Prüfung durch, um zu verifizieren, dass es dieses Bootstrapping-Paket nicht bereits zuvor empfangen hat. Wenn das HFE das Paket bereits zuvor empfangen hat, verwirft es diese Kopie des Pakets. Wenn eine Netzwerksteuerung das Bootstrapping-Paket empfängt, kennt die Netzwerksteuerung den Pfad zurück zu dem neuen Netzwerk-Endpunkt und kann deswegen diesem Netzwerk-Endpunkt die vollständige stationäre Netzwerktopologie über diesen Pfad senden. Dieser Pfad kann auch für herkömmliche Bootstrapping-Anforderungen verwendet werden, wie z.B. DHCP (wobei die Netzwerksteuerungen als die DHCP-Server für die Netzwerk-Endpunkte fungieren).
  • Die HFEs einiger Ausführungsformen sind außerdem dafür konfiguriert, Datenpakete zu verarbeiten, die von einem Netzwerk-Endpunkt an einen anderen gesendet werden, indem sie ein Parsing an den Paketköpfen durchführen, die von dem Netzwerk-Endpunkt hinzugefügt werden, um zu bestimmen, wie die Pakete weiterzuleiten sind. Für Datenpakete, die von einem Netzwerk-Endpunkt an einen anderen gesendet werden, fügt in einigen Ausführungsformen der Quellen-Netzwerk-Endpunkt einen Paketkopf zu dem Paket hinzu, welcher den Pfad durch die Weiterleitungselemente spezifiziert.
  • 4 veranschaulicht konzeptionell ein Verfahren 400 einiger Ausführungsformen, welches zum Verarbeiten von Weiterleitungspaketköpfen durchgeführt wird. Das Verfahren 400 wird von einem HFE einiger Ausführungsformen durchgeführt, um ein Datenpaket weiterzuleiten, das von dem HFE empfangen wird. Dieses Verfahren wird zum Teil unter Bezugnahme auf 5 und 6A-B beschrieben, welche Datenpaket-Weiterleitungsköpfe durch ein Netzwerk von HFEs veranschaulichen.
  • Wie dargestellt, beginnt das Verfahren 400 (bei 405) durch Empfangen eines Datenpakets an einem ersten Anschluss eines HFE (dem Eingabeanschluss für das Paket). In einigen Ausführungsformen umfasst jedes der HFEs mehrere Anschlüsse, durch welche Pakete empfangen und gesendet werden. 5 veranschaulicht konzeptionell ein Paket, welches von einem Netzwerk-Endpunkt 505 durch ein Netzwerk 500 von HFEs 515 bis 535 an einen anderen Netzwerk-Endpunkt 510 gesendet wird. Wie dargestellt, umfasst jedes der HFEs 515 bis 535 mindestens zwei Anschlüsse, welche mit anderen HFEs oder Netzwerk-Endpunkten verbunden sein können. Diese Anschlüsse sind in der Figur für jedes der HFEs nummeriert und werden in einigen Ausführungsformen durch Anschlusskennungen repräsentiert. In einigen Ausführungsformen können HFE-Anschlüsse auch mit Netzwerksteuerungen verbunden sein, welche in dieser Figur nicht dargestellt sind.
  • In dem Verfahren 400 wird (bei 410) ein Parsing an dem Paketkopf des Pakets durchgeführt, um einen Weiterleitungspfad mit Weiterleitungsbefehlen für das HFE zu identifizieren. Jedes Datenpaket, das durch das Netzwerk gesendet wird, umfasst das innere Paket (z.B. Nutzdaten sowie herkömmliche L2-L4-Köpfe) sowie den von dem Netzwerk-Endpunkt erzeugten Paketkopf, welcher den Pfad für das Paket durch das Netzwerk spezifiziert. In einigen Ausführungsformen umfasst dieser Pfad ein Eingabeanschlussfeld und ein Ausgabeanschlussfeld für jedes Weiterleitungselement entlang dem Pfad des Pakets. Unter Verwendung der Netzwerktopologie bestimmt der Quellen-Endpunkt jedes Weiterleitungselement entlang dem Pfad und füllt zumindest die Ausgabeanschlussfelder (und gegebenenfalls auch die Eingabeanschlussfelder) aus. In einigen Ausführungsformen bestimmen die HFEs, welche Gruppe von Eingabe- und Ausgabeanschlüssen zu verwenden ist, basierend auf einem Zähler in dem Paketkopf, der durch jedes Weiterleitungselement heraufgesetzt wird. In anderen Ausführungsformen umfasst jedes Eingabe/Ausgabe-Anschlusspaar in der Liste eine Weiterleitungselement-Kennung, welche die Weiterleitungselemente verwenden, um durch Parsing ihre Weiterleitungsbefehle zu ermitteln.
  • Wie in 5 dargestellt, hängt der Quellen-Netzwerk-Endpunkt 505 eines Pakets 540 einen Paketkopf 545 an dieses Paket an, der von jedem der HFEs 515 bis 530 aktualisiert wird, welches das Paket verarbeitet. Das Paket 540 könnte z.B. ein TCP/IP-Paket mit Nutzdaten sowie Ethernet-, IP- und TCP-Köpfen sein, wobei die HFEs in dem Netzwerk 500 keinen von diesen verarbeiten. Der Paketkopf 545, wie von dem Netzwerk-Endpunkt 505 erzeugt, listet anfänglich Ausgabeanschlüsse für vier HFEs und einen Zähler „[1]“ auf, welcher anzeigt, welche Gruppe von Eingabe- und Ausgabeanschlüssen das nächste HFE verwenden sollte.
  • Wieder zurückkehrend zu 4, wird in dem Verfahren 400 (bei 415) als Nächstes bestimmt, ob der Eingabeanschluss für das HFE durch den Netzwerk-Endpunkt ausgefüllt wurde. Wie in 5 dargestellt, umfasst der Paketkopf 545 keine Eingabeanschlüsse (es sind z.B. lediglich Stellvertrerterzeichen-Werte aufgelistet), wenn er anfänglich von dem Netzwerk-Endpunkt 505 erzeugt wurde.
  • Wenn der Eingabeanschluss nicht ausgefüllt ist, wird in dem Verfahren 400 (bei 420) der erste Anschluss (an welchem das Paket empfangen wurde) als der Eingabeanschluss in den Weiterleitungsbefehlen des Paketkopfs hinzugefügt. In dem Beispiel der 5 füllt jedes der HFEs 515 bis 530, welches den Paketkopf 545 verarbeitet, seinen eigenen Eingabeanschluss aus. Beispielsweise empfängt das erste HFE 515 das Paket an seinem eigenen Anschluss 1, daher ist in dem Paketkopf, den das HFE 515 an das nächste HFE 520 sendet, der Eingabeanschluss mit einem Anschluss für das erste Eingabe/Ausgabe-Anschlusspaar ausgefüllt. In ähnlicher Weise füllt das zweite HFE 520 den zweiten Eingabeanschluss mit seinem eigenen Anschluss 1 aus, und so weiter für die HFEs 525 und 530. Außerdem setzt in diesem Beispiel jedes der HFEs den Zähler herauf, so dass das nächste HFE das richtige Eingabe/Ausgabe-Anschlusspaar verwendet.
  • Als Nächstes wird in dem Verfahren 400 (bei 425) der Ausgabeanschluss, durch welchen das Paket auszugeben ist, aus den Weiterleitungsbefehlen identifiziert, die das Parsing durchlaufen haben. In dem Verfahren wird (bei 430) bestimmt, ob der Ausgabeanschluss betriebsfähig ist. Jedes Weiterleitungselement entlang dem Pfad kennt nur seinen eigenen Status, umfassend, ob seine verschiedenen Verbindungen aktuell funktionsfähig sind. In einigen Ausführungsformen ist, wenn ein Anschluss eines HFE ausfällt (wegen eines Problems mit dem Anschluss selbst, mit dem Anschluss eines anderen HFE, mit dem er verbunden ist, usw.), das HFE dafür konfiguriert, dies in der Datenebene zu erfassen und diesen Anschlussausfallstatus in der Datenebene zu speichern. In einigen Ausführungsformen ist das HFE dafür konfiguriert, den spezifizierten Ausgabeanschluss für ein Paket mit seinem gespeicherten Betriebszustand für den Anschluss (z.B. einem Binärwert, der anzeigt, ob der jeweilige Anschluss funktionsfähig oder ausgefallen ist) zu vergleichen.
  • Wenn der Ausgabeanschluss betriebsfähig ist, wird das Paket in dem Verfahren 400 (bei 435) aus dem spezifizierten Ausgabeanschluss weitergeleitet. In dem Beispiel, das in 5 dargestellt ist, sind alle Anschlüsse der HFEs, die in der Figur dargestellt sind, betriebsfähig, daher durchläuft das Paket 540 erfolgreich das Netzwerk von dem Quellen-Netzwerk-Endpunkt 505 durch die HFEs 515 bis 530 bis zu dem Ziel-Netzwerk-Endpunkt 510. Sobald das Paket an dem Quellen-Netzwerk-Endpunkt 510 ankommt, ist der Zähler auf [5] heraufgesetzt worden und jeder der Eingabeanschlüsse ist ausgefüllt. In einigen Ausführungsformen kann der Ziel-Netzwerk-Endpunkte 510 den Pfad bestimmen, über welchen das Paket gesendet wurde. Wenn jedoch die verwendeten Anschlusskennungen von einem HFE zum anderen überlappen und diese die einzigen Informationen sind, die in dem Paketkopf bereitgestellt werden, dann kann es sein, dass der Ziel-Netzwerk-Endpunkt nicht ausreichend Informationen aufweist, um den Pfad zu bestimmen, der von dem Quellen-Netzwerk-Endpunkt ausgewählt wurde. In einigen Ausführungsformen kann ein erster Netzwerk-Endpunkt Pakete an einen zweiten Netzwerk-Endpunkt unter Verwendung eines anderen Pfades als des Pfades senden, den der zweite Netzwerk-Endpunkt für Pakete in der umgekehrten Richtung verwendet.
  • Wenn der Ausgabeanschluss nicht betriebsfähig ist, wird in dem Verfahren 400 (bei 440) unter Verwendung von Weiterleitungsdaten aus dem Paketkopf ein Pfadausfallpaket erzeugt. Das Pfadausfallpaket einiger Ausführungsformen spezifiziert, dass der ausgefallene Anschluss für zukünftige Paketpfade nicht verwendet werden sollte (zumindest, bis der Pfad wieder funktionsfähig ist), und weist einen Paketkopf auf, der auf den Eingabe- und Ausgabeanschlüssen des Weiterleitungskopfs des ursprünglichen Datenpakets basiert. Speziell bestimmt das Hardware-Weiterleitungselement mit dem ausgefallenen Anschluss unter Verwendung des Paketkopfs den Pfad von dem Quellen-Endpunkt bis zu dem speziellen Weiterleitungselement und erzeugt ein Pfadausfallpaket mit einem Kopf, der den umgekehrten Pfad spezifiziert. Bei dem Pfadausfallpaket-Kopf wird der Eingabeanschluss, an welchem das spezielle Weiterleitungselement das Datenpaket empfangen hat, als sein anfänglicher Ausgabeanschluss verwendet (und der ausgefallene Anschluss als der anfängliche „Eingabeanschluss“) und dann werden für jedes folgende Weiterleitungselement in umgekehrter Reihenfolge gegenüber dem Datenpaketkopf die Eingabeanschlüsse mit den Ausgabeanschlüssen vertauscht. Die Ausgabeanschlüsse (und Eingabeanschlüsse, falls durch den Quellen-Endpunkt ausgefüllt) von Weiterleitungselementen, die von dem ursprünglichen Datenpaket nicht erreicht wurden, werden aus dem Pfadausfallpaket-Kopf entfernt. In dem Verfahren 400 wird (bei 445) das Pfadausfallpaket aus dem ersten Anschluss (dem Eingabeanschluss für das empfangene Datenpaket) herausgeleitet, dann ist das Verfahren beendet.
  • 6A-B veranschaulichen konzeptionell ein Beispiel für das Erzeugen und Senden eines Pfadausfallpakets 600 in dem Netzwerk 500 und ein anschließendes Anpassen durch den Quellen-Netzwerk-Endpunkt 505 über drei Stufen 605 bis 615. Wie in der ersten Stufe 605 dargestellt, ist die Verbindung zwischen den HFEs 525 und 530 aktuell ausgefallen, was von der Datenebene jedes dieser HFEs erfasst worden sein würde. In dieser ersten Stufe sendet der Netzwerk-Endpunkt 505 ein an den Netzwerk-Endpunkt 510 gerichtetes Paket 620 mit einem Paketkopf 625. Der Paketkopf 625 ist der gleiche wie der aus 5 und schreitet auf dieselbe Weise fort, bis er das dritte HFE 525 erreicht. Hier spezifiziert der Paketkopf 625 für das HFE 525, das Paket auf dessen Anschluss 2 zu senden, welcher aktuell ausgefallen ist.
  • Somit erzeugt das HFE 525 in der zweiten Stufe 610 ein Pfadausfallpaket 600 mit dem umgekehrten Pfad des Paketkopfs 625. Wie dargestellt, beginnt der Weiterleitungspfad in dem Pfadausfallpaket 600 mit den Eingabe/Ausgabe-Anschlüssen des HFE 525, wobei die Anschlüsse aus dem Paketkopf 625 vertauscht werden. Dann wird jedes der vorhergehenden Eingabe/Ausgabe-Anschlusspaare in umgekehrter Reihenfolge gegenüber dem Paketkopf 625 ebenfalls vertauscht. Außerdem wird der Zähler auf [2] gesetzt, so dass das HFE 520 die richtige Gruppe von Eingabe/AusgabeAnschlüssen für die Weiterleitung des Pakets verwendet. Dies ermöglicht, dass das Pfadausfallpaket 600 den umgekehrten Pfad zurück zu dem Netzwerk-Endpunkt 505 durchläuft, welcher seine gespeicherte Netzwerktopologie aktualisiert, um die Verbindung zwischen den HFEs 525 und 530 zu entfernen. Die Erzeugung von Pfadausfallpaketen wird nachstehend in Bezug auf 7 detaillierter beschrieben.
  • Außerdem sendet in einigen Ausführungsformen der Netzwerk-Endpunkt 505 eine Meldung an die Netzwerksteuerungen, um den Steuerungen den nichtbetriebsfähigen Anschluss zu melden. In anderen Ausführungsformen sind die Netzwerk-Endpunkte nicht verantwortlich dafür, die Netzwerksteuerungen zu benachrichtigen (welchen vorübergehende Netzwerkänderungen nicht gemeldet werden müssen). In solchen Ausführungsformen wird den Netzwerksteuerungen der nicht-betriebsfähige Anschluss durch einen langsameren Netzwerk-Überwachungsmechanismus gemeldet (z.B. durch Senden von Heartbeat-Meldungen).
  • Die dritte Stufe 615 veranschaulicht, dass der Netzwerk-Endpunkt 505 ein folgendes Paket 630 unter Verwendung eines anderen Pfads an den Ziel- Netzwerk-Endpunkt 510 sendet, wobei es die fehlende Verbindung zwischen den HFEs 520 und 525 berücksichtigt. Der Quellen-Endpunkt 505 hängt einen Paketkopf 635, der ähnlich ist wie der Paketkopf 625, jedoch mit einer anderen Gruppe von Ausgabeanschlüssen, so dass das Paket einem anderen Pfad folgt, um sein Ziel zu erreichen. In einigen Ausführungsformen werden Bootstrapping-Techniken angewendet, um die Netzwerksteuerung und/oder die Netzwerk-Endpunkte zu benachrichtigen, sobald die Verbindung wiederhergestellt ist.
  • In einigen Ausführungsformen erzeugt ein Paketerzeugungs-Schaltungssystem in dem Hardware-Weiterleitungselement ein neues Paket mit der Pfadausfallmeldung und der umgekehrten Pfadspezifikation, während in anderen Ausführungsformen die Datenebene das Pfadausfallpaket direkt aus dem Datenpaket erzeugt. 7 veranschaulicht konzeptionell ein Verfahren 700 einiger Ausführungsformen zum Erzeugen eines solchen Pfadausfallpakets aus einem Datenpaket, welches nicht aus seinem spezifizierten Ausgabeanschluss gesendet werden kann. Das Verfahren 700 wird in einigen Ausführungsformen von der Datenebene eines HFE durchgeführt.
  • Wie dargestellt, beginnt das Verfahren 700 (bei 705) durch Bestimmen, dass der Ausgabeanschluss für ein Datenpaket ausgefallen ist (z.B. die Entscheidung bei 430 des Verfahrens 400). In diesem Fall erzeugt die HFE-Datenebene ein Pfadausfallpaket. In dem Verfahren 700 werden dann (bei 710) die Paketnutzdaten entfernt. Die Nutzdaten umfassen, wie oben angegeben, alle Paketköpfe des internen Pakets (z.B. L2-L4-Köpfe). In einigen anderen Ausführungsformen entfernt das HFE die Nutzdaten nicht und baut die Nutzdaten stattdessen in das Pfadausfallpaket ein, was dem Quellen-Netzwerk-Endpunkt für das ursprüngliche Datenpaket ermöglicht, einfacher zu identifizieren, welches Paket sein Ziel nicht erreicht hat (und somit dasselbe Datenpaket über einen anderen Pfad erneut zu senden).
  • In dem Verfahren 700 wird (bei 715) außerdem eine Pfadausfallmeldung an den Paketkopf angehängt. In einigen Ausführungsformen spezifiziert diese Meldung das HFE mit dem ausgefallenen Anschluss sowie den speziellen Anschluss, der ausgefallen ist (z.B. unter Verwendung von HFE- und Anschlusskennung). In anderen Ausführungsformen spezifiziert die an den Paketkopf angehängte Meldung einfach, dass das Paket ein Pfadausfallpaket ist. Im letzteren Fall kann der Netzwerk-Endpunkt den Weiterleitungspfad verwenden, um das HFE, das das Paket erzeugt hat (durch Verfolgen des Weiterleitungspfads durch seine gespeicherte Topologie) sowie den ausgefallenen Anschluss zu identifizieren (den ersten Eingabeanschluss in dem Weiterleitungspfad).
  • In dem Verfahren 700 wird dann (bei 720) der Weiterleitungspfad für das Pfadausfallpaket erzeugt, indem die Eingabe- und Ausgabeanschlüsse von den eigenen Anschlüssen der HFEs bis zu dem ersten HFE des Datenpaketpfads umgekehrt werden. Das heißt, der ursprüngliche Pfad wird abgeschnitten, wobei alle folgenden HFEs in dem ursprünglichen Datenpaket-Weiterleitungspfad verworfen werden. Dieser Pfad wird dann umgekehrt, wobei der ausgefallene Anschluss, aus welchem das Datenpaket nicht gesendet werden konnte, als der anfängliche Eingabeanschluss verwendet wird. Der letzte Ausgabeanschluss in dem Weiterleitungspfad ist der anfängliche Eingabeanschluss, an welchen der Quellen-Netzwerk-Endpunkt das Datenpaket gesendet hat.
  • Es sei angemerkt, dass die Verwendung der Ausgabeanschlüsse aus dem ursprünglichen Datenpaket als die Eingabeanschlüsse für das Pfadausfallpaket nicht garantiert, dass die Pfadausfallpakete immer an diesen Eingabeanschlüssen ankommen. Wenn beispielsweise eine Multi-Chassis-Link-Aggregation (MLAG) angewendet wird, dann könnten sich die physischen Anschlüsse, an welchen das Pfadausfallpaket empfangen wird, von dem spezifizierten Ausgabeanschluss unterscheiden. Außerdem kann es in bestimmten Fällen sein, dass der Eingabeanschluss in dem Pfadausfallpaket nicht mit dem Ausgabeanschluss in dem Pfad des ursprünglichen Datenpakets übereinstimmt, als Ergebnis eines Problems entweder mit der Weiterleitungsoperation eines der HFEs entlang dem Pfad oder der Topologieinformationen, die von dem Quellen-Endpunkt des ursprünglichen Datenpakets gespeichert sind.
  • Schließlich wird in dem Verfahren 700 (bei 725) das neue Pfadausfallpaket durch den Anschluss, an welchem das ursprüngliche Datenpaket empfangen wurde, herausgeleitet, dann ist das Verfahren beendet. Dieses Paket folgt dann seinem Weiterleitungspfad zurück zu dem ursprünglichen Quellen-Netzwerk-Endpunkt, welcher die Pfadausfalldaten in seine vorübergehende Netzwerktopologie einbaut und anschließende Paketweiterleitungsentscheidungen anpasst.
  • In den obigen Beispielen spezifiziert der Weiterleitungspfad für ein Paket für jedes Weiterleitungselement einen einzigen Ausgabeanschluss. Um ein Broadcast-Paket oder Multicast-Paket zu senden, welches mehrere Ziele erreichen muss, bestimmt der Quellen-Netzwerk-Endpunkt in einigen Ausführungsformen alle Ziel-Netzwerk-Endpunkte für das Paket und sendet Unicast-Pakete über verschiedene Pfade an jedes Ziel. In einigen Ausführungsformen ist jedoch der Netzwerk-Endpunkt auf einige oder alle der HFEs angewiesen, um gemäß den Weiterleitungspfad-Befehlen Kopien des Pakets herzustellen. Anstatt eine einzige Ausgabeanschlusskennung bereitzustellen, wird in einigen Ausführungsformen eine Bitmap verwendet, um anzuzeigen, durch welche Ausgabeanschlüsse ein HFE ein Paket sendet. Die Anschlüsse werden in einer speziellen Reihenfolge abgebildet, die sowohl den Netzwerk-Endpunkten als auch dem HFE bekannt sind, und das HFE sendet eine Kopie des Pakets durch jeden Anschluss, der mit einer 1 in der Bitmap identifiziert wird (oder in anderen Ausführungsformen mit einer 0). Somit spezifiziert ein Unicast-Paket nur einen einzigen Anschluss, aber für mindestens ein HFE spezifiziert ein Multicast-Paket mehrere Anschlüsse in der Bitmap. Dieser Ansatz weist den Vorteil auf, dass weniger Pakete von dem Quellen-Netzwerk-Endpunkt an sein First-Hop-HFE gesendet werden, wodurch in diesem HFE weniger Datenverkehr erzeugt wird.
  • In der obigen Beschreibung umfassen die Datenpaketköpfe, die von dem Quellen-Endpunkt erzeugt werden, lediglich Weiterleitungsbefehle (d.h. Eingabe- und Ausgabeanschlüsse, möglicherweise Prioritätswerte). Zusätzlich zu diesen Weiterleitungsbefehlen sind die HFEs einiger Ausführungsformen dafür konfiguriert, an weiteren Typen von Befehlen ein Parsing durchzuführen und sie auszuführen. In einigen Ausführungsformen ist ein HFE dafür konfiguriert, zu der Zeit, wenn die Netzwerk-Weiterleitungs-IC ein Bootstrapping durchläuft, eine Gruppe von Handlungskennungen zu erkennen und entsprechende Handlungen auszuführen (obwohl in einigen Ausführungsformen auch Änderungen an dieser Konfiguration während der Laufzeit möglich sind). Diese Handlungen können in verschiedenen Ausführungsformen Lesen von Statuswerten und Einbetten der Statuswerte in den Paketkopf, Erzeugen und Senden eines neuen Pakets usw. umfassen.
  • 8 veranschaulicht konzeptionell ein Verfahren 800 einiger Ausführungsformen zum Durchführen eines Parsing an einem Paketkopf und Ausführen von Befehlen, die in dem Paketkopf spezifiziert werden. In einigen Ausführungsformen wird das Verfahren 800 (oder ein ähnliches Verfahren) durch ein HFE für jedes Paket durchgeführt, das von dem HFE empfangen wird. Das Verfahren 800 wird zum Teil unter Bezugnahme auf 9 und 10 beschrieben, welche zwei verschiedene Paketkopfstrukturen einiger Ausführungsformen veranschaulichen.
  • Wie dargestellt, beginnt das Verfahren 800 (bei 805) durch Empfangen eines Pakets an einem HFE. Das Paket kann ein Datenpaket von einem Quellen-Netzwerk-Endpunkt an einen Ziel-Netzwerk-Endpunkt sein (welches z.B. durch eine Anwendung auf einer ersten Maschine erzeugt wird und an eine zweite Maschine gerichtet ist) oder könnte ein Paket speziell zu dem Zweck sein, um zu bewirken, dass ein spezielles HFE oder eine Gruppe von HFEs bestimmte Handlungen vornimmt (z.B. ein Abfragepaket, um einen bestimmten HFE-Status zu ermitteln). Ungeachtet des Pakettyps umfasst das Paket einen von dem Netzwerk-Endpunkt erzeugten Paketkopf, der von den HFEs entlang dem Pfad des Pakets zu lesen ist.
  • Nach dem Empfang des Pakets wird in dem Verfahren 800 (bei 810) an dem Paketkopf ein Parsing durchgeführt, um Handlungen zu identifizieren, die für dieses HFE spezifiziert sind. In einigen Ausführungsformen umfasst ein Paketkopf Gruppen von Handlungen, die für einige oder alle der Weiterleitungselemente entlang dem Pfad des Pakets spezifiziert sind. Jede Handlung umfasst eine Handlungskennung und einen Satz von null oder mehr Argumenten für die Handlungen (z.B. Anschlüsse, durch welche ein Paket zu senden ist, Warteschlangen, für welche der Warteschlangenstatus zu lesen ist, usw.). Jede Handlung entspricht einer Weiterleitungselement-Kennung, welche anzeigt, dass ein spezielles Weiterleitungselement dafür konfiguriert ist, diese Handlung vorzunehmen. In einigen Ausführungsformen werden mehrere parallele ternäre Suchläufe an den Befehlen in dem Paketkopf durchgeführt und die Befehle werden unter der Bedingung ausgeführt, dass die HFE-Kennung passt. Außerdem ermöglichen einige Ausführungsformen globale Befehle (d.h. Befehle, die für jedes HFE auszuführen sind) durch Maskieren der HFE-Kennung in diesen ternären Suchläufen.
  • 9 und 10 veranschaulichen konzeptionell zwei verschiedene Konstruktionen für die Paketköpfe einiger Ausführungsformen. In 9 sind die Weiterleitungspfad-Befehle von den anderen Handlungen getrennt, während in 10 die Weiterleitungsbefehle in der Liste von Handlungen enthalten sind.
  • 9 veranschaulicht ein Datenpaket 900, welches von einem Netzwerk-Endpunkt 905 an ein erstes HFE 910 gesendet wird (die anderen HFEs auf dem Pfad des Datenpakets sind nicht dargestellt). Der Netzwerk-Endpunkt 905 erzeugt Paketköpfe, welche einen Weiterleitungspfad-Kopf 915 und einen Befehlssatz 920 umfassen, und hängt sie an das Datenpaket 900 an. Der Weiterleitungspfad-Kopf 915 ist ähnlich wie die Weiterleitungsköpfe formatiert, die in 5 und 6 dargestellt sind, mit einer Folge von Eingabe- und Ausgabeanschlüssen (wobei die Eingabeanschlüsse gegebenenfalls mit Stellvertreterzeichen besetzt sind, damit die HFEs das Ausfüllen vornehmen können) und einem Zähler, der anzeigt, welches Eingabe/Ausgabe-Anschlusspaar das nächste HFE verwenden wird.
  • Der Satz von Befehlen 920 umfasst, wie dargestellt, verschiedene Handlungen für jedes der HFEs auf dem Pfad. In einigen Ausführungsformen werden diese Befehle unter Verwendung einer HFE-Kennung, die mit einer Handlungskennung gepaart ist, und etwaiger Argumente eingebaut, die für die Handlung benötigt werden. Beispielsweise sind für das erste HFE 910 zwei Handlungen aufgelistet, eine Handlung für das zweite HFE auf dem Pfad, keine Handlungen für das dritte HFE auf dem Pfad, zwei Handlungen für das vierte HFE auf dem Pfad usw. Die Argumente können in Abhängigkeit von der Handlung einen speziellen Anschluss oder eine Warteschlange eines HFE (um z.B. einen Wert daraus auszulesen), einen speziellen Wert zum Speichern an dem HFE usw. spezifizieren. Jedes der HFEs entlang dem Pfad identifiziert seine eigene Handlung, basierend auf den HFE-Kennungen, und wandelt die Handlungskennungen in spezielle auszuführende Handlungen um. Wie erwähnt, werden die HFEs in einigen Ausführungsformen beim Bootstrapping dafür konfiguriert, eine spezielle Gruppe von Handlungskennungen zu erkennen und diese in Handlungen umzuwandeln, welche die HFEs ausführen.
  • 10 veranschaulicht ein Datenpaket 1000, welches von einem Netzwerk-Endpunkt 1005 an ein erstes HFE 1010 gesendet wird (die anderen HFEs auf dem Pfad des Datenpakets sind nicht dargestellt). Der Netzwerk-Endpunkt 1010 erzeugt einen Paketkopf, welcher einen Befehlssatz 1015 umfasst, und hängt ihn an das Datenpaket 1000 an. In diesem Fall umfassen die Paketköpfe keinen separaten Weiterleitungspfad-Kopf, da diese Informationen in dem Befehlssatz 1015 enthalten sind. Der Satz von Befehlen 1015 ist der gleiche wie der Satz von Befehlen 920, außer dass das HFE auf dem Pfad außerdem eine Weiterleitungshandlung mit Eingabe- und Ausgabeanschluss als Argumenten umfasst. Im Allgemeinen wird die Weiterleitungshandlung der letzte Befehl in dem Satz für ein spezielles HFE sein, so dass von der HFE andere Handlungen ausgeführt werden, bevor die Weiterleitungshandlung vorgenommen wird.
  • In dem Fall, wenn die Weiterleitungsbefehle in dem Satz von Befehlen und nicht in einem separaten Weiterleitungspfad-Kopf enthalten sind, müssen die HFEs dennoch Pfadausfallpakete erzeugen, wenn der Ausgabeanschluss nicht betriebsfähig ist. In einigen Ausführungsformen erzeugt das HFE ein Pfadausfallpaket durch Identifizieren der Weiterleitungshandlung für jedes vorhergehende HFE (solange die Handlungsbefehle in der Reihenfolge der HFEs auf dem Pfad angeordnet sind) und Extrahieren der Eingabe- und Ausgabeanschlüsse für jedes der vorhergehenden HFEs auf dem Pfad. Das HFE mit dem ausgefallenen Anschluss erzeugt dann einen Pfadausfallpaket-Kopf ähnlich dem, der oben beschrieben und in 6 dargestellt ist. Zusätzlich zum Entfernen der Nutzdaten wird in einigen Ausführungsformen auch der Befehlssatz-Paketkopf entfernt (sowohl in dem Fall, wenn der Befehlssatz von dem Weiterleitungspfad getrennt ist, als auch, wenn der Befehlssatz den Weiterleitungspfad umfasst), so dass die HFEs bei Rücksendung des Pakets zu dem ursprünglichen Quellen-Netzwerk-Endpunkt keine der Handlungen ausführen.
  • Wieder Bezug nehmend auf 8, wird in dem Verfahren 800 (bei 815) als Nächstes bestimmt, ob es irgendwelche (Nicht-Weiterleitungs-)Handlungen gibt, die von dem HFE auszuführen sind. Wenn weitere Handlungen verbleiben, wird in dem Verfahren (bei 820) die nächste spezifizierte Handlung ausgeführt und das Verfahren kehrt zu 815 zurück, bis alle der (Nicht-Weiterleitungs-)Handlungen ausgeführt worden sind. Wie in 9 und 10 dargestellt, sind die Handlungen in einigen Ausführungsformen nacheinander für jedes HFE aufgelistet. Jedoch können die HFEs in einigen Ausführungsformen dafür konfiguriert sein, die Befehle in bestimmten Fällen neu zu ordnen (um z.B. einen Statuswert zu aktualisieren, bevor der Statuswert gelesen wird).
  • Sobald alle der anderen Handlungen ausgeführt worden sind, wird in dem Verfahren 800 (bei 825) die spezifizierte Weiterleitungshandlung für das Paket ausgeführt. Wie angegeben, kann diese Handlung in verschiedenen Ausführungsformen entweder in dem Rest der Handlungen enthalten sein oder in einem Weiterleitungspfad spezifiziert sein. In einigen Ausführungsformen kann die Weiterleitungshandlung außerdem Replizieren eines Pakets für mehrere Anschlüsse oder Verwerfen eines Pakets umfassen (z.B. wenn das Paket von dem Netzwerk-Endpunkt gesendet wurde, um einen Statuswert eines HFE zu modifizieren, aber kein Datenpaket für einen anderen Endpunkt trägt).
  • Diese Handlungen können in verschiedenen Ausführungsformen in der Komplexität variieren. Beispielsweise könnten die Handlungen Lesen von Zuständen von Weiterleitungselementen (z.B. Warteschlangenstatus, Anschlussstatus, Zeitstempel usw.) und/oder anderen Metadaten und Schreiben dieser Zustandswerte in den Paketkopf umfassen. Speziell könnte eine Handlungskennung einem Lesen der Datenmenge in einer Warteschlange und einem Speichern dieses Werts in dem Paketkopf entsprechen, während das Argument für diese Handlung die spezielle auszulesende Warteschlange spezifizieren würde. Komplexere Handlungen könnten ein Durchführen eines Überlastungsausgleichs zwischen einer Gruppe von spezifizierten Warteschlangen umfassen.
  • 11 und 12 stellen Beispiele für HFEs bereit, welche Befehle ausführen, Warteschlangenzustands-Informationen an verschiedene Typen von Paketen anzuhängen. 11 veranschaulicht konzeptionell ein HFE 1100, welches eine Handlung ausführt, einen Warteschlangen-Tiefenwert an ein Datenpaket 1105 anzuhängen. Wie dargestellt, umfasst das Datenpaket 1105 einen Paketkopf mit einem Befehlssatz 1110. Der Befehlssatz 1110 umfasst zwei Handlungen für das HFE 1100, einschließlich einer Weiterleitungshandlung zum Ausgeben des Pakets über den Anschluss 3. Die erste Handlung spezifiziert, einen Warteschlangen-Tiefenwert an das Paket anzuhängen, wobei ein Argument die spezielle Warteschlange anzeigt, für welche die Warteschlangentiefe anzuhängen ist (im vorliegenden Fall die Warteschlange 11). Somit führt das HFE 1100 diese Handlung zum Anhängen der Warteschlangentiefe aus, indem es die Warteschlangentiefe ausliest und die Daten an einer speziellen Stelle in dem Paket speichert.
  • In einigen Ausführungsformen umfasst das HFE einen Datenverkehrsmanager mit zahlreichen Warteschlangen, in welche Pakete gegeben werden, nachdem sie verarbeitet sind, aber bevor sie ausgegeben werden. Die Warteschlangentiefe für eine spezielle Warteschlange zeigt das Ausmaß an, wie sehr diese spezielle Warteschlange aktuell besetzt ist und von den Netzwerk-Endpunkten verwendet werden kann, um Weiterleitungspfad-Bestimmungen vorzunehmen oder eine Warteschlangenzuordnung für folgende Pakete zu spezifizieren. In einigen Ausführungsformen speichern die Netzwerk-Endpunkte in der Netzwerktopologie nicht nur alle der HFEs und die Verbindungen zwischen Anschlüssen der HFEs, sondern bilden auch alle der Warteschlangen für jedes HFE ab. Die Netzwerk-Endpunkte können die Warteschlangentiefe empfangen (und andere Warteschlangen-Statusinformationen, wie z.B. die Latenzzeit - die Zeit, die ein Paket in einer Warteschlange verbringt, bevor es ausgesendet wird) und diese Daten mit der Topologie speichern, um Paketweiterleitungs-Entscheidungen zu treffen. In einigen Ausführungsformen speichern die Netzwerk-Endpunkte eine Liste von logischen Warteschlangenkennungen für jedes der HFEs und die HFEs speichern eine Abbildung dieser logischen Warteschlangenkennungen auf ihre eigenen physischen Warteschlangen.
  • In 11 führt das HFE 1100 ein Parsing an dem Befehlssatz 1110 durch und identifiziert die Handlung zum Anhängen einer Warteschlangentiefe, anschließend führt es diese Handlung aus. In einigen Ausführungsformen wird die Handlung durch eine Handlungskennung (z.B. einen 8-Bit-Wert, einen 16-Bit-Wert usw.) spezifiziert, welche der Parser oder ein anderes Schaltungssystem des HFE auf eine Handlung oder eine Gruppe von Handlungen abbildet, die auszuführen sind. Das HFE 1100 führt diese Handlung aus und gibt das Datenpaket 1105 aus, wobei sowohl ein Warteschlangen-Tiefenwert 1115 als auch der Befehlssatz 1110 angehängt sind. In diesem Fall empfängt der Ziel-Netzwerk-Endpunkt für das Datenpaket 1105 den Warteschlangen-Tiefenwert 1115 und kann diese Informationen verwenden, um anschließende Weiterleitungsentscheidungen zu treffen.
  • Während 11 ein Beispiel für ein Anhängen von zusätzlichen Befehlen an ein Datenpaket bereitstellt, veranschaulicht 12 ein Beispiel für ein Abfragepaket, welches von einem Netzwerk-Endpunkt gesendet wird, um speziell einen speziellen Statuswert eines HFE 1200 zu bestimmen, und wobei dieser Status zu dem Netzwerk-Endpunkt zurückgesendet wird. Wie dargestellt, empfängt das HFE 1200 einen Paketkopf mit dem Satz von Befehlen 1205. Der Satz von Befehlen 1205 ist nicht an ein Datenpaket angehängt, sondern wird stattdessen von einem Quellen-Netzwerk-Endpunkt erzeugt und separat gesendet. Außerdem sind die Eingabe- und Ausgabeanschlüsse in den Weiterleitungsbefehlen für das HFE 1200 die gleichen (d.h., das HFE sendet das Paket aus demselben Anschluss wie dem, an dem es empfangen wurde).
  • Das HFE 1200 führt ein Parsing an dem Befehlssatz 1205 durch und identifiziert die Handlung zum Anhängen der Warteschlangentiefe für die Warteschlange 11, anschließend führt es diese Handlung aus. Das HFE 1200 gibt dann den Paketkopf 1205 mit einem angehängten Warteschlangen-Tiefenwert 1210 aus. In diesem Fall empfängt der Netzwerk-Endpunkt, der den Paketkopf 1205 erzeugt hat, den Warteschlangen-Tiefenwert und kann diese Informationen verwenden, um anschließende Weiterleitungsentscheidungen zu treffen. In einigen Ausführungsformen können Abfragepakete, welche zu dem Quellen-Netzwerk-Endpunkt zurückkehren, nur unter Verwendung eines Weiterleitungspfads gesendet werden, der von dem Befehlssatz getrennt ist. Anderenfalls muss der Befehlssatz mehrere Weiterleitungsbefehle für die HFEs umfassen, welche das Paket zweimal verarbeiten, und die HFEs verwenden nur den ersten aufgelisteten Befehl. Andere Ausführungsformen umfassen Handlungen zum Entfernen von Befehlen aus dem Befehlssatz, nachdem sie ausgeführt sind, wobei in diesem Fall Abfragepakete mehrere Sätze von Weiterleitungsbefehlen für dasselbe HFE in einem Befehlssatz umfassen können.
  • Die Fähigkeit der HFEs, diese Handlungen vorzunehmen und den Netzwerk-Endpunkten Statusdaten bereitzustellen, ermöglicht diesen Endpunkten, diese Daten bei der Pfadauswahl zu verwenden. In einigen Ausführungsformen verfolgt jeder der Netzwerk-Endpunkte die Warteschlangen-Überlastungszustände für jede Warteschlange jedes der HFEs in dem Netzwerk und kann Datenpakete auf andere Pfade umleiten, wenn die Warteschlangen für diese Datenpakete in einem speziellen Weiterleitungselement zu überlastet sind. Die Netzwerk-Endpunkte können auch im Ergebnis ein Multipathing (z.B. ECMP) für ein gegebenes HFE ausführen, indem sie Datenströme über mehrere verschiedene Pfade verteilen, die von diesem HFE wegführen. Außerdem können Netzwerk-Endpunkte als Überwachungsvorrichtungen fungieren, indem sie Daten (z.B. Warteschlangen-Statusdaten oder andere Daten) von HFEs anfordern und diese Daten auswerten, sobald sie sie von dem HFE empfangen haben.
  • Einige Ausführungsformen ermöglichen dem Quellen-Netzwerk-Endpunkt auch, einen Paketprioritätswert einzubauen (z.B. in die Weiterleitungspfad-Befehle). Die HFEs können diesen Paketprioritätswert verwenden, um Dienstqualitätsgarantien für bestimmte Klassen/Prioritäten von Datenpaketen bereitzustellen. Außerdem können die HFEs in einigen Ausführungsformen eine Überlastungssteuerung auf einer Basis je Paket oder je Datenstrom durchführen, indem sie die lokal verfügbaren Statusinformationen verwenden (d.h. die Warteschlangen-Tiefeninformationen). Diese können weiter verbessert werden, indem jedes HFE seine eigenen Informationen einbettet, welche die folgenden HFEs dann verwenden können. HFEs können in verschiedenen Ausführungsformen z.B. faire Warteschlangenmechanismen realisieren oder können aktiv Pakete verwerfen, um eine Downstream-Überlastung zu verringern.
  • Die HFE-Datenebene ist, um diese verschiedenen Typen von Handlungen auszuführen, in verschiedenen Ausführungsformen unterschiedlich strukturiert. 13 veranschaulicht konzeptionell die Struktur der HFE-Datenebene 1300 einiger Ausführungsformen (z.B. die Struktur der Netzwerk-Weiterleitungs-IC, die in das HFE eingebaut ist). Wie dargestellt, umfasst die Datenebene 1300 eine Eingabe-Pipeline 1305, eine Datenverkehrs-Verwaltungseinheit (als Datenverkehrsmanager bezeichnet) 1310 und eine Ausgabe-Pipeline 1315. In einigen Ausführungsformen umfasst die Datenebene tatsächlich mehrere solcher Pipelines (z.B. mehrere Eingabe-Pipelines und mehrere Ausgabe-Pipelines), welche verschiedenen Anschlüssen des HFE entsprechen. Außerdem verwenden die Eingabe-Pipeline(s) 1305 und die Ausgabe-Pipeline(s) 1315, obwohl sie als separate Strukturen dargestellt sind, in einigen Ausführungsformen tatsächlich dieselben Schaltungsressourcen der Netzwerk-Weiterleitungs-IC, welche dafür konfiguriert sind, sowohl Eingabe- als auch Ausgabe-Pipeline-Pakete synchron zu handhaben. In anderen Ausführungsformen sind die Eingabe-Pipeline(s) 1305 und die Ausgabe-Pipeline(s) 1315 jedoch separate Schaltungssysteme.
  • Im Allgemeinen ist, wenn die Datenebene 1300 an einem ihrer Anschlüsse ein Paket empfängt, das Paket an die Eingabe-Pipeline 1305 gerichtet, welche diesem Anschluss entspricht. Die Eingabe-Pipeline umfasst, wie dargestellt, einen Parser 1320, eine Handlungsausführungsmaschine 1325 und einen Deparser 1330, dessen Operationen nachstehend in Bezug auf 14 detaillierter beschrieben werden. Der Parser 1320 einiger Ausführungsformen identifiziert die Handlungen, die von der Handlungsausführungsmaschine 1325 vorzunehmen sind, und stellt der Handlungsausführungsmaschine 1325 die Paketdaten (z.B. die Paketköpfe, eine Handlungsliste usw.) bereit. Die Handlungsausführungsmaschine 1325 nimmt die Handlungen für das HFE vor und stellt dem Deparser 1330 die Paketdaten bereit, welcher das Paket rekonstruiert und das Paket dem Verkehrsmanager 1310 bereitstellt.
  • Der Verkehrsmanager 1310 einiger Ausführungsformen speichert das Paket in einem Puffer und reiht das Paket in eine spezielle Warteschlange ein (z.B. in eine Warteschlange, die von der Handlungsausführungsmaschine 1325 gemäß den Weiterleitungsbefehlen spezifiziert wird). In einigen Ausführungsformen sendet der Verkehrsmanager das Paket an die Ausgabe-Pipeline 1315 (z.B. gemäß einem Warteschlangenterminierer, der Pakete terminiert, die aus Warteschlangen auszugeben sind, basierend auf Priorität und/oder anderen Faktoren). Diese Ausgabe-Pipeline 1315 umfasst ebenfalls einen Parser 1335, eine Handlungsausführungsmaschine 1340 und einen Deparser 1345 (wie angegeben, können diese dieselben Ressourcen verwenden wie die entsprechenden Eingabe-Pipeline-Strukturen). In Abhängigkeit von der Natur des Netzwerks (z.B. davon, ob die HFEs nur eine Weiterleitung vornehmen oder außerdem verschiedene zusätzliche Handlungen vornehmen) umfasst das HFE in einigen Ausführungsformen keine Ausgabe-Pipeline oder umgeht die Ausgabe-Pipeline für einige oder alle Pakete. Wenn beispielsweise die einzige Handlung, die von dem HFE erwartet wird, Weiterleiten ist, dann übersetzt die Eingabe-Pipeline 1305 die Weiterleitungshandlung in eine spezielle Datenverkehrs-Warteschlange und das Datenpaket kann direkt aus dieser Warteschlange des Verkehrsmanagers 1310 ausgegeben werden. Bestimmte Handlungen, z.B. das Anhängen des Warteschlangen-Status, sind jedoch einfacher von der Ausgabe-Pipeline 1315 vorzunehmen.
  • Wie erwähnt, veranschaulicht 14 konzeptionell weitere Einzelheiten über die Paketverarbeitungsoperationen einer Paketverarbeitungs-Pipeline 1400 einiger Ausführungsformen (z.B. der Eingabe-Pipeline 1305 oder der Ausgabe-Pipeline 1315). Wie dargestellt, umfasst die Pipeline 1400 einen Parser 1405 (z.B. ein Datenebenen-Schaltungssystem zum Durchführen von Parser-Operationen), eine Handlungsausführungsmaschine 1410 (z.B. ein Datenebenen-Schaltungssystem zum Ausführen spezifizierter Handlungen) und einen Deparser 1415 (z.B. ein Datenebenen-Schaltungssystem zum Durchführen von Deparser-Operationen), wie bei den oben beschriebenen Eingabe- und Ausgabe-Pipelines.
  • Der Parser 1405 empfängt, wie dargestellt, ein Paket 1420 (z.B. von einem Anschluss des HFE, von dem Verkehrsmanager) als eine formatierte Zusammenstellung von Bits. Das Paket 1420 umfasst Köpfe (z.B. Weiterleitungsbefehle, andere Handlungsbefehle usw.) sowie das interne Paket (welches verschiedene interne L2-L4-Köpfe, Nutzdaten usw. umfassen kann). Der Parser 1405 führt ein Parsing an diesem Paket durch, um zumindest Handlungsbefehle 1425 zu identifizieren, die von der Handlungsausführungsmaschine 1410 auszuführen sind. In einigen Ausführungsformen stellt der Parser die Paketdaten, Handlungsbefehle usw. der Handlungsausführungsmaschine als eine Gruppe von Daten-Containern bereit, wobei spezielle Container (z.B. Daten, die auf speziellen Gruppen von Drähten transportiert werden) jeweils spezielle Paketkopffelder, Handlungen usw. aufweisen. Außerdem werden in einigen Ausführungsformen einige der Paketdaten (z.B. die Nutzdaten) nicht an die Handlungsausführungsmaschine 1410 gesendet, sondern werden stattdessen direkt an den Deparser 1415 gesendet, wobei die Handlungsausführungsmaschine umgangen wird.
  • In einigen Ausführungsformen ist jeder der Handlungsbefehle 1425 eine Handlungskennung (z.B. ein 8-Bit-Wert, ein 12-Bit-Wert usw.), welche der Handlungsausführungsmaschine 1410 befiehlt, eine spezielle Handlung vorzunehmen, und welche auch ein oder mehrere Argumente umfassen kann. Wie oben beschrieben, bestimmt der Parser 1405 diese Handlungen und Argumente, indem er ein Parsing an den Paketköpfen durchführt, und er stellt der Handlungsausführungsmaschine 1410 die Handlungen bereit die von der Pipeline 1400 vorzunehmen sind. In einigen Ausführungsformen spezifizieren die Handlungskennungen in dem empfangenen Paket, ob sie von der Eingabe-Pipeline oder der Ausgabe-Pipeline vorzunehmen sind (z.B., indem eines der Bits der Kennung so zugeordnet wird, dass es ein Eingabe/Ausgabe-Bit ist), während in anderen Ausführungsformen der Parser dafür verantwortlich ist zu bestimmen, ob eine jeweilige Handlung eine Eingabe-Pipeline-Handlung oder eine Ausgabe-Pipeline-Handlung ist.
  • In anderen Ausführungsformen sind einige oder alle der Handlungsbefehle 1425 Abschnitte von Code (z.B. P4-Programm-Code), der in dem Paket übertragen wird und dem HFE befiehlt, die erforderliche Handlung vorzunehmen. In einigen solchen Ausführungsformen extrahiert und liest der Parser 1405 den Code und wandelt den Code in eine Handlungskennung um, die an die Handlungsausführungsmaschine 1410 weitergegeben wird. In anderen solchen Ausführungsformen gibt der Parser den Code selbst zu der Handlungsausführungsmaschine 1410 weiter, welche den Code ablaufen lässt, um die spezifizierte Handlung vorzunehmen.
  • Die Handlungsbefehle 1425 werden der Handlungsausführungsmaschine 1410 in einigen Ausführungsformen in einer speziellen Reihenfolge bereitgestellt und die Handlungsausführungsmaschine nimmt die Handlungen in dieser Reihenfolge vor. In einigen Ausführungsformen ist dies die Reihenfolge, in welcher die Handlungen in dem Paketkopf aufgelistet sind, während in anderen Ausführungsformen der Parser 1405 die Reihenfolge der Handlungen für die Pipeline modifizieren kann.
  • Die Handlungsausführungsmaschine 1410 führt diese Handlungen in der spezifizierten Reihenfolge aus, was ein Modifizieren der Paketdaten umfassen kann. In einigen Ausführungsformen umfasst die Handlungsausführungsmaschine 1410 mehrere Stufen und jede Stufe nimmt eine der spezifizierten Handlungen vor. In anderen Ausführungsformen werden einige oder alle der Handlungen parallel vorgenommen. Um eine Handlung auszuführen, liest die Handlungsausführungsmaschine 1410 einiger Ausführungsformen die Handlungskennung, welche einem Manipulieren einer Gruppe von Eingaben in einer vorab konfigurierten Weise entspricht. Diese Eingaben können Daten von dem HFE (z.B. ein Warteschlangenstatus), Argumente der Handlungskennung (z.B. eine Warteschlangenkennung) oder die Paketkopfwerte selbst sein (im Fall einer Paketkopfmanipulation).
  • In einigen Ausführungsformen werden die Handlungskennungen 1425 der Handlungsausführungsmaschine in Paketkopfvektor(PHV)-Datencontainern bereitgestellt, in welchen auch die Paketköpfe (und in einigen Fällen auch die Paketdaten) gespeichert sind. Diese Daten in diesen PHV-Datencontainern werden zwischen Stufen der Handlungsausführungsmaschine 1410 weitergegeben und können durch die Handlungen modifiziert werden (z.B. Speichern von Statusdaten für eine Ausgabe mit dem Paket, Schreiben eines Eingabeanschlusses in den Weiterleitungspfad usw.). Um eine Handlung auszuführen, wird in einigen Ausführungsformen keine Übereinstimmungslogik verwendet und stattdessen wird die richtige Handlungskennung direkt aus dem PHV gelesen, um die auszuführende Handlung zu spezifizieren. In anderen Ausführungsformen erfordert die Handlungsausführungs-Stufenstruktur, dass die Handlungskennung aus einer Zuordnungstabelle ausgegeben wird. In einigen solchen Ausführungsformen ist die Zuordnungstabellenlogik dafür konfiguriert, zur Kompilierungszeit die Handlungskennung, die in dem PHV gespeichert ist, einfach zuzuordnen und dieselbe Handlungskennung zur Ausführung auszugeben.
  • Wie dargestellt, gibt die Handlungsausführungsmaschine 1410 die Paketdaten und Paketköpfe (welche durch die verschiedenen Handlungen modifiziert sein können) an den Deparser 1415 aus, zusammen mit Deparser-Befehlen 1430. Diese Deparser-Befehle können Daten, die aus den Paketköpfen zu entfernen sind, wobei diese Daten beim Rekonstruieren des Pakets zu verwenden sind, sowie Informationen über die Ausgabe des Pakets spezifizieren (z.B. die Warteschlange, an welche das Paket gesendet wird usw.). Der Deparser 1415 rekonstruiert das modifizierte Paket 1435 und stellt dieses dem Datenverkehrsmanager (oder dem Ausgabeanschluss, wenn die Pipeline 1400 die Ausgabe-Pipeline ist) bereit.
  • Ein mögliches Problem bei der Bereitstellung des oben beschriebenen Funktionalitätsniveaus für die Netzwerk-Endpunkte ist, dass ein beeinträchtigter Netzwerk-Endpunkt viel Leistung über den Betrieb des Netzwerks aufweist. In einem herkömmlichen Netzwerk weisen die Weiterleitungselemente ihre eigenen Zugangssteuerungslisten(ACL)-Regeln auf, mit denen geprüft werden kann, ob Pakete verworfen werden sollten. Ein Weiterleitungselement, welches nur Handlungen vornimmt, die von den Netzwerk-Endpunkten spezifiziert werden, anstatt Zuordnungsoperationen durchzuführen, weist jedoch keine solchen ACL-Regeln auf.
  • Wenn der Netzwerk-Endpunkt vollständig vertrauenswürdig ist (z.B. im Fall eines sicheren Hypervisor-Netzwerkstapels), dann ist dies kein Problem. Um jedoch in einigen Ausführungsformen sicherzustellen, dass bösartige Endpunkte ein Netzwerk nicht beeinträchtigen können, verifizieren die Weiterleitungselemente die ACL-Regeln unter Verwendung eines gemeinsamen Geheimnisses zwischen den Netzwerksteuerungen und den Weiterleitungselementen (oder separater gemeinsamer Geheimnisse zwischen den Steuerungen und jedem der Weiterleitungselemente).
  • Speziell ist der Quellen-Netzwerk-Endpunkt in einigen Ausführungsformen für ein Evaluieren jedes Pakets gegen einen Satz von ACL-Regeln verantwortlich, welchen der Netzwerk-Endpunkt von der Gruppe von Netzwerksteuerungen empfängt. Die Netzwerksteuerungen einiger Ausführungsformen stellen jedem der Netzwerk-Endpunkte den Satz von ACL-Regeln (welche für unterschiedliche Netzwerk-Endpunkte unterschiedlich sein können) sowie einen vorberechneten Hashwert für jede der ACL-Regeln bereit. Der vorberechnete Hashwert wird von der Netzwerksteuerung für jede ACL-Steuerung unter Verwendung eines geheimen Schlüssels (z.B. mit einer Hashfunktion) erzeugt, auf welchen die Netzwerk-Endpunkte keinen Zugriff haben.
  • 15 veranschaulicht konzeptionell ein Beispiel eines Netzwerks 1500 mit einer Gruppe von Netzwerksteuerungen 1545, welche ACL-Regeln an die Netzwerk-Endpunkte und geheime Schlüssel an die Hardware-Weiterleitungselemente verteilen. Wie dargestellt, umfasst das Netzwerk 1500 vier HFEs 1505 bis 1520, vier Netzwerk-Endpunkte 1525 bis 1540 und eine Gruppe von Netzwerksteuerungen 1545. Es versteht sich, dass ein typisches Netzwerk viel mehr HFEs und Netzwerk-Endpunkte umfassen wird, als in dem vereinfachten Netzwerk 1500 dargestellt sind. Das Netzwerk 1500 ist so aufgebaut, dass das erste HFE 1505 das First-Hop-HFE für zwei der Netzwerk-Endpunkte 1525 und 1530 ist (d.h., diese Netzwerk-Endpunkte sind direkt mit Anschlüssen des HFE 1505 verbunden), das dritte HFE 1515 das First-Hop-HFE für einen dritten Netzwerk-Endpunkt 1535 ist und das vierte HFE 1540 das First-Hop-HFE für einen vierten Netzwerk-Endpunkt 1540 ist. Das zweite HFE 1510 ist ein rein netzwerkinternes und empfängt keine Pakete direkt von einem der Netzwerk-Endpunkte.
  • Die Netzwerksteuerungen 1545 repräsentieren eine Gruppe von Netzwerksteuerungen, welche den Netzwerk-Endpunkten die stationäre Netzwerktopologie bereitstellen und den HFEs Anfangskonfigurationsdaten bereitstellen (z.B. die Abbildung von Handlungskennungen auf Handlungen). Die Netzwerksteuerungen 1545 sind in dieser Figur so dargestellt, dass sie den HFEs 1505 bis 1520 und den Netzwerk-Endpunkten 1525 bis 1540 direkt Daten bereitstellen, obwohl diese Kommunikation in einigen Ausführungsformen durch das Netzwerk 1500 gesendet wird. Das heißt, die Netzwerksteuerungen können auf eine Weise ähnlich wie die Netzwerk-Endpunkte Konfigurationsdaten senden (und z.B. Bootstrapping-Pakete empfangen).
  • Wie in der Figur dargestellt, stellen die Netzwerksteuerungen 1545 jedem der drei HFEs 1505, 1515 und 1520, die First-Hop-HFEs für irgendwelche der Netzwerk-Endpunkte sind, geheime Schlüssel bereit. Diese First-Hop-HFEs sind in einigen Ausführungsformen für die Verwendung der geheimen Schlüssel zum Verifizieren von ACL-Regeln verantwortlich, die an Pakete angehängt sind, die von ihren entsprechenden direkt verbundenen Netzwerk-Endpunkten gesendet werden. In diesem Beispiel empfängt jedes der HFEs einen separaten geheimen Schlüssel: K 1 für das erste HFE 1505, K2 für das dritte HFE 1515 und K3 für das vierte HFE 1520.
  • Die geheimen Schlüssel werden nicht den Netzwerk-Endpunkten 1525 bis 1540 bereitgestellt. Daher können die Netzwerk-Endpunkte keine Hashwerte für eine ACL-Regel berechnen, die nicht von der Netzwerksteuerung gesendet wird, wodurch verhindert wird, dass ein beeinträchtigter Netzwerk-Endpunkt ACL-Regeln formt. Stattdessen stellen die Netzwerksteuerungen die ACL-Regeln, die die Netzwerk-Endpunkte verwenden, um Pakete auszuwerten, bevor sie sie an das HFE-Netzwerk 1500 senden, sowie Hashwerte für jede ACL-Regel bereit, die von den Netzwerksteuerungen unter Verwendung des passenden geheimen Schlüssels vorberechnet werden. Somit stellt die Netzwerksteuerung 1545, wie dargestellt, ACL-Regeln und Hashwerte, die mit dem Schlüssel K1 des ersten HFE 1505 berechnet werden, beiden ersten Netzwerk-Endpunkten 1525 und 1530 bereit. In ähnlicher Weise empfängt der dritte Netzwerk-Endpunkt 1535 die ACL-Regeln sowie Hashwerte für diese Regeln, die mit dem Schlüssel K2 des dritten HFE 1515 berechnet werden, und der vierte Netzwerk-Endpunkt 1540 empfängt die ACL-Regeln sowie Hashwerte für diese Regeln, die mit dem Schlüssel K3 des vierten HFE 1520 berechnet werden. In einigen Ausführungsformen empfangen alle der Netzwerk-Endpunkte denselben Satz von ACL-Regeln, während in anderen Ausführungsformen für verschiedene Netzwerk-Endpunkte verschiedene ACL-Regeln bereitgestellt werden. Außerdem wird, obwohl im vorliegenden Beispiel jedes HFE einen anderen geheimen Schlüssel verwendet, in einigen Ausführungsformen ein einziger geheimer Schlüssel für alle der HFEs in einem Netzwerk verwendet.
  • Wenn er ein Paket sendet, überprüft der Quellen-Netzwerk-Endpunkt für das Paket, wenn er richtig arbeitet, das Paket gegen seinen Satz von ACL-Regeln, die er von dem HFE empfangen hat, um zu bestimmen, ob das Paket zuzulassen oder zu verwerfen ist. In einigen Ausführungsformen spezifizieren die ACL-Regeln, ob Pakete zuzulassen oder abzulehnen sind, basierend auf Kombinationen dieser Quellen- und/oder Zieladressen des Pakets (z.B. MAC-Adressen, IP-Adressen usw.) sowie möglicherweise anderen Paketkopfwerten (z.B. Transportschicht-Anschlussnummern). Wenn die passende ACL-Regel (es sei angemerkt, dass in einigen Ausführungsformen die ACL-Regeln keine Prioritäten aufweisen, aber von der Netzwerksteuerung geglättet werden, um sich überlappende Regeln zu vermeiden) zulässt, dass das Paket durch das Netzwerk gesendet wird, hängt der Quellen-Netzwerk-Endpunkt diese passende ACL-Regel an das Paket an, zusammen mit dem vorberechneten Hashwert für diese Regel, der von den Netzwerksteuerungen empfangen wurde.
  • Wenn der Quellen- Netzwerk-Endpunkt vollständig vertrauenswürdig ist und es keine Möglichkeit gibt, dass einer der Netzwerk-Endpunkte durch bösartig Handelnde beeinträchtigt oder manipuliert wird, dann müssen die HFEs nicht verifizieren, ob der Quellen-Netzwerk-Endpunkt die Regeln richtig angewendet hat. Wenn dies jedoch nicht der Fall ist, sind die HFEs einiger Ausführungsformen dafür konfiguriert zu verhindern, dass bösartige oder beeinträchtigte Netzwerk-Endpunkte Pakete an das Netzwerk senden.
  • Nach Empfang eines Pakets verifiziert das HFE einiger Ausführungsformen sowohl (i), dass die ACL-Regel zu dem Hashwert passt, als auch (ii), dass die ACL-Regel eine korrekte ACL-Regel für das Paket ist. Wenn die ACL-Regel diese beiden Überprüfungen besteht, dann setzt das HFE die Verarbeitung des Pakets fort (z.B. Weiterleiten des Pakets, Vornehmen etwaiger zusätzlicher Handlungen, die in dem Paketkopf spezifiziert sind). Wenn jedoch die ACL-Regel eine der Überprüfungen nicht besteht, dann verwirft das HFE das Paket in einigen Ausführungsformen, unter der Voraussetzung, dass das Paket entweder von einem beeinträchtigten Netzwerk-Endpunkt oder einem unzulässigen Netzwerk-Endpunkt gesendet wurde. In ähnlicher Weise verwirft das Weiterleitungselement in einigen Ausführungsformen, wenn das Paket keine angehängte ACL-Regel aufweist, ebenfalls das Paket.
  • 16 veranschaulicht konzeptionell ein Verfahren 1600 einiger Ausführungsformen zum Verifizieren einer ACL-Regel, die an ein Paket angehängt ist. Das Verfahren 1600 wird von einem HFE durchgeführt, welches ein Paket empfängt und dafür konfiguriert ist, eine ACL-Regel mit einem an das Paket angehängten Hashwert zu erwarten. In einigen Ausführungsformen wird das Verfahren 1600 durchgeführt, bevor das HFE irgendwelche anderen Handlungen ausführt, die in dem Paketkopf spezifiziert sind (z.B. am Start der Eingabe-Pipeline, nach dem Parsing des Pakets). Das Verfahren 1600 wird zum Teil unter Bezugnahme auf 17 und 18 beschrieben, welche ein HFE veranschaulichen, welches verschiedene Aspekte der ACL-Regel-Verifikation durchführt.
  • Wie dargestellt, beginnt das Verfahren 1600 (bei 1605) durch Empfangen eines Pakets an einem Anschluss des HFE, der mit einem Netzwerk-Endpunkt verbunden ist. In einigen Ausführungsformen ist das HFE ein First-Hop-HFE für einen oder mehrere Netzwerk-Endpunkte und ist dafür konfiguriert, das ACL-Verifikationsverfahren nur an Paketen durchzuführen, welche durch seine Anschlüsse empfangen werden, die mit diesen Netzwerk-Endpunkten verbunden sind. In anderen Ausführungsformen führt das HFE dieses Verfahren an allen Paketen durch, die es empfängt (wobei möglicherweise alle HFEs, die ein Paket durchläuft, die ACL-Regel des Pakets verifizieren).
  • Als Nächstes wird in dem Verfahren 1600 (bei 1610) bestimmt, ob eine ACL-Regel mit einem Hashwert an das Paket angehängt ist. In einigen Ausführungsformen führt das HFE außerdem ein Parsing an dem Paket durch, bevor es irgendwelche der Operationen von 1610 aufwärts durchführt. In einigen solchen Ausführungsformen umfasst ein Teil der Parser-Operationen Bestimmen, ob eine ACL-Regel und ein Hashwert an der Stelle in dem Paket vorliegen, wo diese Daten zu erwarten sind. Wenn das Paket keine ACL-regel umfasst, wird (bei 1615) das Paket in dem Verfahren verworfen, anschließend endet das Verfahren.
  • Unter der Annahme, dass an das Paket eine ACL-Regel und ein Hashwert angehängt sind, wird in dem Verfahren 1600 (bei 1620) unter Verwendung eines geheimen Schlüssels ein neuer Hashwert aus der ACL-Regel berechnet. Wie oben beschrieben, wird dieser geheime Schlüssel in einigen Ausführungsformen von dem HFE und der Netzwerksteuerung gemeinsam benutzt. In einigen Ausführungsformen umfasst die Hashwertberechnung Anwenden einer kryptographischen Hashfunktion auf die ACL-Regel unter Verwendung des geheimen Schlüssels.
  • In dem Verfahren 1600 wird dann (bei 1625) bestimmt, ob der neu berechnete Hashwert zu dem vorberechneten Hashwert passt, der an das Paket angehängt ist. Wenn die Hashwerte nicht zueinander passen, zeigt dies an, dass der Quellen-Netzwerk-Endpunkt die ACL-Regel nicht von der Netzwerksteuerung empfangen hat (z.B., weil der Netzwerk-Endpunkt kein verifizierter Endpunkt für das Netzwerk ist). Daher wird in dem Verfahren (bei 1615), wenn die Hashwerte nicht zueinander passen, das Paket verworfen, anschließend endet das Verfahren.
  • 17 veranschaulicht konzeptionell die Handlungsausführungsmaschine 1700 eines HFE, welches diese ACL-Hashwert-Verifikation durchführt. Wie dargestellt, empfängt der Parser des HFE ein Paket 1705, welches einen Paketkopf mit Handlungs- und/oder Weiterleitungsbefehlen, eine ACL-Regel 1710 und einen Hashwert 1715 umfasst. Der Parser 1720 des HFE führt ein Parsing an dem Paket 1705 in seine verschiedenen Felder durch, umfassend die ACL-Regel 1710 und den Hashwert 1715 (sowie eine Liste von Handlungen). Innerhalb des Handlungsausführungsmaschinen-Schaltungssystems 1700 empfängt ein Hasher 1725 (z.B. eine Schaltungssystem-/Logikgruppe, die dafür konfiguriert ist, einen sicheren Hash-Algorithmus auszuführen) die ACL-Regel und den geheimen Schlüssel (in einigen Ausführungsformen sicher an dem HFE gespeichert) und berechnet einen neuen Hashwert 1730. Eine Vergleichseinheit 1735 (z.B. eine Schaltungssystem-/Logikgruppe, die dafür konfiguriert ist, zwei Werte zu vergleichen) vergleicht den empfangenen Hashwert 1715 mit dem neu berechneten Hashwert 1730 und gibt eine Zulassungs-/Verwerfungsentscheidung aus (z.B. als ein einzelnes Bit).
  • Wenn der berechnete Hashwert zu dem Hashwert passt, der an das Paket angehängt ist, wird in dem Verfahren 1600 als Nächstes verifiziert, dass die ACL-Regel eine korrekte ACL-Regel für das Paket ist. In dem Verfahren werden (bei 1630) die benötigten Paketkopfwerte aus der ACL-Regel und (bei 1635) die Werte der entsprechenden Paketköpfe aus dem Paket extrahiert. In einigen Ausführungsformen hat der Parser bereits zuvor ein Parsing an dem Paket in diese Einzelwerte durchgeführt und die Werte in die Paketdaten eingefügt, die an die Handlungsausführungsmaschine des HFE gesendet werden. Außerdem werden in einigen Ausführungsformen (entweder im Parser oder in der Handlungsausführungsmaschine) der Typ der Werte bestimmt, die in der ACL-Regel verwendet werden (z.B. Quellen- und/oder Ziel-IP-Adresse, Quellen- und/oder Ziel-Transportschicht-Anschlussnummern, Quellen- und/oder Ziel-MAC-Adressen, Protokollwerte usw.), und die Paketkopf-Feldwerte bestimmt, die diesen ACL-Regel-Werten entsprechen. Einige Ausführungsformen erfordern, dass die ACL-Regeln in einer speziellen Weise strukturiert sind, so dass der Parser oder andere Komponenten des HFE die benötigten Paketkopfwerte oder -wertebereiche identifizieren können.
  • In dem Verfahren 1600 wird dann (bei 1640) bestimmt, ob die Paketkopfwerte zu diesen Werten passen, die nach der ACL-Regel erforderlich sind. Diese Operation erfordert in einigen Ausführungsformen nicht die Verwendung einer Zuordnungstabellenlogik, da das HFE einfach Werte aus der ACL-Regel mit den entsprechenden Werten aus dem Paketkopf vergleichen muss, anstatt gespeicherte Zuordnungstabelleneinträge zu verwenden. In einigen Ausführungsformen werden die Paketkopfwerte mit einem Bereich von Werten verglichen, der durch die ACL-Regel spezifiziert wird (z.B. einem Bereich von IP-Adressen, spezifiziert durch ein CIDR-Präfix). In anderen Ausführungsformen kann dieser Vergleich durch Vergleichen der Bitwerte eines Abschnitts des Feldes (z.B. für einen Bereich von kontinuierlichen IP-Adressen oder Anschlussnummern) oder durch mehrere einzelne Vergleiche mit verschiedenen Alternativwerten (z.B. für eine Gruppe von MAC-Adressen) erfolgen. Wenn die Paketkopfwerte nicht zu jenen passen, die nach der ACL-Regel erforderlich sind, dann zeigt dies an, dass der Quellen-Netzwerk-Endpunkt eine ungültige ACL-Regel an das Paket angehängt hat (z.B., weil der Quellen-Endpunkt beeinträchtigt ist). Daher wird, wenn die Kopfwerte des Pakets nicht zu jenen passen, die nach der ACL-Regel erforderlich sind, dann in dem Verfahren 1600 (bei 1615) das Paket verworfen, anschließend endet das Verfahren. Anderenfalls wird in dem Verfahren (bei 1645) die Verarbeitung des Pakets fortgesetzt (z.B. durch Vornehmen anderer Handlungen und/oder Weiterleiten des Pakets).
  • Um zu verhindern, dass ein beeinträchtigter Netzwerk-Endpunkt eine Regel höherer Priorität übergeht, welche ein Paket ablehnt, und eine Regel niedrigerer Priorität verwendet, welche das Paket zulässt (was für das Weiterleitungselement wie eine gültige und korrekte ACL-Regel aussehen würde), flachen die Netzwerksteuerungen einiger Ausführungsformen den Satz von ACL-Regeln ab (wodurch sichergestellt wird, dass es keine Überlappungen in dem Regelraum gibt), bevor die ACL-Regeln und die Hashwerte den Netzwerk-Endpunkten bereitgestellt werden. In diesem Fall sind für die Regeln keine Prioritäten erforderlich. In anderen Ausführungsformen kann der Satz von ACL-Regeln überlappend sein, fungiert aber im Ergebnis als eine Positivliste. Das heißt, die Netzwerksteuerung stellt Regeln (welche sich überlappen können) für alle zulässigen Pakete und eine einzelne Regel niedrigerer Priorität bereit, welche alle anderen Pakete ablehnt. In diesem Fall analysiert die Netzwerksteuerung die Regeln, um Regeln zu entfernen, welche Pakete zulassen würden, wenn Regeln höherer Priorität diese Pakete ablehnen (oder die Regeln zu modifizieren, wenn die Regeln einen Bereich von Adressen oder Anschlüssen zulassen und nur ein Abschnitt dieses Bereichs abgelehnt werden sollte). Eine andere Option, die in einigen anderen Ausführungsformen eingesetzt wird, ist, dass, anstatt dass der Quellen-Endpunkt die spezielle Regel anhängt, die das Paket zulässt, der Quellen-Endpunkt den gesamten Regelsatz und den Hashwert anhängen muss, der von der Netzwerksteuerung für den gesamten Regelsatz bereitgestellt wird. Dieser Ansatz weist den Nachteil auf, dass er in Bezug auf die Paketkopfgröße aufwändig ist sowie eine größere Hash-Berechnung für das HFE bedeutet.
  • 18 veranschaulicht konzeptionell die Handlungsausführungsmaschine 1700, welche eine ACL-Regel-Verifikation für das Paket 1705 durchführt. Wie in Bezug auf 17 beschrieben, stellt der Parser 1720 der Handlungsausführungsmaschine 1700 Paketdaten 1805 und die ACL-Regel 1710 bereit, neben anderen Daten. Die ACL-Regel ist so strukturiert, dass die Handlungsausführungsmaschine 1700 (oder in anderen Ausführungsformen der Parser 1720) den Wert oder die Werte isolieren kann, die für einen Paketkopf passen müssen, um die ACL-Regel zu erfüllen. Diese ACL-Regel-Werte 1810 werden einer Vergleichseinheit 1820 in der Handlungsausführungsmaschine 1700 bereitgestellt, zusammen mit entsprechenden Paketkopfwerten 1815. In einigen Ausführungsformen identifiziert entweder der Parser 1720 oder die Handlungsausführungsmaschine 1700 auch den Typ der Werte (d.h. der Paketkopffelder), auf dem die ACL-Regeln basieren, so dass die Vergleichseinheit 1820 die richtigen Paketkopffeld-Werteingaben 1815 verwendet. Die Vergleichseinheit 1820 vergleicht die ACL-Regelwerte 1810 mit den entsprechenden Paketkopffeld-Werten 1815 und gibt eine Zulassungs-/Verwerfungsentscheidung aus (z.B. als ein einzelnes Bit).
  • 19 veranschaulicht konzeptionell ein elektronisches System 1900, mit welchem einige Ausführungsformen der Erfindung realisiert werden. Das elektronische System 1900 kann verwendet werden, um beliebige der oben beschriebenen Steuer-, Virtualisierungs- oder Betriebssystemanwendungen auszuführen. Das elektronische System 1900 kann ein Computer (z.B. ein Desktop-Computer, ein PersonalComputer, ein Tablet-Computer, ein Server-Computer, ein Großrechner, ein Blade-Computer usw.), ein Telefon, ein PDA oder eine beliebige andere Art einer elektronischen Vorrichtung sein. Ein solches elektronisches System umfasst verschiedene Typen von computerlesbaren Medien und Schnittstellen für verschiedene andere Typen von computerlesbaren Medien. Das elektronische System 1900 umfasst einen Bus 1905, eine Verarbeitungseinheit (Verarbeitungseinheiten) 1910, einen Systemspeicher 1925, einen Nur-Lese-Speicher 1930, eine Permanentspeichervorrichtung 1935, Eingabevorrichtungen 1940 und Ausgabevorrichtungen 1945.
  • Der Bus 1905 repräsentiert zusammenfassend alle System-, Peripherie- und Chipsatzbusse, welche die zahlreichen internen Vorrichtungen des elektronischen Systems 1900 kommunikativ verbinden. Beispielsweise verbindet der Bus 1905 die Verarbeitungseinheit(en) 1910 kommunikativ mit dem Nur-Lese-Speicher 1930, dem Systemspeicher 1925 und der Permanentspeichervorrichtung 1935.
  • Aus diesen verschiedenen Speichereinheiten ruft (rufen) die Verarbeitungseinheit(en) 1910 auszuführende Befehle und zu verarbeitende Daten ab, um die Verfahren der Erfindung durchzuführen. Die Verarbeitungseinheit(en) kann (können) ein Einzelprozessor oder in anderen Ausführungsformen ein Multikernprozessor sein.
  • Der Nur-Lese-Speicher (ROM) 1930 speichert statische Daten und Befehle, welche von der (den) Verarbeitungseinheit(en) 1910 und anderen Modulen des elektronischen Systems benötigt werden. Die Permanentspeichervorrichtung 1935 ist andererseits eine Speichervorrichtung zum Lesen und Schreiben. Diese Vorrichtung ist eine nicht-flüchtige Speichereinheit, welche Befehle und Daten speichert, auch wenn das elektronische System 1900 ausgeschaltet ist. In einigen Ausführungsformen der Erfindung wird eine Massenspeichervorrichtung (z.B. eine magnetische oder optische Platte und deren entsprechendes Plattenlaufwerk) als die Permanentspeichervorrichtung 1935 verwendet.
  • In anderen Ausführungsformen wird eine entfernbare Speichervorrichtung (z.B. eine Diskette, ein Flash-Speicher usw.) als die Permanentspeichervorrichtung verwendet. Wie die Permanentspeichervorrichtung 1935 ist der Systemspeicher 1925 eine Speichervorrichtung zum Lesen und Schreiben. Jedoch ist der Systemspeicher, anders als die Speichervorrichtung 1935, ein flüchtiger Speicher zum Lesen und Schreiben, z.B. ein Direktzugriffsspeicher. Der Systemspeicher speichert einige der Befehle und Daten, die der Prozessor zur Laufzeit benötigt. In einigen Ausführungsformen werden die Verfahren der Erfindung in dem Systemspeicher 1925, der Permanentspeichervorrichtung 1935 und/oder dem Nur-Lese-Speicher 1930 gespeichert. Aus diesen verschiedenen Speichereinheiten ruft (rufen) die Verarbeitungseinheit(en) 1910 auszuführende Befehle und zu verarbeitende Daten ab, um die Verfahren einiger Ausführungsformen durchzuführen.
  • Der Bus 1905 verbindet außerdem mit den Eingabe- und Ausgabevorrichtungen 1940 und 1945. Die Eingabevorrichtungen ermöglichen dem Benutzer, Informationen an das elektronische System zu übermitteln und Befehle für dieses auszuwählen. Die Eingabevorrichtungen 1940 umfassen alphanumerische Tastaturen und Zeigevorrichtungen (auch als „Cursor-Steuervorrichtungen“ bezeichnet). Die Ausgabevorrichtungen 1945 zeigen Bilder an, die von dem elektronischen System erzeugt werden. Die Ausgabevorrichtungen umfassen Drucker und Anzeigevorrichtungen, wie z.B. Kathodenstrahlröhren (CRTs) oder Flüssigkristallanzeigen (LCDs). Einige Ausführungsformen umfassen Vorrichtungen, wie z.B. einen Touchscreen, welche sowohl als Eingabe- als auch als Ausgabevorrichtungen fungieren.
  • Schließlich verbindet der Bus 1905, wie in 19 dargestellt, außerdem das elektronische System 1900 über einen (nicht dargestellten) Netzwerkadapter mit einem Netzwerk 1965. Auf diese Weise kann der Computer ein Teil eines Netzwerks von Computern (wie z.B. eines lokalen Netzwerks („LAN“), eines Fernbereichs-Netzwerks („WAN“) oder eines Intranets) oder eines Netzwerks von Netzwerken sein, wie z.B. des Internets. Beliebige oder alle Komponenten des elektronischen Systems 1900 können in Verbindung mit der Erfindung verwendet werden.
  • Einige Ausführungsformen umfassen elektronische Komponenten, wie z.B. Mikroprozessoren und Speicher, welche Computerprogrammbefehle in einem maschinenlesbaren oder computerlesbaren Medium (alternativ als computerlesbare Speichermedien, maschinenlesbare Medien oder maschinenlesbare Speichermedien bezeichnet) speichern. Einige Beispiele solcher computerlesbaren Medien umfassen RAM, ROM, Nur-Lese-Compact-Discs (CD-ROM), beschreibbare Compact-Discs (CD-R), überschreibbare Compact-Discs (CD-RW), Nur-Lese-Digital-Versatile-Discs (z.B. DVD-ROM, Doppelschicht-DVD-ROM), eine Vielfalt von beschreibbaren/überschreibbaren DVDs (z.B. DVD-RAM, DVD-RW, DVD+RW usw.), Flash-Speicher (z.B. SD-Karten, Mini-SD-Karten, Mikro-SD-Karten usw.), magnetische und/oder Halbleiter-Festplattenlaufwerke, Nur-Lese- und beschreibbare Blu-Ray®-Discs, optische Platten ultrahoher Dichte, beliebige andere optische oder magnetische Medien und Disketten. Die computerlesbaren Medien können ein Computerprogramm speichern, welches von mindestens einer Verarbeitungseinheit ausführbar ist und Befehlssätze zum Durchführen verschiedener Operationen umfasst. Beispiele für Computerprogramme oder Computer-Code umfassen Maschinen-Code, wie er z.B. von einem Kompilierer erzeugt wird, und höheren Code umfassende Dateien, die von einem Computer ausgeführt werden, eine elektronische Komponente oder einen Mikroprozessor, der einen Interpretierer verwendet.
  • Obwohl sich die obige Beschreibung hauptsächlich auf Mikroprozessoren oder mehrkernige Prozessoren bezieht, welche Software ausführen, werden einige Ausführungsformen durch eine oder mehrere integrierte Schaltungen ausgeführt, wie z.B. anwendungsspezifische integrierte Schaltungen (ASICS) oder feldprogrammierbare Gate-Arrays (FPGAs). In einigen Ausführungsformen führen solche integrierten Schaltungen Befehle aus, welche auf der Schaltung selbst gespeichert sind.
  • Wie in der vorliegenden Beschreibung verwendet, beziehen sich die Begriffe „Computer“, „Server“, „Prozessor“ und „Speicher“ alle auf elektronische oder andere technologische Vorrichtungen. Diese Begriffe schließen Menschen oder Gruppen von Menschen aus. Für die Zwecke der Beschreibung bedeuten die Begriffe „Anzeigevorrichtung“ oder „Anzeigen“ Anzeigen auf einer elektronischen Vorrichtung. Wie in der vorliegenden Beschreibung verwendet, sind die Begriffe „computerlesbares Medium“, „computerlesbare Medien“ und „maschinenlesbare Medien“ vollständig auf greifbare physische Objekte beschränkt, welche Informationen in einer Form speichern, die von einem Computer lesbar ist. Diese Begriffe schließen alle drahtlosen Signale, drahtgebundenen Download-Signale und alle anderen kurzlebigen Signale aus.
  • Obwohl die Erfindung in Bezug auf zahlreiche spezielle Einzelheiten beschrieben worden ist, erkennt der Fachmann, dass die Erfindung in anderen speziellen Formen verkörpert sein kann, ohne von der Idee der Erfindung abzuweichen. Außerdem veranschaulicht eine Anzahl der Figuren (umfassend 4, 7, 8 und 16) konzeptionell Verfahren. Die speziellen Operationen dieser Verfahren müssen nicht in der genauen dargestellten und beschriebenen Reihenfolge ausgeführt werden. Die speziellen Operationen müssen nicht in einer durchgängigen Reihe von Operationen ausgeführt werden und in verschiedenen Ausführungsformen können verschiedene spezielle Operationen ausgeführt werden. Ferner könnte das Verfahren unter Anwendung mehrerer Teilverfahren oder als Teil eines größeren Makroverfahrens realisiert werden. Somit versteht der Fachmann, dass die Erfindung nicht durch die vorstehenden veranschaulichenden Einzelheiten beschränkt werden soll, sondern stattdessen durch die anhängenden Patentansprüche definiert werden soll.

Claims (20)

  1. Verfahren für ein spezielles Weiterleitungselement (FE) in einem Netzwerk von FEs, umfassend: Empfangen einer Datenmeldung an einem ersten Anschluss des speziellen FE, wobei die Datenmeldung einen Kopf umfasst, welcher (i) einen Ausgabeanschluss für jedes FE entlang einem Pfad von einer Quelle der Datenmeldung bis zu einem Ziel der Datenmeldung und (ii) einen Eingabeanschluss für zumindest jedes FE entlang dem Pfad spezifiziert, den die Datenmeldung zuvor durchlaufen hat; Bestimmen, dass der spezielle Ausgabeanschluss, der für das spezielle FE spezifiziert ist, ein zweiter Anschluss ist, der aktuell nicht betriebsfähig ist; Erzeugen einer Pfadausfallmeldung, welche spezifiziert, dass der zweite Anschluss aktuell nicht betriebsfähig ist, wobei die Pfadausfallmeldung einen Kopf umfasst, welcher die Ausgabeanschlüsse und Eingabeanschlüsse in der Datenmeldung verwendet; und Senden der Pfadausfallmeldung aus dem ersten Anschluss zur Übermittlung an die Quelle der Datenmeldung.
  2. Verfahren nach Anspruch 1, wobei die Bestimmung in einer Datenebene des speziellen Hardware-Weiterleitungselements erfolgt.
  3. Verfahren nach Anspruch 1, wobei der Datenmeldungskopf anfänglich von der Quelle der Datenmeldung mit allen der Ausgabeanschlüsse erzeugt wird, und wobei die Eingabeanschlüsse als Stellvertreterzeichen belassen werden.
  4. Verfahren nach Anspruch 3, wobei jedes FE entlang dem Pfad vor dem speziellen FE (i) den Eingabeanschluss, an welchem das FE die Datenmeldung empfängt, in dem Datenmeldungskopf ausfüllt und (ii) die Datenmeldung aus dem Ausgabeanschluss sendet, der für das FE durch den Datenmeldungskopf spezifiziert ist.
  5. Verfahren nach Anspruch 1, wobei der Datenmeldungskopf anfänglich von der Quelle der Datenmeldung mit allen der Ausgabeanschlüsse und allen der Eingabeanschlüsse für die FEs entlang dem Pfad erzeugt wird.
  6. Verfahren nach Anspruch 1, wobei das Erzeugen der Pfadausfallmeldung Bestimmen des Pfades von der Quelle bis zu dem speziellen FE und Erzeugen eines Pakets umfasst, welches eine Umkehrung des bestimmten Pfads durchläuft.
  7. Verfahren nach Anspruch 1, wobei das Erzeugen der Pfadausfallmeldung Erzeugen eines Paketkopfs für die Pfadausfallmeldung umfasst, welcher (i) einen Eingabeanschluss für jedes FE entlang einem Pfad von dem speziellen FE bis zu der Quelle und (ii) einen Ausgabeanschluss für jedes FE entlang dem Pfad von dem speziellen FE bis zu der Quelle spezifiziert.
  8. Verfahren nach Anspruch 7, wobei der Pfad von dem speziellen FE bis zu der Quelle eine Umkehrung des Pfads von der Quelle bis zu dem FE ist.
  9. Verfahren nach Anspruch 8, wobei (i) die in dem Datenmeldungskopf spezifizierten Ausgabeanschlüsse als Eingabeanschlüsse in dem Pfadausfallmeldungskopf verwendet werden und (ii) die in dem Datenmeldungskopf spezifizierten Eingabeanschlüsse als Ausgabeanschlüsse in dem Pfadausfallmeldungskopf verwendet werden.
  10. Verfahren nach Anspruch 7, wobei die Pfadausfallmeldung ferner einen Indikator umfasst, dass der zweite Anschluss des speziellen FE für folgende Pakete nicht verwendet werden sollte, bis der zweite Anschluss wieder betriebsfähig wird.
  11. Verfahren nach Anspruch 1, wobei das Erzeugen der Pfadausfallmeldung Modifizieren der empfangenen Datenmeldung umfasst.
  12. Verfahren nach Anspruch 1, wobei das Erzeugen der Pfadausfallmeldung Erzeugen einer neuen Datenmeldung an dem speziellen FE umfasst.
  13. Verfahren nach Anspruch 1, wobei die Quelle der Datenmeldung eine Topologie des Netzwerks von FEs speichert und nach dem Empfang der Pfadausfallmeldung die gespeicherte Netzwerktopologie aktualisiert, um anzuzeigen, dass der zweite Anschluss des speziellen FE nicht betriebsfähig ist.
  14. Verfahren nach Anspruch 13, wobei die Quelle der Datenmeldung ferner eine Netzwerksteuerung darüber benachrichtigt, dass der zweite Anschluss aktuell nicht betriebsfähig ist, nachdem sie die Pfadausfallmeldung empfangen hat.
  15. Hardware-Weiterleitungselement (HFE) in einem Netzwerk von Weiterleitungselementen (FEs), wobei das HFE umfasst: eine erste Netzwerk-Schnittstelle zum Empfangen einer Datenmeldung, wobei die Datenmeldung einen Kopf umfasst, welcher (i) einen Ausgabeanschluss für jedes FE entlang einem Pfad von einer Quelle der Datenmeldung bis zu einem Ziel der Datenmeldung und (ii) einen Eingabeanschluss für zumindest jedes FE entlang dem Pfad spezifiziert, welches die Datenmeldung zuvor durchlaufen hat; eine Gruppe von Datenebenenschaltungen zum (i) Bestimmen, dass der spezielle Ausgabeanschluss, der für das HFE spezifiziert ist, eine zweite Netzwerk-Schnittstelle des HFE ist, die aktuell nicht betriebsfähig ist, (ii) Erzeugen einer Pfadausfallmeldung, welche spezifiziert, dass die zweite Netzwerk-Schnittstelle aktuell nicht betriebsfähig ist, wobei die Pfadausfallmeldung einen Kopf umfasst, welcher die Ausgabeanschlüsse und Eingabeanschlüsse in der Datenmeldung verwendet, und (iii) Senden der Pfadausfallmeldung über die erste Netzwerk-Schnittstelle zur Übermittlung an die Quelle der Datenmeldung.
  16. HFE nach Anspruch 15, wobei der Datenmeldungskopf anfänglich durch die Quelle der Datenmeldung mit allen der Ausgabeanschlüsse erzeugt wird, und wobei die Eingabeanschlüsse als Stellvertreterzeichen belassen werden, wobei jedes FE entlang dem Pfad vor dem HFE (i) den Eingabeanschluss, an welchem das FE die Datenmeldung empfängt, in dem Datenmeldungskopf ausfüllt und (ii) die Datenmeldung aus dem Ausgabeanschluss sendet, der für das FE durch den Datenmeldungskopf spezifiziert ist.
  17. HFE nach Anspruch 15, wobei: die Gruppe von Datenebenenschaltungen die Pfadausfallmeldung durch Erzeugen eines Paketkopfs für die Pfadausfallmeldung erzeugt, welcher (i) einen Eingabeanschluss für jedes FE entlang einem Pfad von dem HFE bis zu der Quelle und (ii) einen Ausgabeanschluss für jedes FE entlang dem Pfad von dem HFE bis zu der Quelle spezifiziert; die in dem Datenmeldungskopf spezifizierten Ausgabeanschlüsse als Eingabeanschlüsse in dem Pfadausfallmeldungskopf verwendet werden, und die in dem Datenmeldungskopf spezifizierten Eingabeanschlüsse als Ausgabeanschlüsse in dem Pfadausfallmeldungskopf verwendet werden.
  18. HFE nach Anspruch 15, wobei die Pfadausfallmeldung ferner einen Indikator umfasst, dass die zweite Netzwerk-Schnittstelle des HFE für folgende Pakete nicht verwendet werden sollte, bis die zweite Netzwerk-Schnittstelle wieder betriebsfähig wird.
  19. HFE nach Anspruch 15, wobei die Quelle der Datenmeldung eine Topologie des Netzwerks von FEs speichert und nach dem Empfang der Pfadausfallmeldung die gespeicherte Netzwerktopologie aktualisiert, um anzuzeigen, dass der zweite Anschluss des speziellen FE nicht betriebsfähig ist.
  20. HFE nach Anspruch 19, wobei die Quelle der Datenmeldung ferner eine Netzwerksteuerung darüber benachrichtigt, dass der zweite Anschluss aktuell nicht betriebsfähig ist, nachdem sie die Pfadausfallmeldung empfangen hat.
DE112019001214.2T 2018-03-08 2019-03-05 Erzeugung von Pfadausfallmeldung an Weiterleitungselement Pending DE112019001214T5 (de)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201862640559P 2018-03-08 2018-03-08
US62/640,559 2018-03-08
US201862646341P 2018-03-21 2018-03-21
US62/646,341 2018-03-21
US15/948,990 US10826815B2 (en) 2017-04-09 2018-04-09 Verification of access control list rules provided with a message
US15/948,991 2018-04-09
US15/948,990 2018-04-09
US15/948,991 US10764170B2 (en) 2017-04-09 2018-04-09 Generation of path failure message at forwarding element based on message path
US15/948,992 US10757005B2 (en) 2017-04-09 2018-04-09 Execution of packet-specified actions at forwarding element
US15/948,992 2018-04-09
PCT/US2019/020842 WO2019173406A1 (en) 2018-03-08 2019-03-05 Generation of path failure message at forwarding element

Publications (1)

Publication Number Publication Date
DE112019001214T5 true DE112019001214T5 (de) 2020-11-19

Family

ID=67846885

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019001214.2T Pending DE112019001214T5 (de) 2018-03-08 2019-03-05 Erzeugung von Pfadausfallmeldung an Weiterleitungselement

Country Status (2)

Country Link
DE (1) DE112019001214T5 (de)
WO (1) WO2019173406A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10757005B2 (en) 2017-04-09 2020-08-25 Barefoot Networks, Inc. Execution of packet-specified actions at forwarding element
CN113259143B (zh) * 2020-02-07 2023-04-18 阿里巴巴集团控股有限公司 信息处理方法、设备、系统及存储介质
US11632316B2 (en) * 2020-12-22 2023-04-18 Hewlett Packard Enterprise Development Lp Method and system for reporting unavailability in a label-switched path

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1320224B1 (de) * 2001-12-12 2007-11-21 Alcatel Lucent Telekommunikationsnetzwerk und entsprechenden Paketkopf
US7852771B2 (en) * 2004-06-30 2010-12-14 Ciena Corporation Method and apparatus for implementing link-based source routing in generic framing protocol
US7471669B1 (en) * 2004-09-30 2008-12-30 Nortel Networks Limited Routing of protocol data units within a communication network
US8619546B2 (en) * 2010-08-17 2013-12-31 Alcatel Lucent Method and apparatus for coping with link failures in central control plane architectures

Also Published As

Publication number Publication date
WO2019173406A1 (en) 2019-09-12

Similar Documents

Publication Publication Date Title
US10764170B2 (en) Generation of path failure message at forwarding element based on message path
US9438512B2 (en) Stacking metadata contexts for service chains
DE112008002550B4 (de) Verfahren und System für virtuelle Schnittstellenkommunikation
DE60213509T2 (de) Verfahren und Vorrichtung zur Verbesserung der Verfügbarkeit von Wegeleitsystemen mit mehrwege-Kostengleichheit
US20200014663A1 (en) Context aware middlebox services at datacenter edges
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE112020002497T5 (de) System und verfahren zur dynamischen zuweisung von reduktionsmotoren
DE112018008119T5 (de) Modifizieren einer Ressourcenzuweisung oder einer Strategie in Reaktion auf Steuerungsinformationen von einer virtuellen Netzwerkfunktion
DE102013208431B4 (de) Großer verteilter Switch auf Fabric-Basis unter Verwendung virtueller Switches und virtueller Steuereinheiten
DE102014117460A1 (de) Programmierbares verteiltes Networking
DE60301717T2 (de) Verfahren und Vorrichtung zur inhaltsorientierten Weiterleitung von Paketen im Netz mit Datenspeichervorrichtungen
DE102005032479B4 (de) Fernsteuerung eines Vermittlungsknotens in einem Stapel von Vermittlungsknoten
DE112017000152T5 (de) Virtueller Core eines CCAP (Converged Cable Access Platform)
DE112016004860T5 (de) Verteilte Regelbereitstellung in einer Extended Bridge
DE112019001214T5 (de) Erzeugung von Pfadausfallmeldung an Weiterleitungselement
DE10393571T5 (de) Verfahren und System zum Validieren logischer End-to-End-Zugriffspfade in Storage Area Netzwerken
DE102015013946A1 (de) Netzwerkbasiertes Service Function Chaining
DE112005003124T5 (de) Schnittstelle PCI Express zu erweitertem Schaltnetzwerk
DE102019104942A1 (de) Kommunikation einer Nachricht unter Verwendung einer Netzwerkschnittstellensteuerung in einem Subnetz
EP3192226B1 (de) Vorrichtung und verfahren zur steuerung eines kommunikationsnetzwerks
CN106549780A (zh) 一种网络配置方法、装置及系统
US7254628B2 (en) Network management system with validation of policies
CN109787938A (zh) 实现访问虚拟私有云的方法、装置及计算机可读存储介质
DE102020102981A1 (de) Auswahl von Eingängen für Nachschlagoperationen
CN111010343A (zh) 一种转发组播报文的方法、装置、网络设备及存储介质

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012240000

Ipc: H04L0041000000