DE602004004863T2

DE602004004863T2 - Verteilte Architektur zur Echtzeit - Flussmessung auf der Ebene einer Netzwerkdomäne

Info

Publication number: DE602004004863T2
Application number: DE602004004863T
Authority: DE
Inventors: Pierrick K2H 9K4 GUINGO; Vincent OTTAWA MOUILLERON; Arnold K4M 1J8 JANSEN; Gerard K2A 1Z1 DAMM
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2003-12-12
Filing date: 2004-12-09
Publication date: 2007-11-15
Anticipated expiration: 2024-12-10
Also published as: US8095640B2; DE602004004863D1; US20050132044A1; EP1542398A1; EP1542398B1; ATE354899T1

Description

Feld der Erfindung
Diese Erfindung betrifft computerbasierte Fernmeldesysteme und insbesondere Systeme und verfahren für nichtinvasive Flussmessungen in solchen Fernmeldesystemen.
Hintergrund der Erfindung
Aufgrund des kontinuierlichen Wachstums des Internetverkehrs sind Verfahren zum Durchführen von nichtinvasiven Echtzeit-Flussmessungen immer wichtiger für Betreiber, um Netzwerkleistung zu überwachen, Routerverfügbarkeit zu erfassen, Netzwerkverstopfungsprobleme zu beheben und Dienstqualität zu messen, ohne zusätzlichen Verkehr herbeizuführen. Dies gilt insbesondere für Diensteanbieter, die ihren Kunden Dienstgütevereinbarungen (Service Level Agreements, SLA) garantieren müssen.
Gegenwärtig gibt es mehrere Lösungen oder Mechanismen, sowohl aktiv als auch passiv, um das zugrunde liegende Problem zu handhaben. Einige dieser Lösungen sind nachfolgend dargelegt.
In heutigen Netzwerken speichern und sammeln Vermittlungsstellen/Router in ihrer eingebauten Verwaltungsinformationsdatenbank (Management Information Base, MIB) einen Satz von Verkehrsstatistiken, um so einen Überblick über die Verkehrsleistung beschränkt auf einen Knoten, ohne Überblick über das Verkehrsverhalten auf Netzwerkebene, zu bieten. Ein Netzwerk- oder Elementverwalter kann diese Verkehrsstatistiken unter Verwendung der SNMP-Verwaltungsschnittstelle der Router abfragen. Typische Verkehrsstatistiken können sein: die Anzahl von verworfenen Pakten, Fehlerpaketen, Anschlussausnutzung, Pufferausnutzung, etc. Diese Statistiken werden für spätere Analyse gesammelt. Wenn eine Netzwerkverstopfung oder ein Ereignis auftritt, sendet der in den IP-Router eingebettete SNMP-Agent eine Fallennachricht (Trap-Message) an den SNMP-Verwalter, der dann auf seiner grafischen Benutzerschnittstelle einen Alarm anzeigt.
Das Netzwerkverwaltungssystem für IP-Router umfasst üblicherweise den SNMP-Manager und den SNMP-Agenten, die die SNMP-MIB zum Speichern von Steuerinformation und Leistungsstatistiken verwenden. Die MIB ist jedoch in den IP-Router eingebettet und entspricht der Struktur und Implementierung der zugrunde liegenden Hardware. Wenn die Konstruktion beendet ist, ist eine Änderung der MIB, um neu interessierende Verkehrsleistungsparameter unterzubringen, nicht einfach.
Die Router-MIB ist basierend auf der spezifischen Struktur der Implementierung des IP-Routers konstruiert und ist daher nicht dieselbe für Geräte von unterschiedlichen Verkäufern. Zum Beispiel hat das Argent Guardian-Werkzeug von Argent Software Inc. je nach überwachten Einheiten unterschiedliche Versionen für Leistungsüberwachung, proaktive Problemerfassung und Korrektur. Der Argent Guardian für Cisco kann nur für Cisco-Router verwendet werden, weil er die Cisco-Router-MIB verwendet, um die Verkehrsinformation zu suchen und abzufragen.
Aktive Leistungsüberwachungsmechanismen senden spezielle Testpakete an die zugrunde liegenden Netzwerke oder Router und analysieren die Antwort. Gegenwärtig basieren die meisten Werkzeuge zur Überwachung der Dienstqualität in IP-Netzwerken auf dem traditionellen „Ping" (d.h. ICMP und Echoantwortnachrichten), um die Rundlaufverzögerung zwischen zwei Hosts zu messen. Abwandlungen des Ping umfassen „Nikhef Ping" und „fping". Diverse andere Werkzeuge basieren dem herkömmlichen „Traceroute" wie etwa „Nikhef Traceroute" und „Network Probe Daemon".
Das PingER-Projekt bei SLAC (Stanford Linear Accelerator Center) verwendet wiederholte Pings zwischen ESnet- (Energy Sciences Network)-Orten. Das AMP-(Active Measurement Program)-Projekt von NLANR (National Laboratory for Applied Network Research) führt Pings und Traceroutes zwischen NSF-zugelassenen Hochleistungsverbindungsorten aus. Das NIMI (National Internet Measurement Infrastructure)-Projekt misst die Leistung zwischen Orten unter Verwendung von Traceroute oder TCP-Paketübertragung.
Die typische passive Verkehrsanalyse wird in nichtinvasiver Weise mit Hinblick auf die beobachtete Netzwerkumgebung durchgeführt. Sie führt zu keinem zusätzlichem Verkehr und beeinflusst daher nicht die Leistung des Netzwerks, während die Messungen durchgeführt werden. Der herkömmliche Ansatz umfasst üblicherweise:

– Sammeln von TCP/IP-Paketen (zum Beispiel Verkehrs-Sniffer etc.) oder der Paket-Header-Daten,
– Hardware und Software zum Analysieren der gesammelten Datenbanken, und schließlich
– Offline-Verkehrscharakterisierung und -modellierung.

Das National Laboratory for Applied Network Research (NLANR) hat OCXmon-Überwacher verwendet, um das Licht einer Faserverbindung mit Hilfe von optischen Teilern abzuzapfen und Paket-Header-Spuren zu sammeln. Verkehrsdaten wurden in einem abstrakten Format gesammelt durch Extrahieren und Speichern des Paket-Headers in der Datenbank innerhalb einer vorgegebenen Verkehrszusammenführungsperiode. Darauf folgt eine Offline-Verkehrsanalyse. Systemverkäufer haben sämtlich proprietäre Lösungen zum Sammeln von Statistiken eher auf der Flussebene. Cisco bietet in seinen großen Routern eine NetFlow-Fähigkeit. NetFlow ist in der Lage, Verkehrsflüsse basierend auf IP-Quell-/-Zieladressen, Protokoll-ID-Feld, Dienstart-(Type of Service, TOS)-Feld und Routeranschluss zu identifizieren. Statistiken können für einen Verkehrsfluss gesammelt und, wenn der Fluss abläuft, an einen Sammler exportiert werden. Flussstatistiken können die Fluss-Start-/Stoppzeiten, die Anzahl von Bytes/Paketen und alle IP-Header-Felder umfassen.
Ein IETF-Vorschlag (RTFM, RFC2722) zielt auch auf die Bereitstellung von Flussüberwachungsfähigkeit ab, auch wenn er noch nicht in einem Industrieprodukt verwirklicht ist. Chipanbieter schlagen häufig eingebaute Statistiklösungen vor (insbesondere TCAM-Anbieter, mit zum Beispiel einer Anzahl von Eintragstreffern). Lucent Bell Labs hat diverse Forschungsprojekte zur Verkehrsanalyse, die sich im wesentlichen auf das Sammeln von TCP/UDP/IP-Paket-Header-Daten, Offline-Verkehrsanalyse, Modellierung und Visualisierung konzentrieren.
Dank der herkömmlichen passiven Analysemechanismen haben viele Verkehrsuntersuchungen versucht, das zufällige Verhalten oder die Zusammensetzung von Internetverkehr zu verstehen. Sie alle konzentrieren sich jedoch auf die Offline-Analyse von historischen Daten. Es gibt keine prominenten Forschungsprojekte, die eine Verkehrsanalyse und Steuerung basierend auf Echtzeitverkehrsmessung oder überblickende Verkehrsprofilierung versuchen. Zum Beispiel spiegeln die Projekte von Lucent den herkömmlichen Ansatz wider, große Mengen von Verkehrsmessungsdaten zu sammeln und offline statistisch zu analysieren. Cisco NetFlow misst im wesentlichen Volumen und Dauer jedes Verkehrsflusses zum Zwecke der Buchführung und Offline-Verkehrsanalyse. NetFlow ist jedoch nicht vorgesehen zur Verwendung bei Echtzeit-Netzwerküberwachung und Abfrage. Das OCXmon-Werkzeug von NLANR ist nur für IP-over-ATM-Verkehr und dient nicht zu Verkehrsüberwachung und Steuerungszwecken. Außerdem erfasst jeder OCXmon-Monitor nur die erste ATM-Zelle aus jedem IP-Paket und liefert so eine unvollständige IP-Spur.
Jedoch sind alle diese obigen Lösungen knotenzentriert, und keine verwendet wirklich eine Netzwerkperspektive, um das Problem anzugehen, auch wenn die interessierten Parteien durch das gezeigte Interesse und die für Flusszusammenführungsmerkmale aufgewandten Bemühungen indirekt einen Bedarf eingestehen.
Die vorliegende Erfindung betrifft zwei Aspekte, namentlich Zusammenführung und Korrelation von Paketfilterungsinformation. Die Zusammenführungsaufgabe wird als erste beschrieben, die Korrelationsaufgabe wird später beschrieben. Die Erfindung ermöglicht die Aufteilung dieser Aufgaben auf alle Kantenrouter des Netzwerks und vermeidet so Offline-Analyse durch den Dienstverwalter zum Kompilieren von deren Ergebnissen, wodurch die Ausführung dieser Aufgaben optimiert wird. Die Verzögerungsberechnung wird hier als ein Beispiel einer möglichen Korrelation dargestellt. Fachleuten ist offensichtlich, dass der Korrelationsaspekt auf andere Anwendungen angewandt werden kann. Außerdem ist die Erfindung nicht auf IP-Netzwerke beschränkt, sondern könnte auf ein beliebiges Fernmeldenetzwerk angewandt werden.
Die Grundidee dieser Erfindung ist, die Vorteile von zwei Technologien, Echtzeit-Flussverwaltung (Realtime Flow Management, RTFM) und virtuelles Routernetzwerk, zu kombinieren, um ein Flussüberwachungskonzept auf Netzwerkebene zu schaffen, das eine Charakterisierung von Durchgangsverkehr in passiver Weise bietet.
Gegenwärtige IP-Router und Vermittlungsstellen sammeln begrenzte Verkehrsstatistiken zur Netzwerkleistung über Zeitintervalle. In Erkenntnis des Bedarfs nach zeitnäheren und höherentwickelten Verkehrsmessungen hat die IETF-RTFM-(RFC2722)-Arbeitsgruppe eine allgemeine Grundstruktur zum Messen von Eigenschaften von Verkehrsflüssen in Echtzeit entwickelt. Nach Definieren eines Verkehrsflusses als einen durch eine Startzeit und eine Endzeit begrenzten Verkehrsabschnitts identifiziert IETF RFC2722 Flüsse im Hinblick auf ihre Attributwerte wie etwa Quell-/Zieladressen, kumulative Zählung von Bytes und Paketen, Dienstart, Paketgröße, Flusszustandsinformation, Dienstqualitätsparameter. Die allgemeine Grundstruktur zur Echtzeit-Flussüberwachung ist in 1 gezeigt.
Die RTFM-Architektur umfasst zwei Hauptfunktionskomponenten: den Verkehrsmesser und den Messerableser. Der Verkehrsmesser folgt einem „Regelsatz" (Paketfilter) um den zu überwachenden Fluss von Paketen zu identifizieren. Eine Paketanpassungsmaschine führt die Paketklassifizierung durch, um den Fluss, zu dem ein Paket gehört, nach den definierten Regeln zu identifizieren. Der Verkehrsmesser misst spezifische Attribute der identifizierten Verkehrsflüsse und zeichnet die Messungen in einer Flusstabelle auf. Der Messerableser fragt die Inhalte der Flusstabelle zur Datenanalyse ab. Die folgenden sind die Vorteile der Verwendung der RTFM-Architektur:

– Alle Daten auf dem Netzwerk sind aufzeichenbar – alle über ein Netzwerk übertragenen Daten können verfolgt, aufgezeichnet und zusammengeführt werden, ohne den Datenfluss zu beeinflussen (unter der Annahme, dass notwendige Implementierungsschritte getroffen worden sind, um Knotenleistungsbeschränkungen Rechnung zu tragen, die eventuell auf beschränkte Ausführungstaktzyklen bezogen sind).
– Unabhängigkeit von physikalischen und Datenschichttechnologien (d.h. analoge Telefonleitung, Faseroptik), die verwendet werden, um die Daten zwischen Quelle und Ziel zu übertragen – diese Details werden bei der Messung von Netzwerkflüssen nicht benötigt. Flussüberwachung ergibt einen logischen Überblick über das Netzwerk, der für die Dienstqualitätsverwaltung besser geeignet ist als der physikalische Überblick.
– Gute Leistung auch bei Fehlerbedingungen – Flussmesser sind wesentlich weniger verwundbar als andere Teile der Netzwerkinfrastruktur, da sie die Datenpakete passiv abfangen und so eine exakte Bandbreitenverbrauchsstatistik führen, wo andere Teile des Netzwerks versagen. Flussmessung kann verwendet werden, selbst wenn die gegebenen Netzwerkelemente zur Flussüberwachung nicht in der Lage sind.
– Flussmessungen haben eine bedeutungsvolle Granularität – flexible, übersichtliche und skalierbare Zusammenführungsstrategien können leicht bereitgestellt werden.

Der in der Erfindung betrachtete Ansatz ist, das Kernnetzwerk wie einen einzigen Router arbeiten und erscheinen zu lassen. Dieses Konzept ist diskutiert in einer Veröffentlichung von Hakata et al. mit dem Titel „IP Corel Transport Network", Fujitsu Scientific Technical Journal, 37 Seiten 12 bis 21 (Juni 2001). Die meiste Intelligenz ist auf den Kantenknoten verlagert, und der Kern besteht aus einem einfachen Datentransportmechanismus von sehr hoher Kapazität. Eintreffende IP-Pakete werden am Eingangsknoten verarbeitet und auf zugewiesene Pfade zwischen Eingangs- und Ausgangsknoten geschickt.
Der interne Verkehr von IP-Paketen in dem virtuellen Routernetz erfolgt basierend auf einer Vermittlungstechnologie (Schicht-2-Label-Switching: MPLS), die weniger zeitaufwändig als ein herkömmlicher Routingalgorithmus ist. Diese Architektur entlastet die IP-Daten von der Sprung-für-Sprung-Verarbeitung, die bei gegenwärtigen Routernetzwerken erforderlich ist, die IP-Schicht-Verarbeitung in jedem Kernrouter/Knoten durchführen. Im Grunde brauchen Knoten mit Ausnahme von Kantenknoten keine IP-Schicht-Verarbeitung durchzuführen und müssen lediglich Schicht-2-Label-Switching (MPLS) handhaben.
Der Best-Effort-Pfad und Dienstklassenpfade werden am Kantenknoten vorbereitet, wo jedem IP-Paket der geeignete Pfad pas send zugewiesen wird. Der Dienstklassenpfad wird bereitgestellt durch Ausnutzung der DiffServ-Fähigkeit von MPLS. Dies bedeutet, dass unterschiedliche Dienstklassenpfade realisiert werden können, ohne dass am Kernknoten zu viel Paketverarbeitungsleistung benötigt wird.
Die Schnittstellen (Kantenknoten) des virtuellen Routernetzwerks suchen automatisch nach den optimalen Routen, setzen explizite Pfade und gleichen Lasten aus, indem sie die IP-Flüsse auf mehrere Pfade aufteilen. Auf diese Weise gewährleistet der virtuelle Router eine hohe Ausnutzung der Kernnetzwerkressourcen und verbessert die Dienstqualität durch Vermeidung von Verstopfung.
Eine praktische Implementierung der Zusammenführungs- und Korrelationsaspekte der Erfindung ermöglicht die Durchführung von Leistungsmessungen auf einer flussbezogenen Basis. Wenn Anbieter einen Dienst anbieten, sind sie an ihre Kunden durch Verträge gebunden, die die Qualität der bezahlten Dienste garantieren. Eines der Merkmale des zum Qualifizieren der Vereinbarung verwendeten Verkehrs ist die Verzögerung, das heißt die Ende-zu-Ende-Übertragungszeit von Paketen. Eine der üblichen Klauseln einer Dienstgütevereinbarung ist, dass ein Kunde sich verpflichtet, einen bestimmten Preis für einen Verbindungsdienst zu zahlen, aber nur dann, wenn die Verkehrsverzögerung unter einer bestimmten Schwelle liegt. Wenn die Verzögerung länger wird, hat der Anbieter den Vertrag nicht eingehalten, was zu finanziellen Einbußen führt. Die Gewinnung von zuverlässiger Leistungsinformation über für Kunden bedeutsamen Verkehr ist für alle Parteien von höchster Bedeutung, um den kommerziellen Wert des geleisteten Dienstes zu rechtfertigen.
Die Wichtigkeit der Bereitstellung von kundenbezogener Verkehrsinformation hat zur Entwicklung von flussbezogenen Überwachungstechnologien geführt, wobei die verbreitetste Implementierung das bereits erwähnte NetFlow von Cisco ist.
Keine der existierenden Flussüberwachungslösungen gibt jedoch eine Lösung, um eine flussbezogene Verkehrsleistungsmessung durchzuführen.
Die besten verfügbaren Werkzeuge zum Berechnen der Leistung verwenden auf Ping basierende aktive Messtechniken, bei denen ICMP-Pakete von einem Punkt zu einem anderen gesendet werden. Diese Pakete liefern Sequenznummerierungs- und Zeitinformation, auf deren Grundlage Paketverlust und Verzögerung berechnet werden. In Weiterentwicklungen wurde die Durchführung des Ping mit spezifischer Dienstqualität (passend zu den Dienstbedingungen (CoS) des Kundenverkehrs) erreicht.
Daten über Dienstnutzung durch Kunden können durch eine Flussüberwachungslösung bereitgestellt werden, und die Dienstleistungsfähigkeit kann mit Ping-ähnlichen Werkzeugen berechnet werden. Es gibt nichts, um die aus einem Ping erhaltene Information mit einem spezifischen Kundenfluss zu korrelieren. Ein Ping liefert einen Status auf einer Verbindung zwischen zwei Endpunkten zu einem spezifischen Zeitpunkt, er liefert aber nicht die von einem spezifischen Kundenfluss tatsächlich erfahrene Leistung.
Außerdem ist ein Ping ein aktives Messverfahren. Es funktioniert durch Einführen von neuem Verkehr in den existierenden Verkehr. Es beeinträchtigt so die Gesamtverkehrsleistung und charakterisiert dennoch nicht den tatsächlichen Verkehr.
Andere intrusive Lösungen sind in Betracht gezogen worden. Zum Beispiel durch Verkapseln des Kundenverkehrs in ein spezielles Paketformat mit spezieller Verarbeitung auf der Ausgangsseite oder durch Etikettieren eines Pakets. Doch auch diese Lösungen sind noch nicht befriedigend, da Kundenpakete „angerührt" werden.
Dokument US 2001/021176 offenbart einen Paketvermittler, der einen über ein IP-Netz beförderten Kommunikationsfluss identifiziert, den Kommunikationsfluss beobachtet und Statistikdaten davon aufnimmt, wie etwa die Anzahl von Paketen, die den Vermittler durchlaufen haben, die Anzahl von verworfenen Paketen, die Zeit des Eintreffens der Pakete am Vermittler und die Zeit des Absendens der Pakete vom Vermittler. Der Paketvermittler nimmt Statistikdaten über den Kommunikationsfluss fortlaufend auf, während der Kommunikationsfluss weitergeht. Wenn der Paketvermittler eine Relaisfunktion ausführt, sendet er die lokal erhaltenen Statistikdaten an den stromabwärts benachbart platzierten Paketvermittler. Wenn ein Paketvermittler ein an einer der Endkanten des Netzwerks platzierter Knoten ist, sammelt er die von anderen Vermittlern im Netzwerk erhaltenen und gelieferten Statistikdaten und sendet die gesammelten Statistikdaten an das Netzwerkverwaltungssystem.
Dokument XP 001030373, Tanja Szeby, Florian Schreiner: „QoS Monitoring and Measuring Benchmarking" NGN Initiative, 2002-10-08, Seiten 1 bis 47 bietet eine Übersicht über die existierenden Messtechniken und stellt für jede von ihnen die signifikantesten Implementierungen und Forschungsprojekte dar. Zur Vervollständigung der Übersicht ist Information über Verkehrsgeneratoren, Zeitsynchronisierung, Abtastung und Standardisierungsbemühungen sowie ein Abschnitt betreffend ein Forschungsprojekt, das auf die Kombination von Mess- mit Simulationstechniken abzielt, eingefügt.
Kurzbeschreibung der Erfindung
Die vorliegende Lösung ist ein passives, nicht intrusives Messverfahren und verwendet den Flussbegriff, um Leistungsmessergebnisse für spezifischen Benutzerverkehr zu erhalten.
Gemäß einem ersten Aspekt der vorliegenden Erfindung ist ein Verfahren zum Überwachen von Verkehrsflüssen in einer Domäne eines Fernmeldenetzwerks vorgesehen, wobei die Domäne logisch eingerichtet ist als ein virtuelles Routernetzwerk mit virtuellen Schnittstellen an Kantenknoten der Domäne, mit den Schritten:

a) Festlegen, an einer virtuellen Schnittstelle und in Abhängigkeit von einem Regelsatz, ob ein Paket zu einem zu überwachenden Fluss gehört;
b) Verzeichnen, in Reaktion darauf, dass das Paket zu einem zu überwachenden Fluss gehört, des Pakets in einer diesen Fluss entsprechenden Flussaufzeichnung; und
c) Zusammenführen (Aggregieren) der Flussaufzeichnungen zur Übertragung an einen Sammler, dadurch gekennzeichnet, dass es ferner einen Anfangsschritt des Auswählens einer der virtuellen Schnittstellen als eine virtuelle Master-Schnittstelle umfasst. Als Ergebnis der zusammengeführten Flussaufzeichnungen ist ein Dienstverwalter in der Lage, Aufzeichnungen von dem Sammler abzuleiten und eine synthetisierte Übersicht über das Netzwerk im Hinblick darauf, wie gut der Dienst arbeitet, ohne die Notwendigkeit von Offline-Analyse zu schaffen.

Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist ein System zum Überwachen von Verkehrsflüssen in einer Domäne eines Fernmeldenetzwerks vorgesehen, bei dem die Domäne logisch als ein virtuelles Routernetzwerk mit virtuellen Schnittstellen an Kantenknoten der Domäne eingerichtet ist, wobei das System umfasst:

– Mittel an einer virtuellen Schnittstelle zum Festlegen, in Abhängigkeit von einem Regelsatz, ob ein Paket zu einem zu überwachenden Fluss gehört;
– Mittel zum Verzeichnen, in Reaktion darauf, dass das Paket zu einem zu überwachenden Fluss gehört, des Pakets in einer zu diesem Fluss entsprechenden Flussaufzeichnung; und
– Mittel zum Zusammenführen der Flussaufzeichnungen zur Übertragung an einen Sammler, wobei das System mehrere virtuelle Schnittstellen hat und eine dieser virtuellen Schnittstellen als eine virtuelle Master-Schnittstelle ausgewählt ist.

Kurze Beschreibung der Zeichnungen
Die Erfindung wird nun genauer mit Bezug auf die beigefügten Zeichnungen beschrieben. Es zeigen:
1 ein grundlegendes Echtzeit-Flussüberwachungssystem;
2 das Konzept eines virtuellen Routernetzwerk-Paradigmas gemäß der Erfindung;
3 ein Anfangsmesspunkt-Entdeckungskonzept;
4 die Hinzufügung eines Kantenknotens in dem Messpunkt-Entdeckungskonzept von 3;
5a und 5b die Auswahl einer virtuellen Schnittstelle als Master;
6 den Pfadfluss der Konfigurierung der Messpunkte;
7 ein Beispiel des Pfadflusses der Zusammenführung von Daten;
8 ein Beispiel des optimierten Flusszusammenführungskonzepts;
9 die Sammlung von Flussdaten;
10, dass eine Änderung des Masters keinen Einfluss auf die Flusssammlung hat;
11 eine abstrakte Darstellung einer speziellen Implementierung der vorliegenden Erfindung;
12 ein Beispiel der Information enthaltenden Flusstabelle im Router 1 von 11 für die Verzögerungsberechnung;
13 ein Beispiel einer Information enthaltenden Flusstabelle im Router 3 von 11 für die Verzögerungsberechnung;
14 die Zusammenführung der Flusstabellen von 12 und 13 zur Verzögerungsberechnung; und
15 ein Beispiel der Last im Laufe der Zeit für die Router zur Verzögerungsberechnung.
Detaillierte Beschreibung der Erfindung
Das virtuelle Router-Paradigma der vorliegenden Erfindung wie in 2 gezeigt ermöglicht eine Maskierung des internen Verhaltens einer Netzwerkdomäne. Ein Netzwerk, ein Unternetzwerk, ein autonomes System (12), eine beliebige Art von Clustern von Knoten 14 kann aufgefasst werden als eine selbstwartende (self-maintained) Blackbox, in der notwendige Netzwerkverwaltungsaufgaben automatisch durchgeführt werden. Im Hinblick auf den Mehrwert des Netzwerks sind nur dessen Wechselwirkungen mit ihrer Umgebung von Belang. Daher rührt die Bedeutung der SLA-Prüfung oder inter-domain-(zum Beispiel von AS zu AS) Statistiksammlung. Durch Anwenden des Konzepts der Echtzeitflussmessung auf eine Abstraktion wie etwa ein virtuelles Routernetzwerk 16 kann die Dienstverwaltungsebene Netzwerkbetreibern direkt bedeutsame Statistiken über ihre Dienste im Bezug auf tatsächliche auf Verwaltungsebene zusammenzuführende Aufzeichnungen von diversen Knoten liefern. Die Erfindung bietet eine synthetisierte Übersicht über das Netzwerk, die Kundenfragen, wie gut ein Dienst arbeitet, eher als wie das Netzwerk funktioniert, beantwortet.
Die Lösung einer solchen Aufgabe impliziert die Notwendigkeit, mit dem virtuellen Routernetzwerk (VRN) zu kommunizieren, um dessen Flussüberwachungsverhalten zu spezifizieren, das durch Überwachungsregeln (oder Verwaltungsregeln) definiert ist. Das VRN muss dann eine Überwachung nach den spezifizierten Regeln an seinen Schnittstellen durchführen und Flussaufzeichnungen senden. Dies passt perfekt zur RTFM-Architektur, bei der das VRN ein Messerableser wäre und die virtuellen VRN-Schnittstellen in die RTFM-Messer implementieren würden; es passt aber auch zu einer beliebigen anderen Flussüberwachungsarchitektur, da diese sämtlich die Konzepte des Messpunktes, der Zusammenführung und des Exports verwenden.
Der RTFM-Verwalter (Teil des Dienstverwalters) (nicht dargestellt) sendet seinen Regelsatz an das VRN durch Zielen auf eine von dessen virtuellen Schnittstellen (virtual interface, VI) 18. Bei Empfang des Regelsatzes durch die virtuelle Schnittstelle wird ein Auswahlprozess wie in 3 gezeigt ausgelöst, um die zum Unterstützen der Funktion der VRN-Leistungsüberwachungsschnittstelle (auch als „Master" bezeichnet) bestgeeignete virtuelle Schnittstelle gemeinsam mit dem Dienstverwalter zu definieren. Dieser Auswahlprozess erfolgt anhand von Kriterien wie etwa CPU-Auslastung, zu handhabenden Verkehr, Speicherkapazität. Kandidaten sind alle virtuellen Schnittstellen. Sie sind einander durch ein Protokoll wie etwa BGP (Border Gateway Protocol) bekannt (4). Die Nutzung einer solchen Technologie ermöglicht eine völlige Unabhängigkeit von Topologieänderungen. Virtuelle Schnittstellen können hinzugefügt oder entfernt werden, ohne dass eine spezielle Maßnahme auf Ebene der VRN-Flussüberwachung getroffen werden muss. Um den Master-Auswahlprozess wie in 5a gezeigt zu implementieren, wird eine Liste von virtuellen Kandidatenschnittstellen aufgestellt und von einer virtuellen Schnittstelle zu einer anderen weitergereicht. Bei jedem Sprung prüft die virtuelle Schnittstelle, ob sie bessere Fähigkeiten als die bisherige beste virtuelle Kandidatenschnittstelle hat. Wenn ja, kennzeichnet sie sich selbst als bester Kandidat zur Unterstützung der Master-Funktionalität. Dann gibt die virtuelle Schnittstelle die Liste einfach zur nächsten virtuellen Kandidatenschnittstelle weiter, und so fort. Die Liste wird verbreitet, bis die beste virtuelle Kandidatenschnittstelle sie erneut mit sich selbst als bestem Kandidat empfängt. Dann weiß sie, dass sie unter allen der beste Kandidat ist, um als Master zu agieren. Man beachte, dass dieser Auswahlprozess basierend auf Fähigkeitsänderungen, nach Zeitablauf oder nach Topologieänderungen (5b) erneuert werden kann, wenn eine besser geeignete virtuelle Schnittstelle hinzugefügt worden sein könnte.
Nachdem er gewählt worden ist, hat der Master 20 zunächst die Aufgabe, die Flussüberwachungsregeln an alle virtuellen Schnittstellen zu verbreiten (siehe 6). Dies geschieht einfach durch Bekanntmachen gegenüber jeder virtuellen Schnittstelle gemäß der zuvor zum Wählen des Masters verwendeten Liste. Nachdem es an jeder virtuellen Schnittstelle ausgelöst worden ist, führt das VRN eine Zusammenführung von Flussaufzeichnungen (7) aus, bevor es Aufzeichnungen an die Dienstverwaltung sendet. Eine mögliche Implementierung des Zusammenführungsprozesses folgt dem gleichen kreisförmigen Pfad wie der Auswahlprozess. Der Master sendet seine Flusstabelle an die nächste virtuelle Schnittstelle in der Liste. Bei Empfang aktualisiert die nächste virtuelle Schnittstelle den Aufzeichnungswert von bereits existierenden Flusseinträgen und fügt ihre neuen Einträge hinzu, um widerzuspiegeln, was überwacht wird. Die neue Flusstabelle wird dann an die nächste virtuelle Schnittstelle in der Liste weitergegeben, bis sie zum Master zurückkommt. Zu diesem Zeitpunkt hat der Master einen perfekten zusammengeführten Überblick darüber, was in dem Netzwerk für alle überwachten Flüsse geschehen ist.
Ein Ringausbreitungsschema ermöglicht eine Verbreitung der Zusammenführungsaufgabe an alle Knoten und wird bevorzugt verwendet, da es effizienter als existierende Mechanismen ist, bei denen alle Knoten ihre Flusstabelle zur Zusammenführung an den Master übertragen. Ein besser optimierter Prozess könnte in Betracht gezogen werden, zum Beispiel durch Parallelisieren der Aufgaben, wie in 8 gezeigt.
Der Export der Aufzeichnungen, wie in 9 gezeigt, erfolgt dann nach einem Push- oder Pull-Modell, was bedeutet, dass der Master seine Information an einen Flusssammler 30 (eventuell Teil des Dienstverwalters) sendet. Ein Push-Modell ermöglicht die Maskierung der Änderung des VRN-Masters gegenüber dem Sammler (siehe 10).
Die Idee, RTFM auf virtuelle Netzwerke anzuwenden, ist nach Kenntnis der Anmelderin nie zuvor zu sehen gewesen. Im Vergleich zu einer reinen RTFM-Lösung ist der Vorteil, dass der Dienstüberwachungsverwalter nicht jeden in dem VRN vorhandenen Knoten kennen muss, nicht alle von ihnen konfigurieren muss und, am wichtigsten, später nicht Flussaufzeichnungen von ihnen allen holen muss, um sie zusammenzuführen. Er geht nur mit einer Einheit (dem VRN) um, die ihn mit zusammengeführten Aufzeichnungen versorgt.
Zusätzlich sieht der Dienstverwalter nur, womit er zu tun hat. Echtzeitprobleme, die intensiven Export erfordern, bleiben intern in Bezug auf die virtuellen Schnittstellen und werden dem Dienstverwalter nicht bekannt. All dies spart Exportbandbreite, eines der Hauptprobleme jeder gegenwärtigen Flussüberwachungslösung.
Die Lösung ist topologieunabhängig, da sie auf dem BGP-Protokoll (oder einem Äquivalent) basiert, um das Wissen der virtuellen Schnittstellen aufrecht zu erhalten. Konfiguration und Aktualisierungen sind transparent.
Das Verhalten jeder virtuellen Schnittstelle ist einheitlich. Jede virtuelle Schnittstelle unterstützt dieselbe Funktionalität und kann automatisch die Rolle des Masters zugewiesen bekommen, um Regeln zu verbreiten, Zusammenführung auszuführen und Messdaten zu exportieren. Dies vereinfacht die Installation der Kantenknoten, da die Notwendigkeit vermieden wird, einen jeweils speziellen für jede Aufgabe zu installieren.
Die Erfindung vereinfacht die Installation von groß skalierten Flussüberwachungssystemen durch Einbetten derselben in die Netzwerkelemente und Automatisieren von deren Konfigurierung bei gleichzeitiger automatischer Einschränkung der Übertragung von Messdaten an die Dienstverwalteranwendungen auf die benötigte Information, wodurch die Notwendigkeit von weiterer Verarbeitung vermieden wird.
Gemäß einer weiteren Ausgestaltung der Erfindung führt der virtuelle Netzwerkrouter eine Leistungsberechnung in passiver, nicht intrusiver Weise aus (das heißt das Verfahren fügt keinen Messverkehr zu dem Datenpfad hinzu und verändert auch nicht den Inhalt des gemessenen Benutzerverkehrs).
Durch Verwendung der zuvor beschriebenen Flussüberwachungstechnologie werden nur die relevanten Leistungsparameter, die zu spezifischen Flüssen des Benutzerverkehrs gehören, berechnet und korreliert. Dieses Verfahren führt zu einer geringeren Bandbreitennutzung zum Export von Messdaten als bei existierenden Flussüberwachungslösungen.
Die Veränderung eines beliebigen Parameters eines Flusses zwischen zwei Messpunkten kann effizient verarbeitet und an den Kanten eines Netzwerks korreliert werden. Außerdem ist der Prozess des Korrelierens von Messdaten vollständig verteilt, wodurch zentralisierte Verwaltungssysteme von Korrelationsaufgaben entlastet werden.
Die Flussparameter, bei denen es wichtig ist, die Schwankung zwischen Eingangs- und Ausgangsmesspunkten zu beobachten, sind: Eintreffzeit (zum Berechnen von Verzögerung, Verzögerungsschwankung), Anzahl von Bytes pro Sekunde (Byteratenschwankung, Salvenartigkeit) und die Anzahl von Paketen (Paketverlust). Diese Parameter charakterisieren die durch das Netzwerk induzierte Ende-zu-Ende-Leistung (von Eingang zu Ausgang).
11 liefert eine Grundstruktur zur Veranschaulichung der Erfindung. Es sei angenommen, dass Kunde A B erreichen möchte. Hierfür muss Verkehr über den Backbone 40, der dem Träger C gehört, laufen, während Internet-Konnektivitätsdienst von ISP 1 und ISP 3 bereitgestellt wird. ISP 1, 2 und 3 haben mit dem Träger eine Vereinbarung unterschrieben, die die für ihren Verkehr maximal zulässige Verzögerung definiert (dies ist Teil des SLA). Diese Verzögerung kann pro Flusstyp spezifiziert sein. Zum Beispiel kann für E-Mail eine höhere Verzögerung als für VoIP akzeptiert werden.
Der erste festzuhaltende Punkt ist, dass es ISP 1, 2 und 3 egal ist, wie der Verkehr in dem Netzwerk des Trägers fließt. Ihr Interesse ist, eine zusammengefasste Übersicht der vom Träger C bereitgestellten Ende-zu-Ende-Verkehrsleistung, von Kante zu Kante, zu haben. Gleichzeitig ist ein Ziel, so wenig Daten wie möglich an die Dienstverwaltung zu senden, um die Auslastung der Bandbreite und von Ressourcen an den Knoten zu verringern. Diese zwei Aspekte rechtfertigen die Wiederverwendung der zuvor definierten Grundstruktur und sind in 1 materialisiert durch den Ring 42, in dem alle diese Grundstruktur unterstützenden Kantenknoten zusammengefasst sind.
Einer der Kantenknoten wird als Master gewählt. Nachdem er gewählt ist, gibt der Master den anderen Kantenknoten an, welche Flüsse zu überwachen sind und an welchen benachbarten Kantenknoten sie ihre Flusstabelle zur Korrelation senden müssen. Wenn die Zeit für die Zusammenführung und Korrelation der Messdaten kommt, sendet der Master seine Flusstabelle an den nächsten in der Zusammenführungsliste spezifizierten Kantenrouter (verkörpert durch den kreisförmigen Pfeil in 11). Bei Empfang aktualisiert/korreliert der nächste Kantenrouter Parameter von bereits existierenden Flusseinträgen und fügt seine neuen Einträge hinzu, um widerzuspiegeln, was überwacht wird. Die neue Flusstabelle wird dann an den nächsten Kantenrouter in der Liste weitergegeben, bis sie zum Master zurückkommt. Dann hat der Master eine vollständige, zusammengeführte und korrelierte Übersicht davon, was in dem Netzwerk für alle überwachten Flüsse geschehen ist.
Ein Ringausbreitungsschema von 11 ermöglicht die Verteilung von Aggregations- und Korrelationsaufgaben an alle Kantenknoten und wird bevorzugt verwendet, da es effizienter als existierende Mechanismen ist, bei denen alle Knoten ihre Flusstabelle an einen zentralisierten Sammler übermitteln.
Es wird angenommen, dass alle Kantenknoten exakte Taktsynchronisierungsmechanismen haben. Die Genauigkeit muss derart sein, dass die Taktungenauigkeit auf dem Maßstab der durchgeführten Messungen vernachlässigbar ist. Verzögerungen werden in der Größenordnung von Millisekunden berechnet. Im Vergleich liefert ein GPS-basierter Takt Genauigkeit auf dem Niveau von Mikrosekunden. Es existiert also gegenwärtig die Technologie, die diese Annahme unterstützt. Im Rest des Dokuments bezieht sich eine gegebene Zeit ti auf die gleiche, von allen Knoten im System gemeinsam genutzte Zeitreferenz.
Beginnend zur Zeit t0 wird ein Verzögerungsberechnungsmechanismus für zwischen Knoten A und B fließende Daten ausgelöst, wie in 15 gezeigt.
In Router1 wird eine Schlüsselberechnung für jedes in einem gegebenen Zeitintervall für den Fluss A → B beobachtete Paket durchgeführt, bis eine auf jeden Paketschlüssel angewandte Funktion f() einen spezifischen Wert v zurückgibt.
Der Schlüssel ist gebaut, um dasselbe Paket am Eingangs- und Ausgangsknoten einer Netzwerkdomäne innerhalb eines Flusses zu identifizieren. Dieser Schlüssel sollte auf Invarianten Header-Feldern des Pakets aufgebaut sein. Zum Beispiel sollte er nicht das TTL-Feld berücksichtigen, da dasselbe Paket auf zwei verschiedenen Knoten zwei unterschiedliche Schlüssel hätte. Andererseits ist im Falle eines TCP-Flusses die Sequenznummer ein guter Kandidat für die Integration in einer Schlüsselberechnung, da ein Paket auf seinem Pfad immer die gleiche Sequenznummer behält und die Sequenznummer es unter anderen Paketen des gleichen Flusses eindeutig identifiziert.
f() und v werden verwendet, um die Pakete auszuwählen, an denen eine Verzögerungsberechnung durchgeführt wird. Zum Beispiel könnte f() eine Modulo-Funktion sein. Ein Paket könnte für eine Verzögerungsberechnung nach dem Kriterium. mod(Schlüssel,1000) = v ausgewählt werden. Als Weg zum Berechnen des Paketschlüssels sind f() und v dem Eingangs- und Ausgangsknoten gemeinsam, und das Paket, über das Zeitinformation erhalten werden soll, wird auf beiden Seiten identifiziert.
So wird für ein spezielles Paket, das an Router1 f(Schlüssel) = v erfüllt, ein Eintrag namens „Verzögerung" in die Liste der Felder der vom Flussüberwachungsmechanismus (zum Beispiel RTFM) gehandhabten Flussaufzeichnungen hinzugefügt. Dieser Eintrag enthält den Schlüssel, der berechnet wurde, und einen Zeitstempel. Die Datenstruktur für die Flussaufzeichnung, die der Zeit, an der das Paket beobachtet wurde, entspricht, ist in 12 gezeigt.
In Router3 wird dieselbe Schlüsselberechnung an jedem zum Fluss A → B gehörenden Paket während des gleichen Zeitintervalls durchgeführt. Sie dauert an, bis ein f(Schlüssel) = v gefunden wird, wobei f und v dieselben wie an Router1 sind. Wenn nach einer vernünftigen Zeitspanne p (zum Beispiel TCP-Neusendezeitablauf) kein Wert v gefunden wird, wie in 15 gezeigt, könnte dies bedeuten, dass das Paket verloren gegangen ist, und es erfolgt keine exakte Verzögerungsberechnung zur Zeit t0. Die Schlüsselberechnung wird gestoppt, sobald eine der obigen Bedingungen erfüllt ist, um den Datenpfad-Ressourcenverbrauch zu verringern.
Die Schlüsselberechnung wird an Eingangs- und Ausgangsrouter zur Zeit t1 für die kurze Zeitspanne wieder aufgenommen, die benötigt wird, um das erste nach t1 gesehene Paket zu finden, für das f(Paketschlüssel) = v gilt, und das gleiche Prinzip wird immer wieder angewendet, wie in 15 gezeigt.
Das Zeitintervall zwischen tn und tn + 1 ist konfigurierbar. Dieses Intervall wird vom Betreiber anhand der gewünschten Genauigkeit und im Hinblick auf für den Datenweg geltende übliche Abtasttheorie oder Mittelwertberechnung festgelegt. Eine kurze Zeitintervalldefinition impliziert mehr Abtastungen und damit höhere Genauigkeit. Sie impliziert aber auch mehr zu handhabende Daten und daher einen höheren Datenweg-Ressourcenverbrauch. Glücklicherweise ist die Verzögerungsberechnung keine fortdauernde zeitechte Berechnung. Sie kann zum Beispiel alle 30 Sekunden oder jede Minute (d.h. Zeitintervall i zwischen tn und tn + 1) erfolgen und jeweils über einen Zeitraum von fünf oder zehn Minuten gemittelt werden, wenn Flussaufzeichnungen vor dem Export zusammengeführt werden, wie in 15 gezeigt.
13 gibt ein Beispiel von durch Router3 gesammelter Information unter der Annahme, dass zur Zeit t1 keine Verzögerungsberechnung erfolgt ist, und 14 zeigt, wie Daten aus 12 und 13 gesammelt und in einer Flussaufzeichnung zusammengeführt werden, um dem Dienstverwalter eine Bemittelte Verzögerungsberechnung zu liefern.
15 stellt dar, wie die Verarbeitungslast auf einem Router durch diese Erfindung zeitlich verteilt ist. Es wird ein Intervall i von 30 Sekunden zwischen Verzögerungsmessungen angenommen. Die Anforderung für eine Verzögerungsmessung wäre mit einer Messung pro Minute oder mehr bei länger anhaltenden Flüssen leicht zu erfüllen. Dieses Intervall ist Fluss für Fluss vollständig anpassbar.
Die zur Implementierung der Erfindung benötigten Algorithmen werden nachfolgend dargestellt:

Obwohl spezielle Ausgestaltungen der Erfindung beschrieben und dargestellt worden sind, ist dem Fachmann klar, dass diverse Änderungen vorgenommen werden können, ohne von den Grundkonzepten abzuweichen. Es versteht sich jedoch, dass solche Änderungen in den vollen Rahmen der Erfindung, wie durch die beigefügten Ansprüche definiert, fallen.

Claims

Verfahren zum Überwachen von Verkehrsflüssen in einer Domäne eines Fernmeldenetzwerks, wobei die Domäne logisch eingerichtet ist als ein virtuelles Routernetzwerk (16) mit virtuellen Schnittstellen (18) an Kantenknoten der Domäne, mit den Schritten: a) Festlegen, an einer virtuellen Schnittstelle und in Abhängigkeit von einem Regelsatz, ob ein Paket zu einem zu überwachenden Fluss gehört; b) Verzeichnen, in Reaktion darauf, dass das Paket zu einem zu überwachenden Fluss gehört, des Pakets in einer diesem Fluss entsprechenden Flussaufzeichnung; und c) Zusammenführen der Flussaufzeichnungen zur Übertragung an einen Sammler, dadurch gekennzeichnet, dass es ferner einen Anfangsschritt des Auswählens einer der virtuellen Schnittstelle als eine virtuelle Master-Schnittstelle umfasst.
Verfahren nach Anspruch 1, bei dem das Verfahren an einer Mehrzahl der virtuellen Schnittstellen (18) durchgeführt wird.
Verfahren nach Anspruch 2, bei dem der Schritt des Auswählens der virtuellen Master-Schnittstelle durchgeführt wird durch Abfragen einer jeden der virtuellen Schnittstellen, um festzustellen, welche ein Auswahlkriterium am besten erfüllt.
Verfahren nach Anspruch 3, bei dem das Auswahlkriterium CPU-Nutzung, Verkehrshandhabungskapazität und Speicherkapazität umfasst.
Verfahren nach einem beliebigen der Ansprüche 1 bis 4, das ferner nach dem Auswahlschnitt das Initiieren, durch die virtuelle Master-Schnittstelle, der Verbreitung des Regelsatzes an die anderen virtuellen Schnittstellen umfasst.
Verfahren nach einem beliebigen der Ansprüche 1 bis 5, das nach dem Auswahlschritt durch die virtuelle Master-Schnittstelle das Sammeln von zusammengeführten Flussaufzeichnungen von den anderen virtuellen Schnittstellen umfasst.
Verfahren nach Anspruch 6, ferner mit dem Schritt des Sendens, durch die virtuelle Master-Schnittstelle, der zusammengeführten Flussaufzeichnungen zum Sammler (30).
Verfahren nach Anspruch 6 oder 7, bei dem die Flussaufzeichnungen unter Verwendung einer seriellen Sammlung von Flusstabellendaten zusammengeführt werden.
Verfahren nach Anspruch 6 oder 7, bei dem die Flussaufzeichnungen unter Verwendung einer parallelen Sammlung von Flusstabellendaten zusammengeführt werden.
Verfahren nach einem beliebigen der Ansprüche 6 bis 9, bei dem die zusammengeführten Flussaufzeichnungen dem Sammler (30) unter Verwendung einer Sammler-Schiebe- oder -Zieh-Operation (Push-Pull-Operation) bereit gestellt werden.
Verfahren nach Anspruch 5, bei dem ein Dienstverwalter den Auslöserauswahlprozess durch Senden eines neuen oder aktualisierten Regelsatzes an die virtuelle Masterschnittstelle initiiert.
Verfahren nach Anspruch 11, bei dem der Dienstverwalter zusammengeführte Flussaufzeichnungen vom Sammler (30) empfängt.
System zum Überwachen von Verkehrsflüssen in einer Domäne eines Fernmeldenetzwerks, bei dem die Domäne logisch als ein virtuelles Routernetzwerk (16) mit virtuellen Schnittstellen (18) an Kantenknoten der Domäne eingerichtet ist, wobei das System umfasst: Mittel an einer virtuellen Schnittstelle zum Festlegen, in Abhängigkeit von einem Regelsatz, ob ein Paket zu einem zu überwachenden Fluss gehört; Mittel zum Verzeichnen, in Reaktion darauf, dass das Paket zu einem zu überwachenden Fluss gehört, des Pakets in einer diesem Fluss entsprechenden Flussaufzeichnung; und Mittel zum Zusammenführen der Flussaufzeichnungen zur Übertragung an einen Sammler (30), dadurch gekennzeichnet, dass das System mehrere virtuelle Schnittstellen hat und dass eine dieser virtuellen Schnittstellen als eine virtuelle Master-Schnittstelle ausgewählt ist.
System nach Anspruch 13, bei dem die virtuelle Master-Schnittstelle Mittel zum Verbreiten von Regelsätzen an andere virtuelle Schnittstellen aufweist.
System nach Anspruch 14, bei dem die virtuelle Master-Schnittstelle Mittel zum Sammeln von zusammengeführten Flussaufzeichnungen von den anderen virtuellen Schnittstellen und zum Berichten der zusammengeführten Flussaufzeichnungen an einen Sammler (30) aufweist.
System nach Anspruch 15 mit einem Dienstverwalter zum Initiieren einer Auswahl der virtuellen Master-Schnittstelle und zum Sammeln von zusammengeführten Flussaufzeichnungen vom Sammler (30).
Verfahren nach Anspruch 1 zum Messen von flussbezogener Verkehrsverzögerung zwischen zwei Routern mit synchronisierten Takten, ferner mit den Schritten: a) Berechnen eines Schlüssels, der ein entsprechendes Paket in dem Fluss eindeutig und unveränderlich identifiziert, an jedem der Router; b) Auswählen eines zu überwachenden Pakets an jedem der den Schlüssel verwendenden Router; c) Aufzeichnen eines Zeitstempels bei Auswahl jedes Pakets an jedem der Router; und d) Subtrahieren der Zeitstempel, um die Verzögerung für das Paket festzulegen.
Verfahren nach Anspruch 17, bei dem mehrere Pakete überwacht werden und eine durchschnittliche Verzögerung für die mehreren Pakete berechnet wird.
Verfahren nach Anspruch 18, bei dem, wenn ein Schlüssel innerhalb eines gegebenen Zeitintervalls nicht berechnet werden kann, was verlorene Pakete anzeigt, der Berechnungsschritt beendet wird.
System nach Anspruch 13 zum Messen von flussbezogener Verkehrsverzögerung zwischen zwei Routern mit synchronisierten Takten, ferner mit: Mitteln zum Berechnen eines Schlüssels für jedes Paket in dem Fluss an jedem der Router, wobei der Schlüssel ein entsprechendes Paket in dem Fluss eindeutig und unveränderlich identifiziert; Mitteln zum Auswählen eines zu überwachenden Pakets an jedem der den Schlüssel verwendenden Router; Mitteln zum Aufzeichnen eines Zeitstempels bei Auswahl jedes Pakets an jedem Router; und Mitteln zum Subtrahieren der Zeitstempel, um die Verzögerung für das Paket zu bestimmen.
System nach Anspruch 20, bei dem die Router Kantenrouter in einem virtuellen Routernetzwerk sind.
System nach Anspruch 21, bei dem einer der Kantenrouter als ein Master-Kantenrouter ausgewählt ist und Paketfilterungsinformation an dem Master-Kantenrouter zusammengeführt und korreliert wird.
System nach Anspruch 21, bei dem einer der Kantenrouter als ein Master-Kantenrouter ausgewählt ist und die Zusammenführungs- und Korrelationsprozesse der Paketfilterungsinformation unter den Kantenroutern verteilt sind, wobei die Ergebnisse an den Master-Kantenrouter gesendet und dort kompiliert werden.
System nach Anspruch 22 mit einem Dienstverwalter zum Empfangen der Paketfilterungsinformation.