DE60024908T2

DE60024908T2 - Aggregationsverfahren für globale Flussinformationen

Info

Publication number: DE60024908T2
Application number: DE60024908T
Authority: DE
Inventors: Ii Daniel O. Mahoney; Steven Ball; Kevin Farrell
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 1999-03-25
Filing date: 2000-03-24
Publication date: 2006-07-20
Anticipated expiration: 2020-03-25
Also published as: DE60024908D1; EP1039694A2; CA2302001A1; EP1039694A3; CA2302001C; EP1039694B1; US6751663B1

Description

Hintergrund
Diese Erfindung bezieht sich auf Abrechnungssysteme, die Informationen von Computer-Netzwerken sammeln.
Datensammel-Systeme werden zum Sammeln von Informationen über den Netzwerk-Verkehrsfluss auf einem Netzwerk verwendet. Diese Datensammel-Systeme sind so ausgelegt, dass sie eine Art von Netzverkehr von einem Quellen-Typ erfassen und die Daten an einen Anwendungs-Typ liefern, wie z.B. eine Rechnungsstellungs-Anwendung.
Alternativ können, wie dies in der Veröffentlichung „Internet Usage Billing", die von CISCO SYSTEMS im Internet veröffentlicht wurde, Statistiken gesammelt und an netzabwärts gelegene Daten-Sammeleinrichtungen geliefert werden. Diese Statistiken werden dann zusammengefasst, um die Statistiken in eine IDR zusmmenzufassen. In diesem Dokument werden Statistiken jedoch von vier unterschiedlichen Plattformen gesammelt, und somit würde eine Neuformatierung erforderlich sein, bevor die Statistiken gesammelt werden, was Verarbeitungsleistung erfordert.
Zusammenfassung
Die vorliegende Erfindung ergibt ein Verfahren zum Sammeln von Daten, wie es im Anspruch 1 angegeben ist. Weiterhin wird ein System zum Sammeln von Daten geschaffen, wie es im Anspruch 18 beansprucht wird.
In einem Gesichtspunkt der Erfindung wird ein Verfahren zum Sammeln von Daten von Netzwerk-Einheiten für eine Daten nutzende Anwendung geschaffen, das den Empfang von Netzwerk-Abrechnungs-Datensätzen von einer Vielzahl von Daten-Sammeleinrichtungen, wobei jede der Daten-Sammeleinrichtungen mit einer anderen der Netzwerk-Einheiten gekoppelt ist; und das Zusammenfassen zugehöriger jeweiliger der empfangenen Netzwerk-Aktivitäts-Datensätze zu einem zusammengefassten Netzwerk-Aktivitäts-Datensatz umfasst.
Ein entsprechendes System schließt eine Vielzahl von Daten-Sammeleinrichtungen zum Empfang von Informationen von den Netzwerk-Einheiten ein. Jede Daten-Sammeleinrichtung in der Vielzahl von Daten-Sammeleinrichtungen ist einer unterschiedlichen Einen der Netzwerk-Einheiten zugeordnet und erzeugt Netzwerk-Aktivitäts-Datensätze auf der Grundlage von Information, die von der zugehörigen unterschiedlichen Einen der Netzwerk-Einheiten empfangen wird. Weiterhin schließt es einen Fluss-Zusammenfassungs-Prozessor ein, der mit der Vielzahl von Daten-Sammeleinrichtungen verbunden ist. Der Fluss-Zusammenfassungs-Prozessor empfängt die von der Vielzahl von Daten-Sammeleinrichtungen erzeugten Netzwerk-Aktivitäts-Datensätze und fasst zugehörige der empfangenen Netzwerk-Aktivitäts-Datensätze zu zusammengefassten Netzwerk-Aktivitäts-Datensätzen zusammen.
Die Zusammenfassung der Erfindung beschreibt nicht notwendigerweise alle die Merkmale, die für die Definition der Erfindung wesentlich sind. Die Erfindung kann in einer Teilkombination der beschriebenen Merkmale bestehen.
Kurze Beschreibung der Zeichnungen
Die folgende Beschreibung einer bevorzugten Ausführungsform stellt lediglich ein Beispiel ohne jede Beschränkung auf die Kombination der Merkmale dar, die zur praktischen Ausführung der Erfindung erforderlich sind.
1 ist ein Blockschaltbild eines Servers, auf dem eine Abrechnungs-Anwendung abläuft, die ein Netzwerk überwacht.
2 ist eine Blockdarstellung der Architektur der in 1 verwendeten Abrechnungs-Anwendung.
3 ist eine Blockdarstellung einer Abrechnungs-Unterstützung in einem Zugangs-Prozess, der von einem Internet/Intranet-Diensteanbieter oder einem großen Unternehmen verwendet wird.
4 ist eine Blockdarstellung einer Abrechnungs-Unterstützung in einem Zugangs-Prozess, der von einem Internet/Intranet-Diensteanbieter oder einem großen Unternehmen unter Verwendung einer Extranet-Vermittlung verwendet wird.
5 ist eine grafische Darstellung eines Netzwerkes, das in dem Netzwerk angeordnete Daten-Sammeleinrichtungen einschließt.
6 ist ein Flussdiagramm, das einen typischen Datenfluss-Prozess unter Verwendung eines Abrechnungs-Prozesses zeigt.
7 ist eine schematische Darstellung, die Beispiele von Netzwerk-Abrechnungs-Datensätzen zeigt.
8A–8B, 9A–9B, 10, 11A–11E, 12 und 13A–13B sind schematische Ansichten von Datenstrukturen, die in den Netzwerk-Abrechnungs-Datensätzen verwendet werden.
14 ist ein Blockschaltbild eines Flussdaten-Sammelsystems.
15 ist ein Ablaufdiagramm des Flussdaten-Sammelprozesses der Flussdaten-Sammeleinrichtung nach 14.
16 ist ein Blockschaltbild des Fluss-Zusammenfassungs-Prozessors (FAP).
17 ist ein Ablaufdiagramm des von dem FAP nach 6 ausgeführten Zusammenfassungs-Prozesses.
18–20 sind Beispiele der FAP-Verbesserungs- und Zusammenfassungsteile des Fluss-Zusammenfassungs-Prozesses nach 17.
21 ist eine hierarchische Darstellung eines Zusammenfassungs-Abgleichschemas zum Abgleich der Zusammenfassungs-Aktivität an den Ebenen des Fluss-Zusammenfassungs-Prozessors und der Daten-Sammeleinrichtungen.
22 ist ein Beispiel einer Konfigurationsdatei-Aktualisierung zum Zusammenfassungs- (Richtlinien-) Abgleich.
23 ist ein Ablaufdiagramm eines Informations-Verwaltungsprozesses.
24 ist eine Darstellung eines Netzwerk-Kommunikationspfades zwischen zwei Endstationen in einem Netzwerk.
25 ist eine Darstellung einer ICMP-Mitteilung, die in einem Internetprotokoll- (IP-) Paket eingekapselt ist, sowie die Formate der ICMP-Mitteilung und des IP-Paketes.
26 ist eine Darstellung des Formates eines Kopffeldes und eines Datagramm-Vorspanns einer ICMP-Fehler-Berichts-Mitteilung.
27 ist ein Ablaufdiagramm eines IP-Paketverarbeitungsmechanismus.
28 ist die Nutzdaten-Verarbeitungs-/Protokoll-Korrelation des IP-Paket-Verarbeitungsmechanismus nach 26.
29A–29B sind Diagramme, die eine Paket-unabhängige Paketverlust-Detektions-Überwachungseinrichtung zeigen.
30 ist eine schematische Darstellung, die einen Prozess zur Erfassung der Dienstgüte zeigt.
31 ist eine schematische Darstellung eines Dienste-Verwaltungsprozesses.
32 ist eine schematische Darstellung, die eine Architektur einer Dienste-Bereitstellungs-Anwendung zeigt.
Ausführliche Beschreibung
Architektur
In 1 ist ein Beispiel einer Anordnung 10 zum Sammeln von Information von einem Netzwerk gezeigt. Das Netzwerk schließt verschiedene Netzwerk-Geräte 12 ein. Die Netzwerkgeräte 12 können ungleiche, das heißt unterschiedliche, Netzwerkgeräte sein, die unter unterschiedlichen Protokollen und Formaten arbeiten. Die Netzwerkgeräte 12 sind mit einem Abrechnungsprozess 14 über eine Ausrüstungs-Schnittstelle 16 gekoppelt.
Der Abrechnungsprozess 14 schließt eine Flussdaten-Sammelschicht 18 ein, die als Klienten-Prozess an den Ausrüstungs-Schnittstellen auf oder nahe an den Netzwerk-Geräten 12 abläuft. Einzelne und mehrfache (nicht bezeichnete) Daten-Sammeleinrichtungen können an Zugangspunkten (POP) in einem Netzwerk 11 angeordnet sein. Der Abrechnungsprozess 14 schließt einen Fluss-Zusammenfassungs- und Verteilungsprozess 17 ein, der als ein Server-Prozess auf einem Server 13 abläuft. Der Abrechnungsprozess 14 führt die Daten in einem Format zusammen, das von Rechnungsstellungs- oder anderen vom Benutzer definierten, Daten nutzenden Anwendungen 20 verwendet werden kann, die in Schnittstellenverbindung mit dem Abrechnungsprozess 14 über eine Daten nutzende Anwendungs-Schnittstelle 22 stehen. Somit sammelt der Abrechnungsprozess 14 über die Daten-Sammelschicht 18 mehrfache und unterschiedliche Typen von Daten von dem Netzwerk, normalisiert die Daten in einen gleichförmigen Abrechnungs-Datensatz und stellt offene Schnittstellen zu einer oder mehreren Anwendungen, wie z.B. die Rechnungsstellung, über die Anwendungs-Schnittstelle 22 bereit.
Die Netzwerk-Geräte 12, beispielsweise Vermittlungen, Router, Fernzugangs-Konzentratoren usw. können Daten von unterschiedlichen Arten und Formaten erzeugen, die alle in dem Abrechnungsprozess 14 abgewickelt werden. Beispiele von Netzwerk-Geräten 12 schließen einen Router oder einen Switch oder eine Vermittlung 12a, Kabel- oder Telefon-Modems 12b, eine Datenfluss-Sonde 12c, einen Fernzugangs-Konzentrator 12d, eine Extranet-Vermittlung 12e, einen Domänen-Namenssystem- (DNS-) Server 12f, einen RADIUS-Server 12g und einen Web-Server 12h ein. Eine bestimmte Quelle von Daten, die Datenfluss-Sonde 12c wird nachfolgend in Verbindung mit den 24–28 beschrieben. Die Netzwerk-Geräte 12 können einen „Fern-Authentifizierungs-Einwähl-Benutzerdienst"- (RADIUS-) Server 12g einschließen, der RADIUS-Abrechnungs-Datensätze unter Verwendung eines vorhandenen RADIUS-Abrechnungsprozesses (nicht gezeigt) erzeugt. Der Abrechnungsprozess 14 kann in Schnittstellenverbindung mit dem vorhandenen RADIUS-Abrechnungsprozess stehen und kann vorhandene RADIUS-Datensätze ohne Modifikation der vorhandenen RADIUS-Abrechnungs-Umgebung verwenden. RADIUS ist eine gut akzeptierte Norm in der Industrie und wird über eine Anzahl von unterschiedlichen Arten von Technologien hinweg verwendet (Einwähl-, Kabel-, DSL-, VoIP-Technologien usw.), wobei die bekannteste der Einwähl-Zugang ist. Durch die Unterstützung von RADIUS-Datensätze ergibt somit der Abrechnungsprozess 14 die Fähigkeit, ohne Modifikation in eine vorhandene Netzwerk-Umgebung zu passen.
Der Abrechnungsprozess 14 ermöglicht es Benutzern, wie z.B. einem Unternehmen oder einem Internet-Diensteanbieter, eine vorhandene Abrechnungs-Konfiguration beizubehalten. Informationsquellen können Netzwerk-Verkehrsfluss, RADIUS-Abrechnungs-Daten, RMON/RMON2-Daten, SNMP-basierte Daten und andere Quellen von Daten über die Netzwerk-Nutzung. Der Abrechnungsprozess 14 sammelt Daten über die Flussdaten-Sammelschicht 18 von mehrfachen unterschiedlichen Quellen und erzeugt einen neuen Typ von zusammengesetzten Datensätzen. Diese neuen zusammengesetzten Datensätze führen zu neuer Information, die eine Quelle für die Netzwerk-Abrechnung, die Rechnungsstellung, die Verwaltung, die Kapazitätsplanung usw. bildet.
2 zeigt einen Kern-Prozess, der Datensätze oder Aufzeichnungen von jedem der vorstehenden Ausrüstungs-Typen sowie von anderen Ausrüstungs-Typen abwickeln kann, und der Daten an jede der Vielzahl von vom Benutzer definierten Daten nutzenden Anwendungen liefern kann. Dieser Abrechnungsprozess 14 ergibt eine Flexibilität in der Wahl von Daten nutzenden Anwendungen, die Abrechnungs-Daten verwenden. Derartige Anwendungen können die Rechnungsstellung, die Unternehmens-Rückbelastung oder Kosten-Zuweisungen, die Kapazitätsplanung, die Erkennung von Entwicklungen, die Anwendungs-Überwachung, die Erstellung von Benutzer-Profilen usw. einschließen.
Abrechnungs-Architektur
Gemäß 2 schließt die Ausrüstungs-Schnittstellenschicht 16 des Abrechnungsprozesses 14 verschiedene Ausrüstungs-Schnittstellen 42a–42c ein, die jeweils eine Schnittstelle 42a für den Router/Switch 12a, eine Schnittstelle 42b für das Kabel/Modem-Kopfende 12b und eine Schnittstelle 42c für die Datenfluss-Sonde 12c sind. Die Ausrüstungs-Schnittstellenschicht 16 schließt weiterhin zusätzliche Schnittstellen ein, wie z.B. eine Schnittstelle 42d für einen Fernzugangs-Konzentrator 12d, eine Schnittstelle 42e für eine Extranet-Vermittlung 12e, eine Schnittstelle 42f für einen DNS-Server 12f und eine Schnittstelle 42g für einen RADIUS-Server 12g. Die Ausrüstungs-Schnittstelle kann zusätzliche Schnittstellen haben, die spezifiziert werden können, wenn neue Ausrüstungen hinzugefügt werden. Die Schnittstellen 42a–42g können durch ein Schnittstellen-Dienstprogramm 44 entwickelt werden. Das Schnittstellen-Dienstprogramm 44 ermöglicht es einem Nutzer, einen neuen Ausrüstungs-Schnittstellen-Typ zu konstruieren, um den Abrechnungsprozess 14 mit einem neuen Ausrüstungs-Quellen-Typ zu koppeln.
Der Abrechnungsprozess 14 schließt weiterhin eine Daten-Sammelschicht 18 ein. Die Daten-Sammelschicht 18 ist eine verteilte Schicht, die aus einzelnen Daten-Sammeleinrichtungen, beispielsweise 52a–52g, besteht. Die Daten-Sammelschicht 18 sammelt Daten in Form von unbearbeiteter Abrechnungs-Information, die für den Gerätetyp spezifisch ist. Die Daten-Sammeleinrichtung sammelt Daten über die oben erwähnten Ausrüstungs-Schnittstellen 42a–42g. Die Daten-Sammeleinrichtungen 52a–52g sammeln die Daten und wandeln Daten in normalisierte Datensätze oder Aufzeichnungen um, die hier als Netzwerk-Abrechnungs- Datensätze (NAR's) bezeichnet werden. Jede der Daten-Sammeleinrichtungen 52a–52g leitet in geeigneter Weise Netzwerk-Abrechnungs-Datensätze (NAR's) an einen Datenfluss-Zusammenfassungs-Prozess 60 weiter.
Die Daten-Sammeleinrichtungen 52a–52g unterstützen verschiedene unterschiedliche Sammel-Modelle. Beispielsweise können die Daten-Sammeleinrichtungen 52a–52g ein sogenanntes „Push-Modell" unterstützen, bei dem ein angeschlossenes Gerät eine Übertragung von Daten an den Abrechnungsprozess 14 einleitet. Die Daten-Sammeleinrichtungen 52a–52g können auch ein „Pull-Modell" unterstützen, bei dem der Abrechnungsprozess 14 eine Verbindung zu einer Ausrüstungs-Schnittstelle zum Zweck der Gewinnung von Daten einleitet. Zusätzlich können die Daten-Sammeleinrichtungen 52a–52g ein „Ereignis-gesteuertes Modell" unterstützen, bei dem ein Ereignis, das entweder in der Ausrüstungs-Schnittstellenschicht 16 oder in dem Abrechnungsprozess 14 auftritt, eine Datenübertragung auf der Grundlage irgendeines Schwellwertes oder von Kriterien einleitet, die von der Ausrüstungsschicht 16 erfüllt sind, in denen das Ereignis aufgetreten ist.
Die Daten-Sammeleinrichtungen 52a–52g sind über das gesamte Netzwerk hinweg verteilt. Die Daten-Sammeleinrichtungen 52a–52g sind nahe an oder innerhalb des Netzwerk-Gerätes angeordnet, dem die Sammeleinrichtung zugeordnet ist. Das heißt, die Daten-Sammeleinrichtung kann sich in der Leitung oder außerhalb der Leitung bezogen auf das überwachte Gerät befinden. Die Daten-Sammeleinrichtungen 52a–52g können sich an irgendeiner Stelle befinden. Die Daten-Sammeleinrichtungen 52a–52g können vollständig von den Geräten mit Ausnahme von Kommunikationspfaden entkoppelt sein. Wenn neue Netzwerk-Geräte 12 zu der Abrechnungs-Unterstützungsanordnung 10 hinzugefügt werden, werden auch neue Daten-Sammeleinrichtungen eingesetzt.
Der Abrechnungsprozess 14 schließt weiterhin einen Datenfluss-Zusammenfassungs-Prozessor 60 ein, der ein Teil des (vorstehend erwähnten) Zusammenfassungs- und Verteilungsprozesses 17 ist. Der Datenfluss-Zusammenfassungs-Prozessor 60 ist ein zentraler Sammelpunkt für alle Netzwerk-Abrechnungs-Datensätze (NAR's), die von verschiedenen Daten-Sammeleinrichtungen 52a–52g in der Daten-Sammelschicht 18 erzeugt werden. Der Datenfluss-Zusammen fassungs-Prozessor 60 empfängt NAR's von verschiedenen Daten-Sammeleinrichtungen 52a–52g und fasst zugehörige Information von den empfangenen NAR's über die Abrechnungs-Unterstützungsanordnung 10 hinweg zusammen und bildet eine Zusammenfassung hiervon. Der Zusammenfassungs-Prozessor 60 erzeugt Zusammenfassungs-NAR's, das heißt verbesserte und eindeutige Netzwerk-Abrechnungs-Datensätze. Das heißt, dass der Datenfluss-Zusammenfassungs-Prozess die Datensätze über die Netzwerk-Geräte hinweg zusammenfasst, während einzelne Daten-Sammeleinrichtungen 52a–52g Abrechnungs-Datensätze von einzelnen Datenquellen zusammenfassen können. Die Zusammenfassung wird nachfolgend in den 14–23 beschrieben.
Die Abrechnungs-Architektur schließt weiterhin eine Daten-Verteilungsschicht 70 (Teil des Zusammenfassungs- und Verteilungsprozesses 17) ein. Die Daten-Verteilungsschicht 70 ergibt eine flexible Daten-Verteilungs-Vermittlung zwischen dem Datenfluss-Zusammenfassungs-Prozess 60 und einer vom Benutzer definierten Anwendung über eine Anwendungs-Schnittstellenschicht 22. Die Daten-Verteilungsschicht 70 liefert Information an die Anwendungs-Schnittstellenschicht 22 mit einem vorher definierten Format, Protokoll und eine Ablaufsteuerung, die durch die Anforderungen einer Benutzer-Anwendung bestimmt ist. Die Daten-Verteilungsschicht 70 kann Angebots-, Abfrage- und Ereignis-gesteuerte Daten-Verteilungsmodelle unterstützen. Die Anwendungs-Schnittstellenschicht 22 besteht aus einzelnen Anwendungs-Schnittstellen 82a–82g, die von dem Dienstprogramm 44 bereitgestellt werden. Das Dienstprogramm 44 kann zusammen mit den Netzwerk-Geräte-Schnittstellen 42a–42g zur Erzeugung zusätzlicher Anwendungs-Schnittstellen 82 verwendet werden.
Beispiele von Konfigurationen
Gemäß 3 kann der Abrechnungsprozess 14 im Allgemeinen irgendeine Konfiguration unterstützen. Beispiele von Konfigurationen, die von einem Internet-Diensteanbieter 100, einem Unternehmen A, das seinen eigenen Fernzugang 110 hat, und einem Unternehmen B, das den Internet-Diensteanbieter 120 verwendet, sind gezeigt.
Wie dies in 3 gezeigt ist, sind für den Internet-Diensteanbieter Daten-Sammeleinrichtungen 52a–52d (die in 2 gezeigt sind) an bestimmten Zugangspunkten (POP) verteilt, wie z.B. an Fernzugangs-Konzentratoren 102, die von dem Internet-Diensteanbieter verwaltet werden. Die Fernzugangs-Konzentratoren ermöglichen es einem mobilen Internet-Benutzer 106 oder einem Internet-Benutzer 107 mit Fernzugang, einen Zugang an ein Unternehmen über das Internet über den Internet-Diensteanbieter zu erhalten. In diesem Beispiel schließen die Internet-Diensteanbieter-Anordnung 100 und die Anordnungen 110 und 120 von großen Unternehmen Server 13, 13' und 13'' ein, auf denen Abrechnungsprozesse 14, 14' und 14'' ablaufen. Die Abrechnungsprozesse 14, 14' und 14'' verwalten und sammeln unabhängig voneinander Informationen bezüglich der Netzwerk-Verkehrsnutzung.
Die Internet-Diensteanbieter-Anordnung 100 schließt den Abrechnungs-Server 13 ein, auf dem der Abrechnungsprozess 14 abläuft. Der Abrechnungsprozess 14 schließt eine Flussdaten-Sammelschicht 18 ein, die Daten von dem Diensteanbieter-Netzwerk 100 erfasst. Die Flussdaten-Sammelschicht 18 schließt verteilte einzelne Flussdaten-Sammeleinrichtungen 52a–52d ein. Die verteilten Flussdaten-Sammeleinrichtungen 52a–52d sammeln transaktionsspezifische Einzelheiten über den Typ der Verbindung eines Benutzers und dessen tatsächliche Netzwerk-Nutzung. Diese Daten werden in den verteilten Flussdaten-Sammeleinrichtungen 52a–52d in die NAR's umgewandelt, wie dies weiter oben erwähnt wurde. Die NAR's werden über das gesamte System hinweg durch die Datenfluss-Zusammenfassungsschicht 60 (2) zusammengefasst.
Daten werden dem Internet-Diensteanbieter über die Daten-Verteilungsschicht (2) zugänglich gemacht, so dass der Internet-Diensteanbieter Daten analysieren kann, um Diensteangebote an unterschiedliche Benutzer zu unterscheiden. Der Internet-Diensteanbieter kann derartige ausführliche Abrechnungs-Daten, die von verschiedenen Quellen gesammelt werden, auswerten und verwenden, um von einem Geschäftsmodell mit einem einzigen Pauschaltarif auf eine flexiblere Rechnungsstellung überzugehen. Beispielsweise kann es eine Analyse der Daten dem Internet-Diensteanbieter ermöglichen, neue Dienste-Optionen zu entwickeln, die die Bandbreiten-Nutzung, die Tageszeit, die Anwendungs-Nutzung usw. berücksichtigen. Zusätzlich können Internet- Diensteanbieter Rabatte für Web-Treffer anbieten, die beispielsweise in dem Pufferspeicher eines Internet-Diensteanbieters vorhanden sind, wodurch die Notwendigkeit zum Nachschlagen einer Adresse für eine angeforderte Web-Seite auf dem Internet zu einem Minimum gemacht wird, und er kann eine freie E-Mail-Nutzung anbieten, während er andere Arten von Anwendungen in Rechnung stellt, wie z.B. das Datei-Übertragungsprotokoll und Web-Verkehr.
Die Daten können auch von anderen Anwendungen verwendet werden, wie z.B. der Netzwerk-Planung, Sicherheitsmaßnahmen, Auswertung, Simulationen, Datenfluss-Profilierungs-Kapazitätsplanung und Netzwerk-Auslegung usw. Somit kann der Internet-Dienstenanbieter unabhängig Netzwerk-Verkehr überwachen und auswerten, der beispielsweise von an entfernten Stellen arbeitetenden Angestellten und mobilen Benutzern hervorgerufen wird.
In ähnlicher Weise können andere Instanzen 14', 14'' des Abrechnungsprozesses von Unternehmen verwendet werden, wie dies ebenfalls in 3 gezeigt ist. Beispielsweise kann ein Unternehmen seinen eigenen Fernzugang unterhalten, wie dies für das Unternehmen A gezeigt ist, und es würde einen Server 13' einschließen, auf dem ein Abrechnungsprozess 14' abläuft. Ein Unternehmen könnte den Internet-Diensteanbieter verwenden, wie dies für das Unternehmen B gezeigt ist, und dennoch einen Server 13'' haben, auf dem ein Abrechnungsprozess 14'' abläuft. Der Abrechnungsprozess 14', 14'' schließt eine zugehörige Daten-Sammeleinrichtung ein, die mit den lokalen Netzwerken des Unternehmens A und des Unternehmens B und anderen Netzwerk-Anordnungen gekoppelt sind. In diesem Modell verwenden die Unternehmen Daten von dem Abrechnungsprozess 14', 14'' für Unternehmens-Rückbelastungs-Funktionen, wie z.B. für die Rechnungsstellung an Abteilungen für die Internet-Benutzung innerhalb des Unternehmens usw.
Unterschiedliche Instanzen des Abrechnungsprozesses werden sowohl von den Internet-Diensteanbietern als auch von den Standorten des Unternehmens A und des Unternehmens B verwendet. Die Instanzen 14, 14', 14'' des Abrechnungsprozesses sind unabhängig, und sie müssen keine Abrechnungs-Daten austauschen. Vielmehr existieren sie als getrennte unabhängige Abrechnungs-Domänen.
Gemäß 4 kann eine ähnliche Zugangskonfiguration 100' wie die Konfiguration 100 (3) mit einer Extranet-Vermittlung 122 verwendet werden. Ein Extranet-Zugang ermöglicht es an entfernten Stellen befindlichen Benutzern, sich bei einem Internet-Diensteanbieter (ISP) einzuwählen und ein Firmen- oder Zweigbüro über einen ISP zu erreichen. Die Extranet-Vermittlung 122 ermöglicht Internet-Benutzern einen Zugang an Firmen-Datenbanken, Mail-Server und Datei-Server, um Beispiele zu nennen. Dies stellt eine Erweiterung des Internets in Kombination mit einem Firmen-Intranet dar. Bei dieser Konfiguration kann die Extranet-Vermittlung 122 im Besitz eines Internet-Diensteanbieters sein und von diesem betrieben werden, wie dies für das Unternehmen A gezeigt ist, oder sie könnte alternativ im Besitz von einem Unternehmen sein und von diesem betrieben werden, wie dies für das Unternehmen B gezeigt ist. Benutzer würden einen Zugang an das Firmen-Netzwerk von entweder dem Unternehmen A oder dem Unternehmen B über den Internet-Diensteanbieter unter Verwendung verschiedener Arten von Tunnelungs-Protokollen erhalten, wie z.B. dem Schicht-2-Tunnelungs-Protokoll (L2TP), dem Schicht-2-Weiterleitungs- (L2F-), Punkt-zu-Punkt-Tunnelungs-Protokoll (PPTP) oder über Internetprotokoll-Sicherheit (IPSec) usw. Der Abrechnungs-Server 13, der sich an dem Diensteanbieter befindet, und auch die Abrechnungs-Server 13', 13'' in dem Unternehmen A und dem Unternehmen B ermöglichen es sowohl dem Internet-Diensteanbieter als auch jedem der Unternehmen A und B, einen Abrechnungsprozess 14', 14'' auf den Servern 13', 13'' ablaufen zu lassen, um Netzwerk-Daten zu überwachen und zu sammeln.
Transaktions-Flussmodell
In 5 ist eine grafische Darstellung 140 eines sehr großen Netzwerkes gezeigt, das ein Gerät „A" 142 einschließt, das mit einem Gerät „B" 144 kommuniziert. Die grafische Darstellung schließt Knoten ein (die nicht alle numeriert sind), die Router, Switches oder Vermittlungen, Datenfluss-Sonden usw. darstellen können, die (nicht gezeigte) Schnittstellen aufweisen, die Statistiken über die Information führen, die durch die Schnittstellen durchgeleitet wird. Beispielsweise kann eine Vermittlung oder ein Switch eine Anzahl von Ethernet-Ports haben, und ein Host könnte mit einem der Ports verbunden sein und in Kommunikation mit einer der Schnittstellen stehen, um Information über das Netzwerk zu übertragen. Die Schnittstelle könnte Zähler haben, die zum Verfolgen von „Paketeingang", „Paketausgang", „Byte-Eingang", „Byte-Ausgang" usw. verwendet werden.
In diesem Fall, in dem der Host mit dem Port oder einem Router oder irgendeinem anderen Gerät verbunden ist, das mit dem Port verbunden ist, gibt es keine andere Verbindung, die der Host, Router oder ein anderes Gerät wahrnimmt, als das gesamte Netzwerk. Die ist ein Beispiel eines „verbindungslos orientierten" Protokolls. Eine Daten-Sammeleinrichtung 52 kann in dem Netzwerk in einem Pfad zwischen den Einheiten „A" und „B" angeordnet sein, so dass die Daten-Sammeleinrichtung 52 einige der Pakete überwacht, die den Datenfluss zwischen „A" und „B" bilden. Als eine Einzelpunkt-Überwachungseinrichtung hat die Daten-Sammeleinrichtung 52 kein Konzept, dass es zwei Enden gibt, die kommunizieren. Die Daten-Sammeleinrichtung 52 identifiziert diese Einheiten „A" und „B" in verschiedenen NAR's, die von der Daten-Sammeleinrichtung 52 erzeugt werden. An einer späteren Stufe in der Verarbeitung, entweder in der Daten-Sammeleinrichtung 52 oder an einer anderen Stelle in dem Abrechnungsprozess 14, werden die NAR's korreliert, so dass die NAR's oder einige zusammengefasste NAR's, die von der Daten-Sammeleinrichtung 52 oder dem Rest des Abrechnungsprozesses 14 erzeugt werden, den Einheiten „A" und „B" zugeordnet werden können, für die Abrechnungen geliefert werden, um auf diese Weise eine Verbindung zwischen den Einheiten „A" und „B" zu identifizieren.
Die Daten-Sammeleinrichtungen 52a–52g (2) entwickeln eine Beschreibung der Verbindung. Für einen Router, normalerweise eine Adresse des Objektes, das mit dieser Schnittstelle verbunden ist, könnte diese Schnittstelle als eine Adresse dienen. Ein Switch hat eine IP-Adresse, die als das Ziel verwendet werden kann. Das tatsächliche Gerät, das mit dem Switch oder Router verbunden ist, kann als ein abrechenbares Objekt verwendet werden. Obwohl der Verkehr nicht für den Router bestimmt ist, kann die Daten-Sammeleinrichtung diese Identifikationen als Schlüssel für die Endpunkte „A", „B" verwenden.
In vielen Fällen kann das Protokoll explizit Verbindungen bestimmen. Beispielsweise ist das TCP/IP-Protokoll explizit ein „verbindungsorientiertes" Protokoll, das in dem Internet verwendet wird. Wenn die Daten-Sammeleinrichtung 52 eine Verbindung feststellen muss, kann die Daten-Sammeleinrichtung 52 die „verbindungsorientierte" Eigenart bestimmter Arten von Protokollen, wie z.B. des TCP/IP-Protokolls ausnutzen. Wenn die Daten-Sammeleinrichtung 52 eine TCP/IP-Verbindung verfolgt, kann die Daten-Sammeleinrichtung 52 exakt feststellen, dass A und B verbunden sind, wenn die Verbindung startet, stoppt oder aktualisiert wird. Bei anderen Protokollen, wie z.B. einem „verbindungslosen" Protokoll, und insbesondere bei manchen komplexen Umgebungen, wie z.B. einem virtuellen privaten Netzwerk oder einem Proxy-Server kennt die Daten-Sammeleinrichtung 52 nicht notwendigerweise die tatsächlichen Endpunkte. Die Daten-Sammeleinrichtung 52 weiß lediglich, dass irgendeine Einheit mit irgendeiner anderen Einheit spricht.
Somit ist die Daten-Sammeleinrichtung 52 eine Einzelpunkt-Überwachungseinrichtung, die Verkehr an einem Punkt in dem Netzwerk überwacht und den Verkehr in „Pipe-orientierte" oder „Fluss-orientierte" Abrechnungsinformation umwandelt. Die Daten-Sammeleinrichtung 52 identifiziert eine Quelle und ein Ziel des Verkehrs. Das heißt, dass die Daten-Sammeleinrichtung 52 eine „verbindungsorientierte Nachführung" entwickelt. Durch Verteilen von Daten-Sammeleinrichtungen 52a–52g (2) über das Netzwerk, kann das Netzwerk in Form von Pipes modelliert werden, die zwei Endpunkte haben. Eine Daten-Sammeleinrichtung kann in einer Teil-Pipe angeordnet werden. Die Daten-Sammeleinrichtung 52 bestimmt, dass sich ein Ende der Pipe auf „A" bezieht, während sich das andere Ende der Pipe auf „B" bezieht. Die Daten-Sammeleinrichtung 52 kann an irgendeiner Stelle entlang des Netzwerkes angeordnet sein.
Die grafische Darstellung 140 stellt das Netzwerk als einen gerichteten Graphen dar, unter Einschluss von Teil-Segmenten. Die Endpunkte dieser Teil-Segmente können als Proxy-Einheiten für die tatsächlich abrechenbaren Objekte wirken. Sobald unabhängige Abrechnungs-Datensätze, die sich auf diese zwei Einheiten A und B beziehen, in dem Abrechnungsprozess 14 zusammengefasst wurden, kann der Abrechnungsprozess 14 identifizieren, dass A und B miteinander verbunden sind, und bestimmte Metriken haben.
Einige Ausrüstungen können ein Halb-Pipe-Modell haben, das unabhängige Abrechnungs-Datensätze für jede Halb-Pipe erzeugt. Die Daten-Sammeleinrichtungen können die vollständige Pipe-Information aus der Halb-Pipe-Information zusammenfügen. Der Abrechnungsprozess 14 könnte mit Ausrüstungen gekoppelt sein, die ein Halb-Pipe-Modell für A in Kommunikation mit B und ein getrenntes Halb-Pipe-Modell für B in Kommunikation mit A ergeben. Die Daten-Sammeleinrichtungen 52a–52g kombinieren Informationen in diesen zwei Halb-Pipes in einen bidirektionalen Fluss.
In 6 ist ein Beispiel eines Datenflusses 130 durch den Abrechnungsprozess 14 hindurch gezeigt. In diesem Beispiel wird der Datenfluss 130 durch einen Benutzer 131 eingeleitet, der einen Anruf an einen entfernt angeordneten Zugangs-Konzentrator (RAC) 132 macht. Bei Empfang des Anrufs authentifiziert der RAC 132 den Benutzer 131 gegen eine sichere Zugangssteuerung 134. Nach der Verifizierung verbindet der RAC 132 den Benutzer 131 mit dem Netzwerk 135 und sendet einen (nicht gezeigten) RADIUS-Start-Datensatz an den Abrechnungsprozess 14. Der Abrechnungsprozess 14 erzeugt einen RADIUS-Start-NAR 137a und speichert den RADIUS-Start-NAR 137a in einer Datenbank 62. An diesem Punkt kann der entfernt angeordnete Benutzer die e-mail prüfen, einen Web-Server betrachten und eine Datei übertragen. Für jede Transaktion erfasst der Abrechnungsprozess 14 den IP-Verkehr und erzeugt jeweilige e-mail, http-, und ftp-Netzwerk-Abrechnungs-Datensätze 137b–137d. Diese werden in der Datenbank 62 gespeichert. Bei Abschluss dieser Transaktionen würde sich der Benutzer bei dem Netzwerk abmelden, wobei zu diesem Zeitpunkt der RAC 132 dem Abrechnungsprozess 14 einen RADIUS-Stopp-Datensatz senden würde. Der Abrechnungsprozess 14 erzeugt einen RADIUS-Stopp-NAR 137e und speichert den RADIUS-Stopp-NAR 137e in der Datenbank 62. Alle diese Datensätze, die die Transaktionen des Benutzers wiedergeben, könnten in flexibler Weise in Abhängigkeit von den Notwendigkeiten einer Endbenutzer-Anwendung betrachtet und berichtet werden.
Netzwerk-Abrechnungs-Datensätze (NAR's)
Die Daten-Sammeleinrichtung 52 übersetzt gesammelte Information in Netzwerk-Abrechnungs-Datensätze (NAR's). Ein NAR schließt ein Kopffeld, eine Identifikation für die Abrechnungseinheit und Metriken ein. Der Netzwerk-Abrechnungs-Datensatz (NAR) ist ein normalisierter Datensatz, der Information über die Netzwerk-Nutzungsaktivität eines Benutzers enthält.
Gemäß 7 schliesst ein grundlegender „Aktivitäts"-NAR die Quelle, das Ziel, das Protokoll, den Quellen-Port, den Ziel-Port, Byte- und Paketzählungen usw. ein. Der grundlegende Aktivitäts-NAR kann in vielfacher unterschiedlicher und flexibler Weise zusammengefasst werden, um verschiedene Abrechnungsfunktionen zu unterstützen. Der NAR ist ein Aktivitäts-Datensatz, der bis zu einem gewissen Grad Einzelheiten angibt. Einzelheiten können sich auf der Ebene der angewandten Zusammenfassung ändern, entsprechend den Notwendigkeiten des Endbenutzers/der Anwendung.
7 hat eine Vielzahl von ausschließlich „Aktivitäts-NAR's", die einem sehr niedrigen Grad an Einzelheiten entsprechen können, oder die das Ergebnis einer vorhergehenden Zusammenfassung sein könnten, die eine Ansicht höherer Ebene für die Information ergeben. Somit zeigt 7 eine Sammlung 152 von ausschließlich Aktivitäts-NAR's. Aus diesen grundlegenden Daten könnten zusätzliche „Ansichten" des NAR erzeugt werden, wie z.B. ein Satz von „Zusammenfassungs-NAR's" 154 oder ein anderer Satz von Aktivitäts-NAR's 156, die das Ergebnis einer weiteren Zusammenfassung der grundlegenden Information sein könnten, oder schließlich eine Kombination eines Satzes von zusammenfassenden NAR's und Aktivitäts-NAR's 158. Der Zusammenfassungs-NAR wird durch einen zentralen Zusammenfassungs-Prozessor 60 erzeugt und kann eine den Benutzer identifizierende Information, Protokoll-Information, Verbindungszeit-Information, Daten-Information usw. einschließen.
Die speziellen Einzelheiten, was kombiniert und zusammengefasst werden kann, werden weiter unten beschrieben. Somit ergibt die Verwendung der NAR's durch den Abrechnungsprozess 14 die Fähigkeit, grundlegende Aktivitäts-Information in einer flexiblen Weise zu kombinieren und zusammenzufassen, um die speziellen Notwendigkeiten des Endbenutzers/der Anwendung zu erfüllen.
Die nachfolgende Tabelle 1 entspricht den Feldern, die in einem NAR erfasst werden können. Dies ist im Wesentlichen der Aktivitäts-NAR. Der NAR enthält diese Felder, die dann kombiniert und verwendet werden können, um andere Aktivitäts-NAR's oder Zusammenfassungs-NAR's zu bilden.
TABELLE 1
Der Zusammenfassungs-NAR und der Aktivitäts-NAR haben eine-zu-viele-Beziehung. Das heißt, während es einen einzigen Zusammenfassungs-NAR für einen bestimmten Benutzer über einen bestimmten Anruf geben kann, der Information über die Summe der Nutzung von Netzwerk-Ressourcen über die Dauer des Anrufs enthält, es viele Aktivitäts-NAR's geben kann. Die Aktivitäts-NAR's erfassen Einzelheiten über die tatsächliche Aktivität und die während des Anrufs verwendeten Anwendungen. Der Zusammenfassungs-NAR zeigt daher die Gesamtkosten der Transaktion oder eines Satzes von Transaktionen auf einem Netzwerk an, während die Aktivitäts-NAR's Kosten einer Transaktion zu irgendeinem Zeitpunkt zeigen. Der Zusammenfassungs-NAR wird in dem Fluss-Zusammenfassungs-Prozess 60 erzeugt, wie dies nachfolgend beschrieben wird. Im Wesentlichen wird der Zusammenfassungs-NAR aus einzelnen Aktivitäts-NAR's erzeugt, die in den Daten-Sammeleinrichtungen 52a–52g korreliert werden, wie dies weiter unten beschrieben wird.
Ein NAR ist ein Mitglied eines generischen Daten-Mitteilungssatzes, der zum Transport von Daten, wie z.B. Netzwerk-Abrechnungsdaten, durch den Abrechnungsprozess 14 verwendet wird. Diese System-Datenmitteilungen schließen „Status-Ereignis", „Wartungs-Ereignis", „Verfolgungs-Ereignis", „Netzwerk-Abrechnungs-Datensatz" ein. Mitteilungen des Abrechnungsprozesses 14 nutzen eine gemeinsame MSG_HDR-Struktur, die zur Unterscheidung zwischen den vier Mitteilungen des Abrechnungsprozesses 14 verwendet wird. Das Mitteilungs-Kopffeld (MSG_HDR) schließt den Mitteilungs-Typ, ein Mitteilungs-Ereignis und -Ursache, und eine Mitteilungs-Länge ein.
Netzwerk-Abrechnungs-Datensatz-Datenstrukturen
Wie dies weiter unten beschrieben wird, ist der NAR innerhalb des Abrechnungsprozesses 14 eindeutig. Der NAR hat eine NAR_ID, die eine Abrechnungsprozess-Komponenten-ID angibt. Die Komponenten-ID spezifiziert die Daten-Sammeleinrichtung, die einem bestimmten Netzwerk-Gerät zugeordnet ist, der den NAR erzeugt hat. Die Komponenten-ID, beispielsweise NAR_SRC_ID 203a (nachfolgende 8B) wird zu dem Zeitpunkt zugeteilt, zu dem die Komponente erzeugt wird. Die NAR_ID schließt weiterhin einen Zeitstempel auf der Sekunden- und Mikrosekunden-Ebene ein, so dass der Abrechnungsprozess 14 zwischen mehrfachen von einer bestimmten Komponente erzeugten NAR's unterscheiden kann. Eine Folgennummer, beispielsweise 32 Bits, wird ebenfalls zur Unterscheidung von NAR's von der gleichen Abrechnungsprozess-Komponente verwendet, die den gleichen Zeitstempel haben können. Die Folgennummer, beispielsweise NAR_SEQ_NUM 203c (8B) ist vorzugsweise eine monoton ansteigende Zahl, die beispielsweise mit 1 beginnt. Solange die Komponente arbeitet und NAR's erzeugt, ergibt die Komponente eine neue Folgennummer für einen neuen NAR.
In den 8A–8B ist die Datenstruktur 200 eines Netzwerk-Abrechnungs-Datensatzes (NAR) gezeigt.
Wie dies in 8A gezeigt ist, schließt die NAR-Datenstruktur 200 zwei grundlegende Abrechnungs-Objekte, eine Netzwerk-Abrechnungs-Datensatz- Identifikation 200 und wahlweise ein, oder wie dies gezeigt ist, eine Vielzahl von, Netzwerk-Abrechnungs-Datensatz-Attributen 204a–204n ein, die allgemein mit 204 bezeichnet sind. Die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 hat einen Satz von Objekt-Identifikationen, die in eindeutiger Weise den Netzwerk-Abrechnungs-Datensatz innerhalb des Abrechnungsprozesses 14 identifizieren.
Die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 wirkt als ein Datenbank-Schlüsselwert, der den NAR 200 innerhalb des gesamten Abrechnungsprozesses 14 eindeutig macht. Die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 ermöglicht es, dass die NAR's unter Verwendung von Datenbank-Funktionen abgewickelt und verwaltet werden, wie z.B. die Datenbank-Integritäts-Analyse und die Zuverlässigkeits-Analyse. Die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 gibt dem Abrechnungsprozess 14 weiterhin die Fähigkeit, die Quelle der NAR's zu verfolgen und Mechanismen derart aufzubauen, dass der Abrechnungsprozess 14 die Identität des Ursprungs der NAR's über das gesamte System 10 hinweg aufrechterhalten kann.
Die Vielzahl von Netzwerk-Abrechnungs-Datensatz-Attributen 204a–204n ergibt Metriken für den NAR 200. Die Netzwerk-Abrechnungs-Datensatz-Attribute 204a–204n erfassen spezielle Informationen, die in Daten von Netzwerk-Geräten enthalten sind. Eine Unterscheidung zwischen der Netzwerk-Abrechnungs-Datensatz-Identifikation 202 und der Metrik 204 ermöglicht es dem Abrechnungsprozess 14, logische und arithmetische Operationen an den Metriken 204 durchzuführen, während die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 intakt gehalten wird. Die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 kann im Gegensatz zu der Metrik 204 verbessert werden.
Die Daten-Sammeleinrichtungen 52a–52g (2) sind um den Prozess des Ausfüllens der NAR orientiert. Die Metriken werden von der Daten-Sammeleinrichtung unverändert gelassen und werden transparent in den Abrechnungsprozess-Fluss-Zusammenfassungs-Prozessor 60 weitergeleitet. Die Daten-Sammeleinrichtungen 52a–52g ordnen die Netzwerk-Abrechnungs-Datensatz-Identifikationen 202 zu den Metriken, beispielsweise einer Quelle, und zu einer Ziel-Identifikation an die Metrik zu. In dem Beispiel einer Router-Verbindungsstrecke weisen die Metriken, die die Router-Schnittstelle liefert, die Form von „Eingangsinformation" und „Ausgangsinformation" auf, beispielsweise Eingangs-Oktette, Ausgangs-Oktette, Eingangs-Bytes, Ausgangs-Bytes, Eingangs-Datagramme, Ausgangs-Datagramme, Eingangs-Fehler, Ausgangs-Fehler usw. Die Daten-Sammeleinrichtungen 52a–52g legen fest, was „Ein" und „Aus" bedeutet und ordnen eine eindeutige Identifikation zu, die gegenüber der bestimmten Bedeutung von „Ein" und „Aus" unzweideutig ist. Sobald eine Daten-Sammeleinrichtung 52 diese Konvention festgelegt hat, wird die Konvention über das gesamte System 10 hinweg verwendet.
Daher liefert die NAR-Identifikation 202 Datenbank-Konstrukte an einen NAR, während die Vielzahl von Netzwerk-Abrechnungs-Datensatz-Attributen 204a–204n die tatsächlichen Metriken liefert, die für die Netzwerk-Aktivitäts-Berichte und die Netzwerk-Abrechnung verwendet werden.
Wie dies in 8B gezeigt ist, ist die Netzwerk-Abrechnungs-Datensatz-Identifikation 202 (NAR_ID) ein Satz von Objekten innerhalb des NAR, die den NAR über den gesamten Abrechnungsprozess 14 hinweg eindeutig identifizieren. Die NAR_ID 202 ist so ausgelegt, dass sie eine Anzahl von Eigenschaften eines NAR unterstützt, unter Einschluss der Flexibilität, der Zurechenbarkeit, der Zuverlässigkeit und der Eindeutigkeit. Um diese Eigenschaften zu schaffen, ist die NAR_ID 202 in Objekte unterteilt, die so ausgelegt sind, dass sie speziell diese Eigenschaften liefern. Die Flexibilität wird durch einen NAR_HDR-Abschnitt 203 der NAR_ID unterstützt. Die Zurechenbarkeit wird in dem NAR durch eine explizite Identifikation der Quelle des NAR durch eine Komponenten-Identifikation NAR_SRC_ID 203a erreicht. Die Quellen-Zeit wird in einem NAR_RC_TIME 203b unterstützt. Die Zuverlässigkeit wird in der vorstehend beschriebenen Weise durch die Verwendung einer NAR-Folgennummer (NAR_SEQ_NUM) 203c unterstützt, die so ausgelegt ist, dass sie traditionelle Datenbank-Integritätsmechanismen ermöglicht.
Die NAR_ID 202 wird zur Bereitstellung einer Eindeutigkeit für jede NAR verwendet. Die Verantwortung dafür, dass die Eindeutigkeit und Einzigkeit jedes NAR garantiert ist, wird von jeder Abrechnungsprozess-Komponente abgewickelt, die die Fähigkeit hat, den Ursprung oder die Quelle von Netzwerk-Abrechnungs-Datensätzen zu sein. Diese Verantwortung erfordert es, dass jede Abrechnungsprozess-Komponente die Fähigkeit hat, sich selbst eindeutig in jedem NAR zu identifizieren, den sie erzeugt. Daher besteht die NAR-Typ-Identifikation, NAR_TYPE, aus der Quellen-Komponenten-Identifikation, NAR_SRC_ID, der NAR-Quellen-Zeit, NAR_SRC_TIME, und der NAR-Folgennummer, NAR_SEQ_NUM. Diese drei Daten-Objekte wirken als Datenbank-Schlüssel für einen bestimmten Netzwerk-Aktivitäts-Datensatz und stellen die Eindeutigkeit des NAR über das gesamte System hinweg sicher.
Das NAR_SEQ_NUM-Objekt kann mehrere Zwecke haben. Einer hiervon besteht darin, dass NAR_SEQ_NUM als Unterscheidungsmerkmal verwendet werden kann, wenn zwei NAR's zur gleichen Zeit erzeugt werden. Eine zweite Möglichkeit, in der NAR_SEQ_NUM verwendet wird, besteht in einem monoton ansteigenden Index zur Sicherstellung der Datenbank-Integrität. Weil die NAR_ID eindeutig ist, sollte sie als ein zugeteilter Wert betrachtet werden. Eine NAR_ID wird an dem NAR-Ursprung zugeteilt.
Wenn eine Komponente die Inhalte eines vorhandenen NAR erzeugt oder modifiziert, beispielsweise wenn zwei NAR's miteinander zusammengefasst werden, so stellt die Komponente den Ursprung der NAR_ID dar. Dies gibt die Gelegenheit, dass der Abrechnungsprozess 14 explizite interne Integritätsmechanismen hat, die irgendeinen Netzwerk-Abrechnungs-Datensatz berücksichtigen können, der von dem Abrechnungsprozess verarbeitet wird. Die NAR-Quellen-Identifikation NAR_SRC_ID 203a schließt einen Quellen-Typ 207a und eine Quellen-Seriennummer 207b ein. Die Seriennummer 207b ist ein administrativ zugeteilter Wert, beispielsweise 24 Bits, der in eindeutiger Weise den NAR-Quellen-Typ über den gesamten Abrechnungsprozess 14 hinweg identifiziert. Die Quellen-Seriennummer 207b sollte innerhalb der speziellen Abrechnungs-Domäne eindeutig sein.
Die (NAR_SEQ_NUM) 203c ist monoton ansteigend, beispielsweise eine ganzzahlige nicht Vorzeichen behaftete 32-Bit-Zahl, die als Folgennummer für NAR's wirkt, die von einer bestimmten NAR-Quelle ausgehen. Weil der Wert der NAR_SEQ_NUM „umlaufen" kann, sind die kombinierten 64-Bit-Werte NAR_SRC_ID und NAR_SEQ_NUM lediglich über eine bestimmte Zeitperiode eindeutig.
In den 9A–9B sind Beispiele von Formaten für Netzwerk-Abrechnungs-Datensatz-Attribute 204 gezeigt. Es gibt zwei Variationen eines einzigen NAR_ATTRIBUTE-Formates, die verwendet werden können. Wie dies in 9A gezeigt ist, schließt ein Standard-NAR_ATTRIBUTE-Format 206a Kopffelder NAR_ATTR-Typ, NAR_ATTR-Code, NAR_ATTR-Qualifizierer und NAR_ATTR-Länge und ein „Wertefeld" ein. Um die Größe der Abrechnungsinformation beizubehalten, wenn die Größe des Wertes von NAR_ATTRIBUTE ein Byte ist, das heißt 8 Bits, wie dies in dem NAR-ATTR-Qualifiziererfeld gezeigt ist, kann das Format 206b von NAR_ATTRIBUTE so sein, wie dies in 9B gezeigt ist, und Felder NAR_ATTR-Typ, NAR_ATTR-Code und ein 8-Bit-NAR_WERT-Feld einschließen.
Jedem unterstützten Objekt wird ein NAR_ATTR-Code zugeordnet. Über den NAR_ATTR-Code kann der Abrechnungsprozess 14 die Semantik eines bestimmten NAR_ATTRIBUTE unterscheiden. Obwohl NAR_ATTR-Codes für den NAR_ATTR-Typ spezifisch sind, können die NAR_ATTR-Code-Zuordnungen eindeutig sein, um die Realisierung zu unterstützen. Werte können zugeordnet werden, um eine gewisse explizite hierarchische Struktur zu schaffen. Jedes NAR_ATTR hat einen 8-Bit- NAR_ATTR-Qualifizierer, der Typeninformation für NAR_ATTR liefert. Der NAR_ATTR-Qualifizierer wird verwendet, weil einige unterstützte Objekte unter Verwendung mehrerer unterschiedlicher Typen dargestellt werden. Zähler können beispielsweise 32 Bit und 64 Bit im Fall von zusammengesetzten Objekten sein. Netzwerk-Identifikationen können numerische Indizes oder Zeichenketten als Etiketten verwenden. Das NAR_ATTR-Feld gibt die Länge des NAR-Attributs unter Einschluss des NAR_ATTR-Kopffeldes an.
Es gibt fünf Arten von Netzwerk-Abrechnungs-Datensatz-Attributen, die in dem NAR unterstützt werden. Die fünf Attribute sind das Abrechnungs-Zeitintervall (ACCT_TIME) (10); die Abrechnungs-Einheits-Identifikation (ACCT_ENTITY_ID) (11A–11E); der zurechenbare Einheits-Deskriptor (ACCT_ENTITY_Desc); die Netzwerk-Aktivitäts-Metriken (NET_METRICS) (12), und zwei transparente Attribute (TRANS_ATTR) (13A–13B). Falls erforderlich, können zusätzliche NAR_ATTRIBUTE unterstützt werden. Beispielsweise könnte ein NAR_ATTRIBUTE-Typ auch Sicherheitsattribute für Abrechnungsdaten einschließen, um einen Schutz gegen eine unberechtigte Einführung oder Modifikation von Abrechnungs-Information zu liefern.
Gemäß 10 schließt ein Abrechnungs-Zeitintervall-Datensatz einen Wert „Sekunden" und einen Wert „Mikrosekunden" ein. Die Werte von „Sekunden" und „Mikrosekunden" stellen zusammen einen Zeitstempel der Netzwerk-Aktivität für den NAR dar, wie dies weiter oben erläutert wurde. Wenn sie von einem absoluten Zeitwert abgeleitet werden, der das Ende des Abrechnungs-Zeitintervalls darstellt, ist das Abrechnungs-Zeitintervall die Dauer, wie sie unter Verwendung des Abrechnungs-Zeitintervalls als Startzeit-Wert berechnet wird. Alle Netzwerk-Abrechnungs-Datensätze können ein Abrechnungs-Zeitintervall-Attribut haben.
In den 11A–11E sind Datenstrukturen für die zurechenbare Einheits-Identifikation gezeigt. Die Identifikationen für die zurechenbare Einheit sind eine Sammlung von Einheits-Beschreibungs-Attributen, die zusammen eine zurechenbare Einheit in dem Abrechnungsprozess 14 identifizieren. Der zurechenbare Einheits-Identifikationsmechanismus erleichtert flexible NAR-Zusammenfassungs-Eigenschaften des Abrechnungsprozesses 14. Die ACCT_ENTITY_ID ist die Beschreibung eines Abrechnungs-Objektes innerhalb des Abrechnungsprozesses 14. Es kann eine oder mehrere ACCT_ENTITY_ID's in einem vorgegebenen NAR geben, es muss jedoch zumindest eine ACCT_ENTITY_ID in einem Netzwerk-Abrechnungs-Datensatz geben. Das tatsächlich zurechenbare Objekt ist durch die gesamte Sammlung von ACCT_ENTITY_ID's definiert, die in dem NAR enthalten sind.
In einer Transaktions-basierten Abrechnung wird ein Netzwerk-Abrechnungs-Datensatz zwei ACCT_ENTITY_ID's enthalten, die die Quellen- und Ziel-Einheiten darstellen, die an der Netzwerk-Transaktion beteiligt sind. Für eine traditionelle Fluss-basierte Abrechnung würden dies normalerweise die zwei Netzwerk-Adressen sein, die an dem Fluss beteiligt sind. Qualifizierer sind in den ACCT_ENTITY_ID-Objekten verfügbar, um anzuzeigen, welche ID die Quelle und welches das Ziel der Netzwerk-Transaktion ist.
In direkter Unterstützung von Fluss-basierten Abrechnungs-Datenquellen unterstützt der Abrechnungsprozess 14 einen spezifischen IP-Fluss-Deskriptor.
Dies ist die traditionelle IP-5-Tupel-Fluss-Beschreibung. Der Abrechnungsprozess 14 könnte weiterhin einen 6-Tuppel-Fluss-Deskriptor unterstützen, der eine Dienstetyp- (TOS-) Anzeige in der Fluss-Bezeichnung einschließt. Dies ermöglicht eine Dienstklassen-Unterscheidung in dem Abrechnungsmodell.
Für Netzwerk-Aktivitäts-Datenquellen, die kein Transaktions-Abrechnungsmodell haben, kann lediglich eine einzige ACCT_ENTITY_ID in dem Abrechnungs-Datensatz vorhanden sein. Qualifizierer für die ACCT_ENTITY_ID sind verfügbar, um anzuzeigen, ob das einzelne Objekt die Quelle, das Ziel oder beides für die Abrechnungs-Metriken ist, die eingeschlossen werden. Die Arten der Einheiten schließen Benutzer-Identifikationen und Netzwerk-Einheits-Identifikationen ein. Die Netzwerk-Identifikationen können die IP-Adresse, die Fluss-Beschreibung und die Netzwerk-Objekt-ID einschließen. Andere Arten von Abrechnungs-Einheiten können vorgesehen sein.
Die tatsächlichen abrechenbaren Einheiten für einen bestimmten Netzwerk-Abrechnungs-Datensatz sind in dem vollständigen Satz von ACCT_ENTITY_ID(s) angegeben, die in dem NAR vorhanden sind. Operationen, die auf die NAR's angewandt werden können, insbesondere die Zusammenfassung, können beeinflussen, wie ACCT_ENTITY_ID's in den NAR's verwendet werden. Jede Identifikation für eine abzurechnende Einheit, die vorhanden ist, fügt eine Verfeinerung zu der Definition hinzu, auf welche abzurechnende Einheit die Metrik tatsächlich anzuwenden ist, während jede ACCT_ENTITY_DESC weiterhin die Beschreibung der abzurechnenden Einheit verfeinert.
Unter Bezugnahme auf 11A ist zu erkennen, dass ein NAR_USERNAME eine spezielle Art der NAR_USERID-Datenstruktur ist. Ein System-Zeichenketten-Typ „Username" (Benutzername) 222 kann einen tatsächlichen Benutzer innerhalb des Abrechnungsprozesses 14 darstellen, gegenüber dem abzurechnen ist. Die NAR_USERNAME-Datenstruktur 220 wird zur Übersendung der Zeichenkette verwendet. Die Semantiken können angewandt werden, wenn die Zeichenkette „Username" 222 von Radius- oder von DCHP-Verwaltungssystemen geliefert wird. Die NAR_USERNAME-Datenstruktur 220 schließt einen NAR_USERNAME NAR_ATTR-Qualifizierer ein, der die Rollenbezeichnung liefert und anzeigt, ob das angegebene Objekt als eine Quelle, ein Ziel oder beides wirkt oder in dem System nicht bestimmbar ist. Die NAR_ATTR-Qualifizierer-Bits werden gesetzt, wenn die Rolle (ROLE) unzweideutig bestimmt werden kann.
Gemäß 11B ist eine NAR_USER_ID-Datenstruktur 230 der allgemeine Typ für die Identifikation eines Benutzers, dem gegenüber abzurechnen ist. Der Abrechnungsprozess 14 kann irgendeinen verfügbaren Objekt-Typ verwenden, um den NAR_USER_ID-Wert 232 darzustellen. Der NAR_USER_ID-Wert kann ein vom System bestimmter Zeichenketten- (STRING-) Typ oder ein Benutzer-Index sein, wie er allgemein von einem Datenbank-System geliefert wird. Die Semantiken des NAR_USER_ID-Wertes 232 stimmen in dem Abrechnungsprozess 14 überein und können auch außerhalb des Abrechnungsprozesses 14 übereinstimmen.
In 11C ist eine NAR_IP_ADDRESS-Datenstruktur 240 gezeigt, die die allgemeine Netzwerkkomponenten-Identifikation für ein IP-Unternehmens-Netzwerk ist. Die NAR_IP_ADDRESS-Datenstruktur (240) schließt eine IP-Adresse 242 ein, die üblicherweise innerhalb der Domäne, für die eine Abrechnung erstellt werden soll, eindeutig ist, und sie kann daher als eine Identifikation in dem Abrechnungsprozess 14 verwendet werden. Innerhalb des Abrechnungsprozesses 14 bedingt das Auftreten dieses Datensatzes, dass die Adresse innerhalb des Abrechnungsbereiches eindeutig ist. Der NAR_IP_ADDRESS-Typ schließt einen NAR_IP_ADDRESS-NAR_ATTR-Qualifizierer ein. Der NAR_IP_ADDRESS-Der NAR_ATTR-Qualifizierer liefert eine Rollenbezeichnung und zeigt an, ob das bezeichnete Objekt als eine Quelle, ein Ziel oder als beides wirkt oder in dem System nicht bestimmbar ist. Diese Bits werden gesetzt, wenn die Rolle unzweideutig bestimmt wird.
In 11D ist eine NAR_NETWORK_ID-Typ-Datenstruktur 250 gezeigt. Die NAR_NETWORK_ID-Datenstruktur 250 schließt einen NETWORK_ID-Wert 252 ein, der ein allgemeiner Typ ist, der zur Identifikation einer Netzwerk-Komponente verwendet wird, wenn eine Netzwerk-Adresse unpassend ist. Der Abrechnungsprozess 14 kann irgendeinen verfügbaren Objekt-Typ verwenden, um die NAR_NETWORK_ID darzustellen, doch wird angenommen, dass dieser Wert ein vom Abrechnungsprozess 14 festgelegter Zeichenketten-Typ sein wird (beispielsweise eine Medien-Zugangskontroll- (MAC-) Adresse, die in Netzwerk-Schnittstellenkarten vordefiniert ist), ein Objekt-Typ oder ein Nummern-Index sein wird, der keiner Netzwerk-Adresse zugeordnet werden kann. Die Semantik der NAR_NETWORK_ID ist innerhalb des Abrechnungsprozesses 14 übereinstimmend und kann auch außerhalb des Abrechnungsprozesses 14 übereinstimmend sein. Ein NAR_NETWORK_ID-NAR_ATTR-Qualifizierer ergibt die Rollenbezeichnung und zeigt an, ob das bezeichnete Objekt als Quelle, Ziel oder beides wirkt oder in dem System nicht bestimmbar ist. Diese Bits werden gesetzt, wenn die Rolle unzweideutig bestimmt werden kann.
Gemäß 11E ist eine NAR_FLOW_DESC-Datenstruktur 260 der allgemeine Typ zum Bericht über Fluss-basierte Netzwerk-Aktivität. NAR_FLOW_DESC ist eine zusammengesetzte Datenstruktur 260, die eine IP-Quellen-Adresse 262, eine IP-Zieladresse 263, ein Transport-Protokoll 263, einen Dienstetyp 265, einen Quellen-Port 266 und einen Ziel-Port 267 einschließt, die von der Transport- und Netzwerk-Schicht von IP-Paketen über eine Fluss-Sonde belegt werden. Der NAR_FLOW_DESC-NAR_ATTR-Qualifizierer liefert die Rollenbezeichnung und gibt an, ob das bezeichnete Objekt als Quelle, Ziel oder beides wirkt oder in dem System nicht bestimmbar ist. Diese Bits werden gesetzt, wenn die Rolle unzweideutig bestimmt werden kann.
Daher stellen die Netzwerk-Abrechnungs-Aktivitäts-Datensätze grundlegend Bindungen zwischen einer Einheit, gegenüber der abzurechnen ist, und einen Satz von Metriken dar, die dieser Einheit über eine bestimmte Zeitperiode zugeordnet werden können. Die NAR's ergeben eine Flexibilität bei der Definition oder Spezifizierung der Einheit, gegenüber der abzurechnen ist. Dieser Grad der Flexibilität ist erforderlich, weil bei der Netzwerk-Abrechnung eine Einheit, gegenüber der abzurechnen ist, sich möglicherweise auf Objekte beziehen könnte, die entweder physikalisch oder logisch sind, einzeln oder Mitglieder von Sammlungen sind, oder geografisch oder topologisch festgelegt sind, wie z.B. Netzwerk-Nummern oder autonome Systemnummern.
Ein Satz von Einheiten, gegenüber denen abzurechnen ist, schließt Benutzernamen- und Netzwerk-Objekt-Identifikationen ein. Es kann eine zusätzliche beschreibende Information innerhalb der Netzwerk-Aktivitäts-Berichte und innerhalb von Netzwerk-Komponenten verfügbar sein, die zusätzlich verwendet werden könnte, um Einheiten, gegenüber denen abzurechnen ist, weiter zu beschreiben. Diese Einheits-Attribut-Deskriptoren können in dem Abrechnungsprozess 14 zur Schaffung einer zusätzlichen Flexibilität verwendet werden, wie Netzwerk-Aktivitäts-Information berichtet und zugeschnitten wird. Die Unterstützung für Einheits-Beschreibung kann eine Objekt-Unterstützung für Folgendes einschließen:
Fluss-Deskriptoren

Fluss-Protokoll-Deskriptoren
Fluss-Transport-Port-Deskriptoren

Authentifizierungs-Deskriptoren

NAS-Descriptoren

Zusammenfassungs-Deskriptoren

Klassen-Identifikationen
Sitzungs-Identifikationen
Multi-Sitzungs-Identifikationen
VLAN-Identifikationen
ELAN-Identifikationen
Gruppen-Identifikationen

Zugangs-Identifikationen

Quellen- und Ziel-Ethernet-Adressen
Eintritts- und Austritts-Tunnel-Identifikationen
Eintritts- und Austritts-Port-Nummern
Virtuelle ATM-Schaltungs-VPINCI
Identifikationen von anrufenden und angerufenen Stationen

Fluss-Status-Deskriptoren

Dienstklasse-Identifikationen
Dienstgüte-Identifikationen
Verkehrspfad-Identifikationen
Abrechnungs-Zeitintervall

Abzurechnende Netzwerk-Aktivitäts-Metrik

Quellen- und Ziel-Datagramme
Quellen- und Ziel-Oktette

Erweiterte Netzwerk-Aktivitäts-Attribute

Netwerk-Flusssteuer-Anzeigen
Host-Flusssteuer-Anzeigen
Verkehrs-Burst-Deskriptoren.

In 12 ist eine NET_METRIC-Datenstruktur 270 gezeigt. Eine NET_METRIC-Datenstruktur 270 zur Unterstützung einer Zählung ist in 14 gezeigt. Die NET_METRIC-Datenstruktur 270 wird zur Aufnahme grundlegender Abrechnungs-Werte verwendet, die innerhalb des Abrechnungsprozesses 14 aufgezeichnet werden. Die NET_METRIC-Datenstruktur 270 kann Zeit, Oktette, Datagramme, Zählungen und Zellen, Leitungen, Tunnels usw. unterstützen.
In den 13A und 13B sind zwei grundlegende transparente TRANS_ATTR-Objekte gezeigt; UNDEFINED (undefiniert) 280 und RADIUS 290. Neue TRANS_ATTR-Objekt-Typen können bei Bedarf definiert werden. Dieses sind Objekte, die ein Benutzer über den Abrechnungsprozess 14 senden möchte, die kundenspezifisch sind oder von ihrer Eigenart proprietär sind. Der Abrechnungsprozess 14 ermöglicht eine Objekt-Transparenz, das heißt ein Objekt, auf das das System nicht einwirkt oder es modifiziert. Somit sind die Inhalte von transparenten Attributen bezüglich des Abrechnungssystems nicht definiert. Sie werden unmodifiziert weitergeleitet.
Flussdaten-Sammeleinrichtung
In 14 ist ein Flussdaten-Sammelsystem 300 zur Unterstützung der Flussdaten-Sammeleinrichtungen („FDC") 52 (von 2) gezeigt. Das Flussdaten-Sammelsystem 300 schließt einen Prozessor 302 ein, der mit einem Speicher 304 gekoppelt ist. In dieser Ausführungsform ist die FDC ein Prozess, der in dem Speicher 304 gespeichert und von dem Prozessor 302 ausgeführt wird. Die FDC 52 schließt mehrere NAR-Verarbeitungskomponente oder Prozesse ein. Diese Prozesse schließen einen NAR-Konstruktor 306 zur Umwandlung von Daten, die von der Ausrüstungs-Schnittstelle (EI) 16 (die mit gestrichelten Linien gezeigt ist) erfasst werden, von einem Netzwerk-Gerät oder einer Technologie („Netzwerk-Einheit") in das NAR-Format ein. Es sei daran erinnert, dass jeder Ausrüstungs-Schnittstelle 42a–42g eine Flussdaten-Sammeleinrichtung zugeordnet ist. Somit unterstützt die Kombination einer Ausrüstungs-Schnittstelle und einer Flussdaten-Sammeleinrichtung eine bestimmte Einrichtung oder Technologie und sammelt Daten von dem speziellen Gerät oder der Technologie unter Verwendung eines vordefinierten Formates, einer Ablaufsteuerung und eines Protokolls, das für dieses Gerät/diese Technologie spezifisch ist. Die NAR-Prozesse schließen weiterhin einen Korrelator 308, einen Verbesserungsprozess 310 und eine Zusammenfassungseinrichtung 312 zur Verarbeitung der konstruierten NAR's so ein, wie dies passend ist. Die Einzelheiten dieser Prozesse werden weiter unten anhand der 15 beschrieben.
Unter weiterer Bezugnahme auf 14 schließt der Speicher einen örtlichen Speicher 304 und eine Flussdaten-Sammeleinrichtungs-Konfiguration (Datei) 318 ein. Der örtliche Speicher 314 speichert Daten, die von der Ausrüstungs-Schnittstelle 16 und verarbeiteten NAR's empfangen werden. Die Konfigurations-Datei 318 wird beim Einschalten oder Hochfahren geliefert, um die Flussdaten-Sammeleinrichtung 52 zu konfigurieren. Die Konfigurations-Datei 318 gibt verschiedene Konfigurationsparameter 319, unter Einschluss eines Zeitparameters 320 und einer Richtlinie 322 an. Die NAR-Prozesse 304 belegen und verarbeiten NAR's für Daten, die von den Netzwerk-Geräten über die Ausrüstungs-Schnittstelle 16 empfangen werden, entsprechend der Richtlinie 322 der Konfigurations-Datei. NAR's, die in dem örtlichen Speicher 314 gehalten werden, werden an dem Fluss-Zusammenfassungs-Prozess 60 (2, hier in gestrichelten Linien gezeigt) überführt, wenn die durch den Zeitparameter 320 bestimmte Zeit abläuft.
Es ist aus der vorstehenden Beschreibung zu erkennen, dass die Flussdaten-Sammeleinrichtung 52 eine Software-Komponente des Abrechnungsprozesses ist und auf dem Flussdaten-Sammelsystem 300 abläuft. Das Flussdaten-Sammelsystem 300 kann irgendein Computersystem, wie eine Arbeitsstation oder ein Host-Computer sein, der mit der Ausrüstungs-Schnittstelle kommunizieren kann. Alternativ kann die FDC in dem Netzwerk-Gerät selbst vorliegen. Viele bekannte Einzelheiten des Flussdaten-Sammelsystems 300 wurden aus Gründen der Klarheit in 14 fortgelassen, weil diese Figur dazu bestimmt ist, die Prozesse und Speicherstrukturen hervorzuheben, die der Flussdaten-Sammeleinrichtung zugeordnet sind.
Vom Konzept her ist, wie dies weiter oben beschrieben wurde, jede Flussdaten-Sammeleinrichtung der Abrechnungsprozess-Architektur in der Lage, mehrfache Ausrüstungs-Schnittstellen 16 zu unterstützen. Auf der Implementationsebene gibt es eine Ein-zu-Eins-Entsprechung zwischen jedem Flussdaten-Sammel-"Prozess" und einer vorgegebenen Ausrüstungs-Schnittstelle 16. Beispielsweise könnte ein einziges Computersystem eine Unterstützung sowohl für RADIUS und Fluss-Sonden ergeben und auf diesen können somit getrennte Flussdaten-Sammel-Prozesse für die RADIUS-EI- und die Fluss-Sonden-Ausrüstungs-Schnittstelle ablaufen. Bei einer derartigen Konfiguration, bei der die Flussdaten-Sammel-Prozesse unabhängig ablaufen und direkt in dem Fluss-Zusammenfassungs-Prozessor 60 (2) geladen werden, kann das Computersystem als solches als eine Flussdaten-Sammeleinrichtung betrachtet werden, die mehrfache EI's unterstützt.
In 15 ist ein Datensammel-Prozess 330 gezeigt, der von der Flussdaten-Sammeleinrichtung 52 nach 14 ausgeführt wird. Die Flussdaten-Sammeleinrichtung empfängt bei 332 Daten von der Ausrüstungs-Schnittstelle für ein Netzwerk-Gerät. Die Flussdaten-Sammeleinrichtung führt eine Ausrüstungs-Schnittstellen-spezifische Umsetzung aus, um bei 336 die empfangenen Daten in ein NAR-Format umzuwandeln und das NAR-Kopffeld zu belegen. Sobald der NAR mit den passenden Daten belegt wurde, versucht die Flussdaten-Sammeleinrichtung 52, den neu belegten NAR mit anderen NAR's bei 338 zu korrelieren. Das heißt, die Flussdaten-Sammeleinrichtung 52 vergleicht den neu belegten NAR mit NAR's, die derzeit in dem örtlichen Speicher 314 (aus 14) gespeichert sind, um festzustellen, ob es mehrfache Instanzen des gleichen Objektes gibt. Speziell wird eine Korrelation durch Überprüfen der ACCT ENTITY ID (aus den 11A–11E) ausgeführt.
Die Flussdaten-Sammeleinrichtung verwendet einen Takt und eine Zeit-Bestimmungseinrichtung, so dass alle NAR's, die die Flussdaten-Sammeleinrichtung verarbeitet oder enthält, so betrachtet werden, als ob sie sie in der gleichen Zeitdomäne befinden. Entsprechend muss die Flussdaten-Sammeleinrichtung nicht die Zeit während der Korrelation berücksichtigen. Wenn die Flussdaten-Sammeleinrichtung 52 feststellt, dass eine NAR ACCT_ENTITY_ID (das heißt die Sammlung von Deskriptoren oder Objekten, wie dies weiter oben beschrieben wurde) in dem NAR mit der eines anderen NAR übereinstimmt, die sie derzeit enthält, kann die FDC 52 einen älteren (gespeicherten) NAR durch einen neuen (das heißt zuletzt gelegten) NAR ersetzen und den älteren NAR verwerfen. Beispielsweise kann der vorhandene oder ältere NAR ein Start-Datensatz sein, und der neue NAR ein Stopp-Datensatz, der alle die Daten einschließt, die in dem älteren NAR enthalten waren, wodurch der ältere NAR abgelöst wird. Alternativ kann, wenn der neue NAR ein Replikat eines vorhandenen NAR ist, die FTC entscheiden, den neuen NAR zu verwerfen. Weiterhin kann die Daten-Sammeleinrichtung feststellen, dass die zwei NAR's miteinander vereinigt oder zusammengefasst werden sollten. Somit kann der Korrelationsprozess den neuen NAR verwerfen, einen älteren NAR durch den neuen NAR ersetzen oder die zwei übereinstimmenden NAR's als Kandidaten für eine Zusammenfassung markieren, ein Prozess, der weiter unten im Einzelnen beschrieben wird.
Als Teil des Korrelationsprozesses kann die Flussdaten-Sammeleinrichtung bei 340 den neuen NAR verbessern. Das heißt, die FDC kann feststellen, dass der NAR nicht ohne ein gewisses Ausmaß an Verbesserung korreliert werden kann. Die FDC 52 verbessert den NAR durch Ergänzen der Information, die von der ursprünglichen Quellenausrüstung geliefert wurde, mit Informationen, die nicht von dieser Quellenausrüstung verfügbar ist. Die zusätzliche Information wird zu der ACCT_ENTITY_ID hinzugefügt. Es sei daran erinnert, dass die Abrechnungseinheits-Identifikation ACCT_ENTITY_ID eine Sammlung von Deskriptoren ist, so dass der Verbesserungsprozess 310 zu dieser Sammlung von Deskriptoren weitere hinzufügt. Beispielsweise könnte die abzurechnende Einheit ID ACCT_ENTITY_ID in einem NAR eine Quellen-Adresse und eine Zieladresse zusammen mit einem Wert einschließen, der anzeigt, wie lange der Fluss (für die abzurechnende Einheit) existiert hat. Ein nachfolgend verarbeiteter NAR-Datensatz, der diese gleichen drei Objekte hat, kann korreliert werden Wenn ein nachfolgend verarbeiteter NAR lediglich zwei der drei Objekte hat, kann die Flussdaten-Sammeleinrichtung die ID der abzurechnenden Einheit, ACCT_ENTITY_ID für das dritte (fehlende) Objekt hinzufügen, um eine Korrelation zu ermöglichen. Die Verbesserung kann das Sammeln von Informationen von einem vollständig anderen Netzwerk-Gerät beinhalten (über einen NAR, der von einer anderen Abrechnungsprozess-Komponente erzeugt wird, wie z.B. einer anderen Daten-Sammeleinrichtung) oder sie kann so einfach sein, wie die Hinzufügung eines Zeitstempels zu der Rechnungseinheits-ID des NAR.
Wie dies weiter oben angegeben wurde, kann der Korrelationsprozess bei 342 feststellen, dass zwei NAR's „zusammengefasst" werden sollten. Die Zusammenfassung oder Aggregation vereinigt die Identifikationen der Abrechnungseinheit der beiden NAR's miteinander. Sie vereinigt weiterhin Metriken für NAR's, die Metriken enthalten, wie dies weiter unten beschrieben wird. Die Zusammenfassung der Identifikationen der Abrechnungs-Einheit wird über eine explizite und implizite Übereinstimmung dieser Abrechnungs-Einheits-Identifikationen bewirkt. Die Korrelation beruht auf den explizit übereinstimmenden Feldern, das heißt den Feldern oder Objekten, die tatsächlich verwendet werden, um festzustellen, dass zwei NAR's zusammengefasst werden sollten. Die anderen Deskriptoren oder Objekte in der Abrechnungs-Einheit-ID, die in dem Korrelationsprozess nicht verwendet wurden, um eine Übereinstimmung festzustellen, können gleich oder unterschiedlich sein. Eine Zusammenfassung des ID-Teils für die abrechenbare Einheit in dem NAR behält die explizit übereinstimmenden Objekte bei und bestimmt, welche der implizit übereinstimmenden Objekte (die übereinstimmenden Objekte, die keinen Teil der expliziten Übereinstimmung bildeten) beibehalten oder verworfen werden sollten. Selbstverständlich werden die nicht übereinstimmenden Objekte automatisch verworfen, weil alle die Metriken, die das Ergebnis dieser Zusammenfassung sind, für die Objekte in der ID der zusammengefassten abrechenbaren Einheit ACCT_ENTITY_ID anwendbar sein sollten. Die Entfernung der Abrechnungs-Einheits-ID-Deskriptoren dienen tatsächlich dazu, die semantische Kompliziertheit des NAR zu verringern, während die Verbesserung gerade das Gegenteil bewirkt.
Wenn der Daten-Sammelprozess 330 eine Entscheidung bezüglich der Zusammenfassung oder Aggregation beinhaltet, wendet die Flussdaten-Sammeleinrichtung 52 bei 344 die Zusammenfassungs-Richtlinie 322 (von 14) an und verwendet ein darin definiertes Verfahren. Das Verfahren oder die Methode umreisst den Entscheidungs-Durchführungsprozess, dem die FDC im Fall von implizit übereinstimmenden Objekten folgen soll. Die Zusammenfassungs-Richtlinie wird weiter unten ausführlicher unter Bezugnahme auf 18 erläutert. Sobald die Flussdaten-Sammeleinrichtung den Abrechnungs-Einheit-ID, ACCT_ENTITY_ID-Teil der NAR-Attribute zusammenfasst, kann sie die NAR-Metriken zusammenfassen. Zur Zusammenfassung der Metriken führt die Flussdaten-Sammeleinrichtung einen Summierprozess an den numerischen Metrik-Werten und/oder eine logische Operation (beispielsweise eine UND-Verknüpfung, eine ODER-Verknüpfung oder eine EXKLUSIV-ODER-Verknüpfung) an logischen Metrik-Werten aus. Die Zusammenfassung der Metriken ist für jedes Metrikfeld in dem NAR spezifisch.
Vor dem Beginn der Übertragung bestimmt die Datenfluss-Sammeleinrichtung 52 bei 350, ob der Fluss-Zusammenfassungs-Prozessor 60 zum Empfang von NAR's verfügbar ist. Wenn der Fluss-Zusammenfassungs-Prozessor 60 nicht verfügbar ist, speichert die Flussdaten-Sammeleinrichtung bei 352 die zu übertragenden NAR's in ihrem örtlichen Speicher 314 (16). Die Flussdaten-Sammeleinrichtung 52 setzt die Prüfung 354 der Verfügbarkeit des Fluss-Zusammenfassungs-Prozessors unter periodischen Intervallen fort, bis die Verbindung zwischen dem Fluss-Zusammenfassungs-Prozessor 60 und der Flussdaten-Sammeleinrichtung wiederhergestellt ist. Wenn die periodische Status-Prüfung bei 350 anzeigt, dass der Fluss-Zusammenfassungs-Prozessor verfügbar ist, lädt die Flussdaten-Sammeleinrichtung bei 356 NAR's in den Fluss-Zusammenfassungs-Prozessor 60. Die Ladefunktion kann entsprechend einer von vielen Strategien realisiert werden, beispielsweise eine Datenbank-, Datei- oder Datenstrom-Strategie. Andere Strategien könnten verwendet werden. Wenn die Flussdaten-Sammeleinrichtung bei 358 eine Bestätigung oder Quittierung von dem Fluss-Zusammenfassungs-Prozessor erhält, dass die NAR's geladen wurden, so wird die Übertragung als erfolgreich betrachtet und die örtlich gespeicherten Kopien der übertragenen NAR's werden bei 360 aus dem örtlichen Speicher entfernt. Somit ergeben die „Speicher- und Weiterleitungs"-Fähigkeiten der Flussdaten-Sammeleinrichtung ein Maß der Fehlertoleranz an dieser Abrechnungsprozess-Ebene, um eine zuverlässige Datenübertragung sicherzustellen. Die Flussdaten-Sammeleinrichtung überträgt NAR's nur dann, wenn sie festgestellt hat, dass der Fluss-Zusammenfassungs-Prozessor verfügbar ist, und sie betrachtet die NAR-Übertragung erst bei Empfang einer Bestätigung von dem Fluss-Zusammenfassungs-Prozessor als erfolgreich.
Der Fluss-Zusammenfassungs-Prozessor (FAP) 60 (2) fasst Datensatz-Daten über das System 10 hinweg zusammen und/oder verbessert diese. Er empfängt Daten von der Vielzahl von Flussdaten-Sammeleinrichtungen (FDC's), die eine Zusammenfassung und Verbesserung nahe an der Quelle der Information durchführen (wie dies weiter oben anhand der 17 beschrieben wurde). Während NAR's von mehrfachen FDC's empfangen werden, können die Daten weiter verbessert und/oder reduziert (das heißt zusammengefasst) werden, um die speziellen Notwendigkeiten einer Anwendung oder einer Ausgangs-Schnittstelle auf der Grundlage der Zusammenfassungs-Richtlinie des Fluss-Zusammenfassungs-Prozessors 60 (FAP) zu erfüllen. Die Konstruktion und Betriebsweise des FAP wird nachfolgend ausführlicher beschrieben.
Fluss-Zusammenfassungs-Prozessor
Es wird nunmehr auf 16 Bezug genommen, in der zu erkennen ist, dass eine Realisierung des FAP 60 in Form eines Datenbank-Verwaltungssystems oder spezieller eines Datenbank-Verwaltungssystems mit einer strukturierten Abfragesprache (SQL) ist, wie sie im Handel von der Firma Oracle oder Sybase erhältlich ist. Obwohl dies nicht gezeigt ist, ist es verständlich, dass der FAP auf einem Computersystem installiert ist, wie z.B. einem Host-Computer. Bei Implementation als ein Datenbank-Verwaltungssystem schließt der FAP einen Datenbank-Server 400 ein, der mit einer Datenbank 402 gekoppelt ist. Die FDC's 52 (von 14) können das „Push"-Modell zum Bewegen von NAR's aufwärts zu dem FAP über SQL-Aufrufe bewegen. Die Datenbank 402 speichert eine Vielzahl von Tabellen 404, unter Einschluss einer NAR-Tabelle (die als persistenter Pufferspeicher realisiert ist) und eines Zusammenfassungs-Speichers 408. Weiterhin sind in der Datenbank eine Vielzahl von SQL-Befehlen und Prozeduren (Funktionen) 410 gespeichert, die von dem Server 400 auszuführen sind. Die Funktionen schließen einen FAP-Korrelator 412, eine FAP-Verbesserungseinrichtung (Verbesserungsprozess) 414 und eine FAP-Zusammenfassungseinrichtung 416 ein. Die Datenbank speichert weiterhin eine Konfigurationsdatei 420 zum Speichern von Konfigurationsparametern, wie z.B. Zeit und Richtlinien-Information. Die Betriebsweise des FAP wird nachfolgend unter Bezugnahme auf 17 beschrieben.
In 17 ist ein Gesamt-Fluss-Zusammenfassungs-Prozess 430 gezeigt, der von dem FAP ausgeführt wird. Der FAP empfängt bei 432 einen NAR von einer oder mehreren FDC's und lädt bei 434 den empfangenen NAR in einen persistenten Speicher oder Pufferspeicher (der Datenbank 492 von 16). Wenn der FAP nicht in der Lage ist, den NAR zu laden, fordert er bei 436 auf, dass die übertragende FDC den NAR erneut sendet. Wenn der Ladevorgang erfolgreich ist, sendet der FAP bei 438 eine Bestätigung an die sendende FDC zurück. Der FAP bestimmt bei 440, ob der NAR (mit oder ohne Verbesserung) korreliert werden kann. Wenn der FAP feststellt, dass der NAR korreliert werden kann, korreliert der FAP den NAR bei 442 mit anderen NAR's, die von anderen FDC's empfangen werden. Sobald der NAR korreliert wurde, kann er bei 444 „über das System hinweg" in einer Weise verbessert werden, die ausführlicher anhand der 18 beschrieben wird. Der NAR kann bei 446 verbessert oder ergänzt werden, um Verbesserungs-Information einzuschließen, die von einer externen Quelle gewonnen wird (die beispielsweise von einer Daten-Sammeleinrichtung einer anderen Ausrüstungs-Schnittstelle gesammelt wird). Sobald irgendeine mögliche Korrelation und Verbesserung ausgeführt wurde, bestimmt der FAP bei 448, ob der NAR ein Kandidat für eine Zusammenfassung ist. Wenn dies der Fall ist, wendet der FAP bei 450 die Zusammenfassungs-Richtlinie 420 (von 16) an und speichert bei 452 den resultierenden, zusammengefassten NAR in dem Zusammenfassungs-Speicher, bis eine vorgegebene Zeit abgelaufen ist oder ein Ereignis bei 454 eintritt (wie dies in der FAP-Konfiguration 420 eingestellt ist). Der FAP 456 stellt die Eindeutigkeit und Integrität irgendeines NAR dadurch sicher, dass die NAR-Kopffeld-Information überprüft wird, bevor bei 458 ein derartiger NAR in dem persistenten Speicher neu geladen wird.
Die Abrechnungs-Architektur kann so realisiert werden, dass sie einen zweiten „Schatten"-FAP-Prozess einschließt, der ebenfalls mit den Daten-Sammeleinrichtungen gekoppelt ist und in der Weise arbeitet, wie sie vorstehend bezüglich des Empfangs und der Verarbeitung von NAR's beschrieben wurde. In der dualen/Schatten-FAP-Realisierung schließt die Abrechnungs-Architektur weiterhin ein (nicht gezeigtes) Fehlerdetektionsmodul ein, das sowohl mit dem ersten (primären) als auch zweiten (Schatten-) FAP-Prozess gekoppelt ist. Das Fehlerdetektionsmodul wird betrieben, um einen Fehler bezüglich des ersten Fluss- Zusammenfassungs-Prozesses festzustellen und zu bewirken, dass die Zusammenfassungs-Berichte von dem zweiten Fluss-Zusammenfassungs-Prozess an das Abrechnungsmodul (das heißt den Flussdaten-Verteiler 70) übertragen werden, und zwar anstelle der zusammengefassten Berichte von dem ersten Fluss-Zusammenfassungs-Prozess.
Es wird nunmehr auf 18 Bezug genommen, in der ein Beispiel einer Anwendung des FAP-Verbesserungs-Prozesses 444 (von 17) gezeigt ist. In dem dargestellten Beispiel bestimmt die Verbesserung deterministisch die Quelle des erfassten Netzwerk-Abrechnungs-Datensatzes, des Flusses oder einer Transaktion über ein Netzwerk. Die Verbesserung greift auf andere Informationsquellen auf dem Netzwerk zu, um den Datensatz zu verbessern oder zu ergänzen, um gegenüber einem bestimmten Benutzer zurechenbar zu machen.
In dem in der Figur gezeigten Beispiel werden zwei NAR's von unterschiedlichen Quellen unvermeidbar zusammengefasst, um einen dritten eindeutigen NAR zu erzeugen. Eine erste Quellenausrüstung (oder Quelle) 500 ist ein DHCP- (dynamischer Host-Konfigurationsprotokoll-) Server. Eine zweite Quellen-Ausrüstung (oder Quelle) 502 ist eine (weiter unten erläuterte) Fluss-Sonde. Die Quellen 500, 502 haben entsprechende Flussdaten-Sammeleinrichtungen, eine erste FDC (FDC1) 504 bzw. eine zweite FDC (FDC2) 506 zur Umwandlung ihrer Daten in jeweilige NAR's, NAR1 508 und NAR2 510. Wie dies weiter oben beschrieben wurde, teilt jede Flussdaten-Sammeleinrichtung eine Abrechnungs-Einheits-Identifikation 512, 514 zu und fügt eine Zeitstempel-Information 516, 518 zu den Datensätzen der Quellen hinzu, denen sie entsprechen. Der NAR1 508 schließt in seiner zugeteilten Abrechnungs-Einheits-Identifikation 512 eine „IP-Adressen-zu-Benutzername"-Zuordnung ein, und schließt somit eine IP-Adresse 522 und einen Benutzernamen 524 ein. Die Abrechnungs-Einheit-Identifikation 514 von der zweiten Quelle ist ein IP-zu-IP-Fluss und schließt daher eine erste IP-Adresse 526 und eine zweite IP-Adresse 528 ein. Der NAR2 der Fluss-Sonde schließt außerdem ein Metrik-Attribut 530 ein.
Diese zwei Datensätze NAR1, NAR2 werden durch eine Korrelation 442 (von 17) und eine Verbesserung 444 (17) kombiniert, um einen verbesserten NAR2 532 zu erzeugen. Dieser verbesserte NAR hat eine modifizierte abzurechnende Einheits-Identifikation 534 und eine Metrik. Die modifizierte abzurechnende Einheits-Identifikation ist die vorhandene Abrechnungs-Einheits-ID 514, zu der der FAP die IP-zu-Benutzernamen-Zuteilung von der abzurechnenden Einheits-ID 512 des NAR1 508 hinzugefügt hat.
Unter weiterer Bezugnahme auf 18 hat der NAR1 508 eine IP-zu-Benutzernamen-Umsetzung 512 und ein Abrechnungs-Intervall 516, das eine Startzeit und eine Sitzungszeit umfasst, um ein Zeitintervall anzuzeigen, das durch eine Startzeit „T1" und eine Startzeit + Sitzungszeit („T2") begrenzt ist, das heißt das Abrechnungs-Intervall stellt eine Startzeit und eine Stoppzeit dar. Der Benutzername 524 in der IP-Adressen-zu-Benutzername-Umsetzung wird von dem DHCP-Server 500 geliefert. In dem FAP wird diese NAR1-Information entweder direkt an eine Korrelationsfunktion oder einen örtlichen Speicher (der entweder eine Datenbank, eine Datei oder ein Speicher sein könnte) geliefert, wo auf sie direkt von der Korrelator-Funktion zugegriffen werden kann. Der NAR2 510 hat eine Abrechnungs-Einheits-ID 514, ein T3-zu-T4-Abrechnungs-Zeitintervall 518 und eine Metrik 530. Die Abrechnungs-Einheits-Identifikation 514 hat zwei IP-Adressen 526, 528, von denen eine einer Quellen-IP-Adresse entspricht und die andere einer Ziel-IP-Adresse entspricht. Der NAR2 510 wird dem Korrelator 442 zugeführt, der feststellt, dass das T1-zu-T2-Zeitintervall 516 von der IP-zu-Benutzernamen-Adressen-Umsetzung in dem NAR1 508 das T3-zu-T4-Zeitintervall 518 des NAR2 510 überlappt oder in gewisser Weise auf dieses bezogen ist. Der Korrelator 442 bestimmt, dass T1, T2, T3 und T4 zueinander in Beziehung stehen, und dass die IP-Adresse 522 in der IP-zu-Benutzernamen-Adressen-Umsetzung 512 mit einer der zwei IP-Adressen 526, 528 in dem NAR2 510 in Beziehung steht. Somit verbessert der FAP den NAR2 510 durch Einfügen von der Abrechnungs-Einheits-ID 512 (des NAR1 508) in den Abrechnungs-Einheits-ID-Teil des NAR2 510. Der resultierende verbesserte NAR2 532 hat eine verbesserte Abrechnungs-Einheits-ID 534, die den (nicht gezeigten) T3-zu-T4-Zeitstempel, die IP-zu-IP-Adressen 526, 528 und den Benutzernamen 524 einschließt. Somit hat der verbesserte NAR2 nunmehr eine Umsetzung zwischen dem Benutzernamen und der einen der IP-Adressen 526, 528, die zu der IP-Adresse 522 in Beziehung steht. Die Metrik 530 ist unverändert.
Es sei weiterhin bemerkt, dass der Korrelator in der Lage ist, festzustellen, dass die Zeitintervalle zueinander in Beziehung stehen, weil die Flussdaten-Sammeleinrichtungen zeitlich synchronisiert sind (oder nahezu synchronisiert sind, wenn eine gewisse Größe einer Drift angenommen wird). Wenn daher der Korrelator keine Drift annimmt, so muss T3-zu-T4 innerhalb der Zeitperiode von T1-zu-T2 liegen. Die IP-zu-Benutzernamen-Adressen-Umsetzung ist ein Ereignis, das alle die Abrechnungs-Datensätze umfassen oder abdecken muss, die für diese IP-Adresse gelten. Irgendein dieser IP-Adresse zugeordneter Benutzer begann zum Zeitpunkt T1 und endete bei T2. Lediglich diejenigen Datensätze, die auf diese IP-Adresse zwischen T1 und T2 Bezug nehmen, haben diesen Benutzernamen auf sich angewandt. Wenn die zwei Flussdaten-Sammeleinrichtungen nicht strikt synchronisiert sind, so sollte der Betrag, um den T3-zu-T4 T1-zu-T2 überlappt, dem Ausmaß der Toleranz entsprechen, das heißt der Drift, die in das System eingebaut ist. Der Abrechnungsprozess nimmt einen Drift-Wert von zumindest einer Sekunde selbst für eine strikte Zeitsynchronisation an, so dass T4 um eine Sekunde größer als T2 sein kann.
In 19 ist eine Zusammenfassung eines verbesserten NAR2 532 (von 18) gezeigt. In diesem Beispiel beinhaltet die Zusammenfassung die Kombination von NAR's mit IP-zu-IP-Benutzername-Adressen-Umsetzungen auf Arbeitsgruppen. Um dies zu erreichen, sind zwei Verbesserungen, zwei Korrelationen und eine Zusammenfassungs-Phase erforderlich. Wie dies weiter oben unter Bezugnahme auf 17 bereits beschrieben wurde, wird die IP-Adressen-zu-Benutzernamen-Information von dem FAP empfangen und wird entweder an die Korrelation weitergeleitet oder in dem örtlichen Speicher gespeichert, ist jedoch für den Korrelator verfügbar. Wenn die IP-zu-IP-Adressen-NAR mit Metriken empfangen wird, arbeiten der Korrelator und die Verbesserungseinrichtung zusammen, um die Benutzernamen-Umsetzungen zu diesem IP-zu-IP-Adressen-NAR hinzuzufügen. Der Benutzername könnte für eine oder beide der Quellen- und Zieladressen geliefert werden. Mit größerer Wahrscheinlichkeit würde der Benutzername zu der Quellen-IP-Adresse hinzugefügt.
Gemäß 19 setzt ein weiterer Korrelations- und Verbesserungs-Prozess 442, 444 den Benutzernamen 524 auf eine Arbeitsgruppe um. Der FAP baut Suchschlüssel unter Verwendung von Datenbank-Prinzipien und einer relationalen Algebra auf. So hat beispielsweise die IP-Adresse eine Eins-zu-Eins-Umsetzung mit einem Benutzernamen (die Eins-zu-Eins-Umsetzung ist aufgrund der Eigenart der IP-Adressierung und der Art sichergestellt, wie er DHCP-Server Benutzernamen zuteilt. Daher kann es lediglich einen Benutzer für eine IP-Adresse zu einem vorgegebenen Zeitpunkt geben. Diese Ausdrücke oder Werte sind äquivalente Schlüssel, so dass der Benutzername sehr einfach durch die IP-Adresse ersetzt werden kann. Der Benutzername 524, der in den verbesserten NAR2 532 eingefügt wurde, kann zum Nachschlagen in einer Arbeitsgruppe 540 in einer der Datenbank-Tabellen 404 (16) verwendet werden, bei der Benutzer tatsächlich ein Mitglied der Arbeitsgruppe ist. Daher kann die Verbesserungsfunktion zum Einfügen eines Arbeitsgruppen-Etiketts in dem verbesserten NAR2 verwendet werden (der bereits durch den Benutzernamen verbessert wurde), um einen zweifach verbesserten NAR2 542 zu erzeugen. Wenn der nunmehr zweimal verbesserte Datensatz 542 zusammengefasst werden soll, so wird er in dem Zusammenfassungs-Speicher 408 (16) für eine gewisse Zeitperiode T gehalten, bis andere NAR's für eine mögliche Zusammenfassung empfangen werden.
Es sei nunmehr angenommen, dass ein weiterer NAR in den FAP geladen wird. Dieser neue NAR gelangt an die Korrelation, die bestimmt, dass eine Verbesserung erforderlich ist, um den neuen NAR mit dem zweifach verbesserten NAR2 542 nach 9 zu korrelieren. Als Ergebnis verbessert der FAP den NAR, um den Benutzernamen 524 und die Arbeitsgruppe 540 einzuschließen, um einen resultierenden NAR, „NAR3" 550, zu erzeugen, wie dies gezeigt ist.
Gemäß 20 schließen zusätzlich zu dem Benutzernamen und der Arbeitsgruppe die anderen NAR3-Attribute das T3–T4-Abrechnungs-Intervall, die IP-IP-Adressenumsetzung und die Metriken ein. Mit dieser Verbesserung bestimmt der Korrelationsprozess 444, dass der resultierende NAR3 nunmehr mit dem zweifach verbesserten NAR2 542, der in dem Zusammenfassungs-Speicher gehalten wird, Übereinstimmungen aufweist. Nach der expliziten Feststellung der Übereinstimmung der zwei NAR's wird die Zusammenfassung 448 ausgeführt. Die Zusammenfassung behält die explizit zur Übereinstimmung gebrachten Daten-Objekte, die sich in der Abrechnungs-Einheits-Identifikation befinden, bei, verwirft irgendwelche Fehlübereinstimmungen in der Abrechnungs-Einheits-Identifikation und trifft eine Entscheidung, ob die implizit zur Übereinstimmung gebrachten Objekte (das heißt diejenigen, die gleich zu sein scheinen, jedoch bei der Durchführung der Korrelations-Übereinstimmung nicht verwendet wurden) beizubehalten sind. Sie kombiniert dann die relevanten Metrik-Werte über eine Summierung oder logische Operationen miteinander (beispielsweise eine ODER-Verknüpfung, EXKLUSIV-ODER-Verknüpfung, UND-Verknüpfung). Sobald die Zusammenfassung abgeschlossen ist, enthält der FAP den resultierenden zusammengefassten NAR 552. Während der FAP zusätzliche NAR's empfängt, führt die Zusammenfassungseinrichtung weiterhin eine Summierung und Ausführung dieser logischen Operationen an diesen Metrik-Werten für eine gewisse Zusammenfassungs-Periode aus. Die Dauer dieser Zusammenfassungs-Periode kann in der Größenordnung von 60 Sekunden bis zu einer Woche liegen, oder wie auch immer der FAP zur Zusammenfassung dieser Datensätze konfiguriert ist. Das Ende dieser Periode kann zeitlich oder Ereignis-basiert sein. Sobald ein Ereignis, das die Zeitperiode beendet, eintritt, oder ein Zusammenfassungs-Zeitgeber abläuft, werden die zusammengefassten NAR's, die in dem Zusammenfassungs-Speicher gehalten werden, für eine Ausgabe von dem FAP freigegeben.
Zusammenfassungs-Abgleich
Es ist aus der vorstehenden Beschreibung zu erkennen, dass eine Zusammenfassung an unterschiedlichen Ebenen des Abrechnungsprozesses existiert. Wie dies vorstehend anhand der 15 und 17 gezeigt und beschrieben wurde, sind sowohl die Flussdaten-Sammeleinrichtung und der FAP zu einer Zusammenfassung fähig. Jede Einheit führt die Zusammenfassung entsprechend einer Gesamt-Zusammenfassungs-Richtlinie aus, die definiert, wie die Zusammenfassung oder Aggregation verwendet wird, um Daten zu liefern, die die Anforderungen einer bestimmten Anwendung erfüllen. Die von den unterschiedlichen Ebenen ausgeführte Zusammenfassung kann weiterhin von einer entfernten Stelle aus und unabhängig eingestellt werden, wie dies nunmehr beschrieben wird.
Der Zusammenfassungs-Abgleich oder die Zusammenfassungs-Einstellung beinhaltet die Fähigkeit, den Grad der Zusammenfassung einzustellen, um einen bestimmten Anwendungs-Datenbedarf zu erfüllen. Es gibt zwei Gesichtspunkte der Zusammenfassungs-Einstellung: Steuerung von einer entfernten Stelle aus und veränderliches Ausmaß.
In 21 ist eine grafische Darstellung der Zusammenfassungs-Steuerung und -Einstellung über ein Datenfluss-Zerlegungsmodell dargestellt. Wie dies gezeigt ist, ist das Abrechnungssystem als ein Baum 560 dargestellt. Die Flussdaten-Sammeleinrichtungen sind Blatt-Knoten 562a–562e, und die zwei dargestellten FAP-Prozesse sind Zwischen-Knoten 564a–564b. Die Wurzel 566 ist die Sammelansicht aller der verarbeiteten Abrechnungs-Informationen. Im Hinblick auf die gemeinsame Ansicht aller der Daten und die speziellen Abrechnungs-Informations-Anforderungen einer vorgegebenen Anwendung verkörpert die Wurzel 566 somit eine einzige Abrechnungs-/Zusammenfassungs-Richtlinie 568. Die Abrechnungs-Richtlinie ist derart definiert, dass ein Abrechnungs-Schema eine direkte Ableitung der Abrechnungs-Richtlinie 568 ist.
Die Abrechnungs-Richtlinie 568 wird als eine Sammlung von Abrechnungs-Objekten 570 betrachtet, die jeweils als eine Abrechnungs-Einheits-Identifikation 572 und einen (nicht gezeigten) Satz von Metriken definiert sind. Die Abrechnungs-Einheits-Identifikation ist ein abstraktes Objekt, das sich aus Konstruktions-Funktionen ergibt, die die Daten der Flussdaten-Sammeleinrichtungen als ursprünglichen Startpunkt verwenden. Wenn eine Abrechnungs-Einheits-ID sich in der Abrechnungs-Richtlinie als ein Teil einer Sammlung von Abrechnungs-Objekten befindet, befindet sie sich dort, weil sie aus den FDC-Daten und dem kollektiven Satz von Operationen konstruiert werden kann, die eine Korrelation, Verbesserung und Zusammenfassung ermöglichen. Daher kann, wenn eine Abrechnungs-Einheits-ID konstruiert werden kann, sie auch zerlegt werden.
Um die Anforderungen einer vorgegebenen Benutzer-/Anwendungs-Anforderung zu realisieren, zerlegt daher das Datenfluss-Modell 566 die Abrechnungs-Einheits-ID jedes Objektes in Richtlinien-Information 572a–g, die eine Sammlung von Daten 574, die von den verfügbaren Flussdaten-Sammeleinrichtungen geliefert werden können, und einen Satz von Funktionen oder Methoden 574 einschließt, die zur Korrelation, Zusammenfassung oder Verbesserung dieser Daten zur Konstruktion der Abrechnungs-Einheits-Identifikation benötigt werden.
Die Zusammenfassungs-Einstellung übernimmt eine Abrechnungs-Richtlinie, die eine Sammlung von Abrechnungs-Objekten ist, und zerlegt diese Abrechnungs-Objekte in ihrer Abrechnungs-Einheits-Identifikationen und zerlegt dann weiter die Abrechnungs-Einheits-Identifikationen in einer rekursiven Weise, um die Sammlung von grundlegenden Daten und Funktionen zu liefern, die zur Konstruktion dieser Abrechnungs-Identifikationen benötigt werden. Dieses Konzept baut auf den logisch gerichteten Graphen auf, wie sie in vielen Compilern oder Datenfluss-Systemen zu sehen sind. In Kenntnis der Reihenfolge der Funktionen, der Daten-Anforderungen und der Abhängigkeiten kann die Datenfluss-Software einen logischen Graphen aus der Zerlegung aufbauen, der die Daten-Anforderungen und Verfahren spezifiziert und an Konfigurations-Dateien in den Flussdaten-Sammeleinrichtungen und FAP's verteilt werden, um zu einer Einstellung der Konfiguration dieser Abrechnungs-Komponenten zu führen.
Beispielsweise sei angenommen, dass ein Benutzer wünscht, eine Abrechnung auf einer stündlichen Basis von allen möglichen Informationsquellen zu erhalten. Die Flussdaten-Sammeleinrichtungen 562a–562e sind die Komponenten, die zum Sammeln der rohen Information zur Erzeugung der Abrechnungs-Daten entsprechend einer vom Benutzer festgelegten Abrechnungs-Richtlinie verfügbar sind. Die internen FAP-Prozesse 564a–564b führen eine weitere Korrelation, Verbesserung und Zusammenfassung aus, um die Daten in Richtung auf die Gesamt-Abrechnungs-Daten zu entwickeln, um die Abrechnungs-Richtlinie 568 zu erfüllen, die von einem Benutzer festgelegt ist. Somit werden die Informations-Anforderungen des Benutzers in eine Richtlinie (das heißt eine Sammlung von Objekten) umgesetzt, die von dem Abrechnungssystem empfangen wird und die in die Sätze von Daten-Anforderungen und Verfahren für jede der verfügbaren Abrechnungs-Komponenten 562a–562e, 564a–564b zerlegt werden, das heißt die Richtlinien-Information 572a–572g. Unter der Annahme, dass diese Komponenten oder Prozesse bereits konfiguriert sind, stellen diese Sätze Konfigurations-Aktualisierungen dar, die an die Konfigurations-Dateien verteilt und in diesen gespeichert werden (siehe FAP-Konfigurations-Datei 420 von 16 und FDC-Konfigurations-Datei 318 von 14) in ihren jeweiligen Prozessen.
In 22 ist eine Darstellung der Konfigurations-Aktualisierung gezeigt. Der Zerlegungs-/Konfigurations-Aktualisierungs-Prozess ist in Software realisiert und beruht auf einer bekannten Datenfluss-Technologie, die in Verbindung mit einem verfügbaren Visualisierungs-Werkzeug verwendet wird, um als eine grafische Front-End-Schnittstelle zu wirken. Unter Verwendung derartiger Visualisierungs-Werkzeuge wird die aktualisierte Konfiguration einfach auf die passende Komponente umgesetzt oder abgebildet.
Es sei bemerkt, dass nicht alle Abrechnungsprozesse eine vollständige Sammlung von Daten-Sammeleinrichtungen haben. Beispielsweise ist es, wenn der Abrechnungsprozess eine Benutzer-basierte Abrechnung ausführen soll und der Abrechnungsprozess lediglich eine Fluss-Sonde hat, erforderlich, eine Aufforderung abzugeben, dass der Benutzer eine statische Tabelle von IP-zu-Benutzernamen-Umsetzungen oder eine Quelle für DHCP-Benutzer-IP-Adressen-Umsetzungen liefert. Die Quelle dieser „externen" Information wird zu einem Teil der Zerlegungs-Strategie.
Informations-Verwaltung
Die NAR-Sequenz- oder Folgennummer (NAR_SEQ_NUM, 8B) ermöglicht es Komponenten, die sich in der nächsten Ebene befinden, festzustellen, ob es fehlende NAR's in einer Sammlung von NAR's gibt, und sie kann dazu verwendet werden, eine Messung zu liefern, wie oft NAR's in einer vorgegebenen Zeitperiode erzeugt werden. Mit den Zeitstempeln und den Folgennummern kann eine Erzeugungsrate von NAR's pro Sekunde über das gesamte System hinweg bestimmt werden. Wenn diese Information Teil jedes NAR ist, kann der Abrechnungsprozess 14 eine Messung der funktionellen Fähigkeiten der zwischenliegenden Komponenten bestimmen und einige Gesichtspunkte des Kommunikationskanals zwischen Komponenten feststellen. Weiterhin ist in einer NAR-Identifikation eine Komponententyp-Identifikation 207a enthalten, die angibt, welche Art von Komponente den NAR erzeugt hat, sowie deren Seriennummer 207b, wie es vorstehend in 8B beschrieben wurde. Die Komponententyp-Identifikation ermöglicht es dem Abrechnungsprozess 14, Komponenten-Statistiken und Charakteristiken auf der Grundlage des Komponententyps zu führen. Sie ermöglicht weiterhin eine spezielle Verarbeitung der NAR's. NAR ID's werden in einer sehr spezifischen Weise durch ein Verwaltungssystem zugeteilt, um sicherzustellen, dass die ID's tatsächlich innerhalb des Abrechnungsprozesses 14 eindeutig oder einzigartig sind.
Gemäß 23 sind die Folgennummern (NAR_SEQ_NUM) das Schlüssel-Zuverlässigkeitsmerkmal 590 des Abrechnungsprozesses 14. Dadurch, dass die Folgennummern einen Teil der NAR's bilden und in Kenntnis der Tatsache, dass die Nummern monoton ansteigen, ist es dem Abrechnungsprozess 14 möglich, verloren gegangenen Verkehr oder Datensätze bei 592 zu identifizieren. Dies ermöglicht es weiterhin dem Abrechnungsprozess, bei 592 den Umfang des verloren gegangenen Verkehrs zu bestimmen. Dadurch, dass die NAR's mit gespeicherten Abrechnungsprozess-Komponenten-ID's versehen sind (das heißt eine Daten-Sammeleinrichtung, die einem bestimmten Netzwerkgerät zugeteilt wird, die zu dem Zeitpunkt zugeteilt wird, zu dem die Sammeleinrichtung zugewiesen wird) kann der Informationsverwaltungs-Prozess 590 bei 594 die für den Fluss verantwortliche Daten-Sammeleinrichtung identifizieren. Der Abrechnungsprozess 14 kann die Daten-Sammeleinrichtung, die die NAR's eines bestimmten Flusses erzeugt hat, erneut aufrufen und bei 396 eine Aufforderung geben, dass die fehlenden NAR's (das heißt diejenigen NAR's, für die Folgennummern fehlen) erneut ausgesandt werden.
Wie dies weiter oben anhand der 2 beschrieben wurde, unterstützt der Abrechnungsprozess eine Fluss-Sonde, beispielsweise 12c, die die Netzwerk-Aktivität eines Benutzers zum Zweck der IP-Abrechnung erfasst. Die Fluss-Sonde 12c überwacht den gesamten Verkehr über eine vorgegebene Netzwerk-Verbindungsstrecke und erfasst Daten, die den unterschiedlichen Flüssen in dem Verkehr auf dieser Verbindungsstrecke zugeordnet sind. Sie ist in der Lage, IP-Datenflüsse über eine Anzahl von Technologien zu überwachen (beispielsweise Ethernet, asynchrone Übertragungsbetriebsart (ATM), FDDI usw.).
Ein wesentliches Merkmal der Fluss-Sonde ist ihre Fähigkeit, erfolgreiche und nicht erfolgreiche Verbindungsfähigkeiten festzustellen und zu berichten. Diese Fähigkeit ist für Abrechnungs- und Rückerstattungs-Anwendungen nützlich. Beispielsweise kann ein Benutzer versuchen, eine Verbindung zu einem bestimmten Switch oder einer Vermittlung herzustellen oder ein bestimmtes Netzwerk zu erreichen, wird jedoch zurückgewiesen. Die Fluss-Sonde 12c kann diese Transaktion als nicht erfolgreich identifizieren und der Rechnungsstellungs-Anwendung Informationen liefern, die die Rechnungsstellungs-Anwendung bei der Feststellung verwenden kann, ob der Benutzer für diese Transaktion belastet werden sollte oder nicht. Das Fluss-basierte Verbindungsfähigkeits-Modell, das in den Fluss-Sonden verwirklicht ist, wird allgemein anhand der 23–25 und speziell unter Bezugnahme auf die 27–28 beschrieben.
In 24 ist eine Darstellung eines Netzwerkes 600 gezeigt, bei dem ein Endsystem „A" 602 mit einem anderen Endsystem „B" 604 verbunden ist. Die Endsysteme A 602 und B 604 kommunizieren miteinander über einen Kommunikationspfad 606. Entlang dieses Pfades befinden sich mehrfache Geräte 608 (beispielsweise Router, Switches) zur Unterstützung der Kommunikations-Dienste, die für Kommunikationen zwischen A und B erforderlich sind. Obwohl der Pfad von A zu B als einfache gerade Linie dargestellt ist, ist es zu erkennen, dass die tatsächliche physikalische Topologie dieses Pfades mit größter Wahrscheinlichkeit äußerst kompliziert ist. Für den Zweck des Verständnisses des Verbindungsfähigkeits-Modells der Fluss-Sonde ist es jedoch nicht erforderlich, zu wissen, wie das tatsächliche Netzwerk konfiguriert werden sollte.
Der physikalische Einsatz der Fluss-Sonde in einem Netzwerk, wie z.B. dem Netzwerk 600 beruht auf zwei Kriterien: Betriebsverhalten, beispielsweise muss eine 100 Mb-Sonde in einem Bereich des Netzwerkes eingesetzt werden, der mit 100 Mb arbeitet, und Granularität der zu erzeugenden Information. Das heißt, wenn das Betriebsverhalten oder die Dienstgüte, die von A geliefert wird, von besonderem Interesse ist, so befindet sich die Fluss-Sonde so nahe an A wie möglich, so dass die Fluss-Sonde den gesamten Verkehr sieht, der von A gesehen wird.
Der Einsatz der Fluss-Sonde kann im Verlauf oder außerhalb des Verlaufs des Stromes von interessierenden IP-Paketen sein. Somit kann die Fluss-Sonde 12 In-Line eingesetzt werden, das heißt integriert in eine der Komponenten, die tatsächlich Teil einer Unterhaltung sind (wie die Endstation A 602, wie dies in der Figur gezeigt ist), sie kann eines der Geräte 608 sein, die die Kommunikation tatsächlich unterstützen, oder sie kann außerhalb des Verlaufs angeordnet sein, das heißt Pakete werden kopiert und an eine entfernt liegende Stelle geliefert.
Allgemein wird ein Fluss als irgendeine Kommunikation zwischen miteinander kommunizierenden Einheiten definiert, die durch eine IP-Adresse, ein Protokoll und einen Dienst-Port identifiziert sind. Alle IP-Pakete (oder Datagramme) werden unter Verwendung der Felder kategorisiert, die in den Paketen selbst vorliegen: Quelle/Ziel-IP-Adressen, das in dem PROTO-Feld des IP-Kopffeldes angezeigte Protokoll, und im Fall des Benutzer-Datagramm-Protokolls (UDP) oder des Übertragungskontroll-Protokolls (TCP) durch die Portnummern der Quelle und des Ziels des Paketes.
In einem vorgegebenen Netzwerk-Segment, das durch die Fluss-Sonde überwacht wird, schließt ein großer Teil des typischen IP-Verkehrs TCP-Protokoll-Verkehr ein. Weil die Fluss-Sonde eine Fluss-basierte Überwachungseinrichtung ist, die tatsächlich TCP als einen Fluss verfolgt, kennt sie vollständig das TCP-Protokoll und den Dreiweg-Quittungsaustausch-Algorithmus (Zustandsmaschine) dieses Protokolls. Der TCP-Fluss hat Anzeigen, die anzeigen, dass eine Verbindung hergestellt ist, oder dass ein Fluss unterbrochen wird. Diese Mitteilungen sind jedoch lediglich für die zwei miteinander kommunizierenden Parteien (beispielsweise A und B in 24) von Bedeutung. Das Endsystem A kann anfordern, in der Lage zu sein, mit B zu kommunizieren, und es sendet eine „TCP SYN"-Anzeige. Jedes der Netzwerk-Geräte 608 entlang des Pfades 606 kann diese SYN-Anforderung zurückweisen, vollständig unabhängig von dem vorgesehenen Ziel (in diesem Beispiel, in System B) und ohne die Kenntnis, dass das Endsystem B ein Teilnehmer an dieser Kommunikations-Anforderung ist. Es gibt eine Vielzahl von Problemen, die dazu führen, können, dass eine interne Netzwerk-Komponente eine Anforderung zurückweist. Beispielsweise kann ein Router zwischen A und B feststellen, dass es keine verfügbare Route zur Weiterleitung eines Paketes in Richtung auf B gibt, oder dass der Routenführungs-Pfad außer Betrieb ist (und keine Alternative existiert), oder der Router kann feststellen, dass er nicht die Ressourcen hat, um das Paket abzuwickeln.
Das Internet-Steuermitteilungs-Protokoll (ICMP) wird zur Übertragung dieser Art von Fehlerereignis-Information zurück an den Ursprung der Anforderung vorgesehen. Beispielsweise sei angenommen, dass das Gerät 608 ein Router ist, der sich in einem „Ausfall"-Zustand befindet und die SYN-Anforderung, die er von A empfangen hat, nicht verarbeiten kann. Es existiert eine Unterstützung in dem Internet-Protokoll, insbesondere in ICMP, um diesen Zustand zurück an A zu signalisieren. Der Ursprung A hat die Fähigkeit, das Fehlerereignis mit der Anforderung zu korrelieren und die anfordernde Anwendung zu informieren, dass ihre Anforderung nicht unterstützt wird. Weil das Netzwerk ein vollständig unabhängiges Protokoll, das heißt ICMP, verwendet, um die Information zu übertragen, ist es erforderlich, diese unabhängigen Protokolle (TCP und ICMP) zu korrelieren, um dem Abrechnungsprozess die Information zu liefern, die er über eine vorgegebene Transaktion kennen muss. Insbesondere muss der Abrechnungsprozess wissen, ob die Transaktion erfolgreich oder nicht erfolgreich war, sowie die Ursache des Fehlers, wenn sie nicht erfolgreich war.
Als eine unabhängige Überwachungseinrichtung, die außerhalb des Kontextes der Ursprungs-Einheit („A" in diesem Beispiel) arbeitet, ist die Fluss-Sonde in der Lage, eine vollständige und genaue Aufzeichnung oder einen Datensatz der Transaktion durch Umsetzen der Netzwerk-Steuerinformation auf die Benutzer-Anforderungs-Information zu erzeugen. Zu diesem Zweck korreliert die Fluss-Sonde die Zustands-Information in Protokollen, wie z.B. TCP, mit den Fehlerereignis- oder Zustands-Mitteilungen, die von anderen Protokollen geliefert werden, wie z.B. ICMP. Auf diese Weise ist es möglich, festzustellen, ob eine bestimmte Anforderung für einen Dienst tatsächlich als Ergebnis irgendeines Netzwerk-unabhängigen Ereignisses verweigert wurde. Die Fluss-Sonde korreliert die voneinander verschiedenen Protokolle miteinander und findet einen Weg zur Darstellung des Netzwerk-Ereignisses in seinem normalen Bericht über den TCP-Fluss.
Die Fluss-Sonde hat bestimmte Berichtmechanismen für bestimmte Protokolle. Das TCP-Protokoll hat beispielsweise viel mehr ihren Protokoll-Zuständen zugeordnete Metriken, als UDP-basierte Flüsse. Weil jedoch für ICMP relevante Ereignisse oder Netzwerk-relevante Ereignisse einander nicht zugeordnet sind oder keine Auswirkung auf den Zustand von TCP oder UDP oder irgendeines der normalen Protokolle haben, ergibt die Fluss-Sonde einen Mechanismus zur Markierung ihrer Zustandsverfolgung mit dem Fehlerereignis. Der NAR wird als eine Fluss- Startanzeige, ein fortgesetzter oder Status-Datensatz und ein Stopp-Datensatz dargestellt. Alle die internen Protokollanzeigen der Fluss-Sonde werden auf Start-Dauer- oder Stopp-Zustände umgesetzt. Wenn ein Netzwerk-Zurückweisungsereignis eintrifft (beispielsweise in der Form einer ICMP-Mitteilung oder irgendeiner anderen Art von Internet-Steuerinformation) kehrt die Sonde unabhängig von dem Zustand, den sie als derzeitigen Zustand verfolgt, auf einen Stopp-Zustand zurück und muss die normalen Zeit- oder Übergangs-basierten Stopp-Bedingungen erweitern, um ein bestimmtes ICMP-Ereignis als die Ursache des Geschlossen-Zustandes einschließen. Der NAR der Fluss-Sonde schließt Bit-Anzeigen für die tatsächlichen Protokoll-Zustände ein, die sie verfolgt. Für von ICMP erzeugte Ereignisse zeigt die Fluss-Sonde an, ob die Quelle oder das Ziel durch die Ereignisse beeinflusst wurde. Um diese Netzwerk-Zurückweisung oder das Netzwerk-Ereignis an den Haupt-Fluss zurück zu übertragen ermöglicht der NAR, dass eine bestimmte Netzwerk-Zurückweisungslogik entweder von der Quelle oder dem Ziel berichtet wird, und er hat bestimmte Bit-Anzeigen in entweder dem Quellen- oder dem Zielfeld.
Es gibt zwei Schlüssel-Gesichtpunkte für das Verbindungsmöglichkeitsschema der Fluss-Sonde, soweit sie bisher beschrieben wurde. Zunächst bestimmt die Sonde, dass ein ICMP-Ereignis eingetreten ist. Zweitens korreliert die Sonde dieses Ereignis zu dem „Haupt"-Fluss, das heißt dem gleichen Fluss wie der, der mit der fehlgeschlagenen Anforderung verbunden ist, und sie speichert das exakte ICMP-Ereignis in irgendeinem Zustand, der diesem Fluss zugeordnet ist, so dass das Ereignis an das Abrechnungssystem in einem NAR berichtet werden kann. An diesem Punkt kann es zweckmäßig sein, die IP-Paket- und ICMP-Mitteilungsformate allgemein zu betrachten und auch bestimmte interessierende Felder zu betrachten.
In 25 ist ein Beispiel eines IP-Paketformates 610 gezeigt. Das IP-Paketformat 610 schließt ein IP-Paket-Kopffeld 612 und ein IP-Paket-Datenfeld 614 ein. Das IP-Paket-Kopffeld 612 schließt ein PROTOCOL-Feld 616 zur Anzeige des Protokolls der darin eingekapselten Mitteilung ein. Das Kopffeld schließt weiterhin ein Quellen-IP-Adressenfeld 618, ein Ziel-IP-Adressenfeld 620 und andere (nicht gezeigte) bekannte Felder ein. In dem Beispiel nach 25 ist die in dem IP-Paket-Datenfeld (oder den Nutzdaten) enthaltene Mitteilung eine ICMP-Mitteilung oder ein Paket 622. Das ICMP-Paket ist so formatiert, dass es ein ICMP-Kopffeld 624 und ein ICMP-Datenfeld 626 einschließt. In dem Beispiel würde das Protokollfeld 616 gesetzt, um einen Protokoll-Wert anzuzeigen, der ICMP entspricht.
In 26 ist ein Beispiel eines ICMP-Mitteilungsformates 622 zum Bericht von Fehlern gezeigt. Das Format schließt ein ICMP-Mitteilungs-Kopffeld 624 ein. Das Kopffeld 624 schließt ein Typ-Feld 630, das die Bedeutung der Mitteilung sowie deren Format definiert, und ein Code-Feld 632 ein, das die Mitteilung weiter definiert (Fehlerereignis). Die Fehlerbericht-Mitteilungstypen (Typ-Werte) schließen Folgendes ein: Ziel nicht erreichbar (3); Quellen-Überlastung (4); Quellen-Route ausgefallen (5); Netzwerk für jede Art von Dienst nicht erreichbar (11); und Parameterproblem (12). Jede der Typen hat eine Anzahl von Code-Werten. Für eine Ziel nicht erreichbar-Mitteilung (Typ-Feld-Wert ist 3) schließen die möglichen Codes (Code-Werte) Folgendes ein: Netzwerk nicht erreichbar (0); Host nicht erreichbar (1); Protokoll nicht erreichbar (2); Port nicht erreichbar (3); Fragmentierung erforderlich und DF gesetzt (4); Quellen-Route ausgefallen (5); Ziel-Netzwerk unbekannt (6); Ziel-Host unbekannt (7); Quellen-Host isoliert (8); Kommunikation mit Ziel-Netzwerk durch Verwaltung verboten (9); Kommunikation mit Ziel-Host durch Verwaltung verboten (10); Netzwerk für jede Art von Dienst unerreichbar (11); und Host für Typ des Dienstes nicht erreichbar (12).
Weiterhin ist in dem ICMP-Mitteilungsformat ein Datagramm-Vorspann-Feld 634 enthalten, das einen Vorspann – Kopffeld und erste 64 Datenbits – des IP-Datagramms enthält, das verworfen wurde, das heißt des Datagramms, das die Fehlerereignis-Mitteilung auslöste. Das Datagramm-Vorspann-Feld 634 entspricht der ICMP-Mitteilungs- (Paket-) Nutzinformation. Das IP-Datagramm oder Paket-Kopffeld 612, das teilweise in 24 gezeigt ist, ist hier in seiner Gesamtheit gezeigt. Unter der Annahme, dass das IP-Datagramm eine TCP-Mitteilung überträgt, würde der Protokoll-Wert TCP entsprechen, und der Teil der IP-Datagramm-Daten 636 (erste 64 Bits) würde tatsächlich einem TCP-Mitteilungs-Kopffeld 636 entsprechen, das ein Quellen-Port-Feld 638, ein Ziel-Port-Feld 640 und ein Sequenznummern-Feld 642 einschließt. Der Quellen-Port ist die Port-Nummer, die dem Prozess in dem Ursprungs- (Quellen-) System zugeordnet ist. Der Ziel-Port ist die Port-Nummer, die dem Prozess in dem Ziel-System zugeordnet ist.
Es ist verständlich, dass TCP ein Beispiel eines Protokolls ist. Das Feld 636 könnte einem Teil eines Paket-Kopffeldes von einem Paket eines anderen Protokolltyps entsprechen. Weiterhin könnte das Fehlerberichts-Protokoll ein anderes Protokoll als ICMP sein, und der Umfang des Kopffeldes in dem Feld 636 könnte mehr oder weniger als 64 Bits sein, das heißt dieser Wert kann so eingestellt werden, dass die passende Fluss-Information aus dem Kopffeld der Mitteilung gewonnen werden kann, das in dem verworfenen IP-Paket enthalten war, wie dies weiter unten beschrieben wird.
In 27 ist ein Paketverarbeitungsverfahren („der Prozess") 650 gezeigt, das von der Fluss-Sonde ausgeführt wird. Der Prozess erfasst bei 652 ein neues IP-Paket (Datagramm) und prüft das empfangene Paket bei 654, um festzustellen, ob es gut ist (das heißt gut geformt). Der Prozess 650 überprüft bei 656 das Protokoll-Feld in dem IP-Paket-Kopffeld, um festzustellen, ob das Protokoll das ICMP-Protokoll ist. Wenn das Protokoll ICMP ist, und das Informations-Typ-Feld auf eines der fünf Fehlerberichts-Mitteilungen gesetzt ist, die weiter oben beschrieben wurden, umgeht der Prozess das IP-Paket und die ICMP-Mitteilungs-Kopffelder, und verarbeitet bei 658 die ICMP-Mitteilung oder die Paket-Nutzinformation (26), die einem Teil des IP-Paketes entspricht, das verworfen wurde und auf das sich die Ereignis-Mitteilung bezieht. Der Nutzinformations-Prozess wird nachfolgend anhand der 28 beschrieben. Sobald die Nutzinformations-Verarbeitung abgeschlossen ist, kehrt die Verarbeitung des IP-Paketes 659 zu der Verarbeitung zurück, die ausgeführt worden wäre, wenn bei dem Paket nicht festgestellt worden wäre, dass es eine ICMP-Mitteilung der Fehlerberichts-Art enthält, wie dies weiter oben erläutert wurde, und wie dies nunmehr beschrieben wird.
Unter weiterer Bezugnahme auf 27 wird, wenn das Protokoll nicht ICMP ist und/oder der Informations-Typ kein Fehlerbericht ist, das IP-Paket wie folgt verarbeitet. Die Sonde durchsucht bei 660 das Kopffeld, um die Werte der Felder festzustellen, die dem „Fluss-Schlüssel" entsprechen, den Feldern, die den „Fluss" für die Sonde definieren. Jede Fluss-Sonde kann für eine bestimmte Fluss-Schlüssel-Definition konfiguriert sein. Beispielsweise könnte der Fluss-Schlüssel die Quellen-/Ziel-IP-Adressen, die Quellen-/Ziel-Ports und das Protokoll sein. Die Sonde bestimmt bei 662, ob der Fluss-Schlüssel des verarbeiteten Paket- Kopffeldes mit einem Fluss übereinstimmt, der bereits in der Fluss-Sonde gespeichert ist. Ein örtlicher Speicher in der Fluss-Sonde wird dazu verwendet, Fluss-Darstellungen unter Einschluss von Fluss-Schlüssel-Parametern, Metriken, Zustandsinformationen zu halten. Die Zustandsinformation schließt zusätzlich zu den Protokoll-Steuerungs-bezogenen Zuständen (das heißt TCP „FIN") Fehlerereignisse/Zustandsänderungs-Ursachen und Quellen/Ziele ein, an die die Mitteilung adressiert ist. Diese Fluss-Darstellungen werden in NAR's zu Abrechnungsprozess-Berichtszwecken umgewandelt.
Unter weiterer Bezugnahme auf 27 ist zu erkennen, dass wenn die Fluss-Sonde bei 664 die Fluss-Schlüssel-Information nicht mit einem gespeicherten Fluss in Übereinstimmung bringen kann, die Sonde bei 666 einen neuen Fluss konstruiert (und speichert) und bei 668 den Prozess abschließt. Wenn die Sonde eine Übereinstimmung findet, aktualisiert sie bei 670 die Metrik für den übereinstimmenden gespeicherten Fluss (oder „Haupt"-Fluss). Sie aktualisiert weiterhin bei 672 den Fluss-Zustand des Haupt-Flusses und schließt dann bei 674 den Prozess ab. Es sei bemerkt, dass die Konstruktion eines neuen Flusses bei 676 die Erzeugung eines Start-NAR auslöst, und dass die Aktualisierung des Fluss-Zustandes bei 678 die Erzeugung eines aktualisierten NAR auslöst. Die Erzeugung von NAR's durch die Fluss-Sonde wird weiter unten erläutert.
In 28 ist die Verarbeitung der ICMP-Mitteilungs-Nutzinformation, das heißt des eingebetteten IP-Paketes bei 658 (von 27) gezeigt. Die Verarbeitung der ICMP-Mitteilungs-Nutzinformations-Verarbeitung ist von ihrer Eigenart her rekursiv. Das wesentliche Verfahren ist das gleiche, wie es weiter oben für ein IP-Paket (27) verwendet wurde, jedoch mit einigen Unterschieden.
Wenn die Fluss-Sonde bei 664 feststellt, dass es keinen gespeicherten Fluss gibt, der dem Fluss des verworfenen IP-Paketes oder Datagramms entspricht (das durch die ICMP-Mitteilung in dem Daten-Vorspann-Feld oder der Nutzinformation 634 nach 26 angezeigt ist), so ist die Verarbeitung abgeschlossen. Wenn ein gespeicherter Fluss, der mit dem Fluss-Schlüssel des verworfenen Datagramms überstimmt, gefunden wird, aktualisiert die Sonde bei 672 den Fluss-Zustand, um einen „zurückgewiesenen" Zustand für den gespeicherten Fluss anzuzeigen. Sie aktualisiert weiterhin die Flusszustands-Information, um anzuzeigen, ob es die Quelle oder das Ziel des gespeicherten Flusses war, die bzw. das der ICMP-Mitteilung und der Ereignis-Ursache zugeordnet war. Die Zustandsänderung (auf den zurückgewiesenen Zustand) triggert bei 682 die Erzeugung eines Stopp-NAR, wie dies später beschrieben wird. Sobald die Sonde die Nutzinformations-Verarbeitung 658 abgeschlossen hat, nimmt sie bei 659 die Verarbeitung des ursprünglichen IP-Paketes wieder auf (wie dies in 27 gezeigt ist).
Somit kann die Nutzinformations-Verarbeitung als eine Paketverarbeitungs-Ausnahme betrachtet werden, eine Ausnahme, die aufgerufen wird, wenn festgestellt wird, dass eine ICMP-Fehlerberichts-Mitteilung empfangen wurde. Die ICMP-Mitteilung berichtet irgendein Fehlerereignis und das mit diesem Fehlerereignis verbundene IP-Paket. Der Ausnahmeprozess dient zur Korrelation des Flusses des verworfenen IP-Paketes in der ICMP-Mitteilung mit dem Hauptpassenden gespeicherten) Fluss, so dass die ICMP-Fehler- (Zustands-) Information auf dem Haupt-IP-Fluss abgebildet wird.
Die Fluss-Sonde berichtet über die Netzwerk-Verkehrsaktivität über ein Fluss-Sonden-NAR, der die IP-Fluss-Verkehrsaktivität berichtet. Die Fluss-Sonde kategorisiert den Netzwerk-Verkehr in eine von vier Klassen von Verkehrsfluss: i) verbindungsorientiert (beispielsweise TCP); ii) neuer verbindungsloser Verkehr; iii) Anforderungen/Antwort verbindungslos (beispielsweise Benutzer-Datagramm-Protokoll (UDP), Domänennamen-System (DNS)); und iv) verbindungslos und persistent (beispielsweise Netzwerk-Dateisystem (NFS), Sammelsende-Backbone oder „MBONE"-Sammelverkehr). Auf jede dieser Klassen wendet sie verbindungsorientierte Semantiken für eine gleichförmige Lösung für den Statusbericht an. Das heißt, dass die Fluss-Sonde diese unterschiedlichen Transaktions-Modelle so behandelt, als ob sie die gleichen wären. Es gibt eine gleichförmige Struktur für die Statusberichte, die für jede der vier unterschiedlichen Transaktionen erzeugt werden. Jeder Statusbericht schließt eine Transaktions-Start- und Stopp-Information, Medienzugangskontroll- (MAC-) und IP-Quellen- und Ziel-Adressen, die IP-Optionen, die festgestellt wurden, das verwendete Protokoll der oberen Schicht, das Transaktions-Quellen- und Ziel-Byte und Paketzählungen und für das Protokoll der oberen Schicht spezifische Information ein. Die für das Protokoll spezifische Information und die Kriterien dafür, wann Statusberichte erzeugt werden, sind für jede der vier Transaktionstypen verschieden.
Das verbindungsorientierte Protokoll, das die Fluss-Sonde versteht, ist TCP. Die Fluss-Sonde hat eine vollständige Kenntnis der TCP-Zustandsmaschine und kann daher Statusberichte bei jedem Status-Übergang erzeugen, der in irgendeinem einzelnen TCP gesehen wird. Es sind weiterhin Vorkehrungen zur Erzeugung von Zeitintervall-basierten Statusberichten in den TCP-Verbindungen getroffen, die die Fluss-Sonde verfolgt. Der Statusbericht zeigt an, welche Zustände gesehen wurden, ob irgendwelche Pakete neu ausgesandt wurden, ob die Quelle oder das Ziel geschlossen wurden, und ob der Bericht durch eine Zeitbedingung erzeugt wurde. In der Vorgabe-Betriebsart erzeugt die Fluss-Sonde einen kumulativen Status zu dem Zeitpunkt, zu dem ein TCP schließt, oder einen Zeitablauf aufweist. Diese Strategie bietet die größte Menge an Datenreduktion über Transaktionen.
Irgendein nicht-TCP-Verkehr wird als eine verbindungslose Transaktion kategorisiert. Wenn sie zur Erzeugung des ausführlichsten Grades des Berichtes für verbindungslosen Verkehr konfiguriert ist, kann die Fluss-Sonde die Feststellung einer neuen verbindungslosen Transaktion, das Vorhandensein eines Anforderungs-/Antwort-Paares innerhalb der Transaktion (wie es existiert, wenn die Sonde ein einzelnes Paket von sowohl der Quelle als auch dem Ziel für die Transaktion gesehen hat), die Fortsetzung oder die Transaktions-Persistenz, usw. berichten. Der Transaktions-Persistenz-Status wird mit einer Zeitgeber-Funktion erzeugt. Wenn er innerhalb eines konfigurierten Zeitgeber-Fenstes festgestellt wurde, wird ein Bericht erzeugt.
Der Statusbericht für einen nicht-TCP-Verkehr zeigt an, ob der Bericht ein Anfangsbericht, ein Anforderungs-/Statusbericht oder ein Fortsetzungs- (oder laufender Transaktions-) Bericht ist.
In der Vorgabe-Betriebsart erzeugt die Fluss-Sonde einen Statusbericht, wenn sie eine Anforderungs-/Antwort-"Folge" innerhalb einer Transaktion gesehen hat, und alle 15 Minuten danach, wenn die Transaktion andauert. Dies bietet eine unmittelbare Benachrichtigung über Anforderungs-/Antwort-Verkehr und ein vernünftiges Ausmaß an Daten-Reduktion bei verbindungslosen Transaktionen.
Somit schließt die Fluss-Sonden-Zustandsverfolgung protokollspezifische Zustandsinformationen ein. Sie liefert ausführliche Information über die transportspezifische Fluss-Initialisierung, wie z.B. den Aufbau einer TCP-Verbindung, sowie einen Bericht über die Fortsetzung des Flusses und über Beendigungs-Ereignisse.
Protokoll-unabhängige Paket-Überwachung
Gemäß 29A schließt das Netzwerk 700 eine Überwachung 702 ein, die einen Prozess zur Erkennung von Paketverlust betreibt. Die Überwachung 702 wird speziell unter Verwendung von IP SEC-Authentifizierungs-Koffeldern beschrieben. Die Überwachung 702 verwendet Sequenznummern, die in den IP SEC-Authentifizierungs-Kopffeldern existieren. Die Überwachung 702 kann zur Feststellung verloren gegangener Pakete in irgendeiner Art von Protokoll verwendet werden, das Sequenz- oder Folgenummern in Kopffeldern der Pakete usw. verwendet. Die Überwachung 702 ist eine unabhängige Überwachung, die an irgendeiner Stelle in dem Netzwerk 700 angeordnet werden kann. Die Überwachung 702 ist Protokoll-unabhängig.
Das Netzwerk 700 würde eine Vielzahl derartiger unabhängiger Überwachungen 702 einschließen, die jeweils an entsprechenden einzelnen Punkten in dem Netzwerk 70 angeordnet sind. Typischerweise kann die Überwachung 702 in der Leitung angeordnet werden, wie z.B. in einem Netzwerk-Gerät, wie z.B. einem Switch, Router, Zugangskonzentrator usw. Alternativ kann die Überwachung in einer außerhalb der Leitung befindlichen Anordnung angeordnet werden, in die Netzwerk-Pakete von dem Gerät kopiert und zu der außerhalb der Leitung angeordneten Überwachung gekoppelt werden.
Die Überwachung 702 überprüft jedes Paket eines Netzwerk-Flusses, der durch das Gerät hindurchläuft, das der Überwachung 702 zugeordnet ist. Die Überwachung 702 empfängt serielle IP-Pakete. Die Pakete können das Format haben, das durch die Network Working Group, von S. Kent, Anforderung von Kommentaren: 2402, November 1998 „IP Authentication Header" als Teil der „Internet Official Protocol Standards", The Internet Society (1998) festgelegt wurde. Das IP-Authentifikations-Kopffeld schließt ein „nächstes Kopffeld"-Feld, das die Art der nächsten Nutzinformation nach dem Authentifizierungs-Kopffeld, die „Nutzinformationslänge", ein 8-Bit-Feld, das die Länge des Authentifikations-Kopffeldes spezifiziert, und ein reserviertes 16-Bit-Feld ein. Das IP-Authentifikations-Kopffeld schließt weiterhin einen Sicherheitsparameter-Index, einen willkürlichen 32-Bit-Wert ein, der in Kombination mit einer Ziel-IP-Adresse und einem Sicherheits-Protokoll in eindeutiger Weise die Sicherheits-Zuordnung für ein Datagramm und eine Sequenznummer identifiziert. Die Sequenznummer ist ein nicht Vorzeichen behaftetes 32-Bit-Feld, das einen monoton ansteigenden Zählerwert (Sequenznummer) enthält. Dieses Feld ist immer in derartigen Datagrammen vorhanden und ist für den Zweck der Ermöglichung eines Rückspiel-Schutzdienstes für eine spezifische Sicherheits-Authentifizierung vorgesehen. Gemäß der Norm darf, wenn der Wiederholungsschutz aktiviert ist, die ausgesandte Sequenznummer nicht zyklisch umlaufen. Somit werden der Zähler des Senders und der Zähler des Empfängers dadurch zurückgesetzt, dass eine neue Sicherheits-Authentifikation und somit ein neuer Schlüssel vor der Aussendung des 2³²-sten Paketes erzeugt wird. Das Datagramm schließt weiterhin Authentifizierungs-Daten ein, das heißt ein Feld mit veränderlicher Länge, das den Integritäts-Prüfwert (ICV) für das Datagramm enthält.
In 29B ist ein Paketverlust-Detektorprozess 704 gezeigt, der in der Überwachung 702 abläuft. Der Paketverlust-Detektorprozess 704 überprüft bei 706 Kopffeld-Information in dem Paket, um festzustellen, ob das Paket ein Authentifikations-Kopffeld einschließt. Wenn das Paket kein Authentifikations-Kopffeld einschließt, so ignoriert der Paketverlust-Detektorprozess 704 bei 24 das Paket und beendet sich, um auf das nächste Paket zu warten. Wenn das Paket ein Authentifizierungs-Kopffeld einschließt, prüft der Paketverlust-Detektorprozess 20 bei 708, um festzustellen, ob der Paketverlust-Detektorprozess 20 den Fluss verfolgt hat, der durch die Quellen- und Ziel-IP-Adressen und den SPID-Wert dargestellt ist, der sich in dem Authentifikations-Kopffeld befindet. Der Paketverlust-Detektor führt ein Nachschlagen in einem Pufferspeicher aus, um festzustellen, ob der Fluss in einem Pufferspeicher von derzeit verfolgten Flüssen gespeichert ist. Der Paketverlust-Detektorprozess 20 prüft bei 708 diese Werte, um festzustellen, ob der Paketverlust-Detektorprozess 704 derzeit diesen Sicherheits-Fluss verfolgt.
Wenn der Paketverlust-Detektorprozess 704 diesen Sicherheits-Fluss nicht verfolgt, so stellt der Paketverlust-Detektorprozess 20 bei 710 einen Fluss-Pufferspeicher-Eintrag für diesen Fluss in einem Pufferspeicher her, der in einem (nicht gezeigten) Speicher unterhalten werden kann. Der Paketverlust-Detektorprozess 704 speichert die Quellen- und Ziel-Adresse und den SPID-Wert von dem Authentifikations-Kopffeld. Der Fluss-Pufferspeicher schließt weiterhin alle anderen Authentifikations-Kopffelder von anderen Sicherheitsflüssen ein, die bisher verfolgt wurden. Der Fluss-Pufferspeicher ermöglicht es dem Paketverlust-Detektorprozess 20, viele hundert, tausende usw. von unterschiedlichen Sicherheits-Flüssen zu überwachen. Ein Pufferspeicher-Eintrag wird für jeden unterschiedlichen Fluss hergestellt. Sobald der Pufferspeicher-Eintrag hergestellt wurde, aktualisiert der Paketverlust-Detektorprozess 704 bei 712 den Sequenznummer-Eintrag in dem Pufferspeicher für diesen Sicherheits-Fluss. Das heißt, die anfängliche Sequenznummer in dem Authentifikations-Kopffeld für den aufgefundenen Fluss wird gespeichert. Die Sequenznummer kann an irgendeinem willkürlichen Wert beginnen.
Wenn jedoch der Paketverlust-Detektorprozess 704 bei 708 feststellte, dass er den Fluss verfolgt, so prüft der Paketverlust-Detektorprozess 704 bei 714, ob die Sequenznummer in dem derzeitigen Paket gleich der vorhergehenden für diesen Fluss ermittelten Sequenznummer plus 1 ist. Wenn die Sequenznummer in dem derzeitigen Paket gleich der vorhergehenden Sequenznummer plus 1 ist, so kann der Paketverlust-Detektorprozess 704 die derzeitige Auswertung stoppen, weil der Paketverlust-Detektorprozess 704 keinen Paketverlust auf dieser speziellen Zuordnung feststellte und das System auch keinen Paketverlust aufwies. Der Paketverlust-Detektorprozess 704 aktualisiert bei 712 die gespeicherte Sequenznummer für diesen Fluss in dem Pufferspeicher.
Wenn die Sequenznummer in dem derzeitigen Paket nicht gleich der vorhergehenden für diesen Fluss ermittelten Sequenznummer plus 1 ist, so stellt der Paketverlust-Detektorprozess 704 für die IPSec-Authentifizierungs-Pakete ein möglicherweise fehlendes Paket fest.
Für manche Protokolle, die einen Umlauf zulassen, prüft der Paketverlust-Detektorprozess 704 bei 718, ob die Sequenznummer umgelaufen ist, das heißt von 32 Bits mit ausschließlich 1-Werten auf 32 Bit mit ausschließlich 0-Werten. Die IPSec-Authentifikations-Pakete ermöglichen derzeit keinen Umlauf, so dass der Test 718 für IPSec-Authentifikations-Kopffelder nicht erforderlich sein würde. Wenn für andere Protokolle (oder spätere Versionen des IPSec-Authentifikations-Protokolls) der Paketverlust-Detektorprozess 704 eine Umlaufbedingung feststellt, so hat sich kein Paketverlust ergeben, und das Paket wird verworfen. Der Paketverlust-Detektorprozess 704 aktualisiert bei 712 die gespeicherte Sequenznummer für diesen Fluss in dem Pufferspeicher. Wenn die Sequenznummer irgendeine andere Nummer ist, das heißt wenn sie nicht auf ausschließlich 0-Werte übergegangen ist, so kann ein Paketverlust vorliegen. Wenn ein Paketverlust vorgelegen haben kann, kann der Paketverlust-Detektorprozess 704 feststellen, wieviele Pakete verlorengegangen sind, indem festgestellt wird, wie viele Sequenznummern fehlen.
Wenn Pakete mehr als eine Paket-Überwachung 10 durchlaufen können, so kann der Paketverlust-Detektorprozess 704 eine Anzeige für die Feststellung eines Paketverlustes erzeugen, die nicht anzeigt, dass die Pakete tatsächlich verworfen wurden. Eine Anzeige für ein Paketverlust-Verwerfen in einer Mehrfach-Überwachungs-Ausführungsform zeigt an, dass die verlorengegangenen Pakete den speziellen Paketverlust-Detektorprozess 704 nicht durchlaufen haben. Die angezeigten verloren gegangenen Pakete könnten jedoch auf anderen Segmenten des Netzwerkes sein. Das heißt, dass es möglich ist, dass andere Teile des derzeitigen Flusses sich in anderen Teilen des Netzwerkes befinden. Daher notiert der Paketverlust-Detektorprozess 704, wie viele Pakete tatsächlich erfolgreich übertragen wurden, sowie wie viele verlorengegangen sind und wahlweise ihre Sequenznummern. Diese Werte können mit anderen Werten von anderen Überwachungen 702 verglichen werden, um festzustellen, ob es einen Paketverlust für den Fluss durch das Netzwerk gegeben hat.
Diese Anzeige könnte in Netzwerk-Abrechnungs-Datensätze umgewandelt werden, und so an einen Prozess, beispielsweise den Abrechnungsprozess 14, gekoppelt werden, der Statistiken über diesen bestimmten Fluss berichtet, um eine Zusammenfassung zu schaffen, wie viele Pakete bezogen auf wie viele erfolgreich übersandte Pakete dieses Flusses verlorengegangen sind. In dem Abrechnungsprozess 14 werden die Netzwerk-Abrechnungs-Datensätze korreliert, zusammengefasst, verbessert usw., um Netzwerk-Flüsse zu identifizieren. Diese Information kann zur Bestimmung der Datensätze verwendet werden, die einem bestimmten Netzwerk-Fluss entsprechen, und ob ein bestimmter Netzwerk-Fluss irgendwelche Pakete verloren hat.
Erfassung der Dienstgüte
In 30 ist ein Prozess 730 zur Erfassung der Dienstgüte in einem Netzwerk-System 11 (1) gezeigt. Der Dienstgüte-Erfassungsprozess 730 ermöglicht es einem Administrator, das Netzwerk 11 bei 732 mit einer Richtlinie zu konfigurieren, die einer ersten Dienstgüte entspricht. Der Prozess 730 schließt weiterhin einen Optimierungsprozess ein, der bei 734 die Richtlinie zuordnet oder entwickelt, die verwendete Richtlinie definiert und die Richtlinie dadurch durchsetzt, dass eine durch die Richtlinie diktierte Konfiguration in die verschiedenen Richtlinien-Durchsetzungs-Einrichtungen in dem Netzwerk 11 eingesetzt wird. Der Dienstgüte-Erfassungsprozess 730 ermöglicht es dem Administrator, bei 736 die tatsächlich von dem Netzwerk 11 für einen Kunden auf dem Netzwerk 11 gelieferte Dienstgüte zu beobachten, um festzustellen, ob die vorgesehene Dienstgüte mit der übereinstimmt, die durch die Richtlinie 740 spezifiziert ist.
Der Dienstgüte-Erfassungsprozess 730 verwendet einen Abrechnungsprozess 738 zum Sammeln von Informationen von dem Netzwerk. Ein bevorzugter Abrechnungsprozess ist der Abrechnungsprozess 14, der vorstehend beschrieben wurde. Der Abrechnungsprozess 14 sammelt Daten von dem Netzwerk 11 als Teil des Beobachtungsprozesses 736. Der Abrechnungsprozess sammelt unterschiedliche Arten von Metriken von dem Netzwerk, korreliert diese Metriken mit spezifizierten Netzwerk-Flüssen über die Verwendung von NAR's und setzt gesammelte, korrelierte Information, das heißt NAR's auf die Richtlinie um, die definiert und tatsächlich in dem Netzwerk eingesetzt wurde. Weil der Abrechnungsprozess 14 diese Beobachtungsfunktion ausführt, kann der Abrechnungsprozess bei 738a eine Anzeige liefern, ob die Richtlinie 740 erfüllt ist oder nicht.
Durch Einsetzen des Abrechnungsprozesses 14 zur Beobachtung der Dienstgüte kann der Dienstgüte-Erfassungsprozess 730 die Erfüllung von (nicht gezeigten) Dienstgüte-Vereinbarungen validieren. Wenn der Dienstgüte-Erfassungsprozess 730 feststellt, dass der in einer Dienstgüte-Vereinbarung festgelegte Richtlinien-Wert nicht erfüllt ist, so kann die Richtlinie bei 742 neu abgeschätzt, neu definiert und neu eingesetzt werden. Der Dienstgüte-Erfassungsprozess 730 kann dann erneut die Beobachtung bei 736 ausführen. Über die Beobachtung bei 736 kann der Dienstgüte-Erfassungsprozess 730 bestimmen, ob eine Neuabschätzung und Neudefinition der eingesetzten Richtlinie erfolgreich war. Es könnten mehrere Zyklen dieses Dienstgüte-Optimierungsprozesses erforderlich sein.
Eine wichtige Komponente der Dienstgüte schließt die Feststellung ein, ob es einen Paketverlust gegeben hat. Die anhand der 29A und 29B beschriebene Paket-Detektor-Überwachung kann zur Abschätzung des Paketverlustes verwendet werden. Die Paketerfassungs-Überwachung 702 kann in dem Netzwerk eingesetzt werden und NAR's erzeugen, die zur Feststellung des Paketes verwendet werden können, wie dies weiter oben beschrieben wurde. Diese Information kann in dem Dienstgüte-Erfassungsprozess 730 dazu verwendet werden, abzuschätzen, ob die von der Dienstgüte-Vereinbarung bestimmte Richtlinie dem Kunden bereitgestellt wurde. Zusätzlich gibt es die sogenannte differenzierte Dienste"DiffServe"-Technologie, das eine gut bekannte Dienstgüte-Lösung ist, die für das Internet sowie für Firmen-Netzwerke vorgeschlagen wurde. Im Gegensatz zu einer Ausrichtung pro Fluss bestimmter Arten von Dienstgüte-Lösungen, wie z.B. integrierte Dienste (Int-serv) und Ressourcen-Reservierungs-Aufbauprotokoll (RSVP) klassifizieren DiffServ-fähige Netzwerke Pakete in eine einer kleinen Anzahl von zusammengefassten Flüssen oder „Klassen" auf der Grundlage von Bits, die in dem Diensttyp- (TOS-) Feld des IP-Kopffeldes jedes Paketes gesetzt sind. Die Dienstgüte-Technologie für IP-Netzwerke ist so ausgelegt, dass sie die statistische Wahrscheinlichkeit des Paketverlustes von bestimmten Flüssen verringert. Der Dienstgüte-Erfassungsprozess 730 bildet eine DiffServ-Richtlinie aus, die in einer Sammlung von DiffServ-Konfigurationen zerlegt wird. Die DiffServ-Konfigurationen werden auf eine Sammlung von Routern oder Switches angewandt, auf die der Kunde in dem Netzwerk 10 Zugriff haben würde, und zwar als Teil des Durchsetzungs-/Einsatz-Prozesses 732. Weil der Paketverlust ein statistisches Phänomen ist, beobachtet der Dienstgüte-Erfassungsprozess 730 bei 736 eine große Anzahl von Netzwerk-Flüssen. Der Dienstgüte-Erfassungsprozess 730 kann den Netzwerk-Verkehr aufgrund der Verwendung des Abrechnungs prozesses 14 und der resultierenden NAR's mit der Granularität beobachten, mit der die DiffServ-Richtlinien tatsächlich eingesetzt werden. Die DiffServ-Richtlinien werden im Allgemeinen an der Quellen- und Ziel-IP-Adresse, dem Protokoll und möglicherweise an der Ziel-Port-Ebene eingesetzt.
Durch die Beobachtung der Netzwerk-Flüsse bei 736 mit der gleichen Granularität wie ein DiffServ-Richtlinien-Durchsetzungsmechanismus ergibt sich, wenn der Dienstgüte-Erfassungsprozess 730 einen Paketverlust mit dieser Granularität feststellt, eine direkte Rückführungs-Kopplung, um festzustellen, ob eine Richtlinie tatsächlich durchgesetzt wird oder nicht. Wenn die Richtlinie nicht durchgesetzt ist, so kann ein Administrator die Richtlinie neu abschätzen, die Richtlinie neu definieren und bei 742 neue Durchsetzungs-Strategien erneut einsetzen. Der Dienstgüte-Erfassungsprozess 730 führt dann bei 736 erneut eine Beobachtung aus.
Wie dies erwähnt wurde, gewinnt, weil die Dienstgüte des IP-Netzwerkes eine statistische Erscheinung ist, der Dienstgüte-Erfassungsprozess 730 eine große Anzahl von Proben über eine lange Zeitperiode. Durch diese Optimierung des Dienstgüte-Erfassungsprozesses 730 und den Einsatz von DiffServ bei 734 erhält der Kunde die vorteilhafte Richtlinien-Durchsetzung für diesen Dienst.
Unter Bezugnahme auf 31 ist zu erkennen, dass eine Dienste-Verwaltungsschleife 750 eine Dienste-Bereitstellungs-Anwendung 752, einen Richtlinien-fähigen Netzwerk-Server 754 und einen Abrechnungsprozess 756 einschließt. In einem typischen Beispiel vereinbaren ein Internet-Diensteanbieter (ISP) und ein Kunde eine Dienste-Vereinbarung oder einen Vertrag 751, der eine Dienstgüte für das Netzwerk spezifiziert. Die Vereinbarung 751 hat Anforderungen und Bedingungen, die durch das Richtlinien-fähige Netzwerk 754 durchgesetzt werden. Der Dienstvertrag 751 wird von dem Richtlinien-Server zerlegt, um eine Schablone zu bilden, die den durch die Vereinbarung 751 dargestellten Dienst definiert. Die Schablone wird der Dienste-Bereitstellungs-Anwendung 752 zugeführt, die tatsächlich eine Konfigurations-Datei 752 erzeugt, die an das Netzwerk 10 ausgesandt wird, um das Netzwerk für eine Dienstgüte auf der Grundlage dieser Vereinbarung 751 zu konfigurieren.
Ein Diensteverwaltungs-Rückführungsprozess 750 schließt daher drei Komponenten ein, die Dienste-Bereitstellung 752, den Richtlinien-Server 754 und die Dienste-Abrechnung 756. Die Aufgabe der Dienste-Bereitstellung 752 besteht in dem Senden von Anforderungen 752b an den Richtlinien-Server 754 zum Gewinnen einer passenden aktiven Richtlinie und zum Gewinnen von Regeln und Domänen-Information 754a von dem Richtlinien-Server. Das Bereitstellungssystem kann mit geeigneten Netzwerk-Verwaltungssystemen und (nicht gezeigten) Element-Verwaltungssystemen kommunizieren, um das Netzwerk 10 für einen Ende-zu-Ende-Dienst zu konfigurieren. Wenn die Konfiguration 752a an den verschiedenen (nicht gezeigten) Netzwerk-Geräten an diesem Punkt eingesetzt wird, so wird der Dienst erzeugt. Die Dienstgüte wird von dem Abrechnungssystem 756 überwacht oder überprüft, das durch den vorstehend beschriebenen Abrechnungsprozess 14 gebildet sein kann. Der Abrechnungsprozess 14 überwacht die Dienstgüte durch Erzeugen von geeigneten Netzwerk-Abrechnungs-Datensätzen. Die Netzwerk-Abrechnungs-Datensätze (NAR's) werden als eine Rechnungsstellungs-Anwendung verwendet, um die Rechnungsstellung auf der Grundlage der Dienstgüte abzugleichen, die geliefert wurde, wie dies durch den Abrechnungsprozess 14 bestimmt wurde. Der Abrechnungsprozess 14 kann weiterhin die von dem Richtlinien-Server erzeugten Richtlinien mit den tatsächlichen Dienstgüten vergleichen, die dem Kunden geliefert werden, in dem NAR's überprüft werden, die aufgrund der Nutzung des Netzwerkes durch den Kunden erzeugt werden.
Zusätzlich könnten sich Dienstgüten ändern, und das System berücksichtigt Änderungen, so dass die Dienstverwaltung die Belastung oder Abrechnung in unerschiedlicher Weise für diese Änderungen der Dienstgüte modifizieren kann. Die Dienste-Abrechnung verwendet weiterhin die aktive Richtlinien-Information von dem Richtlinien-Server, um Rechnungsstellungs-Information an ein Rechnungsstellungs-System oder ein Rückbelastungs-System zu liefern, das Einstellungen an den Rechnungsstellungen für den Dienst vornehmen kann. Ein Richtlinien-Server 754 ist auf den Fähigkeiten der Adressenverwaltung, der Domänen-Namenverwaltung usw. aufgebaut. Im Wesentlichen erzeugen in einem Richtlinien-fähigen Netzwerk Richtlinien-Server einen Satz von Regeln oder Richtlinien und wenden diese Regeln auf einen Domänen- oder Problemsatz an. Der Richtlinien-Server kommuniziert die Regeln an den Abrechnungsprozess 14, so dass der Abrechnungsprozess 14 feststellen kann, welche Arten von Datensätzen oder Aufzeichnungen zu erzeugen sind. Alle die Information wird unter Verwendung von Daten-Flüssen beschrieben.
Als Beispiel kann eine Dienstvereinbarung bestimmen, dass einer Firma „X" eine 100%ige Verfügbarkeit eines bestimmten Netzwerk-Gerätes, beispielsweise eines (nicht gezeigten) Routers und dessen entsprechendem Dienst gegeben wird. Um diese Dienstgüte sicherzustellen, sendet der Richtlinien-Server 754 eine Anforderung in einer Schablone an den Bereitstellungs-Dienst 752, um eine Konfigurations-Datei 752a zur Konfiguration des Routers derart zu erzeugen, dass die Firma „X" eine bevorzugte Nutzung des Routers erhält. Somit wird jedesmal dann wenn ein Paket von dem Netzwerk der Firma „X" über den Router läuft, das Paket immer ausgesandt, sofern nicht etwas mit dem Router falsch ist. Dies kann selbst dann eintreten, wenn ein Paket einer Firma „Y", das eine niedrigere Dienstgüte hat, als ein Paket der Firma „X" in dem Router auf die Aussendung wartet. Das Paket von der Firma „Y" wartet, weil die Firma „Y" nicht für die Dienstgüte zahlt, für die die Firma „X" zahlt.
In diesem Fall konfiguriert der Bereitstellungs-Dienst 752 den Richtlinien-Durchsetzungsmechanismus, der in den Router in dem Netzwerk eingebracht wurde. Wie die Richtlinie für die Bereitstellungs-Ausrüstung definiert ist, ist, dass es eine Eins-zu-Eins-Beziehung zwischen der Richtlinie und dem ergibt, was der Abrechnungsprozess 14 in dem Netzwerk überwachen wird. Der Abrechnungsprozess 14 weiß, dass die Firma „X" einen Vertrag hat, der ihr eine 100%ige Verfügbarkeit des Routers zusichert.
Der Abrechnungsprozess nimmt dann jede Informationsquelle, die sie zur Verfügung hat, und konstruiert einen Abrechnungs-Datensatz, der die Dienstgüte wiedergibt, die tatsächlich der Firma „X" geliefert wurde. Die erzeugten Abrechnungs-Datensätze beziehen sich auf zwei Komponenten, das heißt den Router und den Kunden. Der Abrechnungsprozess 14 ist flexibel und kann Abrechnungs-Datensätze für irgendeine Fluss-Abstraktion erzeugen. In dem Diensteverwaltungs-Rückführungsprozess 750 sendet der Richtlinien-Server 754 eine Fluss-basierte Richtlinie an den Bereitstellungs-Dienst 752. Der Bereitstellungs-Dienst 752 verwendet eine Fluss-basierte Richtlinie zur Konfiguration des Netzwerkes. Die gleiche Fluss-basierte Richtlinie wird an den Abrechnungsprozess 14 weitergeleitet, der NAR's mit Metriken erzeugen kann, die dazu verwendet werden können, den gleichen Grad dieser Flüsse auf Übereinstimmung zu bringen. Der Ausgang des Abrechnungsprozesses 14 bestimmt, ob die Dienstgüte, Verfügbarkeit usw., die in dem Vertrag 751 vereinbart wurde, geliefert wurde. Daher liefert der Diensteverwaltungs-Rückführungsprozess 750 die Dienstgüte, die geliefert wurde, mit dem gleichen semantischen Grad wie der tatsächliche Vertrag.
Die Erfassung der Dienstgüte, wie sie von dem Abrechnungsprozess 14 überwacht wird, schließt die Feststellung von Paketverlusten ein, wie dies oben erwähnt wurde. Jeder der von dem Diensteverwaltungs-Rückführungsprozess 750 verwalteten Komponenten erfordert Information. Daher muss der Bereitstellungs-Dienst 752 diese verschiedenen Dienstgüten bereitstellen. Der Richtlinien-Server 754 behält daher bei, was im Wesentlichen eine Durchsetzung der Dienstgüten ist, die von unterschiedlichen Diensttypen angeboten werden, und der Abrechnungs-prozess 750 erfasst, überwacht und prüft, ob diese Klassen der Dienstgüte geliefert werden.
In 32 ist eine Realisierung des Bereitstellungs-Dienstes 752 gezeigt. Der Bereitstellungs-Dienst 752 erstreckt die Konzepte der Geräte-Verwaltung und der Netzwerk-Verwaltung in eine Dienste-Verwaltungsschicht der Funktionalität. Der Bereitstellungs-Dienst 752 schließt einen Bereitstellungs-Kern 782, Bereitstellungs-Module 784 und Element-Verwaltungen 786 ein. Der Bereitstellungs-Dienst 752 ist Benutzer-fokussiert, statt Netzwerk-fokussiert, wie bei der üblichen Netzwerk-Verwaltung. Die Netzwerk-Verwaltung beinhaltet die Kommunikation mit Netzwerk-Systemen und Ausrüstungen. Der Bereitstellungs-Dienst 752 ist mehr in Richtung auf einen Benutzer und die Dienstekonzepte eines Benutzers orientiert. Der Bereitstellungs-Dienst 752 stellt eine weitere Abstraktionsschicht zur Verfügung, die die Beschreibung der Dienste auf einer Benutzer-Ebene zu der Fähigkeit des Netzwerkes in Beziehung setzt, diese Ende-zu-Ende-Dienste zu liefern. Die Architektur 780 des Bereitstellungs-Dienstes 752 ist ein Mehrfach-Gerät 788 am Boden der Architektur und ein Mehrfach-Dienst 790 an der Oberseite der Architektur. Der Bereitstellungs-Dienst 752 wird eingesetzt, um Befehle an die Netzwerk-Systeme zu schreiben, das heißt die Multi-Geräte 788, um die Konfiguration dieser Systeme zu ändern.
Weil viele Endkunden-Dienste nunmehr erfordern, dass ein Netzwerk mit mehrfachen Arten von Netzwerk-Elementen arbeitet, um einen Ende-zu-Ende-Dienst zu liefern, vereinfacht der Bereitstellungs-Dienst 752 die Erzeugung von Information, die für einen Dienste-Anbieter erforderlich ist, um einen Dienstauftrag von einem Kunden in eine Netzwerk-Konfiguration umzusetzen, das heißt alle Befehle, die für alle die unterschiedlichen Elemente in dem Netzwerk erforderlich sind, um einen Ende-zu-Ende-Dienst zu schaffen.
Der Bereitstellungs-Dienst 752 baut auf vorhandenen Systemen auf. Das heißt, dass es in den unteren Schichten vorhandene Element-Verwaltungen gibt, die ein Konfigurations-Verwaltungssystem zu Konfiguration auf der Netzwerk-Schicht haben. Der Bereitstellungs-Dienst 752 fügt eine Schichtung oberhalb der konventionellen Netzwerk-Verwaltungsschicht hinzu. Der Bereitstellungs-Dienst 752 bildet einen von einem Kunden spezifizierte Ende-zu-Ende-Dienst auf die Netzwerk-Elemente ab, die erforderlich sind, um diesen Ende-zu-Ende-Dienst zu erzeugen. Die Umsetzung von Dienstaufträgen eines Kunden in dem Zustand des Netzwerkes kann verschiedene Teile von Arbeitsfluss haben, die erforderlich sind, um diesen Dienstauftrag zu schaffen oder vollständig zu aktivieren.
Zusammenfassend ist festzustellen, dass die vorliegende Erfindung ein System zum Sammeln und Zusammenfassen von Daten von Netzwerk-Einheiten für eine Daten nutzende Anwendung betrifft, wie dies beschrieben wurde. Das System schließt eine Daten-Sammelschicht zum Empfang von Netzwerk-Fluss-Information von den Netzwerk-Einheiten und zur Erzeugung von Datensätzen auf der Grundlage der Information ein. Das System schließt weiterhin eine Fluss-Zusammenfassungsschicht ein, die aus der Daten-Sammelschicht gespeist ist und mit einer Speichereinrichtung gekoppelt ist. Die Fluss-Zusammenfassungsschicht empfängt von der Daten-Sammelschicht erzeugte Datensätze und führt eine Zusammenfassung empfangener Datensätze aus. Das System kann weiterhin eine Ausrüstungs-Schnittstellenschicht einschließen, die mit der Daten-Sammelschicht und einer Verteilungsschicht gekoppelt ist, um ausgewählte Informationen zu gewinnen, die in dem Speichergerät gespeichert sind, und um die ausgewählte Information an eine anfordernde Daten nutzende Anwendung zu verteilen.
Andere Ausführungsformen
Es ist verständlich, dass obwohl die Erfindung in Verbindung mit der ausführlichen Beschreibung beschrieben wurde, die vorstehende Beschreibung die Erfindung erläutern und deren Schutzumfang nicht beschränken soll, der durch den Schutzumfang der beigefügten Ansprüche definiert ist. Andere Gesichtspunkte, Vorteile und Modifikationen liegen innerhalb des Schutzumfanges der nachfolgenden Ansprüche.

Claims

Verfahren zum Sammeln von Daten von Netzwerk-Einheiten für eine Daten nutzende Anwendung, gekennzeichnet durch die folgenden Schritte: Empfangen von Netzwerk-Abrechnungs-Datensätzen (20) von einer Vielzahl von Datensammel-Einrichtungen (18), wobei jede der Datensammel-Einrichtungen (18) mit einer anderen der Netzwerk-Einheiten (12) gekoppelt ist; und Zusammenfassen zugehöriger jeweiliger der empfangenen Netzwerk-Abrechnungs-Datensätze (200) zu einem zusammengefassten Netzwerk-Abrechnungs-Datensatz, wobei der Netzwerk-Abrechnungs-Datensatz (20) ein normalisierter Datensatz ist, der Informationen über die Netzwerk-Nutzungsaktivität eines Benutzers enthält.
Verfahren nach Anspruch 1, bei dem der Schritt des Zusammenfassens weiterhin folgendes umfasst: Zusammenfassen eines Metrik-Teils in dem ersten einen der Netzwerk-Abrechnungs-Datensätze (200) mit dem Metrik-Teil in dem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200).
Verfahren nach Anspruch 1, bei dem der Schritt des Zusammenfassens von betreffenden Netzwerk-Abrechnungs-Datensätzen (200) in einen zusammengefassten Netzwerk-Abrechnungs-Datensatz die Vereinigung zugehöriger einzelner der empfangenen Netzwerk-Abrechnungs-Datensätzen (200) in einen einzigen zusammengefassten Netzwerk-Abrechnungs-Datensatz umfasst.
Verfahren nach Anspruch 3, bei dem der Schritt des Vereinigens zugehöriger einzelner empfangener Netzwerk-Abrechnungs-Datensätze (200) in einem einzigen zusammengefassten Netzwerk-Abrechnungs-Datensatz die Zuordnung eines neues Kopffeldes (203) zu den Netzwerk-Abrechnungs-Datensätzen (200) umfasst.
Verfahren nach Anspruch 1, das weiterhin den Schritt der: Feststellung umfasst, ob ein erster einer der Netzwerk-Abrechnungs-Datensätze (200) mit einem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) korreliert werden kann.
Verfahren nach Anspruch 5, das weiterhin den Schritt der: Korrelation des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) mit einem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) umfasst.
Verfahren nach Anspruch 6, bei dem jeder der ersten und zweiten der Netzwerk-Abrechnungs-Datensätze (200) einen Identifikations-Teil (202) und einen Metrik-Teil (204) einschließt.
Verfahren nach Anspruch 7, bei dem der Schritt der Korrelation folgendes umfasst: Feststellung einer Übereinstimmung zwischen dem Identifikations-Teil (202) in dem ersten einen der Netzwerk-Abrechnungs-Datensätze (200) und dem Identifikations-Teil (204) in dem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200).
Verfahren nach Anspruch 8, bei dem der Identifikations-Teil (200) Deskriptoren einschließt, und bei dem der Schritt der Feststellung folgendes umfasst: explizites Vergleichen eines oder mehrerer der Deskriptoren in dem Identifikations-Teil (202) des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) auf Übereinstimmung mit einem oder mehreren der Deskriptoren in dem Identifikations-Teil (202) des zweiten einen der Netzwerk-Abrechnungs-Datensätze (200), und implizites Vergleichen eines oder mehrerer der Deskriptoren in dem Identifikations-Teil (202) des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) auf Übereinstimmung mit einem oder mehreren der Deskriptoren in dem Identifikations-Teil (202) des zweiten einen der Netzwerk-Abrechnungs-Datensätze (200).
Verfahren nach Anspruch 9, bei dem der Schritt der Korrelation weiterhin folgendes umfasst: Markieren der ersten und zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) als Kandidaten für die Zusammenfassung.
Verfahren nach Anspruch 9, bei dem der Schritt des Zusammenfassens folgendes umfasst: Verwenden einer Zusammenfassungs-Richtlinie, um festzustellen, welcher der implizit auf Übereinstimmung verglichenen Deskriptoren zu speichern ist.
Verfahren nach Anspruch 11, bei dem der Schritt des Zusammenfassens weiterhin das Verwerfen von Deskriptoren mit fehlender Übereinstimmung umfasst.
Verfahren nach Anspruch 12, bei dem der Schritt des Zusammenfassens weiterhin folgendes umfasst: Zusammenfassen des Metrik-Teils in dem ersten einen der der Netzwerk-Abrechnungs-Datensätze (200) mit dem Metrik-Teil (204) in dem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200).
Verfahren nach Anspruch 13, das weiterhin den Schritt der: Speicherung des zusammengefassten Netzwerk-Abrechnungs-Datensatzes in einem Zusammenfassungs-Speicher (408) über eine vorgegebene Zeitperiode umfasst, wobei der zusammengefasste Netzwerk-Abrechnungs-Datensatz innerhalb der vorgegebenen Zeitperiode für eine weitere Korrelation und Zusammenfassung mit anderen Netzwerk-Abrechnungs-Datensätzen (200) verfügbar ist.
Verfahren nach Anspruch 7, das weiterhin den Schritt der: Verbesserung des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) umfasst, um die Korrelation zu ermöglichen.
Verfahren nach Anspruch 15, bei dem der Schritt der Verbesserung folgendes umfasst: Hinzufügen von zusätzlicher Information zu dem Identifikations-Teil (202) in dem ersten einen der Netzwerk-Abrechnungs-Datensätze (200).
Verfahren nach Anspruch 15, bei dem der Schritt der Verbesserung weiterhin folgendes umfasst: Sammeln der zusätzlichen Information von einer anderen der Daten-Sammeleinrichtungen (18).
System zum Sammeln von Daten von Netzwerk-Einheiten (12) für eine Daten nutzende Anwendung, gekennzeichnet durch: eine Vielzahl von Daten-Sammeleinrichtungen (18), die Informationen von den Netzwerk-Einheiten (12) empfangen, wobei jede Daten-Sammeleinrichtung (18) in der Vielzahl von Daten-Sammeleinrichtungen einer unterschiedlichen einen der Netzwerk-Einheiten (12) zugeordnet ist und Netzwerk-Abrechnungs-Datensätze (200) auf der Grundlage der Information erzeugt, die von der zugehörigen unterschiedlichen einen der Netzwerk-Einheiten (12) empfangen wird; und einen Fluss-Zusammenfassungs-Prozessor (13), der mit der Vielzahl von Daten-Sammeleinrichtungen (18) verbunden ist, wobei der Fluss-Zusammenfassungs-Prozessor (18) die Netzwerk-Abrechnungs-Datensätze (200), die von der Vielzahl von Daten-Sammeleinrichtungen (18) erzeugt werden, empfängt und zugehörige der empfangen Netzwerk-Abrechnungs-Datensätze (200) zu einem zusammengefassten Netzwerk-Abrechnungs-Datensatz zusammenfasst; wobei der Netzwerk-Abrechnungs-Datensatz (200) ein normalisierter Datensatz ist, der Informationen über die Netzwerk-Nutzungsaktivität eines Benutzers enthält.
System nach Anspruch 18, bei dem der Fluss-Zusammenfassungs-Prozessor (13) feststellt, ob ein erster einer der Netzwerk-Abrechnungs-Datensätze (200) mit einem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) korreliert werden kann.
System nach Anspruch 19, bei dem der Fluss-Zusammenfassungs-Prozessor (13) den ersten einen der Netzwerk-Abrechnungs-Datensätze (200) mit einem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) korreliert.
System nach Anspruch 18, bei dem die Netzwerk-Abrechnungs-Datensätze (200) einen Identifikations-Teil (202) und einen Metrik-Teil (204) einschließt.
System nach Anspruch 18, bei dem der Fluss-Zusammenfassungs-Prozessor (13) feststellt, ob eine Übereinstimmung zwischen dem Identifikations-Teil (202) in einem ersten einen der Netzwerk-Abrechnungs-Datensätze (200) und dem Identifikations-Teil (202) in einem zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) existiert.
System nach Anspruch 22, bei dem der Identifikations-Teil (202) Deskriptoren einschließt und der Fluss-Zusammenfassungs-Prozessor (13) explizit einen oder mehrere der Deskriptoren in dem Identifikations-Teil (202) des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) mit einem oder mehreren der Deskriptoren (2029 in dem Identifikations-Teil des zweiten eine der Netzwerk-Abrechnungs-Datensätze (200) auf Übereinstimmung vergleicht und implizit einen oder mehrere der Deskriptoren in dem Identifikations-Teil (202) des ersten einen der Netzwerk-Abrechnungs-Datensätze (200) mit einem oder mehreren der Deskriptoren in dem Identifikations-Teil (202) des zweiten einen der Netzwerk-Abrechnungs-Datensätze (200) auf Übereinstimmung vergleicht.
System nach Anspruch 18, bei dem der Fluss-Zusammenfassungs-Prozessor (13) zugehörige der empfangenen Netzwerk-Abrechnungs-Datensätze (200) zu einem einzigen zusammengefassten Netzwerk-Abrechnungs-Datensatz zusammenfasst.
System nach Anspruch 24, bei dem der Fluss-Zusammenfassungs-Prozessor (13) ein neues Kopffeld zu dem einzelnen zusammengefassten Netzwerk-Abrechnungs-Datensatz zuordnet.