DE60318539T2 - Netzwerküberwachungssystem, das auf Veränderungen der Variant und des Mittelwertes der Paketankunftszeiten reagiert - Google Patents

Netzwerküberwachungssystem, das auf Veränderungen der Variant und des Mittelwertes der Paketankunftszeiten reagiert Download PDF

Info

Publication number
DE60318539T2
DE60318539T2 DE60318539T DE60318539T DE60318539T2 DE 60318539 T2 DE60318539 T2 DE 60318539T2 DE 60318539 T DE60318539 T DE 60318539T DE 60318539 T DE60318539 T DE 60318539T DE 60318539 T2 DE60318539 T2 DE 60318539T2
Authority
DE
Germany
Prior art keywords
network
packet
idc
pattern
size
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60318539T
Other languages
English (en)
Other versions
DE60318539D1 (de
Inventor
Chao Frisco Kan
Aziz Plano Mohammed
Wei Richardson Hao
Jimin Plano Shi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of DE60318539D1 publication Critical patent/DE60318539D1/de
Publication of DE60318539T2 publication Critical patent/DE60318539T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/022—Capturing of monitoring data by sampling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/087—Jitter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Description

  • ALLGEMEINER STAND DER TECHNIK
  • Die vorliegenden Ausführungsformen betreffen Computernetzwerke und sind speziell auf ein System zur Überwachung der Netzwerk-Performance und Korrektur der Netzüberlastung durch Auswerten der Änderungen der Paketankunftsvarianz bezüglich der mittleren Paketankunftszeit gerichtet.
  • Im technischen Bericht "Characterizing the Variability of Arrival Processes with Indices of Dispersion" von Ricardo Gusella, International Computer Science Institute, 26 September 1990, 1947 Center Street, Suite 600, Berkeley, California 94704, wird eine Größe eingeführt, die die Bursthaftigkeit der Paketankunftsprozesse charakterisiert.
  • Die US-Patentschrift 2002/0150041 A1 beschreibt ein Verfahren und ein System zur Bereitstellung einer verbesserten Dienstgüte für den Datentransport über das Internet, was auf dem Senden von Testpaketen basiert.
  • Da die Anzahl der Anwender und die Verkehrsmenge im globalen Internet und anderen Netzwerken ständig wächst, entstand eine erhebliche Nachfrage nach einem Satz von Mechanismen, um die Netzwerk-Performance zu überwachen und um korrigierende Maßnahmen als Reaktion auf sinkende Performance zu ergreifen. Die Performance kann in verschiedenen Formen ausgewertet werden, einschließlich, aber nicht begrenzt auf das Erkennen und Troubleshooting von Netzüberlastung. Netzüberlastung resultiert aus Fehlanpassungen zwischen der Netzkapazität und dem Netzbedarf. Die Fehlanpassung kann eine Langzeit-Fehlanpassung oder zu momentanen Zeitpunkten sein. Außerdem kann die Netzkapazität scheinbar groß unter Verwendung von Tools sein, die langzeitige Verkehrsmittelwerte betrachten; jedoch sind diese Verfahren nicht immer geeignet, weil ein offensichtlicheres Problem mit kurzen Bursts von Paketen oder Spitzenbedarf auftreten kann. Mit Überlastanalysemechanismen kann die Zuverlässigkeit und Verfügbarkeit von Netzknoten (z. B. IP-Routern) und gegebenen Internetwegen eingeschätzt werden. Das trifft insbesondere für Internet Service Provider ("ISPs") zu, die versuchen, die Service Level Agreements ("SLAs") zu erfüllen, die sie jetzt Kunden anbieten. Außerdem ist solch ein Bedarf für zugrundeliegende Internet-Protokoll-Netze ("IP-Netze") im Internet weit verbreitet.
  • Das Internet entwickelt sich ebenfalls zu einer fortschrittlichen Architektur, die sucht, die Dienstgüte ("QoS") für Echtzeit-Anwendungen zu garantieren. QoS ermöglicht zu steuern, was mit Paketen passiert, wenn in einem Netzwerk eine Überlastung vorhanden ist, oder genauer, wenn unzureichende Netzkapazität vorhanden ist, um die gesamte angebotene Last ohne wahrnehmbare Warteschlangenverzugszeiten zu liefern. Ein Typ des QoS-Rahmens sucht, strenge spezifische Netzwerk-Performance für Anwendungen wie Bandbreiten/Verzugszeiten-Reservierungen für einen unmittelbar bevorstehenden oder zukünftigen Datenfluß zu garantieren. Solche QoS wird gewöhnlich hinsichtlich der Fähigkeit charakterisiert, um ein anwendungsspezifisches Peak und mittlere Bandbreite, Verzugszeit, Jitter und Paketverlust zu garantieren. Ein anderer Typ besteht darin, die Dienstklasse (Class-of-Service/"CoS") wie zum Beispiel differenzierte Dienste (Differentiated Services/"Diff-Serv") zu verwenden, um das eindeutigere Verfahren darzustellen, um bestimmte Paketarten bevorzugt zu behandeln, aber ohne irgendwelche Performance-Garantien zu machen.
  • Während des QoS-Prozesses, um Dienste besser als das übliche "best effort" bereitzustellen, wird die Netzüberlastungserkennung oft zum Ausgangspunkt für die Netzwerk-Performance-Analyse. In der Vergangenheit sind zahlreiche Überlasterkennungs- und Steuerschemata in Datennetzen untersucht worden. Ein Überlasterkennungsschema verwendet die Transportschichtprotokolle, um Überlastung aus der voraussichtlichen Engpaß-Dienstzeit oder aus Änderungen des Durchsatzes oder der Ende-zu-Ende-Verzugszeit sowie aus Paketverlusten zu folgern. Speziell das Internet hat sich traditionell auf die Mechanismen im Transport Control Protocol ("TCP") verlassen, wie Gleitfenstersteuerung und Übertragungswiederholungs-Timerstörungen, um Überlastung zu vermeiden. TCP arbeitet, um überschüssige Bandbreite durch Erhöhen der Übertragungsraten zu suchen, bis das Netzwerk überlastet ist und dann durch Verringern der Übertragungsrate, wenn einmal Überlastung auftritt. Aus dieser Herangehensweise entstehen einige Einschränkungen. Erstens erfordert die TCP-Überlastungserkennung an einem ersten Knoten eine Bestätigung von einem zweiten Knoten, das heißt, die erhöhte Übertragung wird fortgesetzt, bis die Bestätigung vom zweiten Knoten empfangen wird; folglich ist eine Rückkopplungsverbindung von einem anderen Knoten erforderlich und diese Rückkopplung nutzt ebenfalls Bandbreite im Netzwerk. Zweitens verursacht in seinem Bestreben, Bandbreite zu identifizieren, das TCP notwendigerweise genau die Überlastung, die es anschließend versucht zu minimieren, wo die Überlastung verursacht wird, da das TCP die Bandbreite auf einen Punkt erhöht, der die Netzkapazität übersteigt. Ein anderer Typ des Überlasterkennungsschemas ist, Netzkomponenten wie zum Beispiel Router in den gesamten Prozeß einzubeziehen. Da die meiste Netzüberlastung in Routern auftritt, können sie als eine ideale Position angesehen werden, um die Netzlast und Überlastung zu überwachen und darauf in einem Kontrollschema zu reagieren. Solche netzbasierte Überlastungssteuerung verwendet die explizite Signalisierung zwischen Routern, um Rückkopplungsüberlastungsinformationen an einen Senderouter bereitzustellen, wo der Senderouter anschließend sein Verhalten als Antwort auf die Rückkopplung ändern kann oder ein Gesamtschema die Paketverarbeitung innerhalb eines oder mehr Router ändern kann, um die Überlastung zu verringern. In jedem Fall erfordert dieses letztgenannte Schema ebenfalls eine Form der Rückkopplung von einem Empfangsrouter, dadurch den Verkehr im Netzwerk erhöhend, um die Rückkopplung aufzunehmen, und erfordert ebenfalls die Verläßlichkeit des Senderouters auf die Integrität eines verschiedenen Routers.
  • Angesichts des Obenerwähnten ist es erforderlich, die Nachteile des Standes der Technik anzugehen, wie durch die unten beschriebenen bevorzugten Ausführungsformen erreicht wird.
  • KURZDARSTELLUNG DER ERFINDUNG
  • In der bevorzugten Ausführungsform ist ein Netzwerküberwachungssystem vorhanden, über das Netzverkehr in einer Form von Paketen fließt. Das System umfaßt eine Schaltungsanordnung zum Empfangen eines Pakets, das über das Netzwerk übertragen wurde und zum Bestimmen ob das empfangene Paket ein Bedingungsmuster erfüllt. Das System umfaßt außerdem eine Schaltungsanordnung, die auf eine Bestimmung reagiert, daß das empfangene Paket das Muster erfüllt, zum Bestimmen einer Größe und eine Schaltungsanordnung zum Vergleichen der Größe mit einem Schwellwert, in welchem die Größe über ein definiertes Zeitintervall bestimmt wird und ein Verhältnis der Paketankunftsvarianz und einen Mittelwert der Pakete umfaßt, die während des Zeitintervalls ankommen. Schließlich umfaßt das System eine Schaltungsanordnung, die auf die Größe reagiert, die den Schwellwert übersteigt, um die Netzressourcen einzustellen.
  • Andere Aspekte sind ebenfalls beschrieben und in den Ansprüchen enthalten.
  • KURZBESCHREIBUNG DER MEHREREN ZEICHNUNGSANSICHTEN
  • 1 zeigt ein Blockdiagramm eines Netzwerkssystems 10, in dem die bevorzugten Ausführungsformen implementiert werden können.
  • 2 zeigt ein Blockdiagramm jedes Netzwerkmonitors NM1 bis NM8 von 1.
  • 3 zeigt ein Flußdiagramm der Arbeitsweise jedes Netzwerkmonitors NM1 bis NM8 von 2.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • 1 zeigt ein Blockdiagramm eines Systems 10, in dem die bevorzugte Ausführungsform implementiert werden kann. Das System 10 schließt im Allgemeinen mehrere Stationen ST1 bis ST4 ein, wobei jede mit einem Netzwerk 20 über einen Router gekoppelt ist und jede betriebsfähig ist, Pakete wie eine Quelle zu senden oder Pakete wie ein Ziel zu empfangen. Beispielhaft ist das Netzwerk 20 ein Internet-Protokoll-Netzwerk ("IP-Netzwerk") wie zum Beispiel das globale Internet oder anderes IP verwendendes Netzwerk, wo jede Station und IP-Netzwerke im Allgemeinen im Stand der Technik weithin bekannt. Der Fachmann sollte erkennen, daß die Verwendung des IP-Protokolls beispielhaft ist und viele verschiedene erfinderische Lehren hierin auf zahlreiche andere Protokolle angewendet werden können, einschließlich beispielhaft auf asynchronen Übertragungsmodus ("ATM"), Token Ring, Novell, Apple Talk und noch andere. In jedem Fall, zurückkehrend zum Netzwerk 20 als ein IP-Netzwerk, und ebenfalls beispielhaft kann jede Station STX als einer von verschiedenen unterschiedlichen Typen von Rechenvorrichtungen aufgebaut werden und funktionieren, die alle gemäß dem IP-Protokoll kommunizieren können. Schließlich und ebenfalls beispielhaft sind nur vier Stationen STX gezeigt, um die Darstellung und das Beispiel zu vereinfachen, wo in Wirklichkeit jede solche Station in der Nähe anderer Stationen (nicht gezeigt) und an einem Ort sein können, der sich in beträchtlicher Entfernung von anderen dargestellten Stationen befindet.
  • Fortsetzend mit 1 sind neben der äußeren Peripherie des Netzwerks 20 mehrere Edge-Router ER1 bis ER11 gezeigt, während innerhalb des Netzwerks 20 mehrere Core-Router CR1 bis CR4 gezeigt sind. Die Begriffe Edge-Router und Core-Router sind im Stand der Technik bekannt und betreffen im Allgemeinen die Funktion und den relativen Netzwerkort eines Routers. In der Regel verbinden sich Edge-Router mit entfernt angeordneten Netzwerken und wickeln erheblich weniger Verkehr als Core-Router ab. Außerdem und aufgrund teils der relativen Menge des Verkehrs, der durch Core-Router abgewickelt wird, neigen sie dazu, weniger komplexe Operationen an Daten durchzuführen und erfüllen stattdessen in erster Linie eine Switchingfunktion; mit anderen Worten, wegen der gewaltigen Menge des Durchsatzes, der von den Core-Routern erwartet wird, sind sie in der Regel gerätebegrenzt als Switchingmaschinen und haben nicht die Fähigkeit, Operationen auf der Basis der spezifischen Daten bereitzustellen, die durch den Router gehen. Stattdessen schließen Core-Router in der Regel nicht viel in der Art von Steuerungsmechanismen ein, da 10.000 oder mehr Verbindungen in einem einzelnen Trunk sein könnten. Außerdem verbinden Core-Router in der Regel ihre Operationen nicht mit TCP-bezogenen Elementen und handeln stattdessen auf der IP-Ebene und darunter. Im Gegensatz sind Edge-Router fähig, verschiedene Parameter innerhalb der Datenpakete zu überwachen, die durch den jeweiligen Router angestoßen sind.
  • In jedem Fall sind die verschiedenen Router in 1 nur beispielhaft gezeigt, wo der Fachmann erkennen wird, daß ein typisches Netzwerk eine ganz verschiedene Anzahl beider Typen von Routern einschließen kann. Schließlich ist zu beachten, daß jeder Core-Router CRX und jeder Edge-Router ERX gemäß dem Stand der Technik aufgebaut und funktionieren kann, mit der Ausnahme, daß vorzugsweise ausgewählte Router davon zusätzliche Funktionalität zu Zwecken der Verkehrsüberlastungserkennung einschließen und auf der Basis der Paketankunftsvarianz und Mittelwertes reagieren können, wie später beschrieben ist. Außerdem können ausgewählte Router weiterhin aufgebaut sein, um auf die Verkehrsüberlastungserkennung zu reagieren, die der Router ermittelt, sowie als Antwort auf die Verkehrsüberlastungserkennung eines anderen Routers im Netzwerk 20. Überdies können in einem Verfahren die Core-Router konfiguriert werden, um anders als Edge-Router zu reagieren, wenn Verkehrsüberlastung erkannt wird.
  • Die Diskussion von 1 abschließend, ist zu beachten, daß die verschiedenen Stationen, Edge-Router und Core-Router darin als miteinander in verschiedenen Konfigurationen verbunden und ebenfalls beispielhaft gezeigt sind. Solche Verbindungen sollen ein Beispiel für die spätere Diskussion der bevorzugten Arbeitsweise sein und ebenfalls eine allgemeine Darstellung widerspiegeln, wie Netzwerke im Allgemeinen aufgebaut sind. Folglich ist jede Station STX mit einem einzelnen Edge-Router ERX verbunden dargestellt, wo dieser Edge-Router ERX mit einem oder mehr Core-Routern CRX verbunden ist Die Core-Router CRX sind ebenfalls beispielhaft verbunden mit mehreren anderen Core-Routern CRX gezeigt. Durch Verweis identifiziert die folgende Tabelle 1 jede Station und Router, die in 1 dargestellt sind, sowie das (die) andere(n) Gerät(e), mit dem jedes verbunden ist.
    Station oder Router angeschlossene Knoten
    ST1 ER1
    ST2 ER10
    ST3 ER5
    ST4 ER7
    ER1 ST1; CR1
    ER2 CR1; CR2
    ER3 CR2
    ER4 CR2
    ER5 ST3; CR2; CR3
    ER6 CR3; CR4
    ER7 ST3; CR4
    ER8 CR4
    ER9 CR4
    ER10 ST2; CR1
    ER11 CR1
    CR1 ER1; ER11; ER10; ER2; CR2; CR3; CR4
    CR2 ER2; ER3; ER4; CR1; CR3; CR4; ER5
    CR3 ER5; ER6; CR2; CR1; CR4
    CR4 ER7; ER8; ER9; CR1; CR2; CR3; ER6
    Tabelle 1
  • Die verschiedenen gezeigten Verbindungen gegeben, wie ebenfalls in Tabelle 1 dargestellt, fließen im Allgemeinen die IP-Pakete über die verschiedenen gezeigten Wege des Netzwerks 20 und in Gruppen oder in ihrer Gesamtheit werden solche Pakete oft als Netzverkehr bezeichnet. In dieser Hinsicht und wie unten entwickelt, arbeiten die bevorzugten Ausführungsformen, um zu identifizieren und auf Überlastung in solchem Netzverkehr zu reagieren. Abschließend ist zu beachten, daß 1 eine vereinfachte Version eines Netzwerks oder des Internet darstellen kann, in dem nur einige Stationen und Router gezeigt sind, während der Fachmann ohne weiteres verstehen wird, daß die erfinderischen Konzepte in diesem Dokument auf eine größere Anzahl von Stationen, Routern und die Netzwerk-Interkonnektivität zwischen diesen Geräten angewendet werden können.
  • 1 zeigt auch mehrere Netzwerkmonitore NM1 bis NM8 gemäß den bevorzugten Ausführungsformen, wo die Auswahl von acht solcher Netzwerkmonitore nur beispielhaft ist, die Menge anderer Hardware vorausgesetzt, die für das Netzwerk 20 gezeigt ist. Wie unten im einzelnen aufgeführt ist, ist jeder Netzwerkmonitor NMX betriebsfähig, jedes Paket abzutasten, das über den (die) Leiter empfangen wurde, an dem der Netzwerkmonitor angeschlossen ist, und wenn die Korrekturmaßnahme für nützlich gehalten wird, dann kann eine Routingtabelle, die mit einem Router verbunden ist, der ebenfalls mit dem Netzwerkmonitor NMX verbunden ist, modifiziert werden, um die Netzwerk-Performance zu verbessern. Die Komponenten jedes Netzwerkmonitors NMX sind unten beschrieben, aber an dieser Stelle sind die Verbindungen jedes Monitors in der folgenden Tabelle 2 vermerkt:
    Netzwerkmonitor angeschlossene Knoten
    NM1 CR1; CR2
    NM2 CR2; CR3
    NM3 CR1; CR3
    NM4 CR3; CR4
    NM5 CR1; CR2; CR3; ER7; ER8; ER9
    NM6 CR4; ST4
    NM7 ST2; CR1
    NM8 ER5; ST3
  • 1 und Tabelle 2 veranschaulichen, daß jeder Netzwerkmonitor NM1 bis NM4 und NM8 angeschlossen ist, um Pakete abzutasten, die durch den (die) Leiter zwischen einem Paar von Knoten durchgehen, wie zum Beispiel zwischen den Routern oder zwischen einem Router und einer Station. Jedoch sind die Netzwerkmonitore NM5, NM6 und NM7 jeder durch alternative Beispiele in den jeweiligen Routern CR4, ER7 und ER10 integriert. Infolgedessen ist jeder Netzwerkmonitor NM5, NM6 und NM7 in der Lage, die Pakete abzutasten, die an alle Knoten übermittelt werden, mit dem ihr jeweiliger Router verbunden ist; zum Beispiel bezüglich des Netzwerkmonitors NM5 kann er Pakete abtasten, die an jeden Knoten übermittelt wurden, an dem der Core-Router CR4 angeschlossen ist, nämlich die Core-Router CR1, CR2, CR3 und Edge-Router ER7, ER8 und ER9. Folglich ist der Gegensatz der Netzwerkmonitore NM5, NM6 und NM7 zu den anderen dargestellten Netzwerkmonitoren NM1 bis NM4 gezeigt, um nachzuweisen, daß in der bevorzugten Ausführungsform jeder Netzwerkmonitor NMX Pakete als eine selbständige Entität abtasten kann oder mit der Hardware und Software eines existierenden Routers kombiniert werden kann; tatsächlich kann in den bevorzugten Ausführungsformen ein Netzwerkmonitor NMX ebenfalls mit Netzwerk- oder Elementverwaltungssystemen kombiniert werden. In jedem Fall und durch Einführung in Details, die später bereitgestellt sind, ermöglicht in den bevorzugten Ausführungsformen die Abtastfunktionalität jedes Netzwerkmonitors NMX die Echtzeitüberwachung in einer definierten Zeitperiode, eines Verhältnisses der Paketankunftsvarianz und des Mittelwertes für ausgewählte Pakete, und als Reaktion können Bestimmungen durchgeführt werden und Aktionen können erfolgen, auf der Basis von Schwellwerten, die vom Verhältnis überschritten wurden, dadurch einen Hinweis auf wahrscheinliche Netzverkehrüberlastung darstellend.
  • 2 zeigt ein Blockdiagramm jedes Netzwerkmonitors NM1 bis NM4 und NM8 von 1 mit der weiteren Voraussetzung, daß funktional die folgende Beschreibung ebenfalls auf jeden Netzwerkmonitor NM5, NM6 und NM7 angewandt werden kann, mit dem Zusatz, daß bestimmte Funktionalität durch die Hardware und Software bereitgestellt werden kann, die bereits von jedem jeweiligen Router CR4, ER7 und ER10 zur Verfügung steht. Danach gehend zu 2, ist eine Konsole 30 mit dem Netzwerkmonitor NMX verbunden, wo in der bevorzugten Ausführungsform eine einzelne Konsole 30 mit mehrfachen Netzwerkmonitoren NMX kommuniziert. Zum Beispiel kurz zurückkehrend zu 1, kommuniziert vorzugsweise jeder Netzwerkmonitor NM1 bis NM8 mit einer einzelnen Konsole 30, wo solche Kommunikation ebenfalls durch Pakete zwischen Konsole 30 und den Netzwerkmonitoren NMX sein kann. Konsole 30 kann durch den Fachmann unter Verwendung verschiedener Formen von Hardware und Software aufgebaut werden, wo die Auswahl eine Sache der Implementierungsauswahl ist, um die in diesem Dokument beschriebene Funktionalität zu erreichen. Sich der Funktionalität zuwendend, stellt die Konsole 30 vorzugsweise eine Administrationsfunktion (Konfigurationsfunktion) und eine Berichtsfunktion bereit. Um einem Anwender zu ermöglichen, die Funktionen durchzuführen, können verschiedene Schnittstellen verwendet werden wie zum Beispiel ein web-basiertes Konfigurationstool oder ein Befehlszeilentool, wo ein vorzugweises Verfahren die Konsole 30 implementiert, beispielhaft unter Verwendung des Apache Web-Servers mit der PHP-Server-Scriptsprache, um eine dynamische Schnittstelle zu einem Flußspeicher 32 bereitzustellen. In jedem Fall stellt die Benutzeroberfläche vorzugsweise verschiedene Bildschirme für jede Administrations- und Berichtsfunktion bereit. Die tatsächliche Schnittstelle und Bildschirme jedoch können in verschiedenen Formen implementiert sein, wo es für eine Form wünschenswert ist, daß ein Bediener die Konsole 30 richtig steuern kann, um seine Administrations- und Berichtsfunktionen bezüglich ihres Flußspeichers 32 richtig durchzuführen. Vorzugsweise ein Netzadministrator oder dergleichen verwendet die Verwaltungsfunktionalität der Konsole 30, um einen Satz von Regeln zu erstellen und die Regeln bereitzustellen, zusammen mit einer Methodik zum Bestimmen einer Indexstreuung für Zählwerte ("IDC") und entsprechend dazu an einen später beschriebenen RTFM-Zähler 36. Durch Einführung veranlaßt der Satz der Regeln den Zähler 36, die Paketankunftszeit für jedes Paket zu speichern, das eine (oder mehr) der bereitgestellten Regeln erfüllt, das heißt, es werden jene Pakete aus allen Paketen ausgewählt, die durch den Zähler mit der Ankunftszeit der ausgewählten Pakete hindurchgehen, die aufgezeichnet werden; danach bestimmt der Zähler 36 den IDC für die ausgewählten Pakete während eines vorgegebenen Zeitintervalls t. Auch wenn das System einmal konfiguriert ist und belassen ist, um die Paketankunftszeit der überwachten Pakete zu erfassen, kann der Netzadministrator den Berichtsbildschirm verwenden, um die Informationen abzufragen, um Netzstatusberichte auf der Basis der erfaßten Informationen zu erzeugen und dadurch Netzüberlastung zu analysieren.
  • Wie oben eingeführt ist, ist die Konsole 30 mit einem Flußspeicher 32 verbunden, der vorzugsweise ein Speichermedium darstellt, das eine Flußdatenbank speichert, die überwachte Pakete betrifft. In der bevorzugten Ausführungsform schließt jeder Netzwerkmonitor NMX seine eigene Flußdatenbank ein, obwohl alternative Ausführungsformen erzeugt werden können, wo sich mehr als ein Netzwerkmonitor NNX eine gemeinsame Flußdatenbank teilen. In der bevorzugten Ausführungsform ist die Flußdatenbank im Flußspeicher 32 eine SQL-kompatible Datenbank unter Verwendung des PostgreSQL relationalen Datenbank-Verwaltungssystems, obgleich in alternativen Ausführungsformen verschiedene andere Datenbanktypen im Flußspeicher 32 verwendet werden können. Unter Verwendung der bevorzugten Ausführungsform als ein Beispiel kommuniziert die Konsole 30 mit dieser Datenbank über die PHP-Verbindung des Web-Servers mit der SQL-Datenbank. Folglich kann jede Administrations- und Konfigurationsänderung, die über die Konsole 30 erfolgte, direkt an den Flußspeicher 32 übergeben werden. Das Vorhergehende vorausgesetzt, sollte ein Fachmann verstehen, daß der Zugriff auf den Flußspeicher 32 durch SQL-Abfragen erreicht werden kann, die Netzadministratoren ermöglichen, den Konfigurationsprozeß zu automatisieren oder Berichtsgenerierung zu integrieren. Wie oben eingeführt ist, speichert in der bevorzugten Ausführungsform der Flußspeicher 32 ebenfalls, was in diesem Dokument als ein "Regelsatz" (oder "Regelsätze" im Plural) bezeichnet ist, was ursprünglich an den Flußspeicher 32 von der Konsole 30 als Teil der Administrationsfunktion bereitgestellt wird und was dadurch ebenfalls an den Zähler 36 transportiert wird. Wie durch das Beispiel unten gezeigt ist, spezifiziert jeder Regelsatz ein oder mehr Kriterien, auf die der Zähler 36 jedes kommende Paket auswertet, um zu bestimmen, ob die Kriterien erfüllt sind. Zusätzlich kann in einer Ausführungsform der Flußspeicher 32 die Paketankunftszeitinformationen für die Pakete speichern, die die Kriterien in einem überwachten Fluß erfüllen, so daß solche Informationen ausgewertet werden können, einschließlich Bestimmung der IDC-Informationen und mögliche Reaktionen darauf durch Konsole 30. Außerdem und ebenfalls unten erörtert, kann der Flußspeicher 32 zahlreiche verschiedene Sätze von Paketankunftszeitinformationen speichern, jeder einem verschiedene Satz von Flußkriterien entsprechend, das heißt, entsprechend einem der verschiedenen spezifizierten Regelsätze. Die gespeicherten Informationen sind daher durch die Konsole 30 zugänglich und ermöglichen weitere Auswertungen der Flußinformationen, um Informationen und Berichte bereitzustellen, die für Zwecke der Netzwerktechnik und Verwaltung nützlich sind.
  • Fortsetzend mit 2, stellt die Aufzeichnungsschicht 34 eine Schnittstelle zwischen dem Flußspeicher 32 und einem verwendeten und mit dem Netzwerk gekoppelten Zähler 36 (oder Zählern) bereit. Im Allgemeinen können die Anwendungen der Aufzeichnungsschicht 34 in zwei Kategorien eingeteilt werden: Manageranwendungen und Zählerablesungsanwendungen. Manageranwendungen konfigurieren den Zähler 36 auf der Basis von Informationen, einschließlich Regeln in einem oder mehr Regelsätzen, im Flußspeicher 32. Zählerablesungsanwendungen erlauben, daß die durch den Zähler 36 erfaßten und/oder bestimmten Daten in einem Datenformat bereitgestellt werden können, das durch den Flußspeicher 32 verwendbar ist, und die Aufzeichnungsschicht 34 wirklich das Durchgehen dieser Daten in die Flußdatenbank des Flußspeichers 32 erleichtert. Die Anwendungen der Aufzeichnungsschicht 34 können Informationen zwischen dem Flußspeicher 32 und den Netzwerkproben des Zähler 36 entweder synchron oder asynchron durchlassen. Das bietet den Netzadministratoren die Flexibilität, entweder Echtzeit-Netzwerkflußzähler (d. h. NeTraMet) zu verwenden oder Daten von anderen Netzwerkanalysetools zu importieren, die keine Echtzeitdaten (z. B. Cisco NetFlow-Daten) bereitstellen können.
  • In der bevorzugten Ausführungsform ist der Zähler 36 ein Echtzeit-Verkehrsfluß-Meßzähler ("RTFM"/Real-Time Traffic Flow Measurement), der ein Konzept von der Internet Engineering Task Force ("IETF") ist. Wie in der RTFM-Technik bekannt ist, sind RTFM-Zähler bisher bekannt für den Einsatz in Systemen zum Bestimmen des Dienstes, der durch IP-Pakete angefordert wurde, die durch ein Netzwerk zu Zwecken der Gebührenerfassung gehen, wo solch ein Dienst durch die Transportportnummer identifizierbar ist, die in jedem IP-Paket angegeben ist. Zum Beispiel sieht man RTFM-Zähler gegenwärtig an, daß sie in Systemen verwendet werden können, wodurch die Gebühren für einen Internet-Anwender auf der Basis des von ihm im Internet benutzten Dienstes berechnet werden; zum Beispiel kann eine verschiedene Gebühr dem Anwender für jeden verschiedenen Internet-Dienst berechnet werden, einschließlich Mail, Video, Telefonanrufe und Web-Browsing. Jedoch wie in diesem Dokument ausführlich beschrieben ist, implementiert die bevorzugte Ausführungsform stattdessen den RTFM-Zähler, um jedes Paket auszuwerten und um zu bestimmen, ob das Paket eine Regel im Regelsatz erfüllt und wenn es so ist, um ausreichend Paketankunftszeit zu speichern, die dem definierten Intervall t entspricht, so daß der Paket-IDC bestimmt und als eine Grundlage verwendet werden kann, um Netzüberlastung anzuzeigen und darauf zu reagieren. Folglich prüft der Zähler 36 Echtzeit physikalisch den zugrundeliegenden Netzverkehr und jedesmal, wenn der Zähler 36 ein IP-Paket im Netzwerk erkennt, bestimmt er, ob das Paket eine Regel im Regelsatz bzw. Regelsätzen erfüllt. Ebenfalls während des Echtzeitdurchgangs zahlreicher IP-Pakete durch Auswerten des Zählers 36 kopiert der Zähler 36 nicht immer einen festen Teil jedes derartigen Pakets in eine Datenbank wie zum Beispiel das ganze Paket oder den ganzen Paketheader; stattdessen wertet der Zähler 36 das (die) entsprechende(n) Feld(er) im Paket aus und wenn eine Regel im Regelsatz bzw. Regelsätzen erfüllt ist, dann speichert der Zähler 36 ausreichend Paketankunftszeit, so daß der IDC, die diesem Paket entspricht, bestimmt werden kann. Außerdem kann der Zähler 36 zusätzliche Informationen über jedes die Regel erfüllende Paket speichern, wie weiter später erklärt ist. Zurückkehrend zum Aspekt des Zählers 36, der Informationen speichert, um den Paket-IDC zu bestimmen, zieht der vorliegende erfinderische Anwendungsbereich zwei Alternativen der aktuellen IDC-Bestimmung in Betracht, nämlich, entweder der Zähler 36 kann selbst den IDC bestimmen oder der Zähler 36 kann ausreichend Informationen speichern und die Konsole 30 kann den IDC aus den gespeicherten Informationen bestimmen, wo in jedem Fall der IDC bestimmt wird, wie später ausführlich aufgeführt ist. Außerdem besteht der Kompromiß zwischen diesen Verfahren der zwei alternativen Ausführungsform darin, daß die Implementierung des Zählers den Overhead in Netzwerkprozessoren hineinbringt, aber mit weniger Nachrichtenübermittlungs-Bandbreitenoverhead für Zählerleser. Die Lösung der Leserseite andererseits funktioniert tatsächlich wie eine Anwendungsanalysekomponente in der RTFM-Architektur. Der Overhead für den Routenprozessor ist minimal, aber der Nachrichtenübermittlungs-Bandbreitenoverhead für den Durchgang der Rohdaten an den IDC-Monitor zur Berechnung kann unerträglich sein.
  • Es wurde vorgeschlagen, dafür den Streuungsindex für Zählwerte ("IDC"/Index der Dispersion for Counts) zu verwenden, um die Paket-Bursthaftigkeit in einem Versuch zu charakterisieren, um den Internet-Verkehr zu modellieren, wohingegen im Gegensatz im vorliegenden erfinderischen Anwendungsbereich der IDC stattdessen mit den anderen Attributen kombiniert wird, die hier beschrieben sind, um auf Echtzeitweise die Paketüberlastung zu erkennen und auf sie zu reagieren. Durch Hintergrundinformationen im Stand der Technik wird in einem Dokument mit dem Titel "Characterizing The Variability of Arrival Processes with Index Of Dispersion," (IEEE, Vol. 9, No. 2, Feb. 1991) von Riccardo Gusella, die Verwendung des IDC diskutiert, der ein Maß der Bursthaftigkeit bereitstellt, so daß ein Modell für Internet-Verkehr beschrieben werden kann. Gegenwärtig wird im Stand der Technik mehr über das Identifizieren des Typs des Modells diskutiert, ob existierende oder neu entwickelte, welche den Internet- Verkehr ausreichend beschreiben werden. In dem erwähnten Dokument ist der IDC als ein Maß der Bursthaftigkeit zur Verwendung vorgeschlagen, um solch ein Modell zu erstellen. Der IDC wird als die Varianz der Anzahl der Paketankunftszeiten in einem Intervall der Länge t definiert, dividiert durch die mittlere Anzahl der Paketankunftszeit in t.
  • Zum Beispiel angenommen, daß ein gegebener Netzknoten eine Anticipation (d. h. eine Basislinie) des Empfangens von 20 Paketen pro Sekunde ("pps") hat, und weiterhin angenommen, daß in fünf aufeinanderfolgenden Sekunden dieser Knoten 30 Pakete in Sekunde 1, 10 Pakete in Sekunde 2, 30 Pakete in Sekunde 3, 15 Pakete in Sekunde 4 und 15 Pakete in Sekunde 5 empfängt. Folglich empfängt in den fünf Sekunden der Knoten 100 Pakete; im Durchschnitt empfängt der Knoten 20 Pakete pro Sekunde, das heißt, der durchschnittliche Empfang pro Sekunde ist gleich der erwarteten Basislinie von 20 pps. Jedoch für jede einzelne Sekunde ist eine Varianz ungleich Null in der Menge der Pakete vorhanden, die vom erwarteten Wert von 20 pps empfangen wurden. Zum Beispiel in Sekunde 1 beträgt die Varianz +10, in Sekunde 2 ist die Varianz –10 und so weiter. Als solcher stellt der IDC ein Maß bereit, das diese Varianz widerspiegelt, in der Form eines Verhältnisses im Vergleich zu seinem Mittelwert und aufgrund der beachtlichen Schwankung der Empfangsrate pro Sekunde im Fünf-Sekunden-Intervall wird beachtliche Bursthaftigkeit in den empfangenen Paketen wahrgenommen, wo der Stand der Technik einen Versuch beschreibt, um ein Modell dieser Bursthaftigkeit zusammenzustellen, um Internet-Verkehr zu modellieren.
  • Betrachtend nun die bevorzugte Ausführungsform, verwendet sie den IDC nicht nur als ein Prädikat zur Modellierung des Internet-Verkehrs sondern stattdessen, um eine laufende Bestimmung bereitzustellen, ob der ausgewählte Paketverkehr Überlastung verursacht, wo solche Überlastung zum Teil als Antwort auf einen den Schwellwert übersteigenden IDC erkannt wird, und vorzugsweise außerdem angesichts zusätzlicher Überlegungen, wie zum Beispiel bezüglich der Dienstgüte ("QoS"). Indem somit der IDC in seiner früheren Anwendung sowie im vorliegenden erfinderischen Anwendungsbereich eingeführt wurde, wird seine tatsächliche Bestimmung nun detaillierter erklärt. Erinnernd, daß der IDC als die Varianz der Anzahl der Paketankunftszeit in einem Intervall der Länge t, dividiert durch die mittlere Anzahl der Paketankunftszeiten in t, definiert ist, kann er dargestellt werden, wie in der folgenden Gleichung 1 geschrieben ist:
  • Figure 00180001
  • In Gleichung 1 gibt Nt die Anzahl der Ankunftszeiten in einem Intervall der Länge t an. In der bevorzugten Ausführungsform und zur Schätzung des IDC der gemessenen Ankunftsprozesse wird nur die Zeit zu diskreten, abstandsgleichen momentanen τi (i ≥ 0) berücksichtigt. Außerdem, indem ci die Anzahl der Ankünfte im Zeitintervall τi – Ti-1 anzeigt, kann die folgende Gleichung 2 dann angegeben werden:
  • Figure 00180002
  • In Gleichung 2 sind var(cτ) und E(cτ) die gemeinsame Varianz beziehungsweise der Mittelwert von ci, dadurch wird implizit vorausgesetzt, daß die berücksichtigten Prozesse zumindest schwach stationär sind, das heißt, daß ihr erster und zweiter Moment zeitinvariant sind, und daß die Autokovarianzreihen nur von der Entfernung k, der Nacheilung, zwischen den Abtastwerten abhängig sind: cov(ci, ci+k) = cov(cj, cj+k), für alle i, j und k.
  • Außerdem ist angesichts der Gleichungen 1 und 2 die folgende Gleichung 3 zu berücksichtigen:
  • Figure 00190001
  • Außerdem kann für den Autokorrelationskoeffizienten ξi,j+k wie in der folgenden Gleichung 4 angegeben werden:
  • Figure 00190002
  • Dann kann aus Gleichung 4 die folgende Gleichung 5 geschrieben werden:
  • Figure 00190003
  • Zum Abschluß ist dafür die erwartungstreue Schätzung von E(cτ), var(cτ) und ξj in den folgenden jeweiligen Gleichungen 6 bis 8 angegeben:
  • Figure 00190004
  • Figure 00200001
  • Folglich kann der IDC durch die bevorzugte Ausführungsform unter Verwendung der Gleichungen 6 und 7 und außerdem angesichts der Gleichung 8 bestimmt werden.
  • 3 zeigt ein Flußdiagramm eines Gesamtverfahrens 40 der Arbeitsweise für jeden Netzwerkmonitor NMX von 1 und 2. Während Verfahren 40 unten bezüglich eines einzelnen Netzwerkmonitors NMX beschrieben ist, führt vorzugsweise jeder Netzwerkmonitor NMX ein vergleichbares Verfahren an seinem jeweiligen Standort im Netzwerk 20 durch. Infolgedessen treten verteilte Operationen an verschiedenen Netzwerkorten auf, wo beispielhaft die Ergebnisse jedes einzelnen Netzwerkmonitors NMX durch eine gemeinsame Ressource, wie zum Beispiel an einer einzelnen Konsole 30, akkumuliert werden können. Aus diesen akkumulierten Informationen kann größere Genauigkeit beim Identifizieren der Netzüberlastung erreicht werden sowie können Einstellungen am Verkehr als Antwort auf solche Überlastung vorgenommen werden.
  • Gehend zu Verfahren 40, erfaßt im Schritt 42 ein Netzwerkmonitor NMX gemäß der bevorzugten Ausführungsform ein Netzwerkpaket, das heißt, ein Paket wird über einen Leiter empfangen, mit dem der Monitor verbunden ist. Außerdem und als Antwort bestimmt im Schritt 42 der Netzwerkmonitor NMX, ob das Paket eine Regel im Regelsatz oder Regelsätzen erfüllt, die im Flußspeicher 32 gespeichert sind. Zum Beispiel angenommen, daß der Flußspeicher 32 zwei Regelsätze speichert, die auf 1 gerichtet sind, wo der erste Regelsatz jedes Paket angibt, das von Station ST1 als eine Quelle ausgeht und sich zu Station ST3 als ein Ziel bewegt, und wo der zweite Regelsatz jedes Paket angibt das von Station ST2 als eine Quelle ausgeht und sich zu Station ST4 als ein Ziel bewegt. Folglich wird im Schritt 42 für das erfaßte Paket eine Bestimmung von der Quell- und Zieladresse im Paketheader durchgeführt, ob sie die Bedingungen beider dieser zwei Regeln erfüllen. Es ist auch zu beachten, daß die Quell- und Zieladresse nur beispielhaft bereitgestellt sind, wo in der bevorzugten Ausführungsform die Regeln auf andere Gesichtspunkte gerichtet sein können, die im Paketheader dargestellt sind, einschließlich beispielhaft das Protokollfeld, Feld für Typ des Dienstes ("TOS") oder Quell/Zielportnummer. Darüberhinaus können Paketattribute über jedes Paket anders als die im Paketheader vorgegebenen auch im Regelsatz beziehungsweise den Regelsätzen spezifiziert sein, in welchem Fall als Reaktion der Netzwerkmonitor NMX das erfaßte Paket auswertet, um zu bestimmen, ob das vorgegebene Attribut erfüllt ist. In jedem Fall, wenn keine Regel erfüllt ist, geht das Verfahren 40 an den Anfang von Schritt 42 zurück, um das Erfassen eines nächsten Pakets zu erwarten. Wenn jedoch eine Regel (oder Regeln) erfüllt sind, dann wird das Verfahren 40 von Schritt 42 nach Schritt 44 fortgesetzt.
  • Im Schritt 44 speichert der Netzwerkmonitor NMX im Flußspeicher 32 bestimmte Informationen, die das den Regelsatz erfüllende Paket betreffen, das im Schritt 42 erkannt wurde, im Flußspeicher 32, wo die gespeicherten Informationen als Flußtabelle nachgeschlagen werden können. In der bevorzugten Ausführungsform schließen die gespeicherten Paketinformationen ausreichende Daten ein, um später den IDC für das Paket zu bestimmen, wo solche Informationen deshalb die Ankunftszeit des Pakets einschließen. Außerdem identifizieren die gespeicherten Informationen entweder explizit oder implizit, welche Regel(n) des vorliegenden Pakets erfüllt sind. Wenn das vorliegende Paket das erste ist, um eine Regel zu erfüllen, dann wird ein neuer Flußeintrag im Flußspeicher 32 erstellt, der der erfüllten Regel entspricht und das betreffende Paket identifiziert, wohingegen, wenn ein oder mehr vorhergehende Pakete bereits die gleiche Regel erfüllt haben und demzufolge ein Flußeintrag bereits im Flußspeicher 32 für diese Regel erstellt worden ist, dann werden die Informationen aus dem vorliegenden Paket zu diesem Flußeintrag hinzugefügt. Weiterfort und aus Gründen, die später ausführlich aufgeführt sind, können andere Paketinformationen wie zum Beispiel differenzierte Dienstesteuerungspunkte ("DSCP"/differentiated service control points) des Pakets und sein TOS-Feld gespeichert werden. In jedem Fall kann auf die Flußtabelle durch Konsole 30 zugegriffen werden, wie zum Beispiel durch Verwendung des Simple Network Management Protocol ("SNMP"). Nach Schritt 44 wird das Verfahren 40 mit Schritt 46 fortgesetzt.
  • Im Schritt 46 wird der IDC über ein definiertes Zeitintervall t für einen oder mehr Flüsse im Flußspeicher 32 definiert. Wie oben erwähnt ist, kann der IDC entweder durch den RTFM-Zähler 36 des Netzwerkmonitors NMX bestimmt werden oder er kann alternativ durch Konsole 30 als Antwort auf ihren Zugriff auf den Flußspeicher 32 bestimmt werden. In jedem Fall wird nach der IDC-Bestimmung das Verfahren 40 mit Schritt 48 fortgesetzt.
  • Im Schritt 48 wird der von Schritt 46 bestimmte IDC mit einem Schwellwert verglichen, wo in der bevorzugten Ausführungsform der Schwellwert als ein Wert aufgestellt ist, der voraussetzt, daß ein IDC gleich oder größer als der Schwellwert ein Anzeichen der Überlastung im Verkehrsfluss ist, der dem IDC-Wert entspricht. Folglich, wenn der IDC den Schwellwert nicht übersteigt, dann geht das Verfahren 40 von Schritt 48 zu Schritt 42 zurück, um die Erfassung eines anderen Pakets zu erwarten. Wenn jedoch der IDC den Schwellwert übersteigt, dann werden die Pakete, die diesem überhöhten IDC entsprechen, als potentiell Überlastung verursachende Pakete angesehen, und als Antwort auf die Kennzeichnung dieser Pakete wird das Verfahren 40 von Schritt 48 zu Schritt 50 fortgesetzt. Es ist zu beachten, daß diese letztere Richtung des Flusses in verschiedenen Formen implementiert sein kann. Zum Beispiel kann in einer Ausführungsform der Schritt 48 Vergleich durch den Netzwerkmonitor NMX durchgeführt werden, der, falls der IDC den Schwellwert übersteigt, eine Meldung oder anderen Hinweis an Konsole 30 ausgibt, um den Paketfluß zu identifizieren, der dem überhöhten IDC entspricht. Ebenfalls in diesem Fall berichtet der Netzwerkmonitor NMX vorzugsweise andere Informationen, die gleichen Pakete betreffend, wie zum Beispiel DSCPs oder TOS des Pakets. In einer alternativen Ausführungsform kann die Konsole 30 selbst den Schritt 48 Vergleich durchführen und reagieren, wie im Fluß von 3 gezeigt und wie außerdem unten beschrieben ist.
  • Im Schritt 50, der erreicht worden ist, weil der IDC für einen oder mehr Flüsse den Schwellwert von Schritt 48 übersteigt, bestimmt die Konsole 30 vorzugsweise, ob die Pakete, die dem Fluß entsprechen, der den überhöhten IDC aufweist, die für diese Pakete erforderliche QoS erfüllen. Speziell deshalb, vorausgesetzt, daß bestimmte Paketinformationen (z. B. DSCP, TOS) an die Konsole 30 berichtet worden sind oder durch die Konsole 30 lesbar sind und den potentiell überlastenden Paketen entsprechen, prüft dann die Konsole 30 diese Paketinformationen auf die entsprechenden QoS-Anforderungen für diese Paketflüsse. Mit anderen Worten, unter gegenwärtigen Operationen haben diese Pakete wahrscheinlich die ihnen auferlegten QoS-Anforderungen, und Schritt 48 bestimmt, ob diese QoS erfüllt wird. Außerdem ist in dieser Hinsicht zu beachten, daß die den Paketen auferlegten QoS-Anforderungen in verschiedenen Formen bestimmt werden können, wie zum Beispiel durch Suche nach einer Dienstleistungsvereinbarung ("SLA"/Service Level Agreement), die zwischen einem Internet-Service-Provider ("ISP") und seinem Kunden existiert; mit anderen Worten, Schritt 50 bildet in einem Verfahren die SLA oder Spezifikationen, die dem Kunden garantiert wurden, in einen entsprechenden Satz von QoS-Anforderungen ab, und diese QoS-Anforderungen werden dann mit dem Fluß beziehungsweise den Flüssen verglichen, die einem Schwellwert übersteigendem IDC entsprechen. Wenn die QoS-Anforderungen erfüllt sind, dann geht Verfahren 40 vom Schritt 50 zu Schritt 42 zurück, wohingegen, wenn die QoS-Anforderungen nicht erfüllt sind, dann wird Verfahren 40 vom Schritt 50 zu Schritt 52 fortgesetzt.
  • Im Schritt 52 regelt der Netzwerkmonitor NMX die Verkehrsparameter in einem Versuch nach, um die Überlastung zu reduzieren und um entsprechend die Möglichkeiten zu verbessern, daß die QoS-Anforderungen, die im Zusammenhang mit Schritt 50 diskutiert wurden, zukünftigen Verkehr im identifizierten Fluß erfüllen werden. Zum Beispiel, prüft im Zusammenhang mit dem Netzwerkmonitor NMX eine Funktion, wie zum Beispiel auf ein Routerformungs- und Schedulingmodul verwiesen werden kann, die verfügbaren inneren Ressourcen, um verschiedene Flußwarteschlangen zu optimieren und startet Flußformungsalgorithmen mit dem Ziel, daß für zukünftige Pakete die QoS-Anforderungen erfüllt werden. Es ist zu beachten, daß dieses Modul durch einen Fachmann aufgebaut werden kann, vorausgesetzt die angegebenen Ziele und angesichts der potentiell verfügbaren inneren Ressourcen, die angepaßt werden können, um den Verkehrsfluß zu verbessern. Als ein bevorzugtes Beispiel schließen Router in der Regel verschiedene Pufferspeicher oder Pufferspeicherungsmechanismen bezüglich der empfangenen Pakete ein und von denen Pakete im Netzwerk weitergeleitet werden; auf diese Weise ist ein Typ der Ressource, die angepaßt werden kann, die Neuzuweisung, welche Pakete i welchen Pufferspeichern oder in welchen Abschnitten dieser Pufferspeicher gespeichert werden. Außerdem als Antwort auf die Bestimmung des Routerformungs- und Schedulingmoduls schließt der Netzwerkmonitor NMX ebenfalls vorzugsweise einen Typ der Niederpegelsteuerung im Router ein, der den Fluß auf dem gehenden Datenpaket einstellt, um die Wahrscheinlichkeiten der Verkehrsüberlastung zu reduzieren, wie vorher potentiell durch solche Pakete verursacht wurde. Mit anderen Worten, nach diesen Einstellungen ist es das Ziel der bevorzugten Ausführungsform, daß der IDC für solche Pakete beim Weiterleiten im Netzwerk verringert wird, und ihre QoS-Übereinstimmung verbessert wird. Schließlich ist zu beachten, daß die vorangegangene Diskussion des Nachregelns der Verkehrsparameter durch einen gegebenen Netzwerkmonitor NMX in dem Fall mehr vorzuziehen ist, wenn solch ein Monitor mit einem Router kombiniert wird (z. B. 1, NM5, NM6, NM7), wodurch der Monitor die Einstellung bezüglich seines eigenen entsprechenden Routers vornehmen kann; folglich, wo das Verfahren 40 in selbständigen Netzwerkmonitoren implementiert ist, die nicht Teil eines Routers sind, können diese Monitore nur arbeiten, um Informationen zu sammeln, um die Paketankunftszeit, IDC und möglicherweise QoS-Übereinstimmung zu überwachen, ohne notwendigerweise durch sich selbst ein Nachregeln der Verkehrsparameter zu verursachen.
  • Aus den obigen Abbildungen und der Beschreibung sollte der Fachmann verstehen, daß die bevorzugten Ausführungsformen ein Verfahren der Überwachung des Flusses von Netzwerkpaketen bereitstellen, um potentiell die Überlastung in bestimmten Paketen zu erkennen, wo der Anwendungsbereich der untersuchten Pakete durch einen oder mehr Regelsätze spezifiziert ist, die an einen Zähler bereitgestellt werden, und wo der Zähler vorzugsweise eine Echtzeitvorrichtung ist.
  • Die Ausführungsformen bieten zahlreiche Vorteile gegenüber dem Stand der Technik. Als ein Beispiel im Gegensatz zum TCP-Verfahren, in welchem die Bandbreite erhöht wird, um Überlastung zu verursachen, arbeitet die bevorzugte Ausführungsform in einem passiveren Sinne, um keine Überlastung zu verursachen. Als ein anderes Beispiel kann jeder Netzwerkzähler unabhängig arbeiten, um mögliche Überlastung einzuschätzen und ohne Abhängigkeit von der Integrität eines verschiedenen Routers oder der Verbindungen mit solch einem Router. Als noch ein anderes Beispiel eines Vorteils, im Gegensatz zu aktiven Systemen des Standes der Technik, senden die bevorzugten Ausführungsformen keine speziellen Testpakete (z. B. PING) und bringen keinen zusätzlichen Testverkehr auf der Route der regulären Datenpakete ein. Folglich wirken sich in diesem Sinne die bevorzugten Ausführungsformen nicht auf die Netzwerk-Performance aus. Als ein anderes Beispiel eines Vorteils, verglichen mit den herkömmlichen passiven Messungsmechanismen, in denen die IP-Pakete (oder Abschnitte davon) routinemäßig gespeichert werden und dann später unter Verwendung der Offline-Analyse von Stammdaten untersucht werden, verwenden die bevorzugten Ausführungsformen Echtzeit-RTFM-Zähler, um Paketinformationen von Paketen wiederzugewinnen, wie sie während des tatsächlichen Echtzeit-Verkehrsflusses entstanden sind, und um Abschnitte dieser Pakete zu speichern; diese gespeicherten Daten werden ebenfalls vorzugsweise in Echtzeit oder fast Echtzeit verwendet, wie zum Beispiel in der Größenordnung kleiner als eine Sekunde beim Erfassen der Paketinformationen, um zu erkennen, ob Verkehrsüberlastung in den identifizierten Flüssen auftritt und um Korrekturmaßnahme(n), falls notwendig, zu ergreifen. Als noch ein anderes Beispiel eines Vorteils für eine Management-Informationsdatenbank ("MIB") des Standes der Technik, stellt sie in der Regel die Einzelpunktanalyse bereit, die auf den Verkehrsfluß am Standort der MIB gerichtet ist. Im Gegensatz ziehen die bevorzugten Ausführungsformen das Auswerten der erfaßten Echtzeit-Paketinformationen von mehrfachen Punkten im Netzwerk vor und sie sind nicht auf den Hardwaretyp oder Hersteller jedes Routers eingeschränkt. Weiterfort stellen die bevorzugten Ausführungsformen ebenfalls zahlreiche Vorteile bereit, die von den folgenden wesentlichen Vorteile der RTFM-Zählerarchitektur weitergegeben werden: (1) alle Daten im IP-Netzwerk sind registrierbar; (2) funktional sogar, wenn die gegebenen Netzelemente nicht imstande sind, Flußüberwachung durchzuführen; (3) Unabhängigkeit von Technologien der Bitübertragungsschicht und Datenübertragungsschicht; und (4) gute Performance sogar während Störungszuständen. In allen Fällen sollten die vorhergehenden sowie andere Vorteile vom Fachmann verstanden werden. Als ein zusammenfassender Vorteil, während die bevorzugten Ausführungsformen besonders vorteilhaft in IP-Netzwerken sind, können sie ebenfalls auf zahlreiche andere Netzwerke angewendet werden. Außerdem, während die vorliegenden Ausführungsformen detailliert beschrieben worden sind, könnten verschiedene Substitutionen, Modifikationen oder Änderungen an den oben dargelegten Beschreibungen gemacht werden, ohne vom erfinderischen Anwendungsbereich abzuweichen, der durch die folgenden Patentansprüche definiert ist.
    Bezugszeichen Englisch Deutsch
    FIG. 1
    FIG. 2
    34 RECORDER-SCHICHT
    36 RTFM-ZÄHLER
    CORE NETWORK/ROUTER CORE-NETZWERK/ROUTER
    FIG. 3
    42 PAKET ERFASSEN; PAKET ERFÜLLT REGEL IN REGELSATZ (REGELSÄTZEN)
    YES JA
    44 PAKETINFORMATIONEN SPEICHERN, EINSCHLIEßLICH ANKUNFTSZEIT, IM FLUß ENTSPRECHEND DER (DEN) ERFÜLLTEN REGEL(N)
    46 FÜR DEFINIERTES INTERVALL t IDC FÜR JEDEN FLUß BESTIMMEN
    NO NEIN
    48 IDC > SCHWELLWERT?
    YES JA
    50 QoS ERFÜLLT FÜR SCHWELLWERT ÜBERSTEIGENDES PAKET BZW. PAKETE?
    YES JA
    NO NEIN
    52 VERKEHRSPARAMETER NACHSTELLEN

Claims (10)

  1. Ein Netzwerküberwachungssystem (10) zur Überwachung eines Netzwerks (20), in dem Netzverkehr in Form von Paketen fließt, umfassend: die Schaltungsanordnung (36) zum Empfangen eines allgemeinen Pakets, das über das Netzwerk (20) übertragen wurde; und die Schaltungsanordnung (36) zum Bestimmen einer Größe (IDC), die über ein definiertes Zeitintervall (t) bestimmt wird und ein Verhältnis der Paketankunftvarianz und einer mittleren Paketankunftsrate während des Zeitintervalls (t) umfaßt, dadurch gekennzeichnet, daß das Netzwerküberwachungssystem (10) außerdem umfaßt: die Schaltungsanordnung (36) zum Bestimmen, ob das empfangene Paket ein Bedingungsmuster erfüllt; die Schaltungsanordnung (36) zum Vergleichen der Größe mit einem Schwellwert; und die Schaltungsanordnung (36), die auf die Größe (IDC) reagiert, die den Schwellwert übersteigt, um die Netzressourcen einzustellen; daß die Größe (IDC) dem Bedingungsmuster entspricht; und daß die Schaltungsanordnung (36) zum Bestimmen der Größe (IDC) auf eine Bestimmung reagiert, daß das empfangene Paket das Bedingungsmuster erfüllt.
  2. Das System nach Anspruch 1 und außerdem umfassend die Schaltungsanordnung (36) zum Bestimmen, ob das empfangene Paket mit einem Muster entsprechender Güteanforderungen übereinstimmt, die dem Paket auferlegt sind, in welchem die Schaltungsanordnung zum Einstellen außerdem auf das empfangene Paket reagiert, das nicht mit dem entsprechenden Muster der Güteanforderungen übereinstimmt.
  3. Das System nach Anspruch 1: in welchem das Paket ein Paket in einer Vielzahl von Paketen umfaßt, die über das Netzwerk (20) übertragen wurden; in welchem die Schaltungsanordnung (36) zum Empfangen außerdem zum Empfangen jedes Pakets in der Vielzahl der Pakete ist; in welchem die Schaltungsanordnung (36) zum Bestimmen, ob das empfangene Paket ein Bedingungsmuster erfüllt, zum Bestimmen ist, ob jedes empfangene Paket ein Bedingungsmuster erfüllt; in welchem die Schaltungsanordnung (36) zum Bestimmen einer Größe außerdem auf eine Bestimmung reagiert, daß jedes empfangene Paket das Muster erfüllt, und für jedes Paket, das das Muster erfüllt, die Schaltungsanordnung zum Bestimmen einer Größe (IDC) zum Bestimmen einer jeweiligen Größe (IDC) ist, die dem Muster entspricht, in welcher die jeweilige Größe (IDC) über ein definiertes Zeitintervall (t) bestimmt wird und ein Verhältnis der Paketankunftvarianz und einer mittleren Paketankunftsrate während des Zeitintervalls (t) umfaßt; in welchem die Schaltungsanordnung (36) zum Vergleichen außerdem zum Vergleichen jeder jeweiligen Größe (IDC) mit einem Schwellwert ist; und in welchem die Schaltungsanordnung zum Einstellen der Netzressourcen außerdem auf eine jeweilige Größe (IDC) reagiert, die den Schwellwert übersteigt.
  4. Das System nach Anspruch 1: und außerdem eine Vielzahl von Monitoren umfassend; in welchem ein erster Monitor in der Vielzahl der Monitore die Schaltungsanordnung (36) zum Empfangen und die Schaltungsanordnung (36) zum Bestimmen, ob das empfangene Paket ein Bedingungsmuster erfüllt, umfaßt; in welchem jeder Monitor in der Vielzahl der Monitore umfaßt: die Schaltungsanordnung (36) zum Empfangen eines Pakets, das über das Netzwerk übertragen wurde; und die Schaltungsanordnung (36) zum Bestimmen, ob das empfangene Paket ein Bedingungsmuster erfüllt.
  5. Das System nach Anspruch 4, in welchem jeder Monitor in der Vielzahl der Monitore außerdem umfaßt: die Schaltungsanordnung (36), die auf eine Bestimmung reagiert, daß ein empfangenes Paket für den jeweiligen Monitor das Muster erfüllt, zum Bestimmen einer Größe (IDC), die dem Muster entspricht, in welcher die Größe über ein definiertes Zeitintervall (t) bestimmt wird und ein Verhältnis der Paketankunftvarianz und einer mittleren Paketankunftsrate während des Zeitintervalls (t) umfaßt; die Schaltungsanordnung (36) zum Vergleichen der Größe (IDC) mit einem Schwellwert; und die Schaltungsanordnung (36), die auf die Größe reagiert, die den Schwellwert übersteigt, um die Netzressourcen einzustellen.
  6. Ein Verfahren (40) des Betreibens eines Netzwerküberwachungssystems (10) zur Überwachung eines Netzwerks (20), über das Netzverkehr in einer Form von Paketen fließt, umfassend: das Empfangen (42) eines allgemeinen Pakets, das über das Netzwerk übertragen wurde (20), und das Bestimmen (46) einer Größe (IDC) über ein definiertes Zeitintervall (t), umfassend ein Verhältnis der Paketankunftvarianz und einer mittleren Paketankunftsrate während des Zeitintervalls (t), dadurch gekennzeichnet, daß das Verfahren außerdem umfaßt: das Bestimmen (42), ob das empfangene Paket ein Bedingungsmuster erfüllt; wobei das Bestimmen (46) der Größe (IDC) über das definierte Zeitintervall (t) auf eine Bestimmung (42) reagiert, daß das empfangene Paket das Bedingungsmuster erfüllt; das Vergleichen (48) der Größe (IDC) mit einem Schwellwert; und (52) auf die Größe reagiert, die den Schwellwert übersteigt, um die Netzressourcen einzustellen.
  7. Das Verfahren (40) nach Anspruch 6 und außerdem umfassend das Bestimmen (50), ob das empfangene Paket mit einem Muster entsprechender Güteanforderungen übereinstimmt, die dem Paket auferlegt sind, in welchem der Einstellungsschritt außerdem auf das empfangene Paket reagiert, das nicht mit dem entsprechenden Muster der Güteanforderungen übereinstimmt.
  8. Das Verfahren (40) nach Anspruch 7, in welchem das empfangene Paket ein IP-Paket umfaßt und in welchem die Güteanforderungen die QoS umfassen.
  9. Das Verfahren (40) nach Anspruch 7, in welchem das Bedingungsmuster mindestens ein Kriterium betrifft, das aus einem Muster ausgewählt ist, das aus der Quelladresse und der Zieladresse besteht.
  10. Das Verfahren (40) nach Anspruch 7, in welchem das Bedingungsmuster die Quelladresse, Zieladresse, Protokollfeld, Typ des Dienstfeldes, Quellportnummer und/oder Zielportnummer betrifft.
DE60318539T 2002-11-07 2003-11-05 Netzwerküberwachungssystem, das auf Veränderungen der Variant und des Mittelwertes der Paketankunftszeiten reagiert Expired - Lifetime DE60318539T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US42449502P 2002-11-07 2002-11-07
US424495P 2002-11-07
US10/412,127 US7242668B2 (en) 2002-11-07 2003-04-11 Network monitoring system responsive to changes in packet arrival variance and mean
US412127 2003-04-11

Publications (2)

Publication Number Publication Date
DE60318539D1 DE60318539D1 (de) 2008-02-21
DE60318539T2 true DE60318539T2 (de) 2009-01-08

Family

ID=32233393

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60318539T Expired - Lifetime DE60318539T2 (de) 2002-11-07 2003-11-05 Netzwerküberwachungssystem, das auf Veränderungen der Variant und des Mittelwertes der Paketankunftszeiten reagiert

Country Status (4)

Country Link
US (1) US7242668B2 (de)
EP (1) EP1422871B1 (de)
AT (1) ATE383696T1 (de)
DE (1) DE60318539T2 (de)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE50112159D1 (de) * 2001-08-09 2007-04-19 Ascom Schweiz Ag Analyse eines Datenübertragungssystems
KR100481130B1 (ko) * 2002-11-08 2005-04-07 주식회사 웨어밸리 데이터베이스 시스템에 접속하지 않고 데이터베이스시스템을 모니터링하는 방법
JP2007525856A (ja) * 2003-04-14 2007-09-06 テルケミー、インコーポレイテッド ネットワーク問題を識別し、場所を特定する特定するシステム
US7558844B1 (en) 2003-05-06 2009-07-07 Juniper Networks, Inc. Systems and methods for implementing dynamic subscriber interfaces
US7689686B2 (en) * 2003-05-30 2010-03-30 Microsoft Corporation Active probing for sustainable capacity estimation of networked dataflows
US7349337B1 (en) * 2003-12-12 2008-03-25 Novell, Inc. Techniques for shaping data transmission rates
US7546367B2 (en) 2004-01-15 2009-06-09 Novell, Inc. Methods and systems for managing network traffic by multiple constraints
WO2005109754A1 (en) * 2004-04-30 2005-11-17 Synematics, Inc. System and method for real-time monitoring and analysis for network traffic and content
US20060056308A1 (en) * 2004-05-28 2006-03-16 International Business Machines Corporation Method of switching fabric for counteracting a saturation tree occurring in a network with nodes
JP4654707B2 (ja) * 2005-02-18 2011-03-23 日本電気株式会社 ボトルネック検出システム、測定対象サーバ、ボトルネック検出方法およびプログラム
US20060203730A1 (en) * 2005-03-14 2006-09-14 Zur Uri E Method and system for reducing end station latency in response to network congestion
US9197533B1 (en) * 2005-05-09 2015-11-24 Cisco Technology, Inc. Technique for maintaining and enforcing relative policies with thresholds
US7962616B2 (en) * 2005-08-11 2011-06-14 Micro Focus (Us), Inc. Real-time activity monitoring and reporting
US8842555B2 (en) 2005-10-21 2014-09-23 Qualcomm Incorporated Methods and systems for adaptive encoding of real-time information in packet-switched wireless communication systems
FR2894741B1 (fr) * 2005-12-08 2009-12-04 Centre Nat Etd Spatiales Chaine de reception par satellite
US7907526B2 (en) * 2006-05-26 2011-03-15 Telefonaktiebolaget L M Ericsson (Publ) Traffic-triggered setup of label switched paths
US8797850B2 (en) * 2008-01-10 2014-08-05 Qualcomm Incorporated System and method to adapt to network congestion
US8189486B2 (en) * 2008-03-28 2012-05-29 Verizon Patent And Licensing Inc. Method and system for providing holistic, iterative, rule-based traffic management
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
US8391834B2 (en) 2009-01-28 2013-03-05 Headwater Partners I Llc Security techniques for device assisted services
US8340634B2 (en) 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8626115B2 (en) 2009-01-28 2014-01-07 Headwater Partners I Llc Wireless network service interfaces
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
US20100188993A1 (en) 2009-01-28 2010-07-29 Gregory G. Raleigh Network tools for analysis, design, testing, and production of services
US8635335B2 (en) 2009-01-28 2014-01-21 Headwater Partners I Llc System and method for wireless network offloading
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
ES2369800T3 (es) * 2008-08-18 2011-12-07 Abb Technology Ag Análisis de configuración de comunicación en un sistema de control de procesos.
US8203956B1 (en) * 2008-08-28 2012-06-19 Raytheon Bbn Technologies Corp. Method and apparatus providing a precedence drop quality of service (PDQoS)
US8184529B2 (en) * 2008-10-17 2012-05-22 Brother Kogyo Kabushiki Kaisha Communication apparatus, method, and program for transmitting and receiving packet data
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9647918B2 (en) 2009-01-28 2017-05-09 Headwater Research Llc Mobile device and method attributing media services network usage to requesting application
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US9253663B2 (en) 2009-01-28 2016-02-02 Headwater Partners I Llc Controlling mobile device communications on a roaming network based on device state
US9578182B2 (en) 2009-01-28 2017-02-21 Headwater Partners I Llc Mobile device and service management
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US8793758B2 (en) 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US9571559B2 (en) 2009-01-28 2017-02-14 Headwater Partners I Llc Enhanced curfew and protection associated with a device group
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US9351193B2 (en) 2009-01-28 2016-05-24 Headwater Partners I Llc Intermediate networking devices
US9858559B2 (en) 2009-01-28 2018-01-02 Headwater Research Llc Network service plan design
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US9755842B2 (en) 2009-01-28 2017-09-05 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US11973804B2 (en) 2009-01-28 2024-04-30 Headwater Research Llc Network service plan design
US8745191B2 (en) 2009-01-28 2014-06-03 Headwater Partners I Llc System and method for providing user notifications
US11985155B2 (en) 2009-01-28 2024-05-14 Headwater Research Llc Communications device with secure data path processing agents
US10057775B2 (en) 2009-01-28 2018-08-21 Headwater Research Llc Virtualized policy and charging system
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US20110142058A1 (en) * 2009-12-10 2011-06-16 Telcordia Technologies, Inc. Bridge protocol for flow-specific messages
TWI428034B (zh) * 2010-07-02 2014-02-21 Univ Nat Chiao Tung 錄製、還原與重播網路流量的方法
CN102347933B (zh) * 2010-07-27 2014-05-14 财团法人交大思源基金会 录制、还原与重播网络流量的方法
US9154826B2 (en) 2011-04-06 2015-10-06 Headwater Partners Ii Llc Distributing content and service launch objects to mobile devices
US8631154B2 (en) 2011-06-29 2014-01-14 International Business Machines Corporation Dynamically modifying quality of service levels for resources in a networked computing environment
JP2014131212A (ja) * 2012-12-28 2014-07-10 Fujitsu Ltd 検証プログラム及び情報処理装置
US9203705B2 (en) * 2013-02-28 2015-12-01 Alcatel Lucent Allocation of resources based on constraints and conflicting goals
US9331925B2 (en) * 2013-03-12 2016-05-03 Cisco Technology, Inc. Multiple test site bandwidth limit measurement
WO2014159862A1 (en) 2013-03-14 2014-10-02 Headwater Partners I Llc Automated credential porting for mobile devices
US20140351414A1 (en) * 2013-05-24 2014-11-27 Alcatel Lucent Systems And Methods For Providing Prediction-Based Dynamic Monitoring
US9699323B2 (en) * 2013-06-28 2017-07-04 Alcatel Lucent Separate charging for supplemental content in a data flow
JP2016184824A (ja) * 2015-03-25 2016-10-20 富士通株式会社 パケット解析プログラム、パケット解析装置およびパケット解析方法
US11138547B2 (en) * 2017-10-02 2021-10-05 Hand Held Products, Inc. Bi-modal communication system for secure goods tracking and methods of using the same
US11510220B2 (en) * 2017-11-24 2022-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Location aware scheduling
US10735529B2 (en) * 2017-12-07 2020-08-04 At&T Intellectual Property I, L.P. Operations control of network services
US11146465B2 (en) 2019-04-03 2021-10-12 Global Wireless Solutions, Inc. Determining wireless network performance

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5343465A (en) * 1993-06-11 1994-08-30 Bell Communications Research, Inc. Method and system for real-time burstiness analysis of network traffic
US5570346A (en) * 1994-12-08 1996-10-29 Lucent Technologies Inc. Packet network transit delay measurement system
IL141855A0 (en) * 2001-03-07 2002-03-10 Onetiercommunications Inc A method and apparatus for providing an improved quality of service for data transfer over the internet

Also Published As

Publication number Publication date
US20040090923A1 (en) 2004-05-13
EP1422871B1 (de) 2008-01-09
EP1422871A2 (de) 2004-05-26
US7242668B2 (en) 2007-07-10
DE60318539D1 (de) 2008-02-21
EP1422871A3 (de) 2006-04-05
ATE383696T1 (de) 2008-01-15

Similar Documents

Publication Publication Date Title
DE60318539T2 (de) Netzwerküberwachungssystem, das auf Veränderungen der Variant und des Mittelwertes der Paketankunftszeiten reagiert
DE69927252T2 (de) Auf der Überwachung der Belegung von Puffern basierte Planung der Netzwerkkapazität
DE602004008267T2 (de) Übertragung von überwachungspaketen zur steuerung von überlastung und verbindungsaufbau in paketbasierten netzen mit begrenzter bandbreite
DE602004004863T2 (de) Verteilte Architektur zur Echtzeit - Flussmessung auf der Ebene einer Netzwerkdomäne
DE60031776T2 (de) Verfahren und vorrichtung für ein kommunkationsnetz
DE60317588T2 (de) Verfahren zur Ermittlung der peer-to-peer Servicequalität (QOS)
DE19983761B3 (de) Vorrichtung und Verfahren zum Sammeln und Analysieren von Kommunikationsdaten
DE602005003893T2 (de) Verfahren und Vorrichtung zur nicht-intrusiven Messung der Verzögerungsänderung von Datenverkehr in Kommunikationsnetzwerken
DE602005001965T2 (de) Methodologie und Protokolle für Hochgeschwindigkeitsverkehrmessung und Analyse
DE69736399T2 (de) Verfahren und vorrichtung zur messung des spitzen durchsatzes in datenpacket-netzwerken
DE69432206T2 (de) Dynamische Bandbreitenabschätzung und Adaption für Datenpaketnachrichtennetze
DE602005002158T2 (de) Lastausgleichtechnik für Verkehrstechnik zwischen Domänen
DE60217361T2 (de) Verfahren und System zur Überlastkontrolle in einem Kommunikationsnetzwerk
DE69607142T2 (de) Verwendung von mehrpunktverbindungsdiensten zur herstellung von rufanzapfungspunkten in einem vermittlungsnetz
DE69725261T2 (de) System zur Übermittlung des Netzwerkverkehrs in einem Kommunikationsnetzwerk
DE69910715T2 (de) ABR Flusssteuerung mit Hilfe eines 1-Bit Überlast-Indikators und eines Wavelet Transformations-Filters
DE102006024965A1 (de) Verfahren zum Messen einer Zeitverzögerungsmetrik und Messsystem
DE202016107454U1 (de) System für die Aufrechterhaltung der Service-Level von Netzwerken
EP1428408A2 (de) Verteilte übermittlung von informationen in einem verbindungslosen, paketorientierten kommunikationsnetz
US7610327B2 (en) Method of automatically baselining business bandwidth
DE602004008726T2 (de) Dynamisches System zur Übertragung von Netzwerküberwachungsdaten an Knoten ausserhalb des Management Systems
DE60105391T2 (de) Verfahren zur dynamischen optimisierung der dienstqualität in einem datenübertragungsnetzwerk
DE60210356T2 (de) Verwalter von Dienststufenübereinkommen in einem Datennetz
DE602004012955T2 (de) Parallele Steuerungsvorrichtungen für den Data Link Layer mit Statistikerfassung in einer Netzwerksvermittlungseinrichtung
DE60210918T2 (de) Verfahren zur Überlastdetektion von IP-Flows über ein drahtloses Netzwerk

Legal Events

Date Code Title Description
8364 No opposition during term of opposition