DE102021119015A1 - Erweiterbare plattform für netzwerkverkehrstechnik zur erhöhung der netzwerkresilienz in cloud-anwendungen - Google Patents

Erweiterbare plattform für netzwerkverkehrstechnik zur erhöhung der netzwerkresilienz in cloud-anwendungen Download PDF

Info

Publication number
DE102021119015A1
DE102021119015A1 DE102021119015.0A DE102021119015A DE102021119015A1 DE 102021119015 A1 DE102021119015 A1 DE 102021119015A1 DE 102021119015 A DE102021119015 A DE 102021119015A DE 102021119015 A1 DE102021119015 A1 DE 102021119015A1
Authority
DE
Germany
Prior art keywords
network
isp
updated
application
network path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021119015.0A
Other languages
English (en)
Inventor
Siddheshwar Mahesh
Markus Flierl
Bryan DiCarlo
Bojan Vukojevic
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.)
Nvidia Corp
Original Assignee
Nvidia Corp
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 Nvidia Corp filed Critical Nvidia Corp
Publication of DE102021119015A1 publication Critical patent/DE102021119015A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • 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/04—Network management architectures or arrangements
    • H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H04L41/0809—Plug-and-play configuration
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • 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/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • 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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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/14—Network analysis or design
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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/06—Generation of reports
    • H04L43/062—Generation of reports related to network traffic
    • 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/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • 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
    • 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/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • 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/12—Network monitoring probes
    • 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
    • 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/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
    • 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/50—Testing arrangements
    • 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/02—Topology update or discovery
    • H04L45/028—Dynamic adaptation of the update intervals, e.g. event-triggered updates
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical 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/302—Route determination based on requested QoS
    • 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/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

In verschiedenen Beispielen überwacht eine erweiterbare Netzwerkverkehrstechnik-Plattform den Netzwerkverkehr und die Anwendungsleistung, um die Kommunikationspfade für den Netzwerkeingang und -ausgang dynamisch zu aktualisieren, um die Leistung der Anwendung - wie beispielsweise einer Cloud Gaming-Anwendung, einer Cloud VR (Virtual Reality)-Anwendung und/oder anderer Arten von Hochleistungsanwendungen zu erhöhen. Steckbare, verteilte, anwendungszentrierte Netzwerküberwacher, Richtlinien-Engines und Netzwerkkonfiguratoren werden an der Netzwerkgrenze implementiert, um eine verminderte Netzwerk- und Anwendungsleistung zu erfassen und das Netzwerk-Routing dynamisch zu aktualisieren, um dem Rechnung zu tragen.

Description

  • HINTERGRUND
  • Netzwerk-Streaming-Anwendungen - wie beispielsweise Cloud Gaming, Cloud Virtual Reality (VR), Remote Workstation und/oder andere Anwendungsarten - können extrem empfindlich gegenüber Netzwerkleistungsparametern wie Latenz, Jitter und Paketverlust sein. Das Routing des Netzwerkverkehrs über das Internet wird in der Regel durch das Border Gateway Protokoll (BGP) erleichtert, aber BGP ist nicht latenz-, verlust- oder überlastungsbewusst, was dazu führt, dass Netzwerkverkehr häufig über suboptimale Pfade geleitet wird. Beispielsweise kann Netzwerkverkehr, der über einen suboptimalen Netzwerkpfad geleitet wird - z.B. über eine beliebige Anzahl von autonomen Systemen (AS) -, die Qualität einer Anwendungserfahrung beeinträchtigen und dadurch die Reaktionsfähigkeit des Spiels aufgrund von Verzögerungen, Latenz, Stottern, Frame-Drops und/oder dergleichen verringern.
  • Ein herkömmlicher Ansatz für das Verkehrsrouting ist Multihoming mit zwei oder mehr verschiedenen Internetdienstanbietern (ISPs), so dass bei Ausfall eines ISPs ein anderer ISP genutzt werden kann, um eine Verbindung aufrechtzuerhalten. Doch selbst mit Multihoming kann es vorkommen, dass kein optimaler oder besserer Pfad gewählt wird, wenn zwei oder mehr der ISPs scheinbar in Betrieb sind, wenn auch unter beeinträchtigten Bedingungen. Beispielsweise können einige ISPs „schwarze Löcher“ im Netzwerk verursachen, bei denen der ISP einen Pfad zu einem Netzwerk oder AS ankündigt, aber Nachrichten innerhalb des AS des Internetdienstanbieters stillschweigend fallen lässt, wenn der angekündigte Pfad gewählt wird. Bei der Implementierung einer hybriden Cloud - z.B. unter Verwendung öffentlicher und privater Clouds - kann es bei Anwendungen und Diensten, die auf die hybride Cloud angewiesen sind, zu Ausfällen kommen, wenn diese „schwarzen Löcher“ auftreten. Selbst in konventionellen Multihomed-Systemen kann eine Identifizierung dieser Ereignisse unentdeckt bleiben und somit die Belastbarkeit bzw. Resilienz des Netzes verringern.
  • Einige herkömmliche Systeme implementieren benutzerdefinierte Traffic-Engineering- bzw. Verkehrstechnik-Lösungen mit ihren eigenen proprietären software-definierten Netzwerk (SDN; software-defined networking)-Controllern. Beispielsweise können Monitore bzw. Überwacher (oder Agenten) den Netzwerkverkehr überwachen, um zu bestimmen, ob Aktualisierungen der Netzwerkpfade vorgenommen werden sollten. Diese Netzwerküberwacher sind jedoch weder anwendungsspezifisch noch einbindbar bzw. plugin-fähig, wodurch ihre Effektivität und Erweiterbarkeit zur Optimierung des Netzwerkverkehr-Routings auf Anwendungsbasis einschränkt. Infolgedessen können Aktualisierungen des Netzwerkverkehrs Verkehr so umleiten, dass die Kriterien der Überwacher erfüllt werden, aber die Kriterien tatsächlich in einer Nettoverringerung der Dienstgüte (QoS) für bestimmte Anwendungen resultieren können, da die Überwacher nicht darauf zugeschnitten sind, anwendungsbezogene Daten zu verarbeiten und/oder Aktualisierungen des Netzwerkroutings vorzunehmen, die für den unterstützten Anwendungstyp vorteilhaft sind.
  • KURZBESCHREIBUNG
  • Ausführungsformen der Erfindung beziehen sich auf eine erweiterbare Netzwerkverkehrstechnik-Plattform zur Erhöhung der Netzwerkbelastbarkeit in Cloud-Anwendungen. Es werden Systeme und Verfahren offenbart, die den Netzwerkverkehr und die Anwendungsleistung überwachen, um Kommunikationspfade für Netzwerkeingang und -ausgang dynamisch zu aktualisieren, um die Leistung einer Anwendung - wie z.B. einer Cloud Gaming-Anwendung, einer Cloud-Anwendung für virtuelle Realität (VR), einer Remote Workstation-Anwendung und/oder anderen Cloud-, Streaming- oder Hochleistungsanwendungsarten - zu erhöhen.
  • Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, nutzen die vorliegenden Systeme und Verfahren einbindbare bzw. plugin-fähige, anwendungszentrierte Netzwerküberwacher, Richtlinien-Engines und Netzwerkkon-figuratoren zur Verbesserung der Anwendungsleistung. Die Überwacher, Richtlinien-Engines und/oder Netzwerkkonfiguratoren können am Rande implementiert sein und sind unabhängig von der physischen Topologie eines internen Netzwerks, wodurch die vorliegende Verkehrstechnik-Lösung plugin-fähig und anpassbar ist. Beispielsweise können Netzwerküberwacher über ein Netzwerk oder in einer hybriden Cloud verteilt und so programmiert sein, dass sie anpassbare Netzwerkleistungsmetriken (z.B. Verlust, Latenz, Jitter usw.) und/oder Anwendungsleistungsmetriken (z.B. Ertrag bzw. Ergebnis von Spielestreamsitzungen, QoS (Quality of Service)-Metriken der Anwendung usw.) überwachen. Die überwachten Daten können dann verwendet werden, um eine verschlechterte Netzwerkleistung, weiche Fehler (z.B. „schwarze Löcher“), Flapping und/oder eine verschlechterte Anwendungsleistung zu erfassen. Diese Leistungsprobleme können von Richtlinien-Engines analysiert werden, die dazu angepasst sind, die Ausgaben oder Ermittlungen zugehöriger Überwacher zu verarbeiten, um das Netzwerk-Routing mit adaptiven, verzögerten Rückkopplungsmechanismen dynamisch zu steuern - z.B. um Dämpfung durch Internetdienstanbieter bzw. Internet Service Provider (ISPs), Qualitätsprobleme mit mehreren Pfadaktualisierungen über kurze Zeiträume und/oder dergleichen zu vermeiden. Beispielsweise können die Richtlinien-Engines bestimmte Netzwerk- und/oder Anwendungsleistungsmetriken bzw. -kennzahlen mit einem oder mehreren Bewertungskriterien - z.B. Leistungsschwellenwerten einer beliebigen Anzahl alternativer Pfade - vergleichen, um zu bestimmen, ob und/oder wie Netzwerkkonfigurationseinstellungen oder -kriterien zu aktualisieren sind. Im Ansprechen auf Bestimmungen der Richtlinien-Engines können Netzwerkkonfiguratoren das Routing eingehenden Datenverkehr (z.B. durch Voranstellen von AS-Informationen in den Paket-Headern, um suboptimale Routen zu bestrafen) und/oder das Routing ausgehenden Datenverkehrs (z.B. durch Aktualisieren der Gewichte lokaler Präferenzen, um den Datenverkehr zu lenken, ohne dass externe Aktualisierungen an Netzwerk-nachbarn erforderlich sind) aktualisieren, um Netzwerkpfade dynamisch neu zu konfigurieren und die Leistung von Zielanwendungen zu steigern.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren für eine erweiterbare Netzwerkverkehrstechnik-Plattform zur Erhöhung der Netzwerkbelastbarkeit in Cloud-Anwendungen werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungen näher beschrieben, wobei:
    • 1 ein Blockdiagramm ist, das ein Netzwerkverkehrstechnik-System veranschaulicht, gemäß einigen Ausführungsformen der Erfindung;
    • 2 ein Ablaufdiagramm ist, das ein Verfahren zur Aktualisierung von Netzwerkeinstellungen auf der Grundlage von Metriken für eine Vielzahl von Kommunikationspfaden zeigt, gemäß einigen Ausführungsformen der Erfindung;
    • 3A-3C beispielhafte Darstellungen von Netzwerkroutingproblemen zeigen, die zu einer Verschlechterung der Anwendungs- oder Netzwerkleistung führen, gemäß einigen Ausführungsformen der Erfindung;
    • 4-5 Ablaufdiagramme sind, die Verfahren zur Aktualisierung des Netzwerkverkehr-Routings auf der Grundlage von überwachten Netzwerkleistungsparametern zeigen, gemäß einigen Ausführungsformen der Erfindung;
    • 6 ein Ablaufdiagramm ist, das ein Verfahren zur Aktualisierung des Netzwerkverkehr-Routings auf der Grundlage von überwachten Anwendungsleistungsparametern zeigt, gemäß einigen Ausführungsformen der Erfindung;
    • 7 ein Blockdiagramm ist eines beispielhaften Spiele-Streaming-Systems, das zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist; und
    • 8 ein Blockdiagramm ist eines beispielhaften Computergeräts, das zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung ist.
  • DETAILLIERTE BESCHREIBUNG
  • Es werden Systeme und Verfahren im Zusammenhang mit einer erweiterbaren Netzwerkverkehrstechnik-Plattform zur Erhöhung der Netzwerk-Resilienz bei Hochleistungsanwendungen offenbart. Die hierin beschriebenen Systeme und Verfahren können ein für beliebiges Erhöhen der Netzwerk-Resilienz in beliebigen Anwendungstypen implementiert werden, wie z.B., ohne darauf beschränkt zu sein, Streaming, Cloud Gaming, Cloud Virtual Reality (VR), Remote Workstation-Anwendungen, Anwendungen für die gemeinsame Zusammenarbeit, Machine Learning-Anwendungen und/oder andere Anwendungstypen. Beispielsweise können Anwendungen empfindlich gegenüber verschiedenen Netzwerkleistungsparametern wie beispielsweise Latenz, Verlust und/oder Jitter und/oder Anwendungsleistungsparametern wie beispielsweise Sitzungsleistungsgewinn (engl.: session yield) und/oder Anwendungsqualitätsmetriken bzw.-kennzahlen (QoS) sein. Daher können das hierin beschriebene System und das hierin beschriebene Verfahren in jedem beliebigen System implementiert werden, um die Netzwerk- und Anwendungsleistung für jede beliebige Art von Anwendung zu erhöhen, die über ein oder mehrere Netzwerke - wie beispielsweise das Internet - ausgeführt wird. Darüber hinaus ist, obwohl das Border Gateway Protokoll (BGP) hierin in erster Linie als das Protokoll beschrieben wird, an das Routing-Aktualisierungen oder - Richtlinien gerichtet werden, dies nicht als Beschränkung zu verstehen, und kann jedes beliebige geeignete Protokoll verwendet werden - z.B. das Routing-Informationsprotokoll (RIP), sicheres BGP (sBGP), sicheres Ursprungs-BGP (soBGP; secure origin BGP) usw.
  • In einigen Ausführungsformen kann ein erweiterbares Framework zur Verbesserung der Resilienz von Netzwerkeingangs- und -ausgangspfaden für Rechenzentren - oder anderen Backend-Systemen - unter Verwendung von einbindbaren bzw. plugin-fähigen Netzwerküberwachern, Netzwerkrichtlinien-Engines und/oder Netzwerkkonfiguratoren implementiert sein. Diese plugin-fähigen Komponenten können am Rande bzw. an der Netzwerkgrenze verwaltet werden und somit den Netzwerkverkehr unabhängig von der internen Netzwerktopologie steuern oder manipulieren. Die Netzwerküberwacher können dazu verwendet werden, eine verschlechterte Netzwerkleistung und/oder Anwendungsleistung zu erfassen und diese Informationen in einem für die Netzwerkrichtlinien-Engine verständlichen Format - z.B. im NPI (Network Path Info)-Datenformat - an die Netzwerk-richtlinien-Engine weiterzuleiten. Beispielsweise kann das System eine REST (Representational State Transfer)-Schnittstelle (z.B. API) für externe Überwacher bereitstellen, damit die externen Überwacher Netzwerkpfadinformationen veröffentlichen können. Die Überwacher können diese Netzwerkpfadinformationen im NPI-Datenformat veröffentlichen und/oder die Informationen können von einem nativen Eingabeformat des Überwachers in das NPI-Datenformat übersetzt werden. Insoweit kann jeder beliebige Überwacher zu dem System hinzugefügt werden und kann Informationen in einem beliebigen Format veröffentlichen, und können die Daten in ein Format übersetzt werden, das für die Richtlinien-Engine verständlich ist, ohne dass Anpassungen an der Richtlinien-Engine selbst erforderlich sind. Die Netzwerkrichtlinien-Engine kann bestimmen, ob eine Aktualisierung der Kontrollrichtlinien des Systems - z.B. eines oder mehrerer Core-Switches eines Rechenzentrums - auf der Grundlage der Informationen von den Netzwerküberwachern aktualisiert werden sollte. Beispielsweise kann die Netzwerkrichtlinien-Engine Pfadinformationen auswerten, um Netzwerkpfad-aktualisierungen zu bewerten (z.B. ob Änderungen vorgenommen werden sollten oder können oder nicht), und Netzwerkrichtlinien-Aktualisierungsmeldungen an die Netzwerkkonfigurator-Plugins senden.
  • In einigen Ausführungsformen können einzelne Netzwerkrichtlinien-Engine-Überwacher bzw. Netzwerkengine-Überwacher einzelnen Netzwerkrichtlinien-Engines entsprechen, so dass zusätzliche, aktualisierte oder neue Überwacher jederzeit in die erweiterbare Plattform eingebunden werden können, zusammen mit einer entsprechenden Netzwerkrichtlinien-Engine zur Aktualisierung von Netzwerk-Routing-Informationen auf der Grundlage zumindest eines zusätzlichen, aktualisierten oder neuen Netzwerk- oder Anwendungsparameter(s). Beispielsweise können für neue oder andere Anwendungen, die von dem System unterstützt werden sollen - z.B. von einem Rechenzentrum innerhalb des Systems - unterschiedliche Netzwerkparameter und/oder Anwendungsparameter für die Leistung der Anwendung besonders wichtig sein. Daher können dem System anwendungsspezifische Netzwerküberwacher und/oder Richtlinien-Engines hinzugefügt werden, um die Netzwerkleistung und damit die Anwendungsleistung für die Anwendung zu erhöhen. Infolgedessen können in einigen Ausführungsformen Routing-Richtlinien für verschiedene vom System unterstützte Anwendungen unterschiedlich aktualisiert werden, und können die verschiedenen Überwacher, Richtlinien-Engines und/oder Netzwerkkonfiguratoren für jede bestimmte oder aktuelle Anwendung, die auf dem System ausgeführt wird, modifiziert werden.
  • Als weitere Beispiele für die Erweiterbarkeit des vorliegenden Systems können neue oder andere Netzwerküberwacher zu dem System hinzugefügt werden, ohne dass Änderungen an anderen Komponenten des Systems erforderlich sind - wie beispielsweise Richtlinien-Engines, Netzwerkkonfigurationen, Netzwerkgeräte (Switches usw.) und/oder dergleichen. Weil beispielsweise die Netzwerküberwacher so konfiguriert sein können, dass sie Daten in einem gemeinsamen Format an die Richtlinien-Engines ausgeben - und beispielsweise unter Verwendung einer vorhandenen REST-Schnittstelle - können diese neuen oder zusätzlichen Überwacher dem System hinzugefügt werden, um Netzwerkparameter zu testen, ohne dass eine neue Richtlinien-Engine oder ein neuer Netzwerkkonfigurator erforderlich ist, die bzw. der den Überwachern individuell entspricht. Darüber hinaus kann in einigen Ausführungsformen die Erweiterbarkeit und die Flexibilität des Systems ermöglichen, dass neue Switches - oder andere Netzwerkgerätetypen -durch Hinzufügen eines entsprechenden Netzwerkkonfigurators von dem System unterstützt werden, ohne dass Aktualisierungen oder Änderungen an Netzwerküberwachern und/oder Richtlinien-Engines erforderlich sind, die identifizierte Netzwerkinformationen oder Richtlinien-Aktualisierungs-Informationen an die Netzwerkkonfiguratoren übertragen, die ihrerseits wiederum die Netzwerkgeräte aktualisieren. Infolgedessen kann dem System ein neuer Switch oder ein neues Netzwerkgerät hinzugefügt werden, und können die vorhandenen Netzwerküberwacher und Richtlinien-Engines mit dem Netzwerkkonfigurator kommunizieren, der dem neuen Netzwerkgerät entspricht, um jegliche Änderungen an Import- oder Exportkarten oder anderen Routingprotokollen des Netzwerkgeräts zu implementieren.
  • In einigen Ausführungsformen können die Netzwerkrichtlinien-Engines auch dann, wenn eine Änderung der Netzwerk-Routing-Informationen empfohlen wird, frühere Aktualisierungen über ein bestimmtes Zeitfenster - z.B. dreißig Minuten, zwei Stunden usw. - hinweg berücksichtigen. Um z.B. Dämpfungsstrafen von ISPs zu vermeiden, kann die Netzwerkrichtlinien-Engine Aktionen löschen oder ignorieren, die dazu führen würden, dass ISPs innerhalb des Zeitfensters öfter als eine bestimmte Schwellenanzahl umgeschaltet bzw. gewechselt werden. Um zu vermeiden, dass Netzwerkaktualisierungen über das interne Netzwerk eines Rechenzentrums hinaus veröffentlicht werden, können beispielsweise BGP-Lokalpräferenzgewichte verwendet werden, um ausgehenden Netzwerkverkehr zu leiten. In einigen Fällen, wie beispielsweise dann, wenn Aktualisierungen eingehenden Datenverkehrs erforderlich sind - z. B. wenn ein fallkritisches Ziel-BGP-Autonomsystem (AS) in einen Netzwerkpfad aufzunehmen ist -, können Export-Routenkarten jedoch aktualisiert werden, um eingehenden Datenverkehr von außerhalb des internen Netzwerks eines Rechenzentrums zu steuern.
  • Sobald Kriterien für die Aktualisierung des Netzwerk-Routings festgelegt sind - z.B. für den Wechsel von einem aktuellen Internetdienstanbieter (ISP) zu einem anderen ISP, für die Aktualisierung von Export-Routenkarten, für die Aktualisierung von Import-Routenkarten und/oder für andere Aktualisierungen - können diese Informationen in einem für die Netzwerkkonfiguratoren verständlichen Format (z.B. im Netzwerkrichtlinienaktualisierungs (NPU; network policy update)-Format an die Netzwerkkonfiguratoren gesendet werden. Infolgedessen können die Netzwerkkonfiguratoren Aktualisierungen der Richtlinien für ein oder mehrere Netzwerkgeräte (z.B. Switches und/oder Router) bestimmen und die Routing-Aktualisierungen an den Zielnetzwerkendpunkten implementieren. Beispielsweise kann der Netzwerkkonfigurator einem Core-Switch-Konfigurator entsprechen, mit dem ein lokaler Präferenzwert des Border Gateway Protokolls (BGP) für einen bestimmten ausgehenden Port des Core-Switches aktualisiert werden kann, um Verkehr durch einen bestimmten oder gewünschten ISP zu erzwingen. Letztendlich können die Netzwerk-Routing-Konfigurationen, Präferenzen und/oder Richtlinien aktualisiert werden, um Verkehr über gewünschte Pfade zu schieben und so die Leistung einer auf einem Endbenutzergerät ausgeführten Anwendung zu steigern.
  • Mit Bezug auf 1 ist 1 ein beispielhaftes Blockdiagramm eines Netzwerkverkehrstechnik-Systems 100 (hierin alternativ als „System 100“ bezeichnet), gemäß einigen Ausführungsformen der Erfindung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele dienen. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hierin beschriebenen Elemente funktionelle Entitäten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hierin beschriebene Funktionen, die von Entitäten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen können eine oder mehrere Komponenten, Merkmale und/oder Funktionalitäten des Systems 100 denen des beispielhaften Spiel-Streaming-Systems 700 von 7 und/oder des beispielhaften Rechengeräts 800 von 8 ähnlich sein.
  • Das System 100 kann ein oder mehrere Hostvorrichtungen 102, ein oder mehrere Unterstützungsvorrichtungen 104 und/oder ein oder mehrere Client-Geräte 106 umfassen, die über das Internet 108 über einen oder mehrere Internet Service Provider (ISPs), wie z.B. Transit-ISPs 110A und 11 OB, einen Unterstützungs-ISP 112 und/oder einen Client-ISP 114, kommunizieren. In einigen Ausführungsformen kann das System 100 einer Cloud Computing- und/oder einer verteilten Rechenumgebung entsprechen. Wenn die Host-Anwendung 126 beispielsweise einer Cloud Gaming-Anwendung entspricht, kann das beispielhafte Spiel-Streaming-System 700 von 7 eine geeignete Architektur oder Plattform zur Unterstützung der Cloud Gaming-Anwendung umfassen.
  • Die Transit-ISPs 110 können den Zugang zum Internet (oder einem anderen WAN) für das/die Host-Vorrichtung(en) 102 bereitstellen, der Unterstützungs-ISP 112 kann den Zugang zum Internet für das/die Unterstützungsvorrichtung(en) 104 bereitstellen, und der Client-ISP 114 kann den Zugang zum Internet für das/die Client-Gerät(e) 106 bereitstellen. In einigen Ausführungsformen können einer oder mehrere der Transit-ISPs 110, der Unterstützungs-ISP 112 und/oder der Client-ISP 114 ein und derselbe ISP sein, während in anderen Ausführungsformen einer oder mehrere der ISPs 110, 112 und/oder 114 verschieden sein können. Darüber hinaus können dann, wenn mehr als eine Host-Vorrichtung 102 implementiert ist, verschiedene Host-Vorrichtungen 102 verschiedene Transit-ISPs 110 verwenden, können dann, wenn mehr als eine Unterstützungsvorrichtung 104 implementiert ist, verschiedene Unterstützungsvorrichtungen 104 verschiedene Unterstützungs-ISPs 112 verwenden, und/oder können dann, wenn mehr als ein Client-Gerät 106 implementiert ist, verschiedene Client-Geräte 106 verschiedene Client-ISPs 114 verwenden.
  • Obwohl als das Internet 108 bezeichnet, ist dies nicht als beschränkend anzusehen, und kann das System 100 für beliebige Netzwerktypen implementiert werden, wie z.B. für Weitverkehrsnetze (WANs), lokale Netze (PANs), andere Netzwerktypen oder eine Kombination davon. Obwohl das/die Host-Vorrichtung(en) 102 als multihomed dargestellt ist/sind - z.B. mit zwei Transit-ISPs 110 - soll dies nicht beschränkend sein, und können in einigen Ausführungsformen das/die Unterstützungsvorrichtung(en) 104 und/oder das/die Client-Gerät(e) 106 ebenfalls multihomed sein. Darüber hinaus soll, obwohl nur eine einzige Verbindung durch jeden ISP dargestellt ist, dies nicht beschränkend sein, und kann in einigen Ausführungsformen ein einzelner ISP - wie beispielsweise der Transit-ISP 110A - eine Vielzahl von separaten Routen oder Edge-Router-Zugangspunkten oder Knoten für das/die Host-Vorrichtung(en) 102 beinhalten. In einigen Ausführungsformen kann dies beispielsweise dann, wenn von einem ISP zu einem anderen umgeschaltet bzw. gewechselt wird, einem Wechsel von einer ersten Route (z.B. über einen ersten Edge-Router des ISP) durch einen ISP zu einer zweiten Route (z.B. über einen zweiten Edge-Router des ISP) durch denselben ISP entsprechen.
  • Das/die Host-Vorrichtung(en) 102 kann/können unter Verwendung z.B. einer oder mehrerer Anwendungsprogrammierschnittstellen (APIs) eine Host-Anwendung 126 hosten - z.B. eine Hochleistungsanwendung, eine Cloud Game-Streaminganwendung, eine Virtual-Reality (VR)-Inhalts-Streaminganwendung, eine Inhalts-Streaminganwendung, eine Remote Desktop-Anwendung usw. Das (die) Host-Vorrichtung(en) 102 kann (können) in einigen Ausführungsformen einem Rechenzentrum entsprechen, so dass das (die) Host-Vorrichtung(en) 102 eine beliebige Anzahl von Untervorrichtungen wie beispielsweise Server, Network Attached Storage (NAS), APIs, andere Backend-Vorrichtungen und/oder eine andere Art von Untervorrichtung umfassen kann (können). Beispielsweise kann das/die Host-Vorrichtung(en) 102 eine Vielzahl von Computergeräten (z.B. Server, Speicher usw.) umfassen, die einige oder alle Komponenten der hierin beschriebenen, beispielhaften Rechenvorrichtung 800 von 8 beinhalten oder diesen entsprechen können. In einigen Ausführungsformen kann die Host-Anwendung 126 unter Verwendung einer oder mehrerer Grafikverarbeitungseinheiten (GPUs) und/oder virtueller GPUs ausgeführt werden, um eine Client-Anwendung 132 zu unterstützen, die auf dem/den Client-Gerät(en) 106 ausgeführt wird. In einigen Ausführungsformen kann zumindest ein Teil der Verarbeitung des/der Host-Vorrichtung(en) 102 parallel unter Verwendung einer oder mehrerer paralleler Verarbeitungseinheiten, wie beispielsweise GPUs, Kerne davon (z.B. CUDA-Kerne), anwendungsspezifische integrierte Schaltungen (ASICs), Vektorprozessoren, massiv parallele Prozessoren, symmetrische Multiprozessoren usw., ausgeführt werden. In Ausführungsformen, in denen das Rendering unter Verwendung der Host-Vorrichtung(en) 102 ausgeführt wird, kann/können die Host-Vorrichtung(en) 102 eine oder mehrere Ray-Tracing- und/oder Path-Tracing-Techniken implementieren, um die Qualität von Bildern und/oder Videos in einem Stream zu erhöhen (z.B. wo das Client-Gerät 106 in der Lage ist, hochauflösende - z.B. 4K, 8K usw. - Grafiken anzuzeigen und/oder die Netzwerkeigenschaften derzeit das Streaming derselben unterstützen).
  • Das (die) Host-Vorrichtung(en) 102 kann (können) ein oder mehrere Netzwerkgeräte 124 umfassen - z.B. Switches, Router, Gateways bzw. Netzübergangseinheiten, Hubs bzw. Netzknoten, Brücken, Zugangspunkte usw. - die so konfiguriert sein können, dass sie den Verkehr innerhalb eines Netzwerks der Host-Vorrichtung(en) 102 leiten, ankommenden oder eingehenden Verkehr aus dem Internet leiten, ausgehenden oder austretenden Verkehr in das Internet leiten und/oder zumindest teilweise das Routing des Netzwerkverkehrs durch verschiedene autonome Systeme des Internets steuern (z.B. über Edge-Router der autonomen Systeme unter Verwendung des BGP-Protokolls). Um beispielsweise eingehenden Verkehr aus dem Internet und/oder ausgehenden Verkehr in das Internet zu leiten, können ein oder mehrere Core-Switches implementiert sein, die als ein Tor bzw. Gateway zum Internet (und/oder einem anderen WAN) dienen. Die Core-Switches können Import-Routenkarten (z.B. für ausgehenden Netzwerkverkehr) und/oder Export-Routenkarten (z.B. für eingehenden Netzwerkverkehr) enthalten, die so konfiguriert sein können, dass sie bei der Weiterleitung des Netzwerkverkehrs helfen, der zu dem/den Host-Vorrichtung(en) 102 kommt und/oder von dem/den Host-Vorrichtung(en) 102 ausgeht. Darüber hinaus können die Routing-Richtlinien der Core-Switches - oder anderer Netzwerkgeräte 124 - lokale Präferenzwerte für bestimmte Ausgangsports und/oder Eingangsports enthalten, die vom System 100 verwendet werden können, um den Datenverkehr über einen bestimmten Pfad zu leiten (z.B. über einen bevorzugten Transit-ISP 110). Obwohl es sich bei den hierin beschriebenen Netzwerkgeräten 124 in erster Linie um Core-Switches handelt, soll dies nicht beschränkend sein, und können die hierin für die Core-Switches beschriebenen Techniken zusätzlich oder alternativ für andere Arten von Netzwerkgeräten 124 implementiert werden, ohne den Anwendungsbereich der Erfindung zu verlassen - wie z.B. Verteiler-Switches, Edge-Switches, Router, Zugangspunkte, Core-Schicht-Geräte, Verteilungsschicht-Geräte, Zugangsschicht-Geräte usw. In einigen Ausführungsformen können einer oder mehrere der Netzwerküberwacher 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder der Netzwerkkonfigurator(en) 120 direkt auf den Core-Switches ausgeführt oder eingesetzt werden - z.B., wenn die Core-Switches oder andere Netzwerkgeräte 124 containerisierte Anwendungen unterstützen.
  • Um die Netzwerkeingangs- und/oder Netzwerkausgangs-Routen von der/den Unterstützungsvorrichtung(en) 104 und/oder dem/den Client-Gerät(en) 106 zu kontrollieren oder zu manipulieren, kann/können ein oder mehrere Routeninjektor(en) 122 Export-Routenkarten, die über das Internet verteilt werden, und/oder Import-Routenkarten, die lokal verwaltet werden, aktualisieren, so dass bestimmte Netzwerkpfade von dem/den Host-Vorrichtung(en) 102, der/den Unterstützungsvorrichtung(en) 104 und/oder dem/den Client-Gerät(en) 106 bevorzugt - und somit implementiert - werden. Zum Beispiel kann/können der/die Routeninjektor(en) 122 für Netzwerkeingangsverkehr bewirken, dass ein oder mehrere autonome Systempräfixe zu bestimmten Pfaden hinzugefügt oder vorangestellt werden (z.B. unter Verwendung von BGP-Headern), so dass diese Pfadaktualisierungen an andere Geräte weitergegeben werden - z.B. an die Unterstützungsvorrichtung(en) 104 und/oder das/die Client-Gerät(e) 106 -, um die von den anderen Geräten bei der Kommunikation mit der/den Host-Vorrichtung(en) 102 ausgewählten Netzwerkpfade zu beeinflussen. Wenn also der Transit-ISP 110A derzeit verwendet wird, aber bestimmt wird, dass der Transit-ISP 110B eine bessere Netzwerk- und/oder Anwendungsleistung hat, können die Export-Routenkarten aktualisiert werden, um den Transit-ISP 110A zu benachteiligen (z.B. um den Anschein zu erwecken, dass eine Route durch ein autonomes System des Transit-ISP 110A schlechter ist oder mehr Sprünge enthält), indem den Export-Routenkarten ein oder mehrere zusätzliche autonome Systempräfixe vorangestellt werden.
  • Für ausgehenden Verkehr können die Import-Routenkarten unter Verwendung lokaler Präferenzwerte aktualisiert werden, um die Anzahl der von außen sichtbaren Netzwerknachrichten zu begrenzen (z.B. brauchen diese Aktualisierungen durch Aktualisierung der lokalen Präferenzwerte nicht an andere Geräte im System 100 weitergegeben zu werden). Da die Import-Routenkarten nicht nach außen sichtbar sind oder weitergegeben werden, können die Parameteraktualisierungen nur den ausgehenden Netzwerkpfad für eine Reihe von Netzwerkrouten beeinflussen. Bei Host-Anwendungen 126, die größtenteils aus ausgehendem Datenverkehr bestehen - wie Streaming, Cloud Gaming usw. - kann die Netzwerkqualität durch interne Änderungen beeinflusst werden, die dem größeren Netzwerk unbekannt sind. In Beispielen, in denen andere Dienste außerhalb der Host-Vorrichtung(en) 102 ausgeführt werden - wie z.B. Steuerebenendienste 130, die auf der/den Unterstützungsvorrichtung(en) 104 ausgeführt werden - können sowohl die Import-Routenkarten als auch die Export-Routenkarten aktualisiert werden, um die Auswahl des Netzwerkpfads für den eingehenden und den ausgehenden Verkehr zu der/den Host-Vorrichtung(en) 102 zu beeinflussen. So können in einem Cloud Gaming-Beispiel Kommunikationspfade zwischen der/den Host-Vorrichtung(en) 102 und dem/den Client-Gerät(en) 106 durch Aktualisierungen der Import-Routenkarten manipuliert werden, während Kommunikationspfade zwischen der/den Host-Vorrichtung(en) 102 und der/den Unterstützungsvorrichtung(en) 104 - z.B. die Ausführung von Authentifizierungsdiensten für die Host-Anwendung 126 - durch Aktualisierungen sowohl der Import-Routenkarten als auch der Export-Routenkarten manipuliert werden können.
  • Um Netzwerk-Routing-Entscheidungen und -Aktualisierungen zu treffen, können ein oder mehrere Netzwerküberwacher 116A-116C, eine oder mehrere Netzwerkrichtlinien-Engines 118 und/oder ein oder mehrere Netzwerkkonfiguratoren 120 implementiert sein. Beispielsweise kann die Kombination aus dem/den Netzwerküberwacher(n) 116, der/den Netzwerkrichtlinien-Engine(s) 118 und/oder dem/den Netzwerkkonfigurator(en) 120 einem Netzwerküberwachungs- und Verkehrssteuerungs-Teilsystem des Systems 100 entsprechen. In einigen Ausführungsformen können der/die Netzwerküberwacher 116, die Netzwerkrichtlinien-Engine(s) 118 und/oder der/die Netzwerkkonfigurator(en) 120 plugin-fähig und anpassbar sein, so dass das Teilsystem auf eine beliebige Anzahl verschiedener kommunikativ gekoppelter Geräte (z. B. zur Überwachung und Steuerung des Datenverkehrs zwischen der/den Host-Vorrichtung(en) 102 und der/den Unterstützungsvorrichtung(en) 104, zwischen der/den Host-Vorrichtung(en) 102 und dem/den Client-Gerät(en) 106, zwischen der/den Host-Vorrichtung(en) 102 und anderen Vorrichtung(en) bzw. Gerät(en) (nicht dargestellt) usw.), auf eine beliebige Anzahl verschiedener Host-Anwendungen 126 (z.B. können verschiedene Netzwerküberwacher 116 und/oder Netzwerkrichtlinien-Engine(s) 118 - oder Netzwerkrichtlinien davon - programmiert und in das System 100 eingebunden werden, um den Datenverkehr zu überwachen und zu steuern, um die Netzwerk- und/oder Anwendungsleistung für bestimmte Anwendungen zu erhöhen), auf eine beliebige Anzahl verschiedener Netzwerkparameter und/oder Anwendungsparameter oder eine Kombination davon erweiterbar ist. Beispielsweise können dann, wenn neue Netzwerküberwachungsgeräte 116 kreiert werden, die Netzwerkrichtlinien-Engine(s) 118 und/oder der/die Netzwerkkonfigurator(en) 120 bestimmt werden, die Zielgeräte oder autonomen Systeme bestimmt werden, die mit der Kommunikation zwischen ihnen verbundenen Netzwerk- und/oder Anwendungsleistungsmetriken bestimmt werden, umsetzbare Schwellenwerte bestimmt werden und Richtlinienaktualisierungen bestimmt werden, wenn Schwellenwerte erreicht oder überschritten werden. Als solche können, mit diesen Kriterien im Hinterkopf, in dem System 100 zusätzliche anwendungszentrierte Netzwerküberwacher 116, Netzwerkrichtlinien-Engine(s) 118 und/oder Netzwerkkonfiguratoren 120 implementiert werden.
  • Zum Beispiel können in einigen Ausführungsformen der/die Netzwerküberwacher 116, die Netzwerkrichtlinien-Engine(s) 118 und/oder der/die Netzwerkkonfigurator(en) 120 containerisierten Anwendungen oder Diensten - oder Instanzen davon - entsprechen. Als solches kann das Teilsystem die Auswahl, Organisation und Bereitstellung (z.B. unter Verwendung virtueller Maschinen (VMs) innerhalb der Host-Vorrichtung(en) 102) von Containern in Netzwerk- und/oder Anwendungsleistungs-Überwachungs- und Verkehrsrouting-Pipelines ermöglichen. Die bereitgestellten Container können Instanziierungen des/der Netzwerküberwacher(s) 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder des/der Netzwerkkonfigurators/en 120 hosten. Beispielsweise können Abbilder bzw. Images des/der Netzwerküberwacher(s) 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder des/der Netzwerkkonfigurators/en 120 (z.B. Container-Abbilder) in einer Container-Registrierung bzw. Container-Registry verfügbar sein, und kann das Abbild, sobald es - z.B. von einem Benutzer, automatisch usw. - für den Einsatz in einer Pipeline ausgewählt wurde, verwendet werden, um einen Container für eine Instanziierung des/der Netzwerküberwacher(s) 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder des/der Netzwerkkonfigurators/en 120 zu erzeugen. Beispielsweise kann ein erster Netzwerküberwacher 116 für eine erste Art von Anwendung, die eine sehr geringe Latenzzeit erfordert, geeignet sein, während ein zweiter Netzwerküberwacher 116 eher für eine zweite Art von Anwendung, die einen geringen Paketverlust erfordert, bei der die Latenzzeit jedoch nicht so wichtig ist, geeignet ist. So kann in Ausführungsformen bei der Konfiguration des Systems 100 für den ersten Anwendungstyp der erste Netzwerküberwacher 116 instanziiert werden - zusätzlich zu einer oder mehreren Netzwerkrichtlinien-Engines 118 und/oder einem oder mehreren Netzwerkkonfiguratoren 120 -, um die Konfiguration des Netzwerk-Routings so zu unterstützen, dass die Latenzzeit verringert wird. Im gleichen Beispiel kann in Ausführungsformen bei der Konfiguration des Systems 100 für den zweiten Anwendungstyp der zweite Netzwerküberwacher 116 instanziiert werden - zusätzlich zu einer oder mehreren Netzwerkrichtlinien-Engine(s) 118 und/oder einem oder mehreren Netzwerkkonfiguratoren 120 -, um die Konfiguration des Netzwerk-Routings so zu unterstützen, dass der Paketverlust verringert wird, selbst wenn die Latenzzeit erhöht wird. Infolgedessen kann dass jede Art von Anwendung wie gewünscht arbeiten und positive Nutzererfahrungen bereitstellen, wohingegen dann, wenn eine herkömmliche feste, anwendungsunabhängigen Netzwerküberwachung durchgeführt wird, mindestens eine der Anwendungsarten unter Netzwerk- und/oder Anwendungsleistungsproblemen leiden würde.
  • In einigen Ausführungsformen können, um eine nahtlose Kommunikation zwischen plugin-fähigen und/oder containerisierten Instanzen des/der Netzwerküberwacher(s) 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder des/der Netzwerkkonfigurators/en 120 zu ermöglichen, Daten, die von jeder der Komponenten des Teilsystems erzeugt werden, so formatiert werden - z.B. anfänglich oder nach der Übersetzung aus einem nativen Format -, dass eine nächste Komponente des Teilsystems die Daten versteht und verarbeiten kann. Darüber hinaus kann in einigen Ausführungsformen das Teilsystem, das den/die Netzwerküberwacher 116, die Netzwerkrichtlinien-Engine(s) 118 und/oder den/die Netzwerkkonfigurator(en) 120 umfasst, zwei oder mehr Instanziierungen zu einem beliebigen Zeitpunkt auf verschiedenen VMs beinhalten, die von verschiedenen Computergeräten (z.B. Servern) innerhalb der Host-Vorrichtung(en) 102 für Hochverfügbarkeit (HA; high availability), Clustering und/oder Redundanz gehostet werden. Infolgedessen kann ein einzelner Knoten als Fehlerpunkt des Teilsystems entfernt werden, so dass Softwareabstürze, Hardwarefehler oder -ausfälle und/oder andere Probleme die Ausführung der Netzwerküberwachung und -steuerung des Teilsystems nicht verhindern. In einigen Beispielen können die Instanzen des/der Netzwerküberwacher(s) 116, der Netzwerkrichtlinien-Engine(s) 118 und/oder des Netzwerkkonfigurators/der Netzwerkkonfiguratoren 120 zustandslos sein, so dass die Standardnetzwerkkonfiguration und/oder -richtlinien und/oder aktualisierte Netzwerkkonfigurationen und/oder -richtlinien von einem Konfigurationsdienst gelesen werden können und ein aktueller Zustand des Teilsystems in einer anderen Anwendungs- oder Dienstinstanz (z.B. einem verteilten, spaltenreichen, nichtrelationalen, mit strukturierter Abfragesprache arbeitenden Datenbankverwaltungs- -dienst (NoSQL; non-relational structured query language)) gespeichert werden kann. In einigen Beispielen können die Überwachungsaktualisierungen und/oder Richtlinien in verschiedenen Schlüsselwertspeichern oder Zeitreihendatenbanken gespeichert werden. Darüber hinaus kann sich der Speicherort eines Datenspeichers - oder einer Datenbank -, der/die diese Informationen speichert, auf der/den Host-Vorrichtung(en) 102 und/oder der/den Unterstützungsvorrichtung(en) 104 befinden. In einigen Beispielen, z.B. wenn die Host-Vorrichtung(en) 102 Rechenzentren sind, kann sich der Datenspeicher auf der/den Unterstützungsvorrichtung(en) 104 als ein globaler Datenspeicher befinden, auf den jede Host-Vorrichtung 102 Zugriff hat. In anderen Beispielen kann sich der Datenspeicher auf der/den Host-Vorrichtung (en) 102 befinden, um lokalen Zugriff auf Netzwerk- und/oder Anwendungsleistungsmetriken und/oder auf die Historie der Netzwerkrichtlinienaktualisierungen bereitzustellen - z.B. spezifisch für diese Host-Vorrichtung(en) 102.
  • Der/die Netzwerküberwacher 116 kann/können die Netzwerk- und/oder Anwendungsleistung unter Verwendung von Netzwerkleistungsmetriken (z.B. Latenz, Verlust, Jitter, Kosten in Verbindung mit verschiedenen Transit-ISPs 110, Kapazität in Verbindung mit verschiedenen Transit-ISPs 110 usw.) und/oder Anwendungsleistungsmetriken (z.B. Streaming-Sitzungsleistungsgewinn, Anwendungs-QoS-Metriken usw.) als Eingaben überwachen. Diese Eingaben können durch Übertragen von Testproben (z.B. Pings) und/oder Simulieren von anwendungsspezifischem Netzwerkverkehr zwischen und unter dem/den Netzwerküberwacher(n) 116 und Analysieren der resultierenden Kommunikationen zum Bestimmen der Netzwerk- und/oder Anwendungsleistungsmetriken bestimmt werden. Beispielsweise kann eine REST-Schnittstelle (z.B. API) exponiert werden, um den/die Netzwerküberwacher 116 in die Lage zu versetzen, Netzwerkpfadinformationen wie tatsächliche Pfadinformationen (z.B. welche autonomen Systeme für die Kommunikation mit anderen autonomen Systemen konfiguriert sind), Netzwerkleistungsmetriken (und/oder Daten, die zur Bestimmung derselben analysiert werden können) und/oder Anwendungsleistungsmetriken (oder Daten, die zur Bestimmung derselben analysiert werden können) zu veröffentlichen.
  • Die Netzwerküberwacher 116 können innerhalb des Systems 100 je nach Art der Netzwerkverkehrsinformationen und/oder der Geräte, zwischen denen der Netzwerkverkehr zu überwachen ist, verteilt sein. Als solche können die Netzwerküberwacher 116 Netzwerküberwacher 116A, die auf der/den Host-Vorrichtung(en) 102 ausgeführt werden (z.B. zur Überwachung des Ausgangs- und/oder Eingangsverkehrs zwischen der/den Host-Vorrichtung(en) 102 und der/den Unterstützungsvorrichtung(en) 104 und/oder dem/den Client-Gerät(en) 106, zur Übertragung von Informationen zurück an die Netzwerküberwacher 116B und/oder 116C usw.), Netzwerküberwacher 116B, die auf der/den Unterstützungsvorrichtung(en) 104 ausgeführt werden (z.B., zum Testen von Verkehr zwischen der/den Unterstützungsvorrichtung(en) 104 und der/den Host-Vorrichtung(en) 102 und/oder dem/den Client-Gerät(en) 106, zur Rückmeldung von Informationen an die Netzwerküberwacher 116A und/oder 116C usw.), und/oder Netzwerküberwacher 116C, die auf dem/den Client-Gerät(en) 106 ausgeführt werden (z.B. zum Testen des Verkehrs zwischen dem/den Client-Gerät(en) 106 und der/den Host-Vorrichtung(en) 102 und/oder der/den Unterstützungsvorrichtung(en) 104, zur Rückmeldung von Informationen an die Netzwerküberwacher 116A und/oder 116B usw.) umfassen. In einigen Ausführungsformen kann ein einzelner Netzwerküberwacher 116 auf zwei oder mehr der Host-Vorrichtung(en) 102, der Unterstützungsvorrichtung(en) 104 und/oder der Client-Vorrichtung(en) 106 aufgeteilt sein. Beispielsweise kann ein erster Teil eines Netzwerküberwachers 116 auf der/den Host-Vorrichtung(en) 102 und ein zweiter Teil auf der/den Unterstützungsvorrichtung(en) 104 ausgeführt werden, und können Kommunikationen zwischen den beiden ausgetauscht werden, um verschiedene Netzwerkpfade zu überwachen und Ende-zu-Ende-Netzwerk- und/oder Leistungsmetriken desselben zu testen.
  • Der/die Netzwerküberwacher 116 kann/können die Netzwerkpfadinformationen in einem Netzwerkpfadinformations (NPI)-Datenformat (NPI) veröffentlichen und/oder kann/können spezifische Plugins verwenden, die von dem Teilsystem gehostet werden und dem/den Netzwerküberwacher(n) 116 entsprechen, um native Eingaben (z.B. native Netzwerkpfadinformationen) in das NPI-Datenformat zu übersetzen. Diese im NPI-Datenformat veröffentlichten Informationen können von der/den Netzwerkrichtlinien-Engine(s) 118 ausgewertet werden, um einen aktuellen Netzwerkpfad, andere potenzielle Netzwerkpfade und/oder entsprechende Anwendungs- und/oder Netzwerkleistungsmetriken zu bewerten und zu bestimmen, ob und welche Art von Netzwerkpfadaktualisierungen implementiert werden sollten.
  • Sobald eine Aktualisierung bestimmt wurde, können Änderungen im Netzwerk-Routing als Nachrichten im Netzwerkrichtlinienaktualisierungs (NPU; network policy update)-Datenformat- in Ausführungsformen z.B. nach der Übersetzung aus einem nativen Format - an den/die Netzwerkkonfigurator(en) 120 veröffentlicht oder gesendet werden. Der/die Netzwerkkonfigurator(en) 120 kann/können die Routing-Updates an Zielnetzwerkendpunkten (z.B. dem/den Netzwerkgerät(en) 124) implementieren, wie z.B. durch Aktualisieren von Import-Routenkarten und/oder Export-Routenkarten von Core-Switches (z.B. durch Aktualisieren lokaler Präferenzwerte für einen bestimmten Ausgangs-Port und/oder Voranstellen von Präfixen autonomer Systeme an Export-Routenkarten zur Steuerung eingehenden Verkehrs unter Verwendung des/der Route Injektor(s/en) 122).
  • In einigen Ausführungsformen können die Überwachungspfadinformationen, die Überwachungsaktualisierungen und/oder die Steuerungs- bzw. Kontrollrichtlinien auf der/den Host-Vorrichtung(en) 102 und/oder der/den Unterstützungsvorrichtung(en) 104 gespeichert werden. Beispielsweise können die Informationen in der/den Unterstützungsvorrichtung(en) 104 als ein einziger Punkt des Zugriffs durch die Host-Vorrichtung(en) 102 gespeichert werden.
  • Nun auf 2 Bezug nehmend umfasst jeder Block des hierin beschriebenen Verfahrens 200 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Anweisungen ausführt. Das Verfahren 200 kann auch in Form von computerverwendbaren Anweisungen, die auf Computerspeichermedien gespeichert sind, verkörpert sein. Das Verfahren 200 kann durch eine eigenständige Anwendung, ein Dienst oder ein gehosteter Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder als Plug-in für ein anderes Produkt bereitgestellt sein, um nur einige Beispiele zu nennen. Darüber hinaus wird das Verfahren 200 beispielhaft in Bezug auf das System 100 von 1 beschrieben. Dieses Verfahren kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hierin beschriebenen Systeme.
  • 2 ist ein Ablaufdiagramm, das ein Verfahren 200 zum Aktualisieren von Netzwerkeinstellungen auf der Grundlage von Metriken für eine Vielzahl von Kommunikationspfaden in Übereinstimmung mit einigen Ausführungsformen der Erfindung zeigt. Das Verfahren 200 umfasst bei Block B202 ein Überwachen der Kommunikation und ein Erzeugen von Metriken für Kommunikationspfade. Zum Beispiel können der/die Netzwerküberwacher 116 Netzwerkpfade - einschließlich verschiedener Transit-ISPs 110 - überwachen und Netzwerk- und/oder Anwendungsleistungsmetriken erzeugen. In nicht beschränkenden Beispielen kann die Überwachung die Übertragung von anwendungsspezifischem Verkehr über die verschiedenen Kommunikationspfade umfassen - z.B. die Übertragung von Daten, die einen 4K-Videostrom und einen High-Definition-Audiostrom repräsentieren, zwischen der/den Host-Vorrichtung(en) 102 und dem/den Client-Gerät(en) 106, die Übertragung von Authentifizierungsanfragen zwischen der/den Host-Vorrichtung(en) 102 und der/den Untzerstützungsvorrichtung(en) 104 usw. Als weiteres Beispiel kann die Überwachung die Übertragung von Proben oder Pings (z.B. von der/den Unterstützungsvorrichtung(en) 104 an die Host-Vorrichtung(en) 102), um Zustände der Transit-ISPs 110A und 110B zu bestimmen, und die Überwachung auf Zustandsänderungen im Laufe der Zeit umfassen.
  • Das Verfahren 200 umfasst bei Block B204 ein Auswerten, ob ein Unterschied zwischen einem aktuellen Kommunikationspfad und einem alternativen Kommunikationspfad größer ist als ein Änderungsschwellenwert. Beispielsweise können die Netzwerkpfadinformationen, die einem aktuellen Netzwerkpfad mit dem Transit-ISP 110A entsprechen, mit Netzwerkpfadinformationen verglichen werden, die einem alternativen Netzwerkpfad mit dem Transit-ISP 110B entsprechen - z.B. durch die Netzwerkrichtlinien-Engine(s) 118, um einen Unterschied in einer oder mehreren Netzwerk- und/oder Anwendungsleistungsmetriken zu bestimmen. Wenn die Bestimmung in Block B204 ergibt, dass der Unterschied - z.B. eine gewichtete Gesamtdifferenz von zwei oder mehr Metriken bzw. Messgrößen - nicht größer als ein Änderungsschwellenwert ist, kann das Verfahren 200 zu Block B202 zurückkehren, um die Überwachung fortzusetzen.
  • Wenn die Ermittlung in Block B204 ergibt, dass der Unterschied bzw. die Differenz größer als ein Änderungsschwellenwert ist, kann das Verfahren 200 zu Block B206 fortfahren, um Einstellungen des Ausgangsnetzwerks zu aktualisieren. Beispielsweise kann/können die Netzwerkrichtlinien-Engine(s) 118 bestimmen, dass die Aktualisierungen vorgenommen werden müssen, und können diese Informationen von dem/den Netzwerkkonfigurator(en) 120 verwendet werden, um Routing-Aktualisierungsinformationen zu erzeugen und an das/die Netzwerkgerät(e) 124 weiterzuleiten (z.B. um Import-Routenkarten für eingehenden Verkehr zu aktualisieren).
  • In einigen Beispielen, wie z.B. dann, wenn kritische Dienste - z.B. die Steuerungsebenendienste 130 - Teil der Steuerungsebene sind, aber außerhalb der Host-Vorrichtung(en) 102 ausgeführt werden, kann eine Zwei-Wege-Kommunikation erforderlich sein. Infolgedessen kann das autonome System, das diese Dienste hostet, als kritisches autonomes System oder autonomes Spezialziel-System eingestuft werden (z.B. als autonomes BGP-Ziel-System). In solchen Beispielen kann das Verfahren 200 bei Block B204 zu einem Block B208 fortfahren, um zu bestimmen, ob ein autonomes Zielsystem ein kritisches autonomes System ist. Wenn bestimmt wird, dass das autonome Zielsystem nicht kritisch ist, kann das Verfahren 200 mit Block B202 fortfahren, um die Überwachung fortzusetzen.
  • Wenn in Block B208 bestimmt wird, dass das autonome Zielsystem kritisch ist, kann das Verfahren 200 zusätzlich zu oder alternativ zu den Aktualisierungen bei Block B206 zu einem Block B210 fortfahren, um Eingangsnetzwerkeinstellungen zu aktualisieren. Beispielsweise kann/können die Netzwerkrichtlinien-Engine(s) 118 bestimmen, dass die Aktualisierungen vorgenommen werden müssen, und können diese Informationen von dem/den Netzwerkkonfigurator(en) 120 verwendet werden, um Routing-Aktualisierungsinformationen zu dem/den Netzwerkgerät(en) 124 zu generieren und zu übertragen (z.B. um Export-Routenkarten zu aktualisieren, indem autonome Systempräfixe vorangestellt werden, um den aktuellen Netzwerkpfad einschließlich des Transit-ISPs 110A zu bestrafen, so dass die Unterstützungsvorrichtung(en) 104 den alternativen Netzwerkpfad mit dem Transit-ISP 110B verwenden, um mit der/den Host-Vorrichtung(en) 102 zu kommunizieren).
  • Erneut auf 1 Bezug nehmend, kann/können die Unterstützungsvorrichtung(en) 104 ein oder mehrere Rechenvorrichtungen umfassen - z.B. ein Rechenzentrum oder Rechengeräte wie Server, NAS, APIs usw. desselben -, die Webdienste hosten, wie z.B. die Steuerebenendienste 130. Beispielsweise können die Unterstützungs-vorrichtung(en) 104 die Steuerebenendienste 130 ausführen - z.B. für eine Hybrid Cloud-Plattform -, die die Kommunikation von Informationen ermöglichen, die dem Netzwerk und/oder den Anwendungen zwischen der/den Host-Vorrichtung(en) 102 (z.B. einer Vielzahl von Rechenzentren) und der/den Unterstützungsvorrichtung(en) 104 (z.B. einem oder mehreren Rechenzentren, die die Steuerebenendienste 130 hosten) entsprechen. In einigen Beispielen können die Steuerebenendienste 130 eine Dienstsuche umfassen, um zu bestimmen, wo Upstream-/Backend-Dienstinstanzen verfügbar sind, eine Zustands- bzw. Gesundheitsprüfung, um zu bestimmen, ob die von der Dienstsuche zurückgegebenen Upstream-Dienstinstanzen in Ordnung sind (z.B. einschließlich aktiver Pings und/oder passiver Zustandsprüfungen), Routing, Lastausgleich, Authentifizierung und Autorisierung (z.B. um für eingehende Anfragen zu bestimmen, ob der Aufrufer kryptografisch bestätigt werden kann, ob der Aufrufer den angeforderten Endpunkt aufrufen darf und/oder ob eine authentifizierte Antwort zurückgegeben wird) und/oder Beobachtbarkeit (z.B. können für jede Anfrage detaillierte Statistiken, Protokollierung und verteilte Tracing-Daten generiert werden, so dass die Netzwerküberwacher 116 den verteilten Verkehrsfluss verstehen und Probleme beheben können, wenn sie auftreten).
  • Das/die Client-Gerät(e) 106 kann/können einen oder mehrere Endbenutzer-Gerätetypen umfassen, wie z.B. ein Smartphone, einen Laptop-Computer, einen Tablet-Computer, einen Desktop-Computer, ein tragbares Gerät, eine Spielkonsole, ein Smart-Home-Gerät, das einen KI-Agenten oder -Assistenten enthalten kann, ein Gerät oder System für virtuelle oder erweiterte Realität und/oder eine andere Art von Gerät. In einigen Beispielen kann/können das/die Client-Gerät(e) 106 eine Kombination von Geräten umfassen (z.B. ein Smartphone und eine kommunikativ gekoppelte Smartwatch oder ein anderes tragbares Gerät), und können die damit verbundenen Client-Anwendungen 132, einschließlich Interaktionen mit der Host-Anwendung 126, unter Verwendung eines oder mehrerer der Geräte ausgeführt werden (z.B. Smartphone-Anwendung sendet Benachrichtigung an Smartwatch-Anwendung, Benutzer gibt Eingabe an Smartwatch, Daten, die für die Eingabe repräsentativ sind, werden über das Smartphone an ein anderes Gerät des Systems 100 weitergeleitet).
  • Mit nunmehrigem Bezug auf 3A-3C sind 3A-3C beispielhafte Darstellungen von Netzwerk-Routing-Problemen, die zu einer Verschlechterung der Anwendungs- oder Netzwerkleistung führen, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Beispielsweise können die in 3A-3C dargestellten Probleme mit der Netzwerkleistung und/oder der Anwendungsleistung in Bezug auf die Netzwerküberwacher 116, die Netzwerkrichtlinien-Engines 118 und/oder die Netzwerkkonfiguratoren 120 beschrieben werden, die zur Lösung der jeweiligen Probleme für die jeweiligen Anwendungen angepasst worden sein können. Die Beispiele von 3A-3C sollen nicht beschränkend sein und beschreiben geeignete Beispiele für die Implementierung des Systems 100 von 1.
  • Unter Bezugnahme auf 3A kann 3A einem Beispiel entsprechen, bei dem die Zugänglichkeit der Host-Vorrichtung(en) 102 zu der/den Unterstützungsvorrichtung (en) 104, das/die kritische gemeinsam genutzte Dienste hostet/hosten - wie z.B. die Steuerebenendienste 130 -, auf „Black Hole“-Routing oder Netzwerkausfälle über verschiedene Transit-ISPs 110 überwacht wird. So gibt es beispielsweise Fälle von Netzwerk-Routing-Anomalien, bei denen ein bestimmter Transit-ISP 110 Routen zu einem bestimmten autonomen Zielsystem (z.B. zu der/den Unterstützungs-vorrichtung(en) 104 oder einem autonomen System, das ebenfalls eine Route zu der/den Unterstützungsvorrichtung(en) 104 ankündigt) ankündigt, den Netzwerkverkehr aber aufgrund interner Routing-Probleme des autonomen Systems des Transit-ISPs stillschweigend fallen lässt. Diese Arten von Vorfällen können einen großen Wirkungsradius in dem Netzwerk haben, da mehrere Zonen mit demselben Transit-IP-Anbieter betroffen sein können. Dies kann Probleme verursachen, insbesondere in hybriden Cloud-Umgebungen, in denen die Gewährleistung der Netzwerkbelastbarkeit entscheidend ist, um die Netzwerkkonnektivität zu kritischen Netzwerkdiensten zu garantieren, die in verschiedenen Clouds laufen.
  • Beispielsweise können Soft-Fehler 302 (z.B. „Black-Hole“-Ereignisse, Netzwerkausfälle usw.) im Transit-ISP 110A dazu führen, dass die Steuerungsebenendienste 130 für eine Teilmenge von Diensten, die auf der/den Host-Vorrichtung(en) 102 ausgeführt werden, unerreichbar werden. Um diesen Fehler zu beheben, können die Soft-Fehler von dem System 100 überwacht und erfasst werden, und kann der Verkehr von dem Transit-ISP 110A beispielsweise zu dem Transit-ISP 110B umgeleitet werden. Als solche können die Netzwerküberwacher 116A und 116B auf der/den Host-Vorrichtung(en) 102 bzw. dem/den Unterstützungsvorrichtung(en) 104 installiert und/oder instanziiert werden. Es können Tests durchgeführt werden, um mehrere kritische Netzwerk-Ziel-Agenten zu testen, die in verschiedenen Netzwerken eingesetzt werden, und kann die Qualität des Netzwerks Ende-zu-Ende unter Verwendung der Netzwerküberwacher 116A und 116B überwacht werden. Diese einzelnen Testproben oder Pings können über bestimmte Ausgangspfade, die den Transit-ISP 110A beinhalten, unter Verwendung einer Kombination aus Edge-Switch-Routing-Konfiguration (z.B. Konfiguration der Export-Routenkarten) und Testprotokollparametern (z.B. Internetprotokoll (IP) Differentiated Services Code Point (DSCP)) erzwungen werden. Die Testproben oder Pings können auch separat über andere Netzwerkpfade, z.B. über den Transit-ISP 11 OB, erzwungen werden, um andere Ende-zu-Ende-Netzwerkpfade zwischen der/den Host-Vorrichtung (en) 102 und der/den Unterstützungsvorrichtung(en) 104 zu testen. Die Qualität des Netzwerks von Ende zu Ende, wie über die Testproben ermittelt, kann auf der Grundlage von Netzwerkleistungsmetriken wie beispielsweise Verlust, Latenz, Jitter und/oder anderen Leistungskennzahlen bewertet werden. Meldungen können dann für bestimmte Schwellenwerte eingerichtet werden - z.B. für einzelne Metrik-Schwellenwerte, Kombinationen von Metrik-Schwellenwerten, gewichtete Kombinationen von Mettrik-Schwellenwerten usw., wie hierin näher beschrieben.
  • Der/die Netzwerküberwacher 116A und/oder 116B kann/können auf Meldungen über verschiedene Netzwerkpfade für eingehenden und/oder ausgehenden Verkehr überwachen - z.B. einem ersten Netzwerkpfad, der den Transit-ISP 110A beinhaltet, und einem zweiten Netzwerkpfad, der den Transit-ISP 110B beinhaltet. Die Metriken und Meldungen können von den Netzwerküberwachern 116 über verschiedene Tests (z.B. Jitter-Netzwerktests, Latenz-Netzwerktests, Verlust-Netzwerktests usw., wobei verschiedene Testtypen für verschiedene Metrikanalysen ausgeführt werden können) und verschiedene Netzwerkpfade hinweg aggregiert werden, und die Listen von Meldungen können von den Netzwerküberwachern 116 eingereicht oder veröffentlicht werden. In einigen Ausführungsformen können die Meldungen Metriken für gute und schlechte Netzwerkpfade enthalten, so dass die Netzwerkrichtlinien-Engine 118 nicht nur die Probleme mit dem Netzwerkpfad, der den Transit-ISP 110A beinhaltet, sondern auch den Netzwerkpfad, der den Transit-ISP 110B beinhaltet, analysieren kann, um zu bestimmen, ob ein Änderungsschwellenwert erreicht wurde (z.B. wie in Block B204 des Verfahrens 200 von 2 beschrieben). Die Netzrichtlinien-Engine 118 kann dann auf der Grundlage konfigurierbarer netzüberwachungsspezifischer Richtlinien bestimmen, ob eine Änderung oder Aktualisierung veröffentlicht oder übertragen werden soll. Wenn eine Änderung vorzunehmen ist, kann die Netzwerkrichtlinien-Engine 118 Netzwerkrouten-Updates (z.B. im NPU-Datenformat) generieren, die an den Netzwerkkonfigurator 120 (der konfigurierbare netzwerküberwachungsspezifische Konfiguratoren sein kann) übertragen oder gesendet werden können, und kann der Netzwerkkonfigurator 120 die Richtlinien auf dem/den Netzwerkgerät(en) 124 aktualisieren (z.B. durch Aktualisieren von Import-Routenkarten, Aktualisieren von Export-Routenkarten, Aktualisieren anderer Richtlinien oder eine Kombination davon).
  • Beispielsweise kann auf der Grundlage der Testproben bestimmt werden, dass ein Netzwerkpfad zwischen der/en Unterstützungsvorrichtung(en) 104 und der/den Host-Vorrichtung(en) 102, die den Transit-ISP 110A nutzt (nutzen), einen Fehler aufweist. Von den Netzwerküberwachern 116A und/oder 116B kann eine Meldung erzeugt werden, und die Netzwerkrichtlinien-Engine 118 kann auf der Grundlage der Meldung(en) aktualisierte Richtlinien erstellen. Darüber hinaus kann die Netzwerkrichtlinien-Engine 118 das Meldungsereignis in einen permanenten Speicher einfügen und die Aktivität als „in Bearbeitung“ markieren. Der Netzwerkkonfigurator 120 kann Richtlinien auf dem/den Netzwerkgerät(en) 124 - z.B. den Core-Switches - auf der Grundlage der Meldung(en) aktualisieren, und kann den Status des Meldungsereignisses in dem permanenten Speicher auf „abgeschlossen“ und „aktiv“ aktualisieren (welches von der Netzwerkrichtlinien-Engine 118 verwendet werden kann, um zu bestimmen, ob weitere Aktualisierungen vorgenommen werden sollten oder nicht, um nicht zu viele Aktualisierungen in einem kurzen Zeitraum herauszugeben, die Dämpfungsschwellenwerte der Transit-ISPs 110 verursachen könnten). Infolgedessen kann der Verkehr zu und/oder von der/den Unterstützungsvorrichtung(en) 104 über den Transit-ISP 110B und weg von dem Transit-ISP 110A geroutet werden, um die von den Testproben erfassten Soft-Fehler des Transit-ISPs 110A zu vermeiden.
  • Für die Netzwerkrichtlinien-Engine 118 in diesem Beispiel kann es spezifische Richtlinienregeln für Aktionen geben, die für die spezifischen Netzwerküberwacher 116A und/oder 116B durchgeführt werden, die auf Soft-Fehler testen. Darüber hinaus kann die Netzwerkrichtlinien-Engine 118 eine dynamische adaptive Steuerung für Meldungen implementieren, und kann Unterstützung für automatische Löschungen beinhalten. In einigen Beispielen kann das adaptive Verhalten für bestimmte Netzwerküberwacher 116 mit konfigurierbaren Schwellenwerten feinabgestimmt oder angepasst werden. Der Netzwerkmonitor 116A und/oder 116B dieses Beispiels kann einen Ereignisaktivzustand und einen impliziten Ereignislöschungszustand umfassen (z.B. kann der Netzwerkmonitor 116 auf eine Meldungslisten-API angewiesen sein, und kann das Fehlen einer Meldungsereignis-ID in dem periodischen Meldungs-Push implizieren, dass die Meldung gelöscht wird oder gelöscht werden sollte - und/oder aus dem dauerhaften Zustandsspeicher entfernt wird). Ein Meldungsereignis kann als umsetzbar betrachtet werden, wenn die Netzwerkleistungsmetriken (z.B. Jitter, Latenz, Verlust und/oder andere Metriken) für einen ersten Netzwerkpfad schlechter sind als für einen zweiten Netzwerkpfad und/oder der zweite Netzwerkpfad Leistungsmetriken über einem Schwellenwert aufweist. Ein Pfad für diese Netzüberwachung kann, ohne Beschränkung darauf, definiert werden als {autonomes Zielsystem, autonomes Transit-ISP-System, lokale Ausgangs-IP, Pfadname}.
  • Bei einer Implementierung mit dem Transit-ISP 110A und dem Transit-ISP 110B zwischen der/den Host-Vorrichtung(en) 102 und der/den Unterstützungsvorrichtung(en) 104 kann eine erster Meldung für einen Netzwerkpfad mit dem Transit-ISP 110A erzeugt werden. Infolgedessen kann die Routing-Präferenz auf einen Netzwerkpfad mit dem Transit-ISP 110B umgeschaltet werden, und kann die erste Meldungshistorie für den Transit-ISP 110A für eine zukünftige Flap-Erfassung aufgezeichnet werden.
  • Eine zweite Meldung kann nach der ersten Meldung für den Netzwerkpfad mit dem Transit-ISP 110B generiert werden, während die erste Meldung noch aktiv ist, oder nachdem die erste Meldung kürzlich gelöscht wurde (z.B. kann die Meldungshistorie für eine gewisse Zeitspanne nach der Löschung, z.B. dreißig Minuten, aufrechterhalten werden). Infolgedessen kann die Netzwerkrichtlinien-Engine 118 die potenziellen Nebenwirkungen der ersten Meldungsaktion erkennen, und können die vorherigen Änderungen für die erste Meldung rückgängig gemacht werden, so dass der Netzwerkpfad mit dem Transit-ISP 110A wieder bevorzugt werden kann.
  • Als ein weiteres Beispiel können unter der Annahme, dass ein Wechsel aufgrund der ersten Meldung vorgenommen wurde (und unter der Annahme, dass die zweite Meldung nicht eingetreten ist) und dann die erste Meldung gelöscht wird (z.B. implizit, wie hierin beschrieben), die Routenänderungen rückgängig gemacht werden, so dass der Netzwerkpfad mit dem Transit-ISP 110A bevorzugt wird. Für den Transit-ISP 110A kann ebenfalls eine Meldungshistorie zur künftigen Flap-Erkennung aufgezeichnet werden.
  • Unter der Annahme, dass innerhalb eines bestimmten Zeitraums - z.B. fünfzehn Minuten, dreißig Minuten usw. - eine weitere Meldung für einen Netzwerkpfad, der den Transit-ISP 110A beinhaltet, aktiv ist, kann ein potenzieller Flap erfasst werden. Infolgedessen kann das System 100 die Routenpräferenzen aktualisieren, um den Transit-ISP 110B zu bevorzugen, und kann ohne eine manuelle Löschung der Meldung keine weitere Löschung von Meldungen, die zu Netzwerkpfaden einschließlich des Transit-ISPs 110A zurückkehren würden, erlaubt werden. Insoweit kann das System dazu verwendet werden, sicherzustellen, dass innerhalb des Schwellenzeitraums nicht mehr als zwei Pfadwechsel stattfinden.
  • Als ein weiteres Beispiel können dann, wenn Meldungen in einer einzigen Meldungsliste auf Netzwerkpfade mit dem Transit-ISP 110A und dem Transit-ISP 110B übertragen werden, die Meldungen protokolliert werden, aber es können keine Routing-Aktualisierungs-Ereignisse ausgeführt werden.
  • In einigen Beispielen, z.B. wenn mehr als eine Schwellenzahl (z.B. vier, fünf, zehn usw.) von aktiven und/oder gelöschten Meldungen für einen bestimmten Transit-ISP 110 innerhalb einer Schwellenzeit (z.B. zwölf Stunden, vierundzwanzig Stunden usw.) für ein spezielles autonomes System (z.B. für das (die) Unterstützungsgerät(e) 104) vorliegen, die dazu führen, dass Exportroutenkarten aktualisiert und sichtbar an das Netz weitergegeben werden, kann ein Fehler protokolliert und ignoriert werden, um eine Schwarzlistung und/oder Dämpfung durch die Transit-ISPs 110 zu vermeiden. In Beispielen, in denen ein Schwellenwert für die Anzahl der Meldungen für einen Netzwerkpfad zwischen der/den Host-Vorrichtung(en) 102 und dem/den Client-Gerät(en) 106 gilt, können diese Grenzwerte nicht durchgesetzt werden, da nur Import-Routenkarten aktualisiert werden können, die sich lokal im Netzwerk des/der Host-Vorrichtung(en) 102 befinden und nicht von außen sichtbar sind.
  • Für unterschiedliche Netzleistungsmetriken können verschiedene Schwellenwerte verwendet werden. Beispielsweise können, um eine Meldung zu generieren, verschiedene Schwellenwerte verwendet werden, und sobald eine Meldung generiert wurde, können Unterschieds- oder Änderungsschwellenwerte (z.B. zwischen einem aktuell gemeldeten Pfad und einem alternativen Netzwerkpfad) berücksichtigt werden, um zu bestimmen, ob eine Aktualisierung vorgenommen werden muss. Damit eine Meldung generiert wird, müssen die Schwellenwerte innerhalb einer bestimmten Zeitspanne (z.B. eine Minute, zwei Minuten, vier Minuten usw.) eine bestimmte Anzahl von Malen (z.B. zwei, drei, vier usw.) erreicht werden. Was die Warnschwellen betrifft, können Latenzmeldungen bzw. Latenzwarnungen für intrakontinentalem Verkehr bei mehr als 50 ms, 60 ms usw. und bei inter- oder transkontinentalem Verkehr bei mehr als 100 ms, 200 ms usw. generiert werden. In ähnlicher Weise kann bei Paketverlusten eine Verlustmeldung bei einem Verlust von mehr als fünf Prozent, zehn Prozent, fünfzehn Prozent usw. generiert werden. In Bezug auf die Änderungsschwellen und insbesondere den Paketverlust als Beispiel kann ein Netzwerkpfad als schlechter angesehen werden, wenn der Prozentsatz der Paketverluste mindestens fünf Prozent höher ist als bei einem alternativen Netzwerkpfad. Wenn also der Verlust auf dem Netzwerkpfad, der den Transit-ISP 110A beinhaltet, zwanzig Prozent beträgt, dann kann der Netzwerkpfad, der den Transit-ISP 110B beinhaltet, als besser angesehen werden, wenn der Verlust weniger als oder gleich fünfzehn Prozent beträgt. Als weiteres Beispiel für die Latenzzeit kann ein Netzwerkpfad als schlechter angesehen werden, wenn der Prozentsatz der Latenzzeit mindestens zehn Prozent höher ist als bei einem alternativen Netzwerkpfad. Wenn also die Latenzzeit auf dem Netzwerkpfad, der den Transit-ISP 110A beinhaltet, 80 ms beträgt, kann der Netzwerkpfad, der den Transit-ISP 110B beinhaltet, als besser angesehen werden, wenn die Latenzzeit weniger als oder gleich 72 ms beträgt. In einem weiteren Beispiel für Jitter kann ein Netzwerkpfad kann als schlechter angesehen werden, wenn der Prozentsatz des Jitters mindestens zehn Prozent höher ist als bei einem alternativen Netzwerkpfad.
  • In einigen Ausführungsformen können, um zu bestimmen, ob ein Netzwerkpfad schlechter ist als ein anderer, d.h. ob der Unterschied einen bestimmten Schwellenwert überschreitet, zwei oder mehr Metriken analysiert und gewichtet werden. Zum Beispiel kann zwischen Latenz, Verlust und Jitter der Verlust stärker gewichtet werden als der Jitter und der Jitter stärker als die Latenz. Das heißt, ein Pfad mit achtzig Prozent Verlust und 10 ms Latenzzeit kann als schlechter angesehen werden als ein Pfad mit sechzig Prozent Verlust und 50 ms Latenzzeit.
  • Es sei ein Beispielszenario betrachtet, in dem Meldungen für drei Netzwerkpfade, L1, L2 und L3, generiert wurden. L1 kann 20 % Verlust, 10 ms Latenz und 5 ms Jitter aufweisen, L2 kann 10 % Verlust, 20 ms Latenz und 6 ms Jitter aufweisen und L3 kann 12 % Verlust, 22 ms Latenz und 4 ms Jitter aufweisen. In einem solchen Beispiel können L3 und L2 in Bezug auf Verluste besser sein als L1, und zwischen L3 und L2 ist L2 in Bezug auf Verluste fünf Prozent besser als L3. Insoweit kann L2 der beste Netzwerkpfad sein.
  • In einem anderen Beispielszenario kann L1 einen Verlust von 20 %, eine Latenzzeit von 10 ms und einen Jitter von 5 ms aufweisen, L2 einen Verlust von 12 %, eine Latenzzeit von 20 ms und einen Jitter von 6 ms, und L3 einen Verlust von 12 %, eine Latenzzeit von 22 ms und einen Jitter von 4 ms. In einem solchen Beispiel können L3 und L2 in Bezug auf den Verlust besser sein als L1, L3 und L2 können den gleichen Verlust aufweisen, und L3 hat den besten Jitter und eine Latenz von nur 10 %. Insoweit kann L3 der beste Netzwerkpfad sein.
  • Mit Bezug auf 3B können ein oder mehrere Netzwerküberwacher 116, eine oder mehrere Netzwerkrichtlinien-Engine(s) 118 und/oder ein oder mehrere Netzwerkkonfiguratoren 120 implementiert sein, um eine Klasse von Netzwerkfehlern zu erkennen, einschließlich Link Flapping oder Failover-Verkehr. Beispielsweise können sich innerhalb des Netzwerks des Transit-ISPs 110 oder an der Netzwerkgrenze zwischen dem Transit-ISP 110 und der/den Host-Vorrichtung(en) 102 vorübergehende Ausfälle innerhalb einer kurzen Zeitspanne wiederholen - dies wird als Link Flapping bezeichnet. Dies kann sich von einem harten Port-Fehler unterscheiden, der auf niedrigeren Schichten von Netzwerkprotokollen behandelt werden kann, und hat auch einen viel größeren Einfluss auf die Leistung des Anwendungsnetzwerks. Beispielsweise kann Link Flapping zu Streaming-Fehlern führen, wenn der Verkehr zwischen den Netzwerkpfaden wechselt. Daher kann/können ein/mehrere Netzwerküberwacher 116 außerhalb des Netzwerks der Host-Vorrichtung(en) 102 installiert werden - wie z.B. der Netzwerkmonitor 116B und/oder 116C -, um durch die Ausführung periodischer Pings 304 der Schnittstelle (z.B. von außerhalb des Netzwerks, wie z.B. von verschiedenen Regionen des/der Unterstützungsvorrichtung(en) 104) auf Link Flapping zu überwachen. Wenn sich der Zustand der Erreichbarkeit der Schnittstelle innerhalb eines bestimmten Intervalls mehr als eine bestimmte Anzahl von Malen ändert, kann eine Meldung erzeugt und im permanenten Speicher abgelegt werden. Die Netzwerkrichtlinien-Engine(s) 118 kann/können die Meldung (z.B. im NPI-Datenformat) empfangen und eine Richtlinienaktualisierung bestimmen, die den Verkehr von dem/den Netzwerkpfad(en) wegleitet, der/die den Transit-ISP 110 beinhaltet/beinhalten, bei dem das Link Flapping auftritt.
  • Der Netzwerkmonitor 116B und/oder 116C dieses Beispiels kann einen aktiven Wartungsereignisstatus und einen gelöschten Meldungsereignisstatus beinhalten, der bei der Korrektur ausgegeben wird. Wenn ein aktiver Wartungsereigniszustand im permanenten Speicher vorhanden ist, kann das System 100 Netzwerkrichtlinien - z.B. des/der Netzwerkgeräts/-geräte 124 - auf einen sekundären Modus aktualisieren, der Verkehr (z.B. Eingang und/oder Ausgang) weg von Netzwerkpfaden mit dem Transit-ISP 110 mit Link Flapping verlagert. Beispielsweise können die Import-Routenkarten und/oder die Export-Routenkarten von aktuellen Routenkarten auf aktualisierte oder sekundäre Routenkarten aktualisiert werden. Darüber hinaus kann, sobald das Link Flapping geendet hat (z.B. nach einem Test über einen bestimmten Zeitraum), kann die Meldung gelöscht werden, und können die Aktualisierungen der Import- und/oder Export-Routenkarten rückgängig gemacht werden, um zu den ursprünglichen oder Standardkarten zurückzukehren.
  • Beispielsweise kann der Netzwerkmonitor 116 auf Zustandsänderungen einer Verbindung überwachen, wobei eine Zustandsänderung einer Verbindung entspricht, die von pingbar auf nicht pingbar wechselt. Beispielsweise kann eine Schwellenanzahl von Zustandsänderungen über einen Zeitraum hinweg auftreten müssen, damit eine Meldung generiert wird. Der Schwellenwert kann zwei, drei, fünf usw. Zustandsänderungen innerhalb eines Zeitraums von einer halben, einer, zwei, drei usw. Stunden beinhalten. Als ein nicht-beschränkendes Beispiel kann eine Verbindung, die innerhalb eines Zeitfensters von zwei Stunden zweimal ausfällt und jedes Mal wiederhergestellt wird, als „flapping“ gekennzeichnet werden, und es kann eine Meldung erzeugt werden.
  • Nun auf 3C Bezug nehmend, können ein oder mehrere Netzwerküberwacher 116, eine oder mehrere Netzwerkrichtlinien-Engine(s) 118 und/oder ein oder mehrere Netzwerkkonfiguratoren 120 zur Überwachung der Sitzungserträge pro Transit-ISP 110 implementiert sein. Die Sitzungserträge können einem Prozentsatz erfolgreicher Anwendungssitzungen entsprechen, die nicht aufgrund von Netzwerkproblemen fehlgeschlagen sind oder bei denen kein anderer Fehler aufgetreten ist. Interne Netzwerkqualitätsprobleme bei Transit-ISPs 110 können die Leistung einer Anwendung, wie z.B. einer Cloud Gaming-Anwendung, einer VR-Streaming-Anwendung und/oder anderer Hochleistungsanwendungen, beeinträchtigen. Um dieses Problem anzugehen, kann die Host-Vorrichtung 102 von einem aktuellen Transit-ISP 110 zu einem anderen Transit-ISP 110 wechseln, basierend auf der Leistung der Anwendungssitzung, die von dem/den Netzwerküberwacher(n) 116 überwacht wird. Als solches kann dann, wenn die Anwendungsleistung unter einen Schwellenwert fällt und die Leistung über einen anderen Transit-ISP besser ist, der Sitzungsleistungsgewinns-Netzwerkmonitor 116 eine Meldung ausgeben, um den Netzwerkverkehr auf einen Netzwerkpfad umzuleiten, der den Transit-ISP 110 mit besserer Leistung beinhaltet. In einigen Ausführungsformen können die Metriken der Anwendungsleistung von dem/den Netzwerküberwacher(n) 116 aus den Metriken des Anwendungsstreamings abgefragt werden.
  • Der/die Netzwerküberwacher 116 dieses Beispiels kann einen aktiven Ereignisstatus beinhalten. Wenn ein aktiver Ereignisstatus im permanenten Speicher vorhanden ist, kann das System 100 die Netzwerkrichtlinien - z.B. des/der Netzwerkgerät(s/e) 124 - auf einen sekundären Modus aktualisieren, der den Verkehr (z.B. Eingang und/oder Ausgang) weg von Netzwerkpfaden mit dem Transit-ISP 110 mit geringem Sitzungsleistungsgewinn, QoS oder anderen Anwendungsleistungsproblemen verlagert. Zum Beispiel können die Import-Routenkarten und/oder Export-Routenkarten von aktuellen Routenkarten auf aktualisierte oder sekundäre Routenkarten aktualisiert werden.
  • Beispielsweise kann/können die Netzwerküberwacher 116 eine Schwellenanzahl von Sitzungen auf einem Transit-ISP überwachen (z.B. 50, 80, 100 usw.) und einen Schwellenertrag der Sitzungen berücksichtigen (z.B. weniger als 70 %, 80 % usw.). Insoweit kann eine Meldung generiert werden, wenn der Schwellenwert für den Sitzungsleistungsgewinn unter einem Schwellenwert liegt und die Anzahl der Sitzungen größer als eine Schwellenzahl ist. Sobald eine Meldung generiert ist, kann/können die Netzwerkrichtlinien-Engine(s) 118 bestimmen, ob die Meldung auf der Grundlage eines Vergleichs des aktuellen Netzwerkpfads mit einem anderen Netzwerkpfad, der einen anderen Transit-ISP 110 beinhaltet, umsetzbar ist. Falls beispielsweise der Unterschied zwischen einem aktuellen Netzwerkpfad und einem alternativen Pfad größer ist als ein Änderungsschwellenwert (z.B. 5 %, 10 % usw.), können Aktualisierungen an das/die Netzwerkgerät(e) 124 gesendet werden, um Export-Routenkarten und/oder Import-Routenkarten zu aktualisieren.
  • Wenn beispielsweise der Sitzungsleistungsgewinn aller Sitzungen über einen Zeitraum (z.B. dreißig Minuten, eine Stunde usw.) des Transit-ISPs 110A weniger als 80% beträgt, der Transit-ISP 110B einen Sitzungsleistungsgewinn von mehr als 90% über diesen Zeitraum aufweist und es mindestens hundert Sitzungen jedes Transit-ISPs gibt, können die Richtlinien so aktualisiert werden, dass der Transit-ISP 110B bevorzugt wird.
  • Als weitere, nicht beschränkende Beispiele und zusätzlich zu den Netzwerküberwachern 116, den Netzwerkrichtlinien-Engines 118 und den Netzwerkkonfiguratoren 120 von 3A-3C kann es Netzwerküberwacher 116, Netzwerkrichtlinien-Engines 118 und/oder Netzwerkkonfiguratoren 120 für die Transit-ISPs 110A/110B geben, die für bestimmte Client-ISPs 114 testen. Zum Beispiel können einige Transit-ISPs 110 eine schlechte Konnektivität mit bestimmten Client-ISPs 114 haben, und kann infolgedessen das System 100 verwendet werden, um zu bestimmen, ob - obwohl ein aktueller ISP 110 keinerlei Probleme haben kann - der aktuelle Transit-ISP 110 eine schlechte Verbindung mit dem Client-ISP 114 hat, und kann infolgedessen ein Umschalten bzw. Wechsel verursacht werden. Als ein weiteres Beispiel kann es Netzwerküberwacher 116, Netzwerkrichtlinien-Engines 118 und/oder Netzwerkkonfiguratoren 120 für die Verkehrsoptimierung pro Client-ISP 114 über Transit-ISPs 110 geben. Beispielsweise können auf der Grundlage von Anwendungssitzungsdaten Erkundungs- und Ausnutzungsmodelle erstellt und auf Verbesserungen der Netzwerkleistung überwacht werden. Die Client-ISPs 114 können dann über bestimmte Transit-ISPs 110 geroutet werden, um die Netzwerkqualität und das Benutzererlebnis zu verbessern.
  • In einigen Ausführungsformen können Netzüberwacher 116 Warn- bzw. Meldebedingungen aufweisen, die vorübergehend sind und sich innerhalb eines sehr kurzen Zeitraums mehrfach wiederholen. Um zu verhindern, dass das Teilsystem häufige Netzwerkpfadänderungen vornimmt, kann ein konfigurierbarer Löschverzögerungsparameter pro Netzmonitor 116 vorhanden sein. Der Löschverzögerungsparameter kann das Löschen der Netzwerkpfadänderungen für einen bestimmten Zeitraum (z.B. zwanzig Minuten, dreißig Minuten usw.) rückgängig machen oder verzögern. Jede weitere Meldung während dieses Zeitraums kann den Zeitgeber zurücksetzen. In einigen Beispielen haben die Netzwerküberwacher 116 (z.B. der Netzwerküberwacher für den Sitzungsleistungsgewinn) möglicherweise keine Möglichkeit, sich selbst zu überprüfen und Meldungen zu löschen, sobald der Verkehr nach einer Meldung aus einem bestimmten Pfad entfernt wurde. In solchen Fällen kann das Teilsystem einen konfigurierbaren Parameter für die automatische Löschung unterstützen, mit dem Meldungen nach einer bestimmten konfigurierbaren Zeitspanne gelöscht werden können.
  • Nun auf auf 4-6 Bezug nehmend, umfasst jeder Block der hierin beschriebenen Verfahren 400-600 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Anweisungen ausführt. Die Verfahren 400-600 können auch als computerverwendbare Anweisungen auf Computerspeichermedien gespeichert sein. Die Verfahren 400-600 können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Darüber hinaus werden die Verfahren 400-600 beispielhaft für das System 100 von 1 beschrieben. Dieses Verfahren kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich der, aber nicht beschränkt auf die hierin beschriebenen Systeme.
  • Nun auf 4 Bezug nehmend, ist 4 ein Ablaufdiagramm, das ein Verfahren 400 zur Aktualisierung des Netzwerkverkehr-Routings auf der Grundlage von überwachten Netzwerkleistungsparametern zeigt, gemäß einigen Ausführungsformen der Erfindung. Das Verfahren 400 umfasst bei einem Block B402 ein Übertragen einer ersten Testprobe über einen ersten Netzwerkpfad über einen ersten ISP und einer zweiten Testprobe über einen zweiten Netzwerkpfad über einen zweiten ISP. Beispielsweise kann eine erste Testprobe über einen Netzwerkpfad übertragen werden, der den Transit-ISP 110A beinhaltet, und kann eine zweite Testprobe über einen Netzwerkpfad übertragen werden, der den Transit-ISP 110B beinhaltet.
  • Das Verfahren 400 umfasst bei einem Block B404 ein Analysieren erster Daten, die für erste Qualitätsmetriken, die dem ersten Netzwerkpfad entsprechen, und zweite Qualitätsmetriken, die dem zweiten Netzwerkpfad entsprechen, repräsentativ sind. Beispielsweise können die Netzwerkleistung und/oder Anwendungsleistungsmetriken von dem/den Netzwerküberwacher(n) 116 für Netzwerkpfade über die Transit-ISPs 110A und 110B überwacht werden, und kann/können die Netzwerkrichtlinien-Engine(s) 118 die Daten daraus analysieren.
  • Das Verfahren 400 umfasst bei einem Block B406 ein Empfangen von zweiten Daten, die für eine Meldung repräsentativ sind, die anzeigt, dass der erste Netzwerkpfad von höherer Qualität ist als der zweite Netzwerkpfad. Beispielsweise kann ein Netzwerküberwacher 116 eine Meldung erzeugen, und kann die Netzwerkrichtlinien-Engine 118 die Informationen aus der Meldung entsprechend jedem Netzwerkpfad analysieren, um zu bestimmen, dass ein erster Netzwerkpfad besser ist als ein zweiter Netzwerkpfad.
  • Das Verfahren 400 umfasst bei einem Block B408 ein Bestimmen, einen aktuellen Netzwerkpfad, der den zweiten ISP beinhaltet, auf einen aktualisierten Netzwerkpfad, der den ersten ISP beinhaltet, zu ändern. Beispielsweise können die Netzwerkrichtlinien-Engine(s) 118 bestimmen, dass Richtlinienaktualisierungen implantiert werden sollten, um die Netzwerkpfade zu wechseln bzw. umzuschalten.
  • Das Verfahren 400 umfasst bei einem Block B410 ein Bestimmen aktualisierter Richtlinien für ein oder mehrere Netzwerkgeräte. Beispielsweise kann/können der/die Netzwerkkonfigurator(en) 120 die Aktualisierungen für das/die Netzwerkgerät(e) 124 - wie beispielsweise die Core-Switches - bestimmen, um die Routenkarten zu aktualisieren.
  • Das Verfahren 400 umfasst bei einem Block B412 ein Übertragen dritter Daten, die für die aktualisierten Richtlinien repräsentativ sind, an das/die Netzwerkgerät(e). Beispielsweise kann/können der/die Netzwerkkonfigurator(en) 120 die Richtlinienaktualisierungen an das/die Netzwerkgerät(e) 124 übertragen.
  • Mit Bezug auf 5 ist 5 ein Ablaufdiagramm, das ein Verfahren 500 zur Aktualisierung des Netzwerkverkehrs-Routings auf der Grundlage von überwachten Netzwerkleistungsparametern zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 500 umfasst bei einem Block B502 ein Übertragen von Pings von einer Webüberwachungsplattform an ein Multihomed-Rechenzentrum über einen ersten ISP. Zum Beispiel können die Netzwerküberwachungsplattform(en) 116B Pings an den Transit-ISP 110A übertragen.
  • Das Verfahren 500 umfasst bei einem Block B504 ein Bestimmen, dass eine Anzahl von Zustandsänderungen, die dem ersten ISP entsprechen, größer ist als eine Schwellenanzahl von Zustandsänderungen über einen vorbestimmten Zeitraum. Beispielsweise kann der/die Netzwerküberwacher 116B eine Meldung auf der Grundlage der Anzahl der Zustandsänderungen erzeugen, die einen Schwellenwert über einen bestimmten Zeitraum hinweg überschreiten.
  • Das Verfahren 500 umfasst bei einem Block B506 ein Übertragen erster Daten, die für eine Meldung repräsentativ sind, die anzeigt, dass die Anzahl der Zustandsänderungen größer ist als die Schwellenzahl der Zustandsänderungen. Beispielsweise kann/können der/die Netzwerküberwacher 116 die Meldung - z.B. im NPI-Datenformat - an die Netzwerkrichtlinien-Engine(s) 118 übertragen.
  • Das Verfahren 500 umfasst bei einem Block B508 ein Bestimmen, auf der Grundlage der Meldung von dem ersten ISP zu dem zweiten ISP zu wechseln. Beispielsweise kann/können die Netzwerkrichtlinien-Engine(s) 118 bestimmen, dass ein Wechsel der Transit-ISPs 110 vorgenommen werden sollte.
  • Das Verfahren 500 umfasst bei einem Block B510 ein Bestimmen aktualisierter Richtlinien, um den Wechsel von dem ersten ISP zu dem zweiten ISP zu veranlassen. Beispielsweise kann/können der/die Netzwerkkonfigurator(en) 120 die Aktualisierungen bestimmen, die an dem/den Netzwerkgerät(en) 124 vorgenommen werden sollten.
  • Das Verfahren 500 umfasst bei einem Block B512 ein Aktualisieren aktueller Richtlinien auf aktualisierte Richtlinien auf der Grundlage von zweiten Daten, die für die aktualisierten Richtlinien repräsentativ sind. Beispielsweise können die aktualisierten Richtlinien an das/die Netzwerkgerät(e) 124 übertragen werden, um die Aktualisierung der Richtlinien zu veranlassen.
  • Nun auf 6 Bezug nehmend, ist 6 ein Ablaufdiagramm, das ein Verfahren 600 zur Aktualisierung des Netzwerkverkehrsroutings auf der Grundlage von überwachten Anwendungsleistungsparametern zeigt, gemäß einigen Ausführungsformen der Erfindung. Das Verfahren 600 umfasst bei einem Block B602 ein Bestimmen eines ersten Sitzungsleistungsgewinns für eine erste Vielzahl von Sitzungen einer Streaming-Anwendung über einen ersten ISP und eines zweiten Sitzungsleistungsgewinns für eine zweite Vielzahl von Sitzungen einer Streaming-Anwendung über einen zweiten ISP. Beispielsweise können ein oder mehrere Netzwerküberwacher 116 den Sitzungsleistungsgewinn und/oder die Anzahl von Sitzungen über Netzwerkpfade mit verschiedenen Transit-ISPs 110 bestimmen.
  • Das Verfahren 600 umfasst bei einem Block B604 ein Bestimmen, dass der erste Sitzungsleistungsgewinn unter einem Schwellenwert liegt und dass der zweite Sitzungsleistungsgewinn größer ist als der erste Sitzungsleistungsgewinn. Beispielsweise kann/können die Netzwerkrichtlinien-Engine(s) 118 auf der Grundlage einer Meldung von dem/den Netzwerküberwacher(n) 116 bestimmen, dass der Sitzungsleistungsgewinn über einen aktuellen Transit-ISP 110 schlechter als ein Schwellenwert ist und dass der Sitzungsleistungsgewinn über einen anderen Transit-ISP 110 besser ist.
  • Das Verfahren 600 umfasst bei einem Block B606 ein Bestimmen einer aktualisierten BGP-Import-Routenkarte und/oder einer aktualisierten BGP-Export-Routenkarte. Beispielsweise können der/die Netzwerkkonfigurator(en) 120 die aktualisierten BGP-Import-Routenkarten und/oder die aktualisierten BGP-Export-Routenkarten bestimmen, um einen Wechsel zu einem leistungsfähigeren Transit-ISP 110 zu veranlassen.
  • Das Verfahren 600 beinhaltet bei einem Block B608 ein Veranlassen eines Netzwerkwechsels bzw. einer Netzwerkumschaltung zur Aktualisierung interner Richtlinien auf der Grundlage der aktualisierten BGP-Import-Routenkarte und/oder der aktualisierten BGP-Export-Routenkarte. Beispielsweise kann/können der/die Netzwerkkonfigurator(en) 120 das/die Netzwerkgerät(e) 124 - z.B. einen oder mehrere Core-Switch(es) - veranlassen, interne Richtlinien zu aktualisieren.
  • BEISPIELHAFTES SPIEL-STREAMING-SYSTEM
  • Nun auf 7 Bezug nehmend, ist 7 ein beispielhaftes Systemdiagramm für ein Spiel-Streaming-System 700 gemäß einigen Ausführungsformen der Erfindung. 7 beinhaltet einen oder mehrere Spielserver 702 (die ähnliche Komponenten, Merkmale und/oder Funktionen wie die beispielhafte Rechenvorrichtung 800 von 8 beinhalten können), ein oder mehrere Client-Geräte 704 (die ähnliche Komponenten, Merkmale und/oder Funktionen wie die beispielhafte Rechenvorrichtung 800 von 8 beinhalten können) und ein oder mehrere Netzwerke 706 (die ähnlich wie die hierin beschriebenen Netzwerke sein können). In einigen Ausführungsformen der Erfindung kann das System 700 implementiert sein.
  • In dem System 700 kann/können für eine Spielsitzung das/die Client-Gerät(e) 704 nur Eingabedaten im Ansprechen auf Eingaben an die Eingabevorrichtung(en) empfangen, die Eingabedaten an den/die Spielserver 702 übertragen, kodierte Anzeigedaten von dem/den Spielserver(n) 702 empfangen und die Anzeigedaten auf der Anzeige 724 anzeigen. So werden die rechenintensiveren Berechnungen und Verarbeitungen auf den/die Spieleserver 702 verlagert (z.B. wird das Rendering - insbesondere das Strahlen- oder Pfad-Tracing - für eine grafische Ausgabe der Spielsitzung von der/den GPU(s) des/der Spieleserver(s) 702 ausgeführt). Mit anderen Worten wird die Spielsitzung von dem/den Spielserver(n) 702 auf das/die Client-Gerät(e) 704 gestreamt, wodurch die Anforderungen des/der Client-Gerät(e) 704 an die Grafikverarbeitung und das Rendering reduziert werden.
  • Beispielsweise kann in Bezug aus eine Instanziierung einer Spielsitzung ein Client-Gerät 704 einen Frame bzw. ein Einzelbild der Spielsitzung auf der Anzeige 724 anzeigen, auf der Grundlage eines Empfangens der Anzeigedaten von dem/den Spielserver(n) 702. Das Client-Gerät 704 kann eine Eingabe an eine der Eingabevorrichtungen empfangen und als Antwort Eingabedaten erzeugen. Das Client-Gerät 704 kann die Eingabedaten über die Kommunikationsschnittstelle 720 und über das/die Netzwerk(e) 706 (z.B. das Internet) an den/die Spielserver 702 übertragen, und der/die Spielserver 702 kann/können die Eingabedaten über die Kommunikationsschnittstelle 718 empfangen. Die CPU(s) kann/können die Eingabedaten empfangen, die Eingabedaten verarbeiten und Daten an den/die Grafikprozessor(en) übertragen, die den/die Grafikprozessor(en) veranlassen, ein Rendering der Spielsitzung zu erzeugen. Die Eingabedaten können beispielsweise eine Bewegung einer Figur des Benutzers in einem Spiel, das Abfeuern einer Waffe, das Nachladen, das Werfen eines Balls, das Wenden eines Fahrzeugs usw. repräsentieren. Die Rendering-Komponente 712 kann die Spielsitzung rendern (z.B. repräsentativ für das Ergebnis der Eingabedaten), und die Rendering-Erfassungskomponente 714 kann das Rendering der Spielsitzung als Anzeigedaten erfassen (z.B. als Bilddaten, die den gerenderten Frame der Spielsitzung erfassen). Das Rendering der Spielsitzung kann strahlen- oder pfadverfolgte Beleuchtungs- und/oder Schatteneffekte beinhalten, die unter Verwendung einer oder mehrerer paralleler Verarbeitungseinheiten - wie z.B. GPUs, die darüber hinaus die Verwendung eines oder mehrerer dedizierter Hardwarebeschleuniger oder Verarbeitungskerne zur Durchführung von Strahlen- oder Pfadverfolgungstechniken nutzen können - des/der Spielserver(s) 702 berechnet werden. Der Kodierer 716 kann dann die Anzeigedaten kodieren, um kodierte Anzeigedaten zu erzeugen, und die kodierten Anzeigedaten können über die Kommunikationsschnittstelle 718 über das/die Netzwerk(e) 706 an das Client-Gerät 704 übertragen werden. Das Client-Gerät 704 kann die kodierten Anzeigedaten über die Kommunikationsschnittstelle 720 empfangen, und der Dekodierer 722 kann die kodierten Anzeigedaten dekodieren, um die Anzeigedaten zu erzeugen. Das Client-Gerät 704 kann dann die Anzeigedaten über das Display 724 anzeigen.
  • BEISPIELHAFTE RECHENVORRICHTUNG
  • 8 ist ein Blockdiagramm einer oder mehrerer beispielhaften Rechenvorrichtung(en) 800, die zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist. Die Rechenvorrichtung 800 kann ein Interconnect-System bzw. Verbindungssystem 802 enthalten, das direkt oder indirekt die folgenden Vorrichtungen koppelt: einen Speicher 804, eine oder mehrere Zentralverarbeitungseinheiten (CPUs) 806, eine oder mehrere Grafikverarbeitungs-einheiten (GPUs) 808, eine Kommunikationsschnittstelle 810, Ein-/Ausgabe-anschlüsse (E/A) 812, Ein-/Ausgabekomponenten 814, eine Stromversorgung 816, eine oder mehrere Präsentationskomponenten 818 (z.B. Anzeige(n)) und eine oder mehrere Logikeinheiten 820.
  • Obwohl die verschiedenen Blöcke in 8 als über das Verbindungssystem 802 mit Leitungen verbunden dargestellt sind, soll dies nicht beschränkend sein und nur der Klarheit dienen. In einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente 818, wie z.B. eine Anzeigevorrichtung, als eine E/A-Komponente 814 betrachtet werden (z.B. falls die Anzeige ein Touchscreen ist). Als ein weiteres Beispiel können die CPUs 806 und/oder GPUs 808 Speicher enthalten (z.B. kann der Speicher 804 zusätzlich zu dem Speicher der GPUs 808, der CPUs 806 und/oder anderer Komponenten eine Speichereinrichtung repräsentieren). Mit anderen Worten ist die Rechenvorrichtung von 8 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da sie alle in den Anwendungsbereich der Rechenvorrichtung von 8 fallen.
  • Das Verbindungssystem 802 kann eine oder mehrere Verbindungen oder Busse repräsentieren, wie z.B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 802 kann einen oder mehrere Bus- oder Verbindungsarten umfassen, wie beispielsweise einen ISA (Industry Standard Architecture)-Bus, einen EISA (Extended Industry Standard Architecture)-Bus, einen VESA (Video Electronics Standards Association)-Bus, einen PCI (Peripheral Component Interconnect)-Bus, einen PCle (Peripheral Component Interconnect Express)-Bus und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. Als ein Beispiel kann die CPU 806 direkt mit dem Speicher 804 verbunden sein. Außerdem kann die CPU 806 direkt mit der GPU 808 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 802 eine PCIe-Verbindung beinhalten, um die Verbindung herzustellen. In diesen Beispielen braucht ein PCI-Bus nicht in der Rechenvorrichtung 800 enthalten zu sein.
  • Der Speicher 804 kann einen beliebigen von einer Vielzahl von computerlesbaren Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf die die Rechenvorrichtung 800 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien umfassen. Als Beispiel und ohne Beschränkung darauf können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien beinhalten.
  • Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 804 computerlesbare Anweisungen speichern (z.B. solche, die ein Programm bzw. Programme und/oder ein Programmelement bzw. Programmelemente darstellen, wie z.B. ein Betriebssystem. Die Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das die Rechenvorrichtung 800 zugreifen kann, beinhalten. Wie hierin verwendet, umfassen Computerspeichermedien nicht Signale per se.
  • Die Computerspeichermedien können computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so festgelegt oder verändert wurden, dass Informationen in dem Signal kodiert werden. Die Computerspeichermedien können beispielsweise und nicht beschränkt darauf verdrahtete Medien, wie beispielsweise ein verdrahtetes Netzwerk oder eine direkte Kabelverbindung, und drahtlose Medien, wie beispielsweise akustische, HF-, Infrarot- und andere drahtlose Medien, umfassen. Kombinationen beliebiger der oben genannten Medien sollten ebenfalls in den Bereich computerlesbarer Medien fallen.
  • Die CPU(s) 806 kann/können dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 800 zu steuern, um eines/einen oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 806 kann/können jeweils einen oder mehrere Kerne (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 806 kann/können einen beliebigen Prozessortyp umfassen und je nach Art der implementierten Rechenvorrichtung 800 unterschiedliche Prozessortypen umfassen (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art des Rechengeräts 800 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) arbeitet, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) arbeitet. Die Rechenvorrichtung 800 kann eine oder mehrere CPUs 806 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z.B. mathematischen Co-Prozessoren, beinhalten.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 806 kann/können die GPU(s) 808 dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 800 zu steuern, um eines/einen oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 808 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 806 und/oder eine oder mehrere der GPU(s) 808 können eine diskrete GPU sein. In Ausführungsformen kann eine oder mehrere der GPU(s) 808 ein Coprozessor einer oder mehrerer der CPU(s) 806 sein. Der/die Grafikprozessor(en) 808 kann/können von der Rechenvorrichtung 800 zum Rendern von Grafiken (z.B. 3D-Grafiken) oder zur Durchführung von allgemeinen Berechnungen verwendet werden. Die GPU(s) 808 kann/können zum Beispiel für General-Purpose Computing on GPUs (GPGPU) verwendet werden. Die GPU(s) 808 kann/können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 808 kann/können im Ansprechen auf Rendering-Befehle (z.B. Rendering-Befehle von der/den CPU(s) 806, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 808 kann/können einen Grafikspeicher, z.B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, z.B. GPGPU-Daten, beinhalten. Der Anzeigespeicher kann als Teil des Speichers 804 enthalten sein. Die GPU(s) 808 kann/können zwei oder mehr GPUs umfassen, die parallel arbeiten (z.B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z.B. mit NVLINK) oder die GPUs über einen Switch verbinden (z.B. mit NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 808 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher haben oder sich den Speicher mit anderen GPUs teilen.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 806 und/oder der/den GPU(s) 808 kann/können die Logikeinheit(en) 820 dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 800 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 806, die GPU(s) 808 und/oder die Logikeinheit(en) 820 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 820 können Teil einer oder mehrerer der CPU(s) 806 und/oder der GPU(s) 808 sein und/oder eine oder mehrere der Logikeinheiten 820 können diskrete Komponenten oder anderweitig außerhalb der CPU(s) 806 und/oder der GPU(s) 808 sein. In Ausführungsformen kann eine oder mehrere der Logikeinheiten 820 ein Coprozessor einer oder mehrerer der CPU(s) 806 und/oder einer oder mehrerer der GPU(s) 808 sein.
  • Beispiele für die Logikeinheit(en) 820 umfassen einen oder mehrere Rechenkerne und/oder Komponenten davon, wie Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AlAs), Deep Learning Accelerators (DLAs), Arithmetik-LogikEinheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Eingabe-/Ausgabe-Elemente (E/A), Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 810 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es der Rechenvorrichtung 800 ermöglichen, mit anderen Computergeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 810 kann Komponenten und Funktionen beinhalten, die die Kommunikation über eine Reihe verschiedener Netzwerke, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z.B. LoRaWAN, SigFox usw.) und/oder das Internet ermöglichen.
  • Über die E/A-Anschlüsse 812 kann die Rechenvorrichtung 800 logisch mit anderen Geräten, darunter die E/A-Komponenten 814, die Präsentationskomponente(n) 818 und/oder andere Komponenten, von denen einige in die Rechenvorrichtung 800 eingebaut (z.B. integriert) sein können, gekoppelt sein. Illustrative E/A-Komponenten 814 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 814 können eine natürliche Benutzerschnittstelle (NUI, natural user interface) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch in der Nähe des Bildschirms, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten ausführlicher beschrieben) in Verbindung mit einer Anzeige der Rechenvorrichtung 800 implementieren. Die Rechenvorrichtung 800 kann Tiefenkameras, wie stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung enthalten. Darüber hinaus kann die Rechenvorrichtung 800 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU; inertia measurement unit)) enthalten, die die Erfassung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Rechenvorrichtung 800 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
  • Die Stromversorgung 816 kann eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon sein. Die Stromversorgung 816 kann die Rechenvorrichtung 800 mit Strom versorgen, um den Betrieb der Komponenten der Rechenvorrichtung 800 zu ermöglichen.
  • Die Präsentationskomponente(n) 818 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 818 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 808, der/den CPU(s) 806 usw.) empfangen und die Daten ausgeben (z.B. als Bild, Video, Ton usw.).
  • Die Erfindung kann in dem allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich computerausführbaren Anweisungen wie beispielsweise Programmmodulen, , die von einem Computer oder einer anderen Maschine, z.B. einem persönlichen Datenassistenten oder einem anderen Handheld-Gerät, ausgeführt werden, beschrieben werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Erfindung kann in einer Vielzahl von Systemkonfigurationen angewendet werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Datenverarbeitungsgeräten usw. Die Erfindung kann auch in verteilten Computerumgebungen angewendet werden, in denen Aufgaben von ferngesteuerten Geräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind.
  • Wie hierin verwendet, sollte die Verwendung von „und/oder“ in Bezug auf zwei oder mehr Elemente so verstanden werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. So kann beispielsweise „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B beinhalten.
  • Der Gegenstand der Erfindung wird hierin mit einer Genauigkeit beschrieben, die gesetzlichen Anforderungen entspricht. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht beschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der angewandten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
  • Wie vorstehend beschrieben wurde, überwacht eine erweiterbare Netzwerkverkehrstechnik-Plattform den Netzwerkverkehr und die Anwendungsleistung, um die Kommunikationspfade für den Netzwerkeingang und -ausgang dynamisch zu aktualisieren, um die Leistung der Anwendung - wie beispielsweise einer Cloud Gaming-Anwendung, einer Cloud VR (Virtual Reality)-Anwendung und/oder anderer Arten von Hochleistungsanwendungen zu erhöhen. Einbindbare, verteilte, anwendungszentrierte Netzwerküberwacher, Richtlinien-Engines und Netzwerkkonfiguratoren werden an der Netzwerkgrenze implementiert, um eine verminderte Netzwerk- und Anwendungsleistung zu erfassen und das Netzwerk-Routing dynamisch zu aktualisieren, um dem Rechnung zu tragen.

Claims (26)

  1. Verfahren, umfassend: Übertragen einer ersten Testprobe über einen ersten Netzwerkpfad über einen ersten Internetdienstanbieter (ISP) eines Rechenzentrums und einer zweiten Testprobe über einen zweiten Netzwerkpfad über einen zweiten ISP des Rechenzentrums, der sich von dem ersten ISP unterscheidet, wobei der erste Netzwerkpfad und der zweite Netzwerkpfad das Rechenzentrum mit einem oder mehreren Rechengeräten koppeln, die einen Dienst ausführen, der eine unter Verwendung des Rechenzentrums ausgeführte Anwendung unterstützt; Analysieren, unter Verwendung von Überwachungsagenten, die in dem Rechenzentrum und dem einen oder den mehreren Rechengeräten ausgeführt werden, erster Daten, die für erste Qualitätsmetriken repräsentativ sind, die dem ersten Netzwerkpfad entsprechen, und zweiter Daten, die für zweite Qualitätsmetriken repräsentativ sind, die dem zweiten Netzwerkpfad entsprechen; Bestimmen, unter Verwendung einer Netzwerkrichtlinien-Engine und zumindest teilweise auf der Grundlage eines Vergleichs zwischen den ersten und den zweiten Daten, einen aktuellen Netzwerkpfad, der den zweiten ISP beinhaltet, auf einen aktualisierten Netzwerkpfad, der den ersten ISP beinhaltet, zu ändern; Bestimmen, unter Verwendung eines Netzwerkkonfigurators, von aktualisierten Richtlinien für einen oder mehrere Core-Switches des Rechenzentrums, um zu veranlassen, dass der aktuelle Netzwerkpfad auf den aktualisierten Netzwerkpfad wechselt; und Übertragen dritter Daten, die für die aktualisierten Richtlinien repräsentativ sind, an einen oder mehrere Core-Switches.
  2. Verfahren nach Anspruch 1, wobei das Übertragen der ersten Testprobe über den ersten Netzwerkpfad über den ersten ISP und der zweiten Testprobe über den zweiten Netzwerkpfad über den zweiten ISP zumindest teilweise auf Edge-Switch-Netzwerk-Routing-Konfigurationen und Internetprotokoll (IP)-Differentiated Services Code Point (DSCP)-Parametern basiert.
  3. Verfahren nach Anspruch 1 oder 2, wobei die erste Qualitätsmetrik und die zweite Qualitätsmetrik jeweils einem oder mehreren von Verlust, Latenz oder Jitter entsprechen.
  4. Verfahren nach Anspruch 3, wobei ein gewichteter Durchschnitt eines oder mehrerer des Verlusts, der Latenz oder des Jitters für jeden des ersten Netzwerkpfads und des zweiten Netzwerkpfads berechnet wird und die Meldung zumindest teilweise auf der Grundlage eines Vergleichens des gewichteten Durchschnitts für den ersten Netzwerkpfad und den zweiten Netzwerkpfad erzeugt wird.
  5. Verfahren nach Anspruch 3 oder 4, wobei ein gewichteter Durchschnitt des einen oder der mehreren des Verlusts, der Latenz oder des Jitters für jeden des ersten Netzwerkpfads und des zweiten Netzwerkpfads berechnet wird, wobei der Verlust stärker gewichtet wird als der Jitter und der Jitter stärker gewichtet wird als die Latenz.
  6. Verfahren nach einem der vorangehenden Ansprüche, wobei die Netzwerkrichtlinien-Engine und der Netzwerkkonfigurator zumindest teilweise in dem Rechenzentrum ausgeführt werden.
  7. Verfahren nach einem der vorangehenden Ansprüche, wobei die Übertragung der ersten Testprobe über den ersten Netzwerkpfad über den ersten ISP und der zweiten Testprobe über den zweiten Netzwerkpfad über den zweiten ISP zumindest teilweise unter Verwendung des Border Gateway Protokolls (BGP) ausgeführt wird.
  8. Verfahren nach einem der vorangehenden Ansprüche, ferner umfassend: Empfangen einer Anzahl von Meldungen oberhalb einer Schwellenanzahl von Meldungen über eine vorbestimmte Zeitspanne, wobei jede Meldung der Anzahl von Meldungen zumindest teilweise auf der Grundlage einer Leistung des zweiten ISP, die besser als die des ersten ISP ist, oder der Leistung des ersten ISP, die besser als die des zweiten ISP ist, erzeugt wird; und Ignorieren zusätzlicher Meldungen nach der Meldungen der Anzahl von Meldungen, um eine Dämpfung durch den ersten ISP und/oder den zweiten ISP zu vermeiden.
  9. Verfahren nach einem der vorangehenden Ansprüche, ferner umfassend, dass nach einer Schwellenwert-Zeitspanne ausgehend von dem Empfang einer Meldung, ohne dass eine zusätzliche Meldung empfangen wird, die dem zweiten ISP entspricht, zu einem anderen Netzwerkpfad zurückgekehrt wird, der den zweiten ISP beinhaltet.
  10. Verfahren nach einem der vorangehenden Ansprüche, wobei die Überwachungsagenten mindestens eines sind von: Plugins; anwendungsspezifisch; oder Instanziierungen von containerisierten Anwendungen.
  11. Verfahren nach einem der vorangehenden Ansprüche, wobei mindestens eines der Überwachungsagenten, der Netzwerkrichtlinien-Engine oder der Netzwerkkonfigurator Instanziierungen von containerisierten Anwendungen entsprechen.
  12. System, umfassend: einen Web-Überwachungsagenten zum: Übertragen von Pings von einer Webüberwachungsplattform an ein Multihomed-Rechenzentrum über einen ersten Internetdienstanbieter (ISP) des Multihomed-Rechenzentrums; Bestimmen, zumindest teilweise auf der Grundlage der Pings, dass eine Anzahl von Zustandsänderungen, die dem ersten ISP entsprechen, größer ist als eine Schwellenanzahl von Zustandsänderungen über eine vorbestimmte Zeitspanne; und Übertragen von ersten Daten, die für eine Meldung repräsentativ sind, die anzeigt, dass die Anzahl der Zustandsänderungen größer ist als die Schwellenanzahl der Zustandsänderungen über die vorbestimmte Zeitspanne; eine Netzwerkrichtlinien-Engine zum: Empfangen der ersten Daten; und Bestimmen, zumindest teilweise auf der Grundlage der Meldung, von dem ersten ISP weg zu einem zweiten ISP des Multihomed-Rechenzentrums hin zu schalten; einen Netzwerkkonfigurator zum: Bestimmen aktualisierter Richtlinien, um das Wegschalten von dem ersten ISP hin zu dem zweiten ISP zu veranlassen; und Übertragen zweiter Daten, die für die aktualisierten Richtlinien repräsentativ sind; und einen oder mehrere Core-Switches des Multihomed-Rechenzentrums zum: Empfangen der zweiten Daten; und Aktualisieren aktueller Richtlinien auf die aktualisierten Richtlinien zumindest teilweise auf der Grundlage der zweiten Daten.
  13. System nach Anspruch 12, wobei die Netzwerkrichtlinien-Engine und der Netzwerkkonfigurator in dem Multihomed-Rechenzentrum ausgeführt werden.
  14. System nach Anspruch 12 oder 13, wobei der Web-Überwachungsagent unter Verwendung eines oder mehrerer Rechengeräte ausgeführt wird, die sich in Bezug auf das Multihomed-Rechenzentrum entfernt befinden, und wobei ferner die Pings von dem einen oder den mehreren Rechengeräten über ein oder mehrere zwischengeschaltete autonome Systeme übertragen werden, bevor sie ein autonomes System des ersten ISP erreichen.
  15. System nach einem der Ansprüche 12 bis 14, wobei die aktualisierten Richtlinien bewirken, dass mindestens eine von aktuellen Import-Routenkarten auf aktualisierte Import-Routenkarten geändert wird, oder mindestens eine von aktuellen Export-Routenkarten auf aktualisierte Export-Routenkarten geändert wird.
  16. System nach Anspruch 15, wobei die aktualisierten Export-Routenkarten durch Voranstellen eines oder mehrerer autonomer Systempfade an einen Border Gateway Protokoll (BGP)-Header erzeugt werden.
  17. System nach einem der Ansprüche 12 bis 16, wobei der Web-Überwachungsagent, die Netzwerkrichtlinien-Engine und der Netzwerkkonfigurator Instanziierungen von containerisierten Anwendungen entsprechen.
  18. System nach einem der Ansprüche 12 bis 17, wobei der Web-Überwachungsagent mindestens eines ist von: einem Plugin; anwendungsspezifisch; oder einer Instanziierung einer containerisierten Anwendung.
  19. System nach einem der Ansprüche 12 bis 18, wobei mindestens eines des Web-Überwachungsagenten, der Netzwerkrichtlinien-Engine oder des Netzwerkkonfigurators Instanziierungen von containerisierten Anwendungen entspricht.
  20. Verfahren, umfassend: Bestimmen, unter Verwendung eines Überwachungsagenten-Plugins und über eine Zeitspanne, eines ersten Sitzungsleistungsgewinns für eine erste Vielzahl von Sitzungen einer Streaming-Anwendung über einen ersten Internetdienstanbieter (ISP), und eines zweiten Sitzungsleistungsgewinns für eine zweite Vielzahl von Sitzungen der Streaming-Anwendung über einen zweiten ISP; Bestimmen, unter Verwendung des Überwachungsagenten-Plugins, dass der erste Sitzungsleistungsgewinn unter einem Schwellenwert liegt und dass der zweite Sitzungsleistungsgewinn größer ist als der erste Sitzungsleistungsgewinn; Bestimmen, unter Verwendung eines Netzwerkrichtlinien-Plugins und zumindest teilweise basierend darauf, dass der erste Sitzungsleistungsgewinn unter dem Schwellenwert liegt und der zweite Sitzungsleistungsgewinn größer als der erste Sitzungsleistungsgewinn ist, mindestens eines einer aktualisierten Border Gateway Protokoll (BGP)-Import-Routenkarte oder einer aktualisierten BGP-Export-Routenkarte; und Veranlassen, unter Verwendung eines Netzwerkkonfigurator-Plugins, dass interne Richtlinien zumindest teilweise auf der Grundlage der aktualisierten BGP-Import-Routenkarte oder der aktualisierten BGP-Export-Routenkarte aktualisiert werden.
  21. Verfahren nach Anspruch 20, wobei die Streaming-Anwendung eine Cloud Gaming-Anwendung ist und das Überwachungsagenten-Plugin, das Netzwerkrichtlinien-Plugin und das Netzwerkkonfigurator-Plugin in einem Rechenzentrum ausgeführt werden, das die Cloud Gaming-Anwendung hostet.
  22. Verfahren nach Anspruch 20 oder 21, wobei die Bestimmung der aktualisierten Export-BGP-Routenkarte den Netzwerk-Switch veranlasst, einen oder mehrere autonome Systempfade einem BGP-Header voranzustellen.
  23. Verfahren nach einem der Ansprüche 20 bis 22, wobei die Bestimmung mindestens eines der aktualisierten Border Gateway Protokoll (BGP)-Import-Routenkarte oder der aktualisierten BGP-Export-Routenkarte zumindest teilweise darauf basiert, dass der zweite Sitzungsleistungsgewinn größer als ein anderer Schwellenwert ist.
  24. Verfahren nach einem der Ansprüche 20 bis 23, wobei das Überwachungsagenten-Plugin, das Netzwerkrichtlinien-Plugin und das Netzwerkkonfigurator-Plugin Instanziierungen von containerisierten Anwendungen entsprechen, die in einem Rechenzentrum ausgeführt werden, das zumindest teilweise die erste Vielzahl von Sitzungen und die zweite Vielzahl von Sitzungen hostet.
  25. Verfahren nach einem der Ansprüche 20 bis 24, wobei das Bestimmen des ersten Sitzungsleistungsgewinns und des zweiten Sitzungsleistungsgewinns unter Verwendung des Überwachungsagenten-Plugins ein Übertragen anwendungsspezifischer Daten entsprechend der Streaming-Anwendung über das Internet unter Verwendung des ersten ISP und des zweiten ISP beinhaltet.
  26. Verfahren nach einem der Ansprüche 20 bis 25, wobei mindestens eines der Plugins für den Überwachungsagenten, des Plugins für die Netzwerkrichtlinie oder des Plugins für den Netzwerkkonfigurator Instanziierungen einer containerisierten Anwendung entspricht.
DE102021119015.0A 2020-07-24 2021-07-22 Erweiterbare plattform für netzwerkverkehrstechnik zur erhöhung der netzwerkresilienz in cloud-anwendungen Pending DE102021119015A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/938,184 US11456941B2 (en) 2020-07-24 2020-07-24 Extensible network traffic engineering platform for increasing network resiliency in cloud applications
US16/938,184 2020-07-24

Publications (1)

Publication Number Publication Date
DE102021119015A1 true DE102021119015A1 (de) 2022-01-27

Family

ID=79179612

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021119015.0A Pending DE102021119015A1 (de) 2020-07-24 2021-07-22 Erweiterbare plattform für netzwerkverkehrstechnik zur erhöhung der netzwerkresilienz in cloud-anwendungen

Country Status (3)

Country Link
US (2) US11456941B2 (de)
CN (1) CN113973077B (de)
DE (1) DE102021119015A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10560326B2 (en) * 2017-09-22 2020-02-11 Webroot Inc. State-based entity behavior analysis
US20220368622A1 (en) * 2021-05-11 2022-11-17 Jpmorgan Chase Bank, N.A. Systems and methods for network optimization using end user telemetry
US11611566B2 (en) * 2021-06-25 2023-03-21 Microsoft Technology Licensing, Llc Automatic verification of safety for virtualized networks
US11706130B2 (en) * 2021-07-19 2023-07-18 Cisco Technology, Inc. Root-causing user experience anomalies to coordinate reactive policies in application-aware routing
US20230022959A1 (en) * 2021-07-20 2023-01-26 Cisco Technology, Inc. Detecting critical regions and paths in the core network for application-driven predictive routing
US11570058B1 (en) * 2021-10-05 2023-01-31 Bank Of America Corporation Auto simulation of connectivity checks from the client side
US11711279B2 (en) * 2021-10-26 2023-07-25 Juniper Networks, Inc. Application records using session information
US20230198878A1 (en) * 2021-12-20 2023-06-22 Tibit Communications, Inc. Method and system for network segment performance monitoring
US11805048B1 (en) * 2022-04-27 2023-10-31 At&T Intellectual Property I, L.P. Dynamic network metric sharing and application metric based network path selection
US20230362083A1 (en) * 2022-05-03 2023-11-09 Microsoft Technology Licensing, Llc Monitoring for inconsistent latency in data centers

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004056047A1 (en) * 2002-12-13 2004-07-01 Internap Network Services Corporation Topology aware route control
KR100542341B1 (ko) * 2003-02-19 2006-01-10 삼성전자주식회사 비쥐피 프로토콜을 분산 처리하는 장치 및 그 방법
US7769884B2 (en) * 2003-10-31 2010-08-03 International Business Machines Corporation Network route control
US7710865B2 (en) * 2005-02-25 2010-05-04 Cisco Technology, Inc. Disaster recovery for active-standby data center using route health and BGP
US7995465B2 (en) * 2007-05-18 2011-08-09 Nvidia Corporation Intelligent load balancing and failover of network traffic
US8750288B2 (en) * 2012-06-06 2014-06-10 Juniper Networks, Inc. Physical path determination for virtual network packet flows
US9503343B2 (en) * 2012-12-14 2016-11-22 Ca, Inc. Method and system for detecting network topology change
US9356871B2 (en) * 2013-03-15 2016-05-31 Cisco Technology, Inc. Programmable management engine for networks
US9887874B2 (en) * 2014-05-13 2018-02-06 Cisco Technology, Inc. Soft rerouting in a network using predictive reliability metrics
US10439909B2 (en) * 2014-05-16 2019-10-08 Cisco Technology, Inc. Performance monitoring in a multi-site environment
AU2015346090B2 (en) * 2014-11-14 2019-11-28 Bigleaf Networks, Inc. Circuit-aware load balancing with dynamic quality of service
US9787579B2 (en) * 2015-04-06 2017-10-10 Verizon Digital Media Services Inc. Application controlled path selection based on type-of-service
US11102273B2 (en) * 2015-05-13 2021-08-24 Cisco Technology, Inc. Uplink performance management
US9929949B2 (en) * 2015-06-29 2018-03-27 Google Llc Systems and methods for inferring network topology and path metrics in wide area networks
US10187321B2 (en) * 2015-08-19 2019-01-22 Cisco Technology, Inc. Dynamic VPN policy model with encryption and traffic engineering resolution
US9942631B2 (en) * 2015-09-25 2018-04-10 Intel Corporation Out-of-band platform tuning and configuration
US10079863B2 (en) * 2015-11-18 2018-09-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10158679B2 (en) * 2015-11-18 2018-12-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10116524B2 (en) * 2016-02-29 2018-10-30 Wesley Howard Jensen Machine-learning optimization for computing networks
EP3552430B1 (de) * 2016-12-12 2022-09-21 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und vorrichtung zur anpassung eines dienstkontinuitätsschwellwerts in einem drahtloskommunikationsnetzwerk
US11178030B2 (en) * 2017-04-20 2021-11-16 T-Mobile Usa, Inc. Mobile internet fallback/switchover and restore mechanism
CN108289064B (zh) * 2018-04-23 2021-07-27 清华大学深圳研究生院 一种数据中心网中混合式负载均衡方法
TWI813743B (zh) * 2018-08-23 2023-09-01 美商阿爾克斯股份有限公司 在網路路由環境中的獨立資料儲存空間
US20210211347A1 (en) * 2020-01-07 2021-07-08 Cisco Technology, Inc. Aggregated signal feedback for saas experience in multi-cloud sd-wan deployments
US11857872B2 (en) * 2020-07-21 2024-01-02 Nvidia Corporation Content adaptive data center routing and forwarding in cloud computing environments

Also Published As

Publication number Publication date
US20220029906A1 (en) 2022-01-27
CN113973077A (zh) 2022-01-25
US20230015677A1 (en) 2023-01-19
US11456941B2 (en) 2022-09-27
CN113973077B (zh) 2023-06-02
US11876697B2 (en) 2024-01-16

Similar Documents

Publication Publication Date Title
DE102021119015A1 (de) Erweiterbare plattform für netzwerkverkehrstechnik zur erhöhung der netzwerkresilienz in cloud-anwendungen
DE112020001459T5 (de) Konsistente Route-Ankündigungen zwischen redundanten Controllern im globalen Netzwerk-Access-Point
DE112021003383T5 (de) Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen
CN103384989B (zh) 用于对多个下一跳进行策略路由的系统和方法
DE112013006420B4 (de) Erweiterte Verbindungszusammenfassung (LAG) zur Nutzung in mehreren Switsches
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
CN102132255B (zh) 故障切换时使用备份虚拟服务器的指标通过多个虚拟服务器负载平衡的系统和方法
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
US20200296007A1 (en) Enriched flow data for network analytics
DE202015009244U1 (de) Routing von Datenverkehr innerhalb von und zwischen autonomen Systemen
DE112014000358T5 (de) Regionales Firewall-Clustering in einer vernetzten Datenverarbeitungsumgebung
DE112013003289T5 (de) Gerät, System und Verfahren für client-geregelte Sitzungspersistenz zwischen ein oder mehreren Clients und Servern eines Rechenzentrums
US11550621B2 (en) Distributable and customizable load-balancing of data-associated computation via partitions and virtual processes
DE112013006417B4 (de) Verlustfreie Schalterstruktur mit niedriger Latenzzeit zum Gebrauch in einem Rechenzentrum
DE112013000731T5 (de) Skallerbare virtuelle Geräte-Cloud
US20140173092A1 (en) Exchange of server health and client information through headers for request management
DE102017122738A1 (de) Virtueller Router mit dynamischer Flussauslagerungsfähigkeit
DE102014117460A1 (de) Programmierbares verteiltes Networking
DE112016003242T5 (de) System und verfahren zum handhaben von verbindungsverlust in einem netzwerk
DE102019104942A1 (de) Kommunikation einer Nachricht unter Verwendung einer Netzwerkschnittstellensteuerung in einem Subnetz
DE102018214007A1 (de) Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken
DE102018202432A1 (de) Strukturunterstützung für die Dienstgüte
Shurman et al. Collaborative execution of distributed mobile and IoT applications running at the edge
US10643010B2 (en) Scalable simulation system with scalable data propagation
US20230119908A1 (en) Simulation Systems and Methods Using Query-Based Interest

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012801000

Ipc: H04L0047100000