DE102008042344A1

DE102008042344A1 - Programmierbare passive Datenerfassungseinheit

Info

Publication number: DE102008042344A1
Application number: DE102008042344A
Authority: DE
Inventors: Slawornir Santa Clara Ilnicki
Original assignee: Agilent Technologies Inc
Current assignee: Viavi Solutions Inc
Priority date: 2007-10-26
Filing date: 2008-09-25
Publication date: 2009-05-28
Also published as: US20090109973A1; US8427966B2

Abstract

Eine konfigurierbare Datenerfassungseinheit 10 nutzt vorteilhaft voneinander abhängige Steuerelemente 12, 14, 15, 17 einer Datenerfassungseinheit, die Datensteuersignale von einem Steuerelement an die anderen weiterleiten, um die Entnahme von Daten zu steuern. Die Steuerelemente arbeiten jeweils parallel an einem Wort, und zwar auf der Grundlage eines von einem der Steuerelemente festgelegten Zustands. Die zu berücksichtigenden Daten werden von Zeitsteuerungs-Offsets festgelegt, die von der jeweiligen Länge des Paketkopfbereichs abhängen, und eine an den Daten auszuführende Funktion wird von einzelnen Steuereinheiten auf der Grundlage von Vorlageninformationen, die jedem Steuerelement eigen sind, gesteuert. Die Datenerfassungseinheit weiß nichts über Protokolle. Sie arbeitet an einem Strom von Paketworten und führt ihre Funktionen entsprechend festgelegten Vorlagen aus. Es ist der Hostrechner 121, der die Datenerfassungseinheit steuert und der festlegt, welcher Protokoll-Kopfbereich ausgewertet werden soll und in welcher Weise dies zu geschehen hat. Der Host-Steuerrechner weist die Datenerfassungseinheit über festgelegte Vorlagen, die als Definitionen von Zustandsmaschinen dienen, an, welche Aufgaben sie wann durchführen soll.

Description

TECHNISCHES GEBIET
Diese Beschreibung betrifft die Überwachung von Netzwerkverkehr mit Hilfe von Datenerfassungseinheiten (grobes) und insbesondere Systeme und Verfahren zum Aufbau dieser Datenerfassungseinheiten innerhalb einer bestehenden Struktur.
DER ERFINDUNG ZUGRUNDE LIEGENDER ALLGEMEINER STAND DER TECHNIK
Vorhandene Datenerfassungseinheiten führen Überwachungsfunktionen am Internetverkehr aus. Zu diesen Überwachungsfunktionen gehört üblicherweise die Durchführung von bestimmten Operationen an Daten (wie zum Beispiel Ethernet) in Paketen oder Rahmen, die einen bestimmten Punkt (den Punkt, an dem sich die Datenerfassungseinheit befindet) in dem Netzwerk durchlaufen. Übliche Funktionen wären beispielsweise das Filtern von Daten, das Erfassen von Daten, das Weiterleiten von erfassten Daten, das Zusammenfassen von Daten usw. Bei den vorhandenen Datenerfassungseinheiten handelt es sich um eigenständige Einheiten, die die Übertragungsleitung über einen Splitter oder in Form von einer eingebundenen Einheit (in-line device) anzapfen. Manche dieser Datenerfassungseinheiten werden in Schnittstellenwandlern in Verbindung mit Vermittlungsstellen und Routern angeordnet. Die Schnittstellenwandler dienen dazu, Datensignale von einem Medium, z. B. Lichtwellenleiter, zur Übertragung auf einem anderen Medium, z. B. Kupfer, zu wandeln. Die vorhandenen Datenerfassungseinheiten, die als eigenständige Einheiten arbeiten, können so konfiguriert werden, dass sie unterschiedliche Arten von Daten in unterschiedlichen Anordnungen erfassen, sie sind kostspielig und ihr Platzbedarf entspricht gewöhnlich der Größe eines Laptops. Datenerfassungseinheiten, die Teil eines Schnittstellenwandlers oder einer Vermittlungsstellen- oder Router-Leitungsanschlusskarte sind, haben zwar einen geringen Platzbedarf, weisen aber dahin gehend eine Beschränkung auf, dass sie sehr spezifisch sind. Wenn man also versucht, eine Datenerfassungseinheit bei eingeschränktem Platzangebot zu verwenden, muss man den Funktionsumfang, den die Datenerfassungseinheit bereitstellt, beschränken, damit man eine Datenerfassungseinheit verwenden kann, die nur einen geringen Platzbedarf hat. Eine solche Datenerfassungseinheit ist entweder in einem kundenprogrammierbaren Universalschaltkreis (FPGA) oder in Hardware wie einem ASIC realisiert. Bei einer typischen Ausführung einer Datenerfassungseinheit in einem ASIC ist es nicht möglich, die Betriebsweise einer bestimmten Datenerfassungseinheit zu ändern.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Eine konfigurierbare Datenerfassungseinheit nutzt vorteilhaft voneinander abhängige Steuerelemente der Datenerfassungseinheit, die Datensteuersignale von einem Steuerelement an das andere weiterleiten, um die Datenentnahme zu steuern. Die Steuerelemente arbeiten jeweils parallel an einem Wort, und zwar auf der Grundlage eines von einem der Steuerelemente festgelegten Zustands. Die zu berücksichtigenden Daten werden von Zeitsteuerungs-Offsets festgelegt, die von der jeweiligen Länge des Paketkopfbereichs abhängen, und eine an den Daten auszuführende Funktion wird von einzelnen Steuereinheiten auf der Grundlage von Vorlageninformationen, die jedem Steuerelement eigen sind, gesteuert. Die Datenerfassungseinheit weiß nichts über Protokolle. Sie arbeitet an einem Strom von Paketworten und führt ihre Funktionen entsprechend festgelegten Vorlagen aus. Es ist der Hostrechner, der die Datenerfassungseinheit steuert und der festlegt, welcher Protokoll-Kopfbereich ausgewertet werden soll und in welcher Weise dies zu geschehen hat. Der Host-Steuerrechner weist die Datenerfassungseinheit über festgelegte Vorlagen, die als Definitionen von Zustandsmaschinen dienen, an, welche Aufgaben sie wann durchführen soll.
In einer Ausführungsform dienen Vorlagen, die in verschiedene Steuerelemente der Datenerfassungseinheit geladen werden, zur Steuerung der Funktionen, die von dem zugehörigen Steuerelement durchgeführt werden. Diese Funktionen hängen von Signalen ab, die von anderen der Steuerelemente empfangen werden, und sie sind unabhängig von einem zentralen Protokollspeicher. Dadurch kann die Datenerfassungseinheit dauerhaft festverdrahtet gesteuert werden, wie beispielsweise durch einen ASIC. Das Profil der Datenerfassungseinheit, die diese Konzepte verwendet, kann so kompakt gestaltet werden, dass es den Abmessungen von vorhandenen Datenerfassungseinheiten, die einen geringen Platzbedarf haben, entspricht.
Im Vorstehenden wurden die Merkmale und die technischen Vorteile der vorliegenden Erfindung in groben Zügen aufgezeigt, damit sich die folgende ausführliche Beschreibung der Erfindung besser verstehen lässt. Weitere Merkmale und Vorteile der Erfindung, die den Gegenstand der Ansprüche der Erfindung bilden, werden nachstehend beschrieben. Für den Fachmann dürfte es sich verstehen, dass die Konzeption und die im Einzelfall beschriebene Ausführungsform ohne Weiteres als Änderungs- oder Gestaltungsgrundlage für andere Strukturen verwendet werden können, um dieselben Zwecke der vorliegenden Erfindung zu erfüllen. Der Fachmann sollte auch verstehen, dass solche gleichwertigen Konstruktionen nicht von der Wesensart und dem Umfang der in den beigefügten Ansprüchen dargelegten Erfindung abweichen. Die neuartigen Merkmale, die sowohl im Hinblick auf den Aufbau als auch auf die Betriebsweise der Erfindung als kennzeichnend für die Erfindung erachtet werden, lassen sich zusammen mit weiteren Aufgaben und Vorteilen anhand der folgenden Beschreibung besser verstehen, wenn diese in Verbindung mit den beiliegenden Figuren betrachtet wird. Es sollte sich jedoch ausdrücklich verstehen, dass jede einzelne der Figuren lediglich zum Zweck der Veranschaulichung und Beschreibung vorgesehen und nicht als Angabe der Beschränkungen der vorliegenden Erfindung zu verstehen ist.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Damit sich die vorliegende Erfindung besser verstehen lässt, wird nun Bezug auf die folgenden Beschreibungen in Verbindung mit den beigefügten Zeichnungen genommen, bei denen:
1 ein Blockschaltbild einer Ausführungsform einer Datenerfassungseinheit ist, die gemäß den Lehren der vorliegenden Erfindung aufgebaut ist;
die 2, 3, 4 und 5 Ausführungsformen von Vorlagen zeigen, die zur Programmierung von mindestens einem Teil der passiven Datenerfassungseinheit verwendet werden;
6 eine Ausführungsform eines Prozesses zur Steuerung der Datenerfassung mithilfe einer passiven programmierbaren Datenerfassungseinheit zeigt; und
die 6 bis 9 Ausführungsformen von Aspekten des Betriebs der passiven Datenerfassungseinheit zeigen.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Diese Erfindung befasst sich mit einer in Hardware ausgeführten Datenerfassungseinheit, welche aus mehreren Steuerelementen besteht. Jedes Steuerelement verfügt über integrierte Funktionen, die von Eingangssignalen von anderen Steuerelementen gesteuert werden, sowie Vorlagen, die einem bestimmten Steuerelement zugeordnet sind, das festlegt, wann eine integrierte Funktion ausgeführt werden soll. In einer Ausführungsform enthält die gegebene Art der Ausführung einer Datenerfassungseinheit, die gemäß den Konzepten dieser Erfindung arbeitet, Steuerelemente wie zum Beispiel eine Auswerteeinheit für Paketkopfbereiche (Packet Header Parser, PHP), ein Paketfilter (Packet Filter, PF), eine Paketdaten-Entnahmeeinheit (Packet Data Extractor, PDE), eine Einheit zur Entnahme von Paketstichproben (Packet Sampler, PS), einen Ausgangspufferspeicher (Output Buffer, OB) und eine Konfigurationssteuereinheit (Configuration Controller, CC). Ankommende Pakete oder Rahmen werden von der Datenerfassungseinheit in Form von Worten, d. h. in Form von jeweils einem Paketwort, empfangen. Ein Paketwort könnte eine Größe von einem, zwei, vier, acht usw. Byte haben. Dies hängt von der jeweiligen Art der Ausführung ab. Ein Paketwort ist eine Einheit, an der die Steuerelemente Operationen ausführen. Zu jedem Paketwort gehört ein Versatz, der für den Beginn des Paketwortes in Bezug auf den Beginn einer festgelegten Grenze von Bedeutung ist, welche in einem typischen Fall der Beginn eines bestimmten Protokoll-Kopfbereichs sein könnte. Im Allgemeinen empfängt das Steuerelement ein Paketwort, wenn dieses die Datenerfassungseinheit durchläuft, und es verwendet Daten aus seiner Vorlage, um festzustellen, ob eine Operation durchgeführt werden soll. Wenn Paketworte ankommen, prüft die PHP die Daten, um festzustellen, ob sie für Daten in ihrer Vorlage von Bedeutung sind, indem sie sich den Offset und den Typ eines Kopfbereichs anschaut, der gerade von der PHP verarbeitet wird. Gleichzeitig findet eine parallele Ausführung des PF, der PDE und der PS statt, der PF und die PDE werden jedoch vom Ausgangssignal der PHP gesteuert, bei dem es sich um einen Typ eines Paketkopfbereichs, der auch als Zustand (Zustand der Verarbeitung des Paketkopfbereichs) bezeichnet wird, und den Offset vom Beginn des Kopfbereichs handelt. Die PS, sofern sie mittels Konfiguration aktiviert wird, führt Operationen an einem ganzen Paket oder Rahmen durch und liefert als Ausgabe ein Signal, wenn ein bestimmtes Paket für eine Paketprüfung in Betracht kommt. In einer Ausführungsform würde die PS anstelle eines Signals "festschreiben" ("commit") ein Signal "überspringen" ("skip") senden, und dies wäre dann eine Anweisung an den PF und/oder die PDE, nichts mit dem Paket zu machen. Bei einer vollkommenen Übereinstimmung mit dem Paketfilter werden gegebenenfalls entnommene Daten dann "festgeschrieben", d. h., sie sind gültig und können versendet werden. Die PDE entnimmt Daten und speichert diese Daten in einem Pufferspeicher (OB). Wenn der Pufferspeicher bestimmte Kriterien wie zum Beispiel die Uhrzeit oder die Größe des Pufferspeichers erfüllt, werden die Daten in dem Pufferspeicher von der Datenerfassungseinheit versendet. Die hier erörterten Konzepte ermöglichen die Integration einer Datenerfassungseinheit in einen ASIC oder einen FPGA.
1 ist ein Blockschaltbild einer Ausführungsform einer Datenerfassungseinheit, wie zum Beispiel der Datenerfassungseinheit 10, die gemäß den Lehren der vorliegenden Erfindung aufgebaut ist. In einer Ausführungsform, die in 1 gezeigt ist, ist die Datenerfassungseinheit eine eingebundene Einheit, die Verkehr (nicht gezeigt) durchleitet und in der Lage ist, "vorbeikommende" Pakete abzufangen, sie zu verarbeiten und die Ergebnisse an einen von der Datenerfassungseinheit entfernten Ort zu senden. Eine Hardware-Ausführung einer solchen Datenerfassungseinheit könnte ein abgeänderter standardmäßiger Small-Form-Factor-Pluggable-(SFP-)Gigabit-Schnittstellenwandler (Sendeempfänger) sein. Der standardmäßige SFP ist eine analoge Einheit, die elektrische Signale (NRZ-Daten) in optische oder elektrische Signale von 1 Gigabit Ethernet wandelt. Die Datenerfassungseinheit 10 "zergliedert" die analogen Signale, indem sie sie in digitale Signale wandelt und diesen Prozess beim Aussenden wieder umkehrt, d. h. die Signale von digital nach analog wandelt. Eine typische Lichtwellenleiter-Version eines SFP hat eine Größe von 13,7 mm (Breite) × 55,9 mm (Länge) × 8,5 mm (Höhe). Das bedeutet, dass eine in solch einen Sendeempfänger eingebettete Datenerfassungseinheit ein sehr kleiner ASIC-Chip sein muss, beispielsweise ein ASIC-Chip mit einer Größe von 5 × 5 mm.
Die in 1 gezeigte passive programmierbare Datenerfassungseinheit verarbeitet Pakete von einem Zugriffspunkt eines Datennetzwerks 120, wie zum Beispiel vom Zugriffspunkt 11, entsprechend festgelegten/konfigurierten Paketfiltern, wie etwa den Paketfiltern 14, und vergleicht über bestimmte Zeiträume Daten von dem Paket entsprechend festgelegten Vorlagen mit Daten in den gespeicherten Paketfilterwerten (Paketfilterdefinition). Die Datenerfassungseinheit enthält mindestens eine Auswerteeinheit für Paketkopfbereiche (PHP) wie zum Beispiel die Auswerteeinheit 12, mehrere Paketfilter (PF) 14, mehrere Paketdaten-Entnahmeeinheiten (PDE) 15 und mindestens einen Ausgangspufferspeicher (OB) 16. Die Auswerteeinheit für Paketkopfbereiche, die Paketfilter und die Paketdaten-Entnahmeeinheiten werden über konfigurierte Vorlagen gesteuert.
Das erste Element von den mehreren Steuerelementen der Datenerfassungseinheit in dieser Ausführungsform ist beispielsweise eine Auswerteeinheit für Paketkopfbereiche. Ihre Vorlage informiert die PHP darüber, wie sie Paketkopfbereiche verarbeiten (auswerten) soll. Es ist eine Zustandsmaschine, bei der jeder Zustand einen anderen Typ eines Protokoll-Kopfbereichs darstellt. Das Signal, das den Typ des Protokoll-Kopfbereichs anzeigt, steuert die Vorlagen der Paketfilter und der Paketdaten-Entnahmeeinheiten, welche die anderen Steuerelemente zur Datenentnahme der Datenerfassungseinheit aufweisen. Die Vorlagen haben Anweisungscharakter und können von Zeit zu Zeit geändert werden, was später erörtert wird. Die Entnahme-Steuerelemente der Datenerfassungseinheit sind voneinander abhängig, und diese gegenseitige Abhängigkeit wird teilweise von Daten in den verschiedenen Vorlagen gesteuert, und sie sind auch von dem Zustand von einem oder mehreren der Steuerelemente abhängig.
Der jeweilige Zustand der Paketverarbeitung wird vom Typ des Protokoll-Kopfbereichs dargestellt, der von der Datenerfassungseinheit gerade empfangen und verarbeitet wird. In einer Ausführungsform erfolgt die Realisierung in Form von einer Datenflussmaschine, in der Pakete bei ihrer Ankunft jeweils paketwortweise verarbeitet werden. Ein Paketwort wird als eine Multiplizierung von Bytes definiert, d. h., in Abhängigkeit von der gegebenen Art der Ausführung könnte es eine Anzahl von einem, zwei, vier, acht usw. Bytes pro Wort sein. Ein Paketwort ist eine Einheit, an der ein Steuerelement zu einem bestimmten Zeitpunkt Operationen durchführt. Eine Ausführungsform, die hier beschrieben und in Form der Vorlagen beispielhaft aufgezeigt wird, nimmt eine Paketwortlänge von zwei Byte an. Wenn die Paketdaten durch die Datenerfassungseinheit fließen, werden sie zeitgleich mit der Filterung und der Datenentnahme, der sie unterzogen werden, ausgewertet. Der Grund dafür, dass Pakete "on the fly", d. h. ohne zeitliche Verzögerung (in Echtzeit), verarbeitet werden, liegt in dem Bestreben, die Latenzzeit zu verringern, wodurch die Datenerfassungseinheit mit dem ankommenden Datenverkehr Schritt halten kann.
Während Paketworte durch die Auswerteeinheit für Paketkopfbereiche (PHP) fließen, verwendet die PHP die Daten aus ihrer Vorlage, um festzustellen, welches der nächste Paketkopfbereich ist und um ferner festzustellen, wann der nächste Kopfbereich beginnt. Das Ausgangssignal von der PHP ist der Kopfbereich-Typ (ein Zustand), der nachstehend erörtert wird. Ebenfalls von der PHP bestimmt wird der Kopfbereich-Startpunkt als ein Offset eines Paketwortes im Verhältnis zum Beginn eines bestimmten Paketkopfbereichs. Es sollte hier darauf hingewiesen werden, dass die PHP das Konzept des Paketkopfbereichs nicht versteht. Sie wird über ihre Vorlage "informiert" beziehungsweise dahin gehend programmiert, dass sie weiß, welche Schritte durchzuführen sind, wenn der Paket-Offset einen bestimmten Wert erreicht. Beispielsweise kann die PHP die Daten dem Paketkopfbereich entnehmen, der die Größe des Paketkopfbereichs beschreibt. Sie erhält auch eine Anweisung, wo sie nach dem nächsten Typ eines Protokoll-Kopfbereichs Ausschau halten soll. Der Typ des Kopfbereichs und der Offset steuern die Vorlagen des PF und der PDE. Ein erster Paketkopfbereich ist zum Beispiel standardmäßig Ethernet. Dies ließe sich natürlich ändern, indem man in der PHP eine andere Vorlage konfiguriert. Die PHP (auf der Grundlage der Daten ihrer Vorlage) schaut nach dem Ethernet-Typ, der sich am Offset 6 (16-Bit-Worte) befindet und der PHP mitteilt, dass es bei Fertigstellung des Ethernet-Kopfbereichs einen nächsten, dem Typ entsprechenden Protokoll-Kopfbereich geben wird. Im Falle von Ethernet hat das Paket eine feste Größe. VLAN beispielsweise könnte, muss aber nicht, als ein anderer Kopfbereich-Typ angesehen werden. Wenn nicht, muss die PHP mit der Verarbeitung von VLANs fortfahren, wenn Ethernet plus VLAN als ein Typ eines Protokoll-Kopfbereichs angesehen werden. Wenn das nächste Protokoll zum Beispiel IP ist, muss die PHP während der Verarbeitung des Kopfbereichs auch die Größe des IP-Protokollkopfbereichs feststellen. Bei Verwendung von Optionen kann der IP-Protokollkopfbereich unterschiedlich groß sein, und deshalb gibt die PHP-Vorlage an, wo sich die Größe des IP-Kopfbereichs befindet. Sobald dieses Feld als ein Paketwort an der PHP ankommt, wird es entsprechend verarbeitet, und die Größe des IP-Protokollkopfbereichs wird ermittelt.
Am Offset 6 haben die ankommenden Daten folglich einen Wert, der den Ethernet-Typ darstellt. Die Vorlage der PHP enthält Werte, wobei jeder Wert einen Ethernet-Typ darstellt. Die Auswerteeinheit für Paketkopfbereiche hat eine Maschine (nicht gezeigt), die, sobald die Paketdaten den Offset 6 erreichen, die diversen Werte des Ethernet-Typs aus der Vorlage parallel vergleicht, wobei sie auf Übereinstimmung mit den jeweiligen Daten schaut, die in dem Datenstrom am Offset 6 enthalten sind. Wenn der Ethernet-Typ (der in dem jeweiligen ankommenden Datenwert enthalten ist) mit einem Wert übereinstimmt, der sich in der Vorlage befindet, aktiviert die PHP auf der Grundlage von Informationen, die sie aus der Vorlage erhalten hat, ein Signal (einen Wert) für den nächsten Kopfbereich-Typ oder Zustand, wenn der Ethernet-Kopfbereich das Ende erreicht. Es sei angemerkt, dass die Datenerfassungseinheit diesen Typ nicht selbst "kennen" musste, da die Vorlage die Informationen, die erforderlich sind, um eine Umsetzung aus dem in den jeweiligen Daten enthaltenen Wert in einen Datentyp zu ermöglichen, mitführt. Dies macht es dann verhältnismäßig einfach, die Datenerfassungseinheit für verschiedene Protokolle, die sich entwickeln, zu programmieren, indem nach Bedarf verschiedene Vorlagen an die PHP oder den PF oder die PDE gesendet werden.
Da die PHP, der PF und die PDE Paketworte auf deren Weg durch die Datenerfassungseinheit parallel verarbeiten, laufen mehrere Instanzen des PF und der PDE parallel, wobei sie gleichzeitig entsprechend ihren eigenen jeweiligen Vorlagen Daten filtern oder dem Paket entnehmen. Anders ausgedrückt, die passive programmierbare Datenerfassungseinheit verfügt über integrierte Operationen, die nur aufgerufen werden, wenn Paketdaten bestimmte in den Vorlagen angegebene Offsets erreichen. Wie vorstehend erörtert wurde, weiß die Datenerfassungseinheit selbst nichts über das Protokoll, das sie befolgt, noch weiß sie etwas über das Paket, das sie verarbeitet. Die Datenerfassungseinheit weiß, wonach sie sucht und wann das Gesuchte ankommen wird, wobei dieses Wissen auf Informationen aus der Vorlage beruht und durch Wert- und Maskentabellen gestützt wird. Die Datenerfassungseinheit versteht folglich nicht, dass ein Datenstrom ein Ethernet- oder IP-Kopfbereich ist. In der Datenerfassungseinheit befindliche Elemente werden jedoch über die Vorlagen programmiert, die jedem Steuerelement der Datenerfassungseinheit eigen sind und diesem Element Anweisungen hinsichtlich der Schritte geben, die durchzuführen sind, wenn ein bestimmtes Paket einen bestimmten Offset erreicht. Die Datenerfassungseinheit selbst weiß, wie alle Funktionen, die beispielsweise durch eine Festverdrahtung, durch einen ASIC usw. gesteuert werden, durchzuführen sind. Die Festverdrahtung weiß jedoch nicht, welche Funktion sie durchführen oder wann sie diese Funktion durchführen soll, außer wenn sie von Zeit zu Zeit Anweisungen von einer Vorlage enthält, die in eines der Elemente der Datenerfassungseinheit geladen wird. Es sei angemerkt, dass die Datenerfassungseinheit mit einem standardmäßigen Satz von Werten konfiguriert werden kann, so dass die Datenerfassungseinheit beispielsweise auch dann funktioniert, wenn eine oder mehrere der Vorlagen aufgrund von beschädigten Daten oder aufgrund von Problemen beim Herunterladen usw. nicht zur Verfügung stehen. Es sei auch angemerkt, dass auf Wunsch jeweils nur bestimmte Datenfelder überwacht werden müssen. Die Vorlagen ermöglichen es, jede Datenerfassungseinheit neu zu konfigurieren, damit sie nach Bedarf andere Daten oder andere Protokolle verarbeiten kann.
2 zeigt beispielhalber Daten 20 einer PHP-Vorlage für eine mit einem typischen Protokollstapel konfigurierte Datenerfassungseinheit.
3 zeigt einen PHP-Protokollbaum auf der Grundlage der Vorlage 20. Wenn die PHP am Offset 6 des Ethernet-Kopfbereichs folglich "entdeckt" (was vorstehend auf der Grundlage der von der PHP verwendeten Vorlage erörtert wurde), dass es sich bei dem nächsten Protokoll um das IP handelt, aktiviert sie das Signal, zum Beispiel, indem sie bei Erreichen des Offsets 7 einen Wert von 3 (Zustand = 3) setzt. Nach Abschluss des 6. Offsets lautet der dann aktuelle Zustand der Paketverarbeitung "IP" (Zustand = 3). Dies tritt ein, wenn der passende Ethernet-Typ 0x800 lautet, wie beim Prozess 30 gezeigt ist. Wenn dies geschieht, setzt die PHP den Offset auf 0 zurück, da alle anderen Vorlagen (PF und PDE) auf einem Offset vom Beginn des Paketkopfbereichs beruhen, der gerade vorbeikommt. Es sei hier angemerkt, dass sich die PHP ebenfalls im Zustand "IP" (Zustand = 3) befindet. Anders ausgedrückt, jedes Steuerelement tritt in einen von der PHP gesteuerten Zustand ein und führt diesem Zustand entsprechende Funktionen aus, wobei es seine Vorlage als Angabe von durchgeführten Funktionen verwendet.
4 veranschaulicht eine Ausführungsform 40 der PF-Vorlage und der Wert- und Maskentabellen des Paketfilters. Die Datenerfassungseinheit kann mehrere Paketfilter ausführen, die auf Wunsch zu Gruppen zusammengefasst werden können, so dass ein Typ von Vorlage gemeinsam benutzt werden kann, aber die Datenerfassungseinheit kann mehrere unterschiedliche Vorlagen haben, die gleichzeitig ausgeführt werden. Alle Filter werden parallel verarbeitet. Um jedoch Irritationen in dieser Beschreibung zu vermeiden, werden bei dem behandelten Beispiel nur eine einzige Paketfilter-Definition und zwei verschiedene Filter erörtert. Die Vorlage 40 ist für ein Filter mit 5 Tupeln (IP-Quellen- und -Zieladresse, IP-Protokolltyp und Anschlussquelle und -ziel) bestimmt. Die Vorlage stellt in dieser Ausführungsform eine Paketwort-Größe von 2 Byte dar.
Im Betrieb macht der PF nichts und erlaubt Paketen, vorüberzuziehen, bis er ein Signal 101 (1) von der PHP empfängt (wie vorstehend erörtert wurde), dass die ankommenden Paketworte IP-Kopfbereichdaten sind. Wenn der PF von dem Signal von der PHP aktiviert wird, ruft er Daten aus der Feldertabelle 42 ab, die Teil der Vorlageninformationen ist. Der Offset auf diese Tabelle befindet sich in der Kopfbereich-Tabelle 41 und hängt vom Typ des Protokoll-Kopfbereichs oder vom Zustand des Protokoll-Kopfbereichs ab, der von der PHP durch ein Signal angezeigt wird. Der PF entnimmt dieser Tabelle den Offset (Zeile 402) vom Beginn des IP-Kopfbereichs und die Größe (Zeile 403) des zu prüfenden Feldes. Der PF wartet dann, bis der Offset den aus der Feldertabelle abgerufenen Offset erreicht. Die Zeile 401 zeigt an, ob das nächste Feld zu demselben Typ von Paketkopfbereich gehört. Ein Wert von "1" bedeutet fortsetzen (es gibt noch weitere Felder für den gleichen Kopfbereich), und ein Wert von "0" bedeutet, dass es das letzte Feld ist, das zu dem gleichen Kopfbereich gehört. In diesem Beispiel enthält der IP-Kopfbereich zwei Felder für den Paketkopfbereich, eines für den Protokoll-Typ und eines für IP-Adressen. Die IP-Adressen "Quelle" und "Ziel" werden zu einer Gruppe in einem Feld zusammengefasst, da sie nebeneinander liegen. Natürlich könnten diese IP-Adressen in zwei Felder aufgeteilt werden, aber dies stellt keine wirksame Ausnutzung von Ressourcen dar. Der PF hat den Zweck zu prüfen, welche Daten von den Datenentnahmeelementen, die parallel arbeiten, gespeichert werden sollen. Wenn die Prüfung positiv verläuft, wird an die anderen Steuerelemente ein Festschreibe-Signal gesendet, wie später erörtert wird.
Wenn der Offset (in diesem Beispiel der Offset 4) erreicht ist, ruft der PF Wert- und Maskentabellenwerte der Daten aus der Tabelle 43 ab, maskiert das Paketwort zuerst unter Verwendung der Maske aus der Tabelle 43 und vergleicht die Werte aus der Tabelle 43 mit dem ankommenden maskierten Paketwort, das in dem Beispiel ein 2-Byte-Wert ist. Es sei angemerkt, dass 4 einen ganz bestimmten Aufbau der Daten zeigt. In einem allgemeineren Fall wird die PF-Vorlage von einem Kopfbereich-Typ gesteuert, der die Entnahme von Daten aus Tabellen entsprechend einem Offset vom Beginn eines Paketkopfbereichs erlaubt und die abgerufenen Werte mit Werten vergleicht, die in der Vorlage gespeichert sind. Dies alles beruht auf dem Zustand der Datenerfassungseinheit, der von der PHP festgelegt wird. Der PF überwacht alle übereinstimmenden Paketfilterwerte. Wenn einer der geprüften Paketfilterwerte nicht übereinstimmt, nimmt der PF dies als "nicht übereinstimmendes" Filter zur Kenntnis. Nur ein übereinstimmendes Filter wird berücksichtigt, nachdem das ganze Paketfilter verarbeitet wurde. Wenn das Paketfilter (wie in 4) beispielsweise IP src = 192.25.140.0/24; IP dst = 130.27.0.0/0; Protokolltyp = UDP (17); UDP src Port = * (beliebig) und UDP dst Port = 5000 lautet und wenn mit Ausnahme des UDP-Zielanschlusses (UDP dst Port) alles übereinstimmt, wird ein bestimmtes Paket in Bezug auf diesen bestimmten Filter als "nicht übereinstimmend" betrachtet. Gegebenenfalls stimmt er mit dem Filter 2 in 4 überein, wenn der UDP-Zielanschluss (UDP dst Port) in dem Paket 6000 lautet.
Die PDE 15 (1) arbeitet parallel mit dem PF, um dem Datenpaket, das an dem Zugriffspunkt vorbeikommt, bestimmte Daten zu entnehmen. Die von der PDE zu entnehmenden Daten beruhen Paketwort für Paketwort entsprechend ihrer/ihren eigenen Vorlage(n) ebenfalls auf den Zustandsinformationen von der PHP, wie im Prozess 102 gezeigt ist. Von der PDE entnommene Daten werden im Ausgangspufferspeicher 16 gespeichert, aber nicht festgeschrieben. Entnommene Daten werden festgeschrieben, wenn eines der Paketfilter, das zu einer bestimmten PDE gehört, ein Signal abgibt (übereinstimmt) und wenn eine zugehörige Einheit zur Entnahme von Paketstichproben, wie beispielsweise die Einheit zur Entnahme von Paketstichproben 17, sofern sie konfiguriert ist, ebenfalls ein Signal abgibt, d. h., wenn sie durch ein Signal anzeigt, dass sie Daten von diesem Paket annimmt. Es sei angemerkt, dass die Bedeutung der "Übereinstimmung" des Paketfilters als Ausnahme angesehen werden könnte, d. h., statt nach Übereinstimmung zu suchen, könnte die Datenerfassungseinheit nach Nichtübereinstimmung suchen. In diesem Fall legen wir ein "Ausnahmepaketfilter" fest, d. h. ein Paketfilter, das, wenn alle Werte mit der Datenerfassungseinheit übereinstimmen, keine Maßnahme ergreift. Dies stellt die Umkehr eines normalen Paketfilter-Übereinstimmungsmusters dar. Beispielsweise möchten wir vielleicht den gesamten Verkehr mit Ausnahme von ganz bestimmtem Verkehr wie IP-Gruppenadressierung (IP multicast), ICMP usw. erfassen. Es ist denkbar, dass die Paketfilter-Definition (Vorlage) auch logische Operationen wie NICHT, ODER und UND enthalten könnte, die dem Paketfilter Anweisungen geben könnten, wie er Felder des Paketfilters behandelt. Die Paketfilter-Vorlage kann etwa Informationen (in 4 nicht gezeigt) dahin gehend enthalten, dass beispielsweise die IP-Adressen mit den Werten des Paketfilters übereinstimmen UND der Zielanschluss zum Beispiel NICHT mit seinem Wert übereinstimmt. Anders ausgedrückt, Filteroperationen sind gegebenenfalls nicht auf vollständige Übereinstimmung aller Werte oder auf vollständige Nichtübereinstimmung aller Werte beschränkt, sondern auf Operationen, die von logischen Operatoren, beispielsweise von einem Berkley Packet Filter (BPF), angegeben werden.
Die PS arbeitet an dem gesamten Paket und ist entweder einem bestimmten Paketfilter oder einer bestimmten PDE zugeordnet. Sie könnte als diskrete oder zufällige Einheit konfiguriert werden. Diskret bedeutet, dass Paketdaten von der PDE nur "festgeschrieben" werden, wenn eine Anzahl von N Paketen durchgelaufen ist, die mit einem bestimmten Filter übereinstimmten oder deren Daten für eine bestimmte PDE als festgeschrieben vorgesehen waren. Ein Paketfilter könnte als vollständig offen definiert werden, d. h., jedes beliebige Paket und in diesem Fall nur alle N-ten Paketdaten werden als von der PDE festgeschriebene Paketdaten betrachtet. Wenn zum Beispiel N = 1000 ist, kommt nur jedes tausendste Paket, das vorbeikommt und bestimmte Kriterien (z. B. Übereinstimmungen mit einem Paketfilter) erfüllt, für eine Datenentnahme in Betracht. Im zufälligen Fall werden für die PS drei Werte festgelegt: Mindestwert, Mittelwert und Höchstwert ("min", "mean" und "max"). Die Anzahl der Pakete, die vorbeikommen und Übereinstimmungskriterien erfüllen, muss auch mit dem Wert der Zufallszahl der PS übereinstimmen. Die PS hat annahmehalber zum Beispiel die folgenden festgelegten Werte: min = 5000, mean = 7000 und max = 10000. Zuerst zieht die PS eine zufällige Zahl zwischen 5000 und 10000 mit einer Mittelwertverteilung von 7000. Unter der Annahme, dass die PS einen Wert von 8450 wählt, wird jedes 8450-ste Paket als festgeschrieben betrachtet. Sobald dieses Paket ausgewählt wurde, wählt die PS eine neue Zufallszahl für die nächste Serie der vorbeikommenden Pakete. Wenn die PS einem Paketfilter zugeordnet ist, gilt die ausgewählte Zahl der PS nur für gefilterte Pakete, die mit einem bestimmten Filter übereinstimmen. Die PS kann ein eigenständiges Element oder sie könnte Teil des PF oder der PDE oder aber Teil des PF und auch der PDE sein. Üblicherweise wird die Einheit zur Entnahme von Paketstichproben ausgeschaltet. Wenn die Menge der erzeugten resultierenden Daten (entnommenen Daten) jedoch hoch ist und ein hohes Verkehrsaufkommen erzeugt, könnte das Paket-Stichprobenverfahren zur Anwendung kommen und dadurch die zu berücksichtigende und letztendlich zu entnehmende Datenmenge verringern.
5 zeigt ein Beispiel einer PDE-Vorlage, zum Beispiel die Vorlage 50, bei der die entnommenen Daten mit denselben Feldern wie das Paketfilter übereinstimmen. Es sei angemerkt, dass die Feldertabelle 52 der PDE-Vorlage 50 mit der Tabelle 42 der PF-Vorlage 40 übereinstimmt. Dies ist lediglich ein Beispiel, um die Beschreibung zu vereinfachen. In anderen PDE-Vorlagen kann die PDE angewiesen werden, der Offset-Position des Pakets nur bestimmte Daten und nicht alle Daten zu entnehmen. Die Anweisung könnte zum Beispiel lauten, nur die ersten N Paketworte zu erfassen oder nur bestimmte Paketworte von einem oder mehreren bestimmten Paketkopfbereichen oder von Paket-Nutzdaten zu erfassen, die selbst als ein spezieller Paketkopfbereich erachtet werden.
Die entnommenen Daten könnten von der Datenerfassungseinheit mit einem Zeitstempel versehen werden und/oder den entnommenen Daten könnte über die Steuereinheit 18 (1) eine Folgenummer zugeordnet werden, die dem Umgang mit entnommenen Daten, die verloren gingen, als die Daten von der Datenerfassungseinheit gesendet wurden, dient. Dies ist gegebenenfalls notwendig, wenn die Datenerfassungseinheit eine unzuverlässige Transportweise nutzt, so dass die Möglichkeit besteht, Ergebnisse zu erfassen, die zwischen der Datenerfassungseinheit und einem entfernten Verarbeitungspunkt wie zum Beispiel dem Punkt 122 verloren gehen.
Man beachte, dass die Vorlagen einfache Programme auf der Grundlage von Speicherorten von Daten und Datentypen ausführen und keine Daten auf der Grundlage von bekannten oder gespeicherten Protokollen verarbeiten, die vorab in der Datenerfassungseinheit gespeichert wurden. Dadurch kann die Datenerfassungseinheit dann bei der Verarbeitung von verschiedenen Protokollen flexibel sein, während sie weiterhin nur einen geringen Platzbedarf hat. Die Datenerfassungseinheit verwendet den Paket-Protokollkopfbereich als einen Zustand, in dem der PF und die PDE arbeiten. Wenn in dem Kopfbereich-Tabelleneintrag des PF oder der PDE kein Wert für einen bestimmten Zustand (Kopfbereich-Typ) angegeben ist, ignoriert die Datenerfassungseinheit jedwede Operation an einem aktuellen Prototoll-Kopfbereich, der die Datenerfassungseinheit durchläuft. Anders ausgedrückt, die Kopfbereich-Tabelle ist eine einfache Zustandsmaschine mit zwei Zuständen und dient dazu, entweder nichts zu tun oder Daten entsprechend einer Position (einem Offset) dieser Daten in einem Datenstrom zu verarbeiten, der die Datenerfassungseinheit durchläuft.
Die passive Datenerfassungseinheit kann mittels Informationen einer Zustandsmaschine programmiert werden, die von einem Host-Steuerrechner wie zum Beispiel dem Hostrechner 121 über das Datennetzwerk 120 gesendet werden. Der Host-Steuerrechner versteht, was er in Bezug auf Datenpakete, die den Zugriffspunkt 11 und folglich die Datenerfassungseinheit 10 durchlaufen, überwachen oder melden muss. Der Hostrechner sendet Vorlagen an die Datenerfassungseinheit (in einer Ausführungsform unter Verwendung einer IP-Adresse der Datenerfassungseinheit), wobei die Vorlagen von der Konfigurations- Steuereinheit 13 dem Datenstrom entnommen werden. Diese Vorlagen werden dann in der Datenerfassungseinheit gespeichert, zum Beispiel in der PHP, im PF, in der PDE und in der PS, und dienen dazu, den Datenerfassungseinheiten Skripte oder Programme zur Durchführung von Operationen an bestimmten Daten bereitzustellen.
Neue Vorlagen werden nur gesendet, wenn sich der Host-Steuerrechner entscheidet, die Operationen, die eine Datenerfassungseinheit an den Paketen durchführen soll, zu ändern. Der Hostrechner kann Paketfilterwerte und Masken häufiger ändern als Vorlagen. Tatsächlich kann eine einmal gesendete Vorlage überhaupt nicht geändert werden, aber der Benutzer trifft vielleicht die Entscheidung, dass er andere Daten in Übereinstimmung mit Paketfilterwerten entnehmen und dieselbe Paketfilter-Vorlage, zum Beispiel mit 5 Tupeln, verwenden möchte. Der Benutzer kann zum Beispiel versuchen, HTTP-Verkehr (TCP-Anschluss 80) zu erfassen, oder er kann sich dafür entscheiden, SSH-Verkehr (Anschluss 22) zu erfassen. Wenn der Benutzer ICMP-Verkehr erfassen möchte und Vorlagen der PHP, des PF und der PDE keine ICMP-Protokollkopfbereiche enthalten, müssen neue Vorlagen an die Datenerfassungseinheit gesendet werden. Die Vorlage der PHP kann bereits ICMP-Protokollkopfbereiche enthalten, die Vorlage des PF möglicherweise jedoch nicht, d. h. der Eintrag 0xFF in der Kopfbereich-Tabelle ist ein Beispiel dafür, wie ein Eintrag als ungültig gekennzeichnet werden könnte. In solch einer Situation muss die Vorlage des PF ersetzt oder aktualisiert werden. Man beachte auch, dass auf Wunsch ein Zähler oder ein anderer Mechanismus verwendet werden kann, um verschiedene Merkmale der entnommenen Daten zu überwachen, selbst wenn diese Daten anschließend nicht an einen fernen Standort übertragen werden. Beispielsweise kann die Größe der Pakete gespeichert und eine durchschnittliche Größe an den fernen Standort gesendet werden. Oder die Anzahl der Pakete kann gezählt werden, wobei dies alles von Informationen gesteuert wird, in den Vorlagen enthalten sind. Wie vorstehend erörtert wurde, braucht die Datenerfassungseinheit wieder nichts über die Pakete oder deren jeweiligen Pakettyp zu wissen, vielmehr führt die Datenerfassungseinheit Operationen an Daten an einem bestimmten Ort auf der Grundlage von übereinstimmenden oder maskierten Werten aus, was von den Vorlagen gesteuert wird.
Es sei angemerkt, dass es für die Bedeutung des Zustands wichtig ist, dass er über alle Vorlagen hinweg gleich ist. Wenn der IP-Kopfbereichtyp in der PHP beispielsweise als der Wert 5 festgelegt ist, müssen alle anderen Vorlagen ebenfalls "verstehen", dass ein Wert von 5 für einen IP-Kopfbereich steht. Anders ausgedrückt, diese Vorlagen müssen hinsichtlich des Kopfbereich-Typs oder des Zustands des Paketkopfbereichs übereinstimmend sein.
Die 6 bis 9 zeigen Ausführungsformen von Aspekten des Betriebs der passiven Datenerfassungseinheit.
6 zeigt eine Ausführungsform des Prozesses 60 zur Steuerung der Datenerfassung mit Hilfe einer passiven programmierbaren Datenerfassungseinheit. Wie vorstehend erörtert wurde, fließen beim Prozess 601 Paketworte durch die Auswerteeinheit für Paketkopfbereiche, und die PHP verwendet die Daten aus ihrer Vorlage, um die Maßnahmen festzustellen, die andere Steuerelemente der Datenerfassungseinheit durchführen werden. Wenn der Prozess 601 feststellt, dass ein neues Paket angekommen ist, setzt der Prozess 602 den Zustand auf 0. Dies könnte auch der Standard-Zustand sein, wenn eine Vorlage nicht verfügbar ist. Der Prozess 603 setzt auch den Paketkopfbereich-Offset auf 0. Wenn dies kein neues Paket ist, erhöht der Prozess 604 den Offset-Kopfbereich, um anzuzeigen, an welcher Stelle im Datenstrom die PHP Operationen durchführt.
Der Prozess 609 stellt fest, ob der Offset der Paketgröße gleich dem Offset des Paketkopfbereichs ist. Wenn ja, ruft der Prozess 610 die Größe des Kopfbereichs ab. Es sei hier angemerkt, dass eine PHP-Vorlage auch Standardgrößen des Protokoll-Kopfbereichs enthält (2). Und diese Standardwerte könnten überschrieben werden, wenn ein bestimmter Typ eines Protokoll-Kopfbereichs ein Größenfeld oder Bits enthielte, die eine andere Größe als die Standardgröße anzeigen würden. Der Prozess 605 stellt fest, ob der nächste Offset des Kopfbereich-Typs gleich dem Offset des Paketkopfbereichs ist. Wenn ja, stellt der Prozess 606, wie vorstehend erörtert wurde, fest, ob der nächste Wert des Kopfbereich-Typs, der in dem Wort enthalten ist, das gerade aus den Daten gelesen wird, welche an der Datenerfassungseinheit vorbeikommen, mit einem der nächsten Werte der Kopfbereich-Typen übereinstimmt, die aus der gerade aktiven PHP-Vorlage abgerufen werden. Man beachte, dass diese Funktion in der Ausführungsform, die gerade erörtert wird, parallel ausgeführt wird, was durch das/die beim Prozess 606 dargestellte(n) zusätzlichen) Kästchen angezeigt wird.
Wenn der/die Prozess(e) 606 eine Übereinstimmung feststellt/feststellen, ermittelt der Prozess 607 anhand der Vorlage den nächsten Zustand, und der Prozess 608 fährt fort, um zu prüfen, ob dies das Ende eines Paketkopfbereichs ist. Wenn das Ende eines Paketkopfbereichs erreicht ist, setzt die PHP einen neuen Zustand für den Paketkopfbereich und leitet diesen Zustand, wie vorstehend erörtert wurde, zusammen mit den Offset-Informationen an die anderen Steuerelemente weiter. Folglich verwendet die Datenerfassungseinheit den Kopfbereich-Typ des Paketprotokolls als einen Koordinierungsmechanismus, durch den die verschiedenen Steuerelemente parallel arbeiten können.
7 zeigt eine Ausführungsform des Prozesses 70, in der der Prozess 701 feststellt, ob gerade ein Wort von einem neuen Paket empfangen wird. Wenn es der Beginn eines Pakets ist, veranlasst der Prozess 701 den Prozess 702, eine Markierung zu setzen, die besagt, dass das Paket mit Paketfilterungskriterien "übereinstimmte". Und wenn sich während der Verarbeitung der Paketfilter bei einem der Paketfilter keine Übereinstimmung feststellen lässt, wird diese Markierung auf "nicht übereinstimmend" zurückgesetzt. Wenn dies nicht der Beginn des Pakets ist, stellt der Prozess 703 fest, ob sich der Typ/der Zustand des Paketkopfbereichs geändert hat. Wenn ja, ruft der Prozess 704 den Feld-Offset aus der Feldertabelle der Vorlage ab und gibt diese Information an den Prozess 706 weiter.
Wenn sich der Zustand nicht geändert hat, stellt der Prozess 705 fest, ob der PF in einem aktiven/gültigen Zustand arbeitet. Wenn ja, stellt der Prozess 706 fest, ob der Offset des Paketkopfbereichs mit dem Offset des Feldes übereinstimmt. Wenn ja, ruft der Prozess 707 die Wert- und Maskendaten aus der PF-Vorlage ab. Wie vorstehend erwähnt wurde, wird diese Funktion ebenfalls über mehrere unterschiedliche Werte, d. h. verschiedene Paketfilter, die konfiguriert/definiert werden, parallel ausgeführt.
Der/die Prozess(e) 708 stellt/stellen dann fest, ob die Werte, die aus dem jeweiligen Paketwort abgerufen wurden, welches maskiert ist, mit den aus der PF-Vorlage abgerufenen Werten übereinstimmen. Wenn es keine Übereinstimmung gibt, setzt der Prozess 709 die Filter-Markierung auf "nicht übereinstimmend". Wenn es eine Übereinstimmung gibt, stellt der Prozess 710 fest, ob das Ende des Feldes erreicht wurde, und wenn nicht, wird der Prozess 707 wiederholt, wenn ein neues Paketwort ankommt. Wenn das Ende des Feldes erreicht wurde, stellt der Prozess 711 fest, ob dies das Ende der Paketfilter-Definition ist. Wenn nicht, wird der Prozess 704 wiederholt, um Vorbereitungen für das nächste Paketwort zu treffen. Wenn das Ende des Filters erreicht wurde, stellt der Prozess 712 fest, ob es eine Übereinstimmung mit dem Filter gab. Wenn ja, wird ein Festschreibungssignal gesetzt. Das Festschreibungssignal wird von anderen Steuerelementen verwendet, wie vorstehend erörtert wurde und mit Bezug auf die Entnahme von Daten, die in 8 gezeigt ist, nachstehend ausführlich beschrieben wird.
8 zeigt eine Ausführungsform des Prozesses 80, bei dem die Entnahme von Paketdaten gesteuert wird. Der Prozess 801 stellt fest, ob sich der Typ/Zustand eines Protokoll-Kopfbereichs geändert hat und ob er einen gültigen Eintrag im Kopfbereich der PDE-Vorlage hat. Wenn ja, ruft der Prozess 802 den Feld-Offset und Informationen über die Größe aus seiner Vorlage ab. Wenn sich der Zustand nicht geändert hat, stellt der Prozess 803 fest, ob die PDE in einem aktiven/gültigen Zustand arbeitet. Wenn ja, führt der Prozess 804 eine Prüfung durch, um festzustellen, ob das vorbeikommende Paketwort zu einem gültigen Feld gehört. Wenn es nicht zu einem gültigen Feld gehört, wird es ignoriert.
Der Prozess 805 legt dann alle erfassten Daten in einem Pufferspeicher ab, zum Beispiel im Ausgangspufferspeicher 16, 1. Der Prozess 805 stellt fest, ob das Ende des Felds erreicht ist und wenn ja, stellt der Prozess 807 fest, ob dies das Ende der Datenentnahme ist. Wenn nicht, wird der Prozess 802 wiederholt, d. h., die PDE wird auf die Verarbeitung des nächsten Paketwortes vorbereitet. Wenn die Datenentnahme beendet ist, ignoriert der Prozess 808 auf der Grundlage dessen, ob ein Festschreibungssignal von dem PF empfangen wurde oder nicht, entweder das Paketwort, oder der Prozess 809 macht aus den im Pufferspeicher abgelegten Daten permanente Daten.
9 zeigt eine Ausführungsform des Prozesses 90 zur Steuerung des Herunterladens von Vorlagen durch die passive programmierbare Datenerfassungseinheit. Die Vorlagen dienen als ein Programm zur vorübergehenden Steuerung von einem oder mehreren Elementen der Datenerfassungseinheit, um Funktionen an Daten entsprechend Zuständen auszuführen, die von einem oder mehreren der Elemente festgelegt wurden. Wie in 9 gezeigt ist, stellt der Prozess 901 fest, ob ein oder mehrere Datenpakete an die Datenerfassungseinheit adressiert sind. Wenn ja, entfernt der Prozess 902 das Paket aus dem Datenstrom, und wenn der Prozess 903 feststellt, dass diese Daten eine neue oder eine überarbeitete Vorlage oder Vorlagenwerte darstellen, werden die empfangenen Daten mittels des Prozesses 904 im Speicher zur Verwendung durch eines oder mehrere der Steuerelemente der Datenerfassungseinheit abgelegt. Die in dieser Ausführungsform erörterten Steuerelemente sind die PHP, der PF, die PDE und die PS. Diese heruntergeladenen Daten stellen neue oder aktualisierte Vorlagen und/oder Werte dar, die in Verbindung mit den Vorlagen zu verwenden sind. Wie vorstehend erörtert wurde, können die Vorlagen- und/oder die Wert-Daten im Speicher abgelegt werden, und zwar physisch verbunden mit dem jeweiligen Element, zu dem sie gehören, oder die Vorlagendaten und/oder Werte könnten in einem zentralen Speicher der Datenerfassungseinheit abgelegt werden.
Zwar wurden die vorliegende Erfindung und ihre Vorteile ausführlich beschrieben, doch sollte es sich verstehen, dass verschiedene Ab- und Veränderungen sowie Ergänzungen daran vorgenommen werden können, ohne von der Wesensart und dem Umfang der Erfindung abzuweichen, die mittels der beigefügten Ansprüche dargelegt wird. Überdies gilt der Umfang der vorliegenden Anwendung als nicht auf die im Einzelfall gewählten Ausführungsformen des Prozesses, der Maschine, der Herstellung, der Zusammensetzung des Gegenstands, der Mittel, der Verfahren und der Schritte, die in der Beschreibung aufgezeigt wurden, beschränkt. Der Fachmann versteht ohne Weiteres anhand der Beschreibung der vorliegenden Erfindung, dass Prozesse, Maschinen, die Herstellung, Zusammensetzungen des Gegenstands, Mittel, Verfahren beziehungsweise Schritte, die derzeit vorhanden oder später zu entwickeln sind und die weitgehend dieselbe Funktion ausführen oder weitgehend dasselbe Ergebnis erzielen wie die entsprechenden, hier beschriebenen Ausführungsformen gemäß der vorliegenden Erfindung angewendet werden können. Folglich sind die beigefügten Ansprüche so zu verstehen, dass sie im Rahmen ihres Geltungsbereichs diese Prozesse, diese Maschinen, diese Herstellung, diese Zusammensetzungen des Gegenstands, diese Mittel, diese Verfahren beziehungsweise diese Schritte beinhalten.

Claims

Datenerfassungseinheit, die Folgendes aufweist: ein erstes Element 12, um mindestens ein Merkmal festzustellen, das zu Daten gehört, die an einem Zugriffspunkt 11 vorbeikommen, mit dem die Datenerfassungseinheit verbunden ist, wobei das Merkmal von dem ersten Element auf der Grundlage einer Übereinstimmung zwischen Daten festgestellt wird, die in einer Vorlage 40 enthalten sind, welche dem feststellenden Element vorübergehend zugeordnet wird, und wobei die Daten zu einem bestimmten Zeitpunkt an dem Zugriffspunkt vorbeikommen; und mindestens ein Steuerelement 15 zur Entnahme von Daten, um, gesteuert von Informationen, die von dem ersten Element erhältlich sind, eine Entnahme von bestimmten Daten aus dem Datenzugriffspunkt zu steuern, wobei die zur Verfügung stehenden Informationen auf der Grundlage von mindestens einem festgestellten Merkmal der Daten, die an dem Zugriffspunkt vorbeikommen, erzeugt werden.
Datenerfassungseinheit nach Anspruch 1, wobei das mindestens eine Merkmal einen Zustand des ersten Elements aufweist.
Datenerfassungseinheit nach Anspruch 2, wobei sich die Datenerfassungseinheit auf mindestens einem von Folgendem befindet: einem ASIC-Chip; einem FPGA.
Datenerfassungseinheit nach Anspruch 2, wobei die Vorlage von Zeit zu Zeit von einem Standort 121 aus geändert werden kann, der von der Datenerfassungseinheit entfernt ist.
Datenerfassungseinheit nach Anspruch 2, wobei mindestens eines der Steuerelemente Folgendes aufweist: ein Paketfilter 14, um festzulegen, welche Daten berücksichtigt werden sollen, und wobei die Festlegung zumindest teilweise auf Daten beruht, die in einer Vorlage enthalten sind, welche dem Paketfilter zugeordnet ist, wobei sich die Vorlage von der Vorlage unterscheidet, die dem ersten Element zugeordnet ist.
Datenerfassungseinheit nach Anspruch 5, wobei die Paketfilter-Vorlage Felder zur Verwendung durch den Paketfilter festlegt, wobei die Felder dem Paketfilter ermöglichen, bestimmte Daten aus den Daten, die an dem Zugriffspunkt vorbeikommen, zur Berücksichtigung auszuwählen.
Datenerfassungseinheit nach Anspruch 5, wobei mindestens eines der Steuerelemente Folgendes aufweist: eine Paketdaten-Entnahmeeinheit 15, 17, um den Daten, die an dem Datenzugriffspunkt vorbeikommen, bestimmte Daten zu entnehmen, wobei die bestimmten Daten jederzeit zumindest teilweise auf Daten beruhen, die in einer Vorlage 50 enthalten sind, welche der Paketdaten-Entnahmeeinheit zugeordnet ist, wobei sich die Vorlage der Paketdaten-Entnahmeeinheit von der Vorlage unterscheidet, die irgendeinem anderen Steuerelement der Datenerfassungseinheit zugeordnet ist.
Datenerfassungseinheit nach Anspruch 7, wobei das Paketfilter und die Paketdaten-Entnahmeeinheit wortweise parallel an den Daten arbeiten und wobei die Entnahme nur stattfindet, wenn der Paketfilter mit einem Merkmal übereinstimmt, das von einem Feld und einem Wert einer Paketfilter-Vorlage, die von dem festgestellten Merkmal gesteuert werden, festgelegt wird.
Verfahren zur Überwachung eines Übertragungsnetzwerks, das Folgendes aufweist: Veranlassen, dass eine an einem Datenzugriffspunkt in dem Netzwerk eingefügte Datenerfassungseinheit Daten verarbeitet, die an dem Datenzugriffspunkt vorbeikommen, wobei die Konfiguration Folgendes aufweist: gesteuert von einer Auswerteeinheit für Paketkopfbereiche Feststellen, von welchem Typ ein nächster Paketkopfbereich sein wird, 606, wenn der aktuelle Paketkopfbereich endet, 608, und welches der nächste Zustand der Auswerteeinheit zu Beginn eines nächsten Paketkopfbereichs sein wird, 607, wobei der Zustand von dem festgestellten nächsten Paketkopfbereich abhängt, wobei die Feststellung auf Daten beruht, die in einer Vorlage enthalten sind, welche zu der Auswerteeinheit für Paketkopfbereiche gehört; Weitergeben des Startpunktes des festgestellten nächsten Paketkopfbereichs als einen Offset, 611, sowie des nächsten Zustands der Auswerteeinheit für Paketkopfbereiche an mindestens ein Daten-Steuerelement; und Entnehmen von bestimmten Daten aus dem Datenzugriffspunkt in Echtzeit, wobei die Entnahme von einem oder mehreren der Datenentnahme-Elemente 80 gesteuert wird, wobei die jeweiligen Daten von Daten abhängig sind, die in einer Vorlage enthalten sind, welche vorübergehend einem jeden Datenentnahme-Element in Verbindung mit dem weitergegebenen festgestellten nächsten Paketkopfbereich, dem Startpunkt des Kopfbereichs als ein Offset und dem nächsten Zustand der Auswerteeinheit für Paketkopfbereiche zugeordnet wird.
Verfahren nach Anspruch 9, das des Weiteren Folgendes aufweist: Senden, 809, von 16 Ergebnissen der Entnahme von der Datenerfassungseinheit an einen von der Datenerfassungseinheit entfernten Standort.