DE102022108273A1 - Plattform für automatische gruppierung und routing - Google Patents

Plattform für automatische gruppierung und routing Download PDF

Info

Publication number
DE102022108273A1
DE102022108273A1 DE102022108273.3A DE102022108273A DE102022108273A1 DE 102022108273 A1 DE102022108273 A1 DE 102022108273A1 DE 102022108273 A DE102022108273 A DE 102022108273A DE 102022108273 A1 DE102022108273 A1 DE 102022108273A1
Authority
DE
Germany
Prior art keywords
nodes
route
pcm
vpnc
connectivity
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
DE102022108273.3A
Other languages
English (en)
Inventor
Dilip Gupta
Harish Magganmane
Stephen Su
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.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
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 Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102022108273A1 publication Critical patent/DE102022108273A1/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/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/24—Multipath
    • 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/42—Centralised 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/58—Association of routers
    • H04L45/586—Association of routers of virtual routers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Es werden Systeme und Verfahren zur automatischen Gruppierung von Zweigstellengeräten auf der Grundlage von Geräteinformationen (z. B. IPSec-Tunnelkonnektivität usw.) bereitgestellt. Die Geräte mit ähnlichen Zweiggateways, die üblicherweise ähnliche Routeninformationen und/oder Eigenschaften (z. B. AS-PATH, Kosten, MED, Metric1, Metric2, Community/Extended Community) und/oder Geräte mit ähnlichen Konnektivitätsgraphen erhalten, können gruppiert werden. Dadurch kann die Zahl der elektronischen Mitteilungen im gesamten Netz verringert und die Recheneffizienz für den Controller und die Geräte erhöht werden.

Description

  • Hintergrund
  • Software-definierte Weitverkehrsnetze (SDWANs) sind Netztopologien, die Standorte eines Weitverkehrsnetzes (WAN) miteinander verbinden und dabei die Grundsätze des Software-definierten Netzwerks (SDN) nutzen, z. B. die Trennung der Steuerungsebene der Verkehrsverwaltung von der Datenweiterleitungsebene. SDWANs unterstützen die Konsolidierung der Infrastruktur durch Virtualisierung von Netzwerkfunktionen (NFV). NFV reduziert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN durch Virtualisierung der Netzwerkfunktionen mithilfe virtueller Maschinen auf gängiger und kostengünstigerer „Standard“-Hardware.
  • Figurenliste
  • Die vorliegende Offenbarung wird in Übereinstimmung mit einer oder mehreren verschiedenen Ausführungsformen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen lediglich der Veranschaulichung und stellen lediglich typische oder beispielhafte Ausführungsformen dar.
    • 1 zeigt ein Beispiel für eine SDWAN-Umgebung in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
    • 2 zeigt eine beispielhafte Systemarchitektur eines SDWAN-Overlay-Routing-Dienstes in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
    • 3 zeigt eine schematische Darstellung eines Beispiels eines Pfadberechnungsmoduls gemäß den Ausführungsformen der hier offengelegten Technologie.
    • 4 zeigt eine schematische Darstellung eines beispielhaften Cloud-Zweigstellen-Gateway-Protokolldienstes in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
    • 5 zeigt ein Beispiel für eine Computerkomponente in Übereinstimmung mit verschiedenen Ausführungsformen der hier offengelegten Technologie.
    • 6 zeigt eine schematische Darstellung einer Untergruppe von Virtual Private Network Clients (VPNCs), Knotengeräten und SDWAN Overlay Routing Service (SORS) in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
    • 7 zeigt die Gruppenzweiggeräte auf der Grundlage von Routeninformationen in Übereinstimmung mit den Ausführungsformen der hier offengelegten Technologie.
    • 8 zeigt ein Beispiel für eine Computerkomponente gemäß verschiedenen Ausführungsformen der hier offengelegten Technologie.
    • 9 ist ein Beispiel für eine Computerkomponente, die zur Implementierung verschiedener Merkmale der in der vorliegenden Offenbarung beschriebenen Ausführungsformen verwendet werden kann.
  • Die Abbildungen sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offengelegt wird.
  • Detaillierte Beschreibung
  • Ein softwaredefiniertes Weitverkehrsnetz (SDWAN) ermöglicht es einem Netzwerkadministrator, Zweigstellen über ein Weitverkehrsnetz (WAN) mit einem Hauptstandort zu verbinden. Die Verwendung von Software Defined Networking (SDN) entkoppelt die Entscheidungen über den Netzwerkverkehr von den verschiedenen Geräten innerhalb des Netzwerks, wie z. B. Routern, Switches, Brücken und anderen gängigen Netzwerkgeräten. Durch diese Entkopplung wird jedes Netzwerkgerät im Wesentlichen zu einem einfachen Gerät für die Weiterleitung von Paketen. Das SDWAN legt auf der Grundlage von Client-Richtlinien (z. B. QoS-Anforderungen, Bandbreite usw.) die potenziellen Verkehrswege durch jedes Netzwerkgerät fest, um die Zweigstellen innerhalb des SDWAN mit dem Kernstandort oder dem Rechenzentrum zu verbinden, das jedem Netzwerkgerät über einen Steuerkanal zur Verfügung gestellt wird. Anstatt eine Entscheidung über die Weiterleitung des Datenverkehrs zu treffen, wenn Daten empfangen werden, führen die Netzwerkgeräte einfach die vom SDWAN-Administrator festgelegte Route aus.
  • Wie bereits angedeutet, erleichtert der Einsatz eines SDWAN die Virtualisierung von Netzwerkdiensten über das WAN. Die Netzwerkfunktionsvirtualisierung (NFV) verringert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN, indem die Netzwerkfunktionen mithilfe virtueller Maschinen auf gängigerer und billigerer „Standard“-Hardware virtualisiert werden, anstatt auf proprietärer, dedizierter Hardware (wie traditionell erforderlich). So können beispielsweise Funktionen wie Routing, Lastausgleich und Firewalls als virtuelle Maschinen (VMs) betrieben werden, die in einem Rechenzentrum und/oder in der Cloud gehostet werden. NFV konzentriert sich jedoch auf die Virtualisierung von Funktionen, kümmert sich aber nicht darum, wie die Datenpakete zu den virtuellen Maschinen geleitet werden, auf denen die Netzwerkfunktionen ausgeführt werden. SDWAN in Kombination mit NFV bietet ein umfassenderes virtuelles Netzwerk, bei dem das SDWAN die Routing-Richtlinien für die Verkehrsströme von den Zweigstellen zum Kernstandort oder zum Rechenzentrum, in dem die virtuellen NFV-Maschinen laufen, bereitstellt. Zweigstellenbenutzer sind in der Lage, diese Ressourcen über das SDWAN zu nutzen, wodurch die Abhängigkeit von teurer proprietärer Hardware verringert und die Menge der an den Zweigstellen des WAN erforderlichen Computerhardware reduziert wird.
  • SDWANs können durch die Schaffung eines virtuellen Overlay implementiert werden, das transportunabhängig ist und die zugrunde liegenden privaten oder öffentlichen Netzverbindungen abstrahiert. Zu diesen Netzverbindungen können Multiprotocol Label Switching (MPLS), Internet-Breitband, Glasfaser, Wireless oder Long Term Evolution (LTE) gehören, um nur einige zu nennen. In einigen Beispielen werden VPN-Tunnel (Virtual Private Network) zwischen WAN-Standorten eingerichtet, um eine private, sichere Verbindung über potenziell anfällige und unsichere öffentliche Verbindungen (z. B. Internetverbindungen) zu ermöglichen. Die Kunden können bestehende WAN-Verbindungen beibehalten und ein Overlay-SDWAN implementieren, das diese Tunnel nutzt, um die Bandbreite zu optimieren, indem der WAN-Verkehr zu und von anderen WAN-Standorten über bestimmte Routen geleitet wird, die diese Tunnel einschließen. Dementsprechend können SDWANs verwendet werden, um die Netzwerkkontrolle über das gesamte WAN zu zentralisieren. Fernanwender, z. B. in Zweigstellen, können Ressourcen nutzen, die in einem Rechenzentrum und/oder in der Cloud gehostet werden, um Anwendungen innerhalb des Netzwerks auszuführen.
  • SDWAN-Anbieter nutzen in der Regel das Border Gateway Protocol (BGP), ein standardisiertes Protokoll für externe Gateways, um Routing- und Erreichbarkeitsinformationen zwischen Systemen auszutauschen und so ein SDWAN zu realisieren. Bei BGP wird das Wissen über die Routen jedoch föderiert (z. B. eine aggregierte, einzige Datenquelle, die in einem virtuellen Speicher aus verteilten Quellen generiert wird, um ein gemeinsames Datenmodell zu erstellen), und es werden mehrere Ebenen benötigt, um eine große Anzahl von Zweigstellen zu unterstützen, und ein Mieter/Kunde muss Paare von BGP-Instanzen konfigurieren. In einem SDWAN, in dem die Anzahl der Zweigstellen sehr groß sein kann, sind Standard-BGP-Mechanismen möglicherweise nicht ausreichend oder nicht praktikabel.
  • In einer SDWAN-Architektur, die eine einschichtige Architektur verkörpert, bei der jedes Gerät/jeder Router direkt mit einem Orchestrator kommunizieren kann (z. B. um SDWAN zu erreichen, kann Routing zwischen Zweigstellen-Gateways und Virtual Private Network Clients (VPNCs) durchgeführt werden usw.). Ein Orchestrator umfasst eine Speichernetzwerkarchitektur, die in einer eigenständigen virtuellen Maschine bereitgestellt wird, die dazu dient, den Zustand der physischen Ports mit Fabric Monitoring, End-to-End-Diagnose und vordefinierten Vorlagen zur Reduzierung von Konfigurationsfehlern zu bewerten. Dieses Routing kann als Cloud-basierter Overlay-Routing-Dienst implementiert werden.
  • Jedes Zweigstellen-Gateway kann seine lokal erlernten und statisch konfigurierten Präfixe an den Overlay-Routing-Dienst weitergeben (ein Präfix oder Routing-Präfix kann eine Adresse eines Netzes identifizieren, und Routen können zwischen Präfixen bestimmt/konfiguriert werden), insbesondere an einen von mehreren CBS-Servern. CBS-Server können Routenaktualisierungen an Branch-Gateways senden, die diese Routenaktualisierungen an einen Underlay-Routing-Stack beim Tenant weiterleiten. Branch-Gateways stellen die Verbindung zu CBS-Servern über einen Kanal her, der für einen bestimmten CBS-Server lastausgleichend ist. Zweigstellen-Gateways können eine Neusynchronisierung durchführen, um einen gemeinsamen Status mit den CBS-Servern/Overlay-Routing-Dienst zu erreichen. Danach veröffentlichen die Zweigstellen-Gateways erneut gelernte Routen (zusammen mit allen relevanten Tunnel-Flaps), woraufhin die CBS-Server diese Statusaktualisierungen an alle PCMs in einem bestimmten Cluster veröffentlichen. Die Veröffentlichung dieser Zustandsaktualisierungen löst in jedem PCM neue Routenberechnungen aus, woraufhin die PCMs neue Aktualisierungen an alle CBS-Server veröffentlichen, die ihrerseits Aktualisierungen an alle relevanten Zweigstellen-Gateways verteilen.
  • Eine weitere Einschränkung der Standard-Border-Gateway-Protokoll (BGP)-Mechanismen sind Verarbeitungs- und Speicherbeschränkungen bei der Implementierung eines Netzes mit einer großen Anzahl von Knoten. So kann BGP zwar die Routeninformationen definieren, ist aber aufgrund der realen Analyse von Verarbeitungs- oder Speicherbeschränkungen funktionell begrenzt. Wenn die Anzahl der Knoten von ihrem ursprünglichen Wert abweicht oder versucht wird, eine große Anzahl von Knoten zu unterstützen (z. B. 1.000 usw.), müsste jeder der Knoten die Routeninformationen mit einer Netzwerkänderung berechnen und diese Informationen an andere Knoten weiterleiten. Bei einer großen Anzahl von Knoten sind die Verarbeitungskapazitäten dieser Knoten auf die Neuberechnung der Routeninformationen ausgerichtet, und oft ist administrative Unterstützung erforderlich, um die neuen Routen zu definieren. Daher ist die Ermittlung und Pflege genauer Routing-Tabellendaten schwierig, langsam und statisch.
  • Außerdem ist BGP ein verteiltes Routing-Protokoll, bei dem jeder Knoten seine Routeninformationen an seine Nachbarknoten weitergibt. Auf der Grundlage der erhaltenen Routeninformationen kann jeder Knoten innerhalb des Netzes seine eigenen besten Routen berechnen. Bei Netzen mit Hunderten oder Tausenden von Knoten wird es immer schwieriger, Änderungen am Netz oder am Layout vorzunehmen und/oder Probleme in einem so großen Netz zu beheben.
  • Ausführungsformen der vorliegenden Offenlegung beinhalten einen verbesserten Netzwerk-Controller zur Bestimmung von Knotenrouten auf der Grundlage von Anzeigen von jedem Knoten (z. B. Unicast usw.). Das System kann Zweigstellengeräte automatisch auf der Grundlage von Geräteinformationen gruppieren (z. B. IPSec-Tunnelkonnektivität usw.). Die Geräte mit ähnlichen Zweigstellen-Gateways, die üblicherweise ähnliche Routeninformationen und/oder Routing-Eigenschaften erhalten (z. B., Werte, die vom BGP-Algorithmus zur Bestimmung einer Pfadauswahl verwendet werden, einschließlich Autonomous System (AS)-Pfad, Kosten, Multiple Exit Discriminator (MED)-Metrik, Metric1, Metric2, Community/Extended Community) und/oder Geräte mit ähnlichen Konnektivitätsgraphen können gruppiert werden (wobei die Konnektivitätsgraphen Eckpunkte darstellen, die mit Kanten verbunden sind, um das Vorhandensein gemeinsamer Ressourcen zu demonstrieren, indem Geräte verbunden werden, wenn sie ähnliche Gateways teilen, wie z. B. dasselbe primäre Gateway und sekundäre Gateway). Auf diese Weise kann die Anzahl der im gesamten Netz übertragenen elektronischen Kommunikationen verringert und die Recheneffizienz für den Controller und die Geräte erhöht werden.
  • In einem Beispiel für eine Hub-and-Spoke-Konnektivität (z. B. eine zentrale Komponente, die mit mehreren Kommunikationsnetzen in ihrer Umgebung verbunden ist) können die Knoten 1 bis 100 alle mit demselben Hub-Knoten 1 verbunden sein. Daher können die Knoten 1-100 und der Hub-Knoten-1 als eine Gruppe zusammengefasst werden. Die Routen für die Gruppe können einmal als Gruppe berechnet werden, anstatt sie für jeden Knoten einzeln zu berechnen.
  • Darüber hinaus können in einer Gruppe statt nur der besten Routen (z. B. der schnellsten Routen, der geringsten Anzahl von Sprüngen usw.) auch die zweit- oder drittbesten Routen gleichzeitig berechnet werden. Die besten Routen und die alternativen besten Routen können auf jedes Gerät in der Gruppe heruntergeladen werden, so dass bei Netzunterbrechungen jeder Knoten auf alternative beste Routen umschalten kann, ohne dass eine erneute Berechnung der Routen erforderlich ist.
  • Die Routing-Daten können von der Steuereinheit gepflegt und dynamisch aktualisiert werden, wenn neue Knoten hinzugefügt werden. Die Routing-Entscheidung kann vom Controller auf zentralen Servern oder in der Cloud verwaltet werden. Im Vergleich zu einem verteilten Ansatz kann die zentralisierte Entscheidung den Bedarf an neuer Router-Hardware verringern, wenn das Netzwerk wächst. Dies kann auch dazu beitragen, dass nicht ständig neue Router-Hardware hinzugefügt werden muss, um Pakete weiterzuleiten oder Routing-Tabellen zu aktualisieren, und dass weniger manuelle Eingriffe erforderlich sind, um diese Routen zur Routing-Tabelle hinzuzufügen.
  • 1 zeigt ein Beispiel für ein SDWAN 100, in dem Ausführungsformen der hier offengelegten Technologie anwendbar sind. Das SDWAN-Beispiel 100 ist der Einfachheit halber vereinfacht dargestellt, und ein Fachmann wird verstehen, dass die Technologie der vorliegenden Offenlegung auf SDWANs mit mehr oder weniger komplexen Architekturen anwendbar ist. Wie in dargestellt, umfasst das Beispiel-SDWAN 100 eine Vielzahl von entfernten Standorten 102a, 102b, 102c, 102d, die jeweils über ein SDWAN-Knotengerät verfügen. Ein SDWAN-Knotengerät ist ein Netzwerkgerät, z. B. ein Router, Switch, Modem, eine Brücke, ein Hub oder ein anderes gängiges Netzwerkgerät, das als Gateway oder Zwischenpunkt innerhalb des SDWAN dient. Bei den entfernten Standorten 102a, 102b, 102c, 102d kann es sich um eine Zweigstelle oder einen anderen Benutzer handeln, der sich in größerer Entfernung von einem Kernstandort des Netzwerks, z. B. einem Rechenzentrum, befindet. In verschiedenen Ausführungsformen ist der Kernstandort die Einheit, die virtualisierte Netzwerkfunktionen (VNFs) hostet, die von allen entfernten Standorten 102a, 102b, 102c, 102d gemeinsam genutzt werden können.. In verschiedenen Ausführungsformen ist das SDWAN-Knotengerät an den entfernten Standorten 102a, 102b, 102c, 102d so konfiguriert, dass es als Edge-Gerät für den entfernten Standort fungiert und einen Zugangspunkt zum SDWAN 100 bereitstellt. Das SDWAN-Knotengerät an den entfernten Standorten 102a, 102b, 102c, 102d kann in verschiedenen Ausführungsformen ein Modem oder ein anderes Gateway-Netzwerkgerät umfassen.
  • In verschiedenen Ausführungsformen kann der Verkehr zwischen entfernten Standorten und den Datenzentren über ein SDWAN-Zwischenknotengerät 104 geleitet werden. Das SDWAN-Zwischenknotengerät 104 kann den SDWAN-Knotengeräten an den entfernten Standorten 102a, 102b, 102c, 102d und den Datenzentren 108a, 108b, 108c, 108d ähnlich sein. Das SDWAN-Zwischenknotengerät 104 kann als Zugangspunkt zu den Transportnetzen 106a, 106b des SDWAN 100 für eine Vielzahl von entfernten Standorten dienen. Somit kann das SDWAN-Knotengerät 104 als Zweigstellen-Gateway betrachtet werden, und SDWAN-Knotengeräte an entfernten Standorten 102a, 102b, 102c, 102d können als Virtual Private Network Concentrators (VPNCs) betrachtet werden. Wie in 1 dargestellt, können die entfernten Standorte 102c und 102d mit einem SDWAN-Knotengerät 104 verbunden sein. Die Verwendung eines oder mehrerer Zwischengeräte, wie des SDWAN-Zwischenknotens 104, innerhalb des SDWAN ermöglicht in einigen Ausführungsformen die Schaffung verschiedener Dienstregionen.
  • SDWAN 100 umfasst außerdem ein oder mehrere Datenzentren 108a, 108b, 108c, 108d. Jedes Datenzentrum 108a, 108b, 108c, 108d verfügt auch über ein SDWAN-Knotengerät, ähnlich dem SDWAN-Knotengerät an entfernten Standorten 102a, 102b, 102c, 102d. In verschiedenen Ausführungsformen können die Datenzentren 108a, 108b, 108c, 108d eine oder mehrere Anwendungen hosten, die von Benutzern an den entfernten Standorten 102a, 102b, 102c, 102d genutzt werden können. In verschiedenen Ausführungsformen können ein oder mehrere Datenzentren von dem Kunden verwaltet werden, der Eigentümer des SDWAN 100 ist. In anderen Ausführungsformen können ein oder mehrere Rechenzentren von einem dritten Dienstanbieter verwaltet werden.
  • Jedes Transportnetz 106a, 106b kann mit einer Reihe von Rechenzentren verbunden sein. Wie in 1 dargestellt, ist das Transportnetz 106a mit den Datenzentren 108a, 108b verbunden, während das Transportnetz 106b mit den Datenzentren 108c, 108d verbunden ist. In verschiedenen Ausführungsformen können einige Anwendungen in einem Cloud-Host 110 gehostet werden, auf den von einem oder mehreren Rechenzentren zugegriffen werden kann, die entweder dem Transportnetz 106a oder 106b zugeordnet sind. Wie in 1 dargestellt, bieten die Datenzentren 108b und 108c Zugang zu mindestens einer Cloud-Anwendung, die im Cloud-Host 110 gehostet wird.
  • Jeder entfernte Standort 102a, 102b, 102c, 102d ist über das SDWAN-Knotengerät mit den Transportnetzen 106a, 106b verbunden. Die Transportnetze 106a, 106b umfassen verschiedene Transporttechnologien, wie öffentliches Internet, Multiprotocol Label Switching (MPLS), privates Internet, asynchroner Übertragungsmodus, drahtloses WAN, Breitband, Satellitenkommunikation oder andere Netzwerktechnologien. In verschiedenen Implementierungen kann es sich bei den Transportnetzen um Netze verschiedener Dienstanbieter handeln. Wie dargestellt, kann das SDWAN 100 mehr als ein Transportnetz umfassen (Transportnetze 106a, 106b). SDWAN 100 kann ein Verfahren zur Definition eines Client-Netzwerks bereitstellen, das die bestehenden Transportinfrastrukturen von Dienstanbietern für das physische Routing des SDWAN-Datenverkehrs zwischen verschiedenen SDWAN-Knotengeräten überlagert. Obwohl in nur zwei Transportnetzwerke 106a, 106b dargestellt sind, können verschiedene Ausführungsformen andere Mengen von Transportnetzwerken umfassen, die zusätzliche Flexibilität bei der Art und Weise bieten, wie der Anwendungsverkehr von entfernten Standorten 102a, 102b, 102c, 102d zu dem zugehörigen Datenzentrum 108a, 108b, 108c, 108d geleitet wird, das die Anwendung hostet. Die Rechenzentren 108a, 108b, 108c, 108d verfügen über eigene SDWAN-Knotengeräte, die Servern und anderen Komponenten des jeweiligen Rechenzentrums den Zugang zum SDWAN 100 ermöglichen.
  • Innerhalb des SDWAN 100 kann die Konnektivität zwischen entfernten Standorten und den Rechenzentren und/oder Cloud-Anwendungen über eine vom SDWAN-Administrator gehostete Steuerungssoftware gesteuert werden. Der Kunde kann Richtlinien entwickeln, die sicherstellen, dass verschiedene Datenverkehrsklassen innerhalb des Netzwerks so geroutet werden, dass die Anforderungen an die Dienstgüte (QoS) und die Service Level Agreements (SLA) erfüllt werden. So kann der Client beispielsweise eine Mindestverfügbarkeitszeit (z. B. 23 Stunden pro Tag usw.), Bandbreite, Verzögerung und Fehlerrate für Anwendungen und Datenverkehr mit hoher Priorität bei begrenzter Netzwerkkapazität festlegen, die vom SDWAN-Administrator bereitgestellt wird. In einem anderen Beispiel kann der Kunde ein erwartetes Serviceniveau (z. B. Qualität, Verfügbarkeit, Verantwortlichkeiten usw.) definieren, das vom SDWAN-Administrator bereitgestellt wird. Diese Richtlinien werden verwendet, um Routing-Tabellen zu entwickeln, die an die SDWAN-Knotengeräte (wie die in 1 beschriebenen SDWAN-Knotengeräte) verteilt werden. Die SDWAN-Knotengeräte können den Verkehr der verschiedenen Sitzungen, die durch das SDWAN-Knotengerät fließen, identifizieren und die in der Routing-Tabelle für diese Verkehrskategorie enthaltenen Routing-Regeln anwenden. Um sicherzustellen, dass die Anforderungen erfüllt werden, können sich die Kunden auf die Grundsätze des Traffic Engineering konzentrieren (z. B. können eine oder mehrere Anwendungen den Netzwerkverkehr auf einer Kommunikationsverbindung auf der Grundlage der Verbindungseigenschaften umleiten, wie z. B. Dynamic Packet State (DPS)-Richtlinien usw.), indem sie die Route ändern, die bestimmte Daten durch die Transportnetze nehmen, um die Anforderungen zu erfüllen. So kann ein Netzwerkadministrator beispielsweise Regeln für eine bestimmte Verkehrsklasse festlegen, so dass diese im Allgemeinen über das SDWAN-Knotengerät einer Zweigstelle an ein zwischengeschaltetes SDWAN-Knotengerät (zur Anwendung von DPI) und dann über das öffentliche Internet-Transportnetz an ein Rechenzentrum übertragen wird. In bestimmten Szenarien kann derselbe Datenverkehr jedoch auch über ein MPLS-Netzwerk übertragen werden. Dementsprechend können die SDWAN-Knotengeräte und die Datenpfade zwischen den Zweigstellen und den Rechenzentren/Cloud-Architekturen vor der Installation festgelegt werden.
  • 2 zeigt eine Beispielsystemarchitektur 200 zur Realisierung eines SDWAN-Overlay-Routing-Dienstes (SORS) 201 (z. B. ein Controller-Gerät zur Gruppierung von Zweigstellengeräten, Bestimmung ähnlicher Routen usw.) gemäß einer Ausführungsform. Wie in 2 dargestellt, kann jeder Tenant (z. B. Tenants A-Z, die verschiedenen Kunden entsprechen, usw.) über entsprechende Zweigstellen-Gateways und/oder VPNC-Overlay-Agenten (OAs) verfügen (austauschbar). So kann beispielsweise Mieter A über Zweigstellen-Gateways 214a, 214b verfügen, Mieter B über Zweigstellen-Gateways 216a, 216b..., Mieter Y über Zweigstellen-Gateways 218a, 218b und Mieter Z über Zweigstellen-Gateways 220a-c. Jedes Filial-Gateway kann so konfiguriert sein, dass es sich mit dem SORS 201 über einen Kanal verbindet. Jedes Zweigstellen-Gateway kann über seinen jeweiligen Kanal seine lokal erlernten und statisch konfigurierten Präfixe an SORS 201 veröffentlichen. Jeder Kanal kann einen Open-Source-Remote-Procedure-Call (RPC), wie z.B. gRPC, verwenden, der HTTP/2 für den Transport nutzt. Dies ermöglicht die Erstellung mehrerer, bidirektionaler Streams über dieselbe TCP-Verbindung. So kann jede Anwendung, z. B. ein Routingdienst, ein Tunneldienst usw., ihren eigenen Stream erstellen. Es ist zu beachten, dass für SORS 201 ein spezifischer DNS-Domänenname und eine entsprechende virtuelle IP-Adresse (VIP) angegeben werden können, um den Verkehr der Steuerungsebene von anderem Managementverkehr zu isolieren.
  • Es versteht sich, dass jedes Zweig-Gateway eine Verbindung zu einem Underlay-Routing-Daemon herstellen kann (z. B. ein im Hintergrund laufender Serverprozess, der eine Routing-Tabelle aktualisieren kann, aber keinen manuellen Eingriff wie einen Routenbefehl erfordert). Der Underlay-Routing-Daemon kann die statisch konfigurierten Präfixe abrufen (z. B. können alle Zweigstellen-Gateways und/oder VPNC-Overlay-Agenten ihre lokal erlernten und statisch konfigurierten Präfixe an den Underlay-Routing-Daemon weitergeben). Ein CBS-Server, z. B. einer der CBS-Server 210a-d (die weiter unten ausführlicher beschrieben werden), kann Routenaktualisierungen an das entsprechende Zweigstellen-Gateway senden, das wiederum die Routenaktualisierungen an den Underlay-Routing-Daemon weiterleitet. Auf diese Weise kann der Underlay-Routing-Daemon die Präfixe konfigurieren, die jeder Zweig-Gateway schließlich an das SORS 201 veröffentlicht.
  • Jedes Zweigstellen-Gateway 214a/b, Zweigstellen-Gateway 216a/b, Zweigstellen-Gateway 218a/b, Zweigstellen-Gateway 220a/b/c kann die lokal erlernten und statisch konfigurierten Präfixe an den SORS 201 gegenüber einer ELB-Komponente (Elastic Load Balancing) 212a veröffentlichen (z. B. ein Webserver, der auch als Reverse Proxy, Load Balancer, Mail Proxy und HTTP-Cache usw. verwendet werden kann).
  • In einigen Beispielen führt ELB 212a einen Lastausgleich auf Schicht 4 durch. Das heißt, ELB 212a kann einen Lastausgleich von Host-zu-Host-Kommunikationsdiensten für die OSI-Transportschicht durchführen und dann die Kanaldaten an einen Reverse-Proxy/Load-Balancer-Cluster 212 weiterleiten. Das heißt, ELB 212a führt einen Layer-4-Lastausgleich durch, wenn es Kanaldaten zur Verteilung an den Reverse-Proxy/Lastausgleichs-Cluster 212 annimmt, der die HTTP-Terminierung durchführt und als zwischengeschalteter Proxy-Dienst für die Weiterleitung der Kanaldaten an SORS 201 fungiert. ELB 212a (oder eine ähnliche/äquivalente Funktion) kann als Einstiegspunkt in die Cloud implementiert werden. Der Reverse-Proxy/Load-Balancer-Cluster 212 kann jeden Kanal (der sicher sein kann) beenden und einen Klartextkanal zu einem der CBS-Server, z. B. den CBS-Servern 210a-d, aufbauen. In einigen Ausführungsformen können benutzerdefinierte Header von Datenpaketen, die über die Kanäle übertragen werden, als Grundlage für die Auswahl eines bestimmten CBS-Servers verwendet werden, an den ein Kanal weitergeleitet wird. In einigen Ausführungsformen kann ein Zweigstellen-Gateway (z. B. das Zweigstellen-Gateway 214a) solche benutzerdefinierten Header einfügen, um eine Mieterkennung oder andere relevante Felder anzugeben.
  • Jeder der CBS-Server 210a-210d kann den/die dorthin gerouteten Kanal/Kanäle hosten. Jeder der CBS-Server 210a-210d kann für die Verteilung der vom PCM generierten Routen an alle interessierten Zweigstellen-Gateways eines an den jeweiligen CBS-Server (oder die Gruppe von CBS-Servern) angeschlossenen Mandanten verantwortlich sein. Es ist zu beachten, dass alle Filial-Gateways, die zum selben Mandanten gehören, mit einem bestimmten CBS-Server oder einer Gruppe von CBS-Servern verankert werden können. Dies kann in einigen Ausführungsformen getan werden, um die Speichernutzung auf den CBS-Servern zu optimieren, wo ohne eine solche Speicheroptimierung alle CBS-Server im SORS 201 alle Zustände/Präfixe aller Tenants, die mit jedem der CBS-Server verbunden sind, zwischenspeichern müssten.
  • In der „umgekehrten Richtung“ und wie oben erwähnt, kann jeder der CBS-Server 210a-210d verwendet werden, um die Präfixe und alle Routing-Updates, die von einem Zweigstellen-Gateway (z. B. einem oder mehreren der Zweigstellen-Gateways 214a/b, 216a/b, 218a/b, 220 a-c) empfangen werden, an jedes PCM zu veröffentlichen. Bei einem Ausfall eines CBS-Servers leitet der Reverse-Proxy/Load-Balancer-Cluster 212 Kanalverbindungen an aktive CBS-Server weiter, und die Zweigstellen-Gateways/VPNCs können ihren jeweiligen Status mit einem aktiven CBS neu synchronisieren. Der aktive CBS kann den Redis-Cluster 208 aktualisieren und eine entsprechende Benachrichtigung über den Message Broker 209 (z. B. ein Modul, das eine Nachricht aus dem formalen Nachrichtenprotokoll des Senders in das formale Nachrichtenprotokoll des Empfängers übersetzt) und den Redis-Cluster 208 (siehe unten) senden.
  • In einigen Ausführungsformen kann eine Kombination aus Überwachungsskripten und regelmäßigem Datenvergleich von einem Redis-Cluster 208 aus Redis-Instanzen durchgeführt werden, wobei Redis-Schlüssel von mehreren Redis-Instanzen gemeinsam genutzt werden, die den Redis-Cluster 208 bilden. Der Redis-Cluster 208 kann aus Gründen der Ausfallsicherheit/Redundanz über Slave-Knoten verfügen. Bei den verglichenen Daten kann es sich um Streckenstatus- und Tunnelstatusdaten handeln. Redis kann sich auf einen speicherinternen Datenstrukturspeicher beziehen, der als Datenbank, Cache und Message Broker verwendet werden kann. Ein Datenverlust in einem Redis-Cluster, wie z. B. Redis-Cluster 208, kann z. B. durch den Ausfall eines Redis-Knotens oder durch einen Neustart eines Redis-Knotens entstehen. Bei einem Ausfall oder Neustart können die Daten, die den letzten Zustand der Zweigstellen-Gateways widerspiegeln, von den CBS-Servern 210a-210d im redis-Cluster 208 neu aufgefüllt werden. Die CBS-Server 210a-210d können dann jedes PCM 206a, b...n und den PCM-Scheduler 204 (der weiter unten ausführlicher beschrieben wird) benachrichtigen, um die Routen zwischen den Zweigstellen-Gateways und den VPNCs für jeden der zugehörigen Tenants neu zu berechnen.
  • Der PCM-Scheduler 204 (der eine Vielzahl von PCM-Scheduler-Instanzen umfassen kann) kann verwendet werden, um die Mieterzuweisung zu handhaben, z. B. die Zuordnung von PCMs, z. B. PCMs 206a-n, zu Mietern, z. B. Mietern A-Z. Es versteht sich, dass die Mieterzuweisung dynamisch sein kann, und die PCMs 206a- können so konfiguriert werden, dass sie bei Bedarf auf eine Reihe von Mietern einwirken. Darüber hinaus können alle PCMs so konfiguriert werden, dass sie als Slaves für die PCM-Scheduler-Instanzen 204 fungieren.
  • Im Betrieb können die Zweigstellen-Gateways 214a/b, 216a/b, 218a/b, 220a-c mit den CBS-Servern 21 0a-d über entsprechende Kanäle verbunden werden, wie oben beschrieben. Im Gegenzug wird der Status der Zweigstellen-Gateways/VPNCs (d. h. Route(n) und Verbindungsstatus), der von dem jeweiligen Zweigstellen-Gateway veröffentlicht wird, von dem entsprechenden CBS-Server 210a-210d in den Redis-Cluster 208 übertragen. Darüber hinaus kann jeder CBS-Server 210a-210d Benachrichtigungen, die den neuen Zustand der Zweiggateways/VPNCs anzeigen, an einen Nachrichtenbroker 209, z. B. einen Kafka- oder RabbitMQ-Nachrichtenbroker, sowie an den redis-Cluster 208 weiterleiten. Es versteht sich, dass der Redis-Cluster208 und der Message-Broker 209 nebeneinander bestehen können, wenn die Zustandsmeldungen nicht skalierbar sind (z. B. wenn dasselbe Ereignis auf dem Redis-Cluster 208 und dem Message-Broker 209 gebucht wird, dann sind die Zustandsmeldungen möglicherweise nicht skalierbar usw.), um einen hohen Schreibdurchsatz zu gewährleisten. Auf diese Weise kann der PCM-Scheduler 204 alle Benachrichtigungen vom Message-Broker 209 auffangen, und wenn ein Tenant noch keinem PCM zugewiesen ist, kann der PCM-Scheduler 204 diesen noch nicht zugewiesenen Tenant einem geeigneten PCM zuordnen, z. B. einem der PCMs 206a-d. Für PCMs, die bereits einem oder mehreren Mandanten zugewiesen/zugeordnet wurden, können solche PCMs einfach auf Aktualisierungen in mandantenspezifischen Redis-Warteschlangen über die Redis-Knoten des Redis-Clusters 208 warten.
  • Es sei darauf hingewiesen, dass jeder der CBS-Server 210a-d als Helfer für die Vorsortierung von Zustandsmeldungen auf der Basis der einzelnen Mandanten fungieren kann. Darüber hinaus können PCMs, denen Mandanten zugewiesen sind, weiterhin Zustandsmeldungen aus den oben erwähnten redis-Warteschlangen abrufen. Dementsprechend werden diese PCMs nicht notwendigerweise vom PCM-Scheduler 204 gesteuert. PCM Scheduler 204 kann einen oder mehrere der folgenden Faktoren für die Planung berücksichtigen: die Anzahl der aktiven/aktiven PCMs, die Anzahl der Geräte, z. B. SDWAN-Knoten, die jedem Tenant zugeordnet sind, die Anzahl der einem Tenant zugewiesenen Tunnel sowie die letzte Status-/Konfigurationsaktualisierung für einen Tenant. Die Anzahl der aktiven PCMS, Tenant-Geräte und Tenant-Tunnel kann für den Lastausgleich bei der Zuordnung von Tenants zu PCMs verwendet werden. Die letzte Status-/Konfigurationsaktualisierung, die einem Tenant zugeordnet ist, kann verwendet werden, um einen zuletzt genutzten Tenant von einem PCM zu trennen oder sein Mapping aufzuheben. Darüber hinaus kann der PCM-Scheduler 204 Informationen über die Zuordnung von Tenants zu PCMs sowie Tenant-relevante Informationen speichern, z. B. die Anzahl der Geräte und Tunnel, die einem Tenant in einem verteilten Key-Value-Speicher 202 zugeordnet sind (z. B. ein einziger, von verschiedenen Geräten gemeinsam genutzter Datenspeicher, in den jedes Gerät Daten einspeisen und aus dem es Daten abrufen kann usw.).). Die Speicherung solcher Informationen kann zur Wiederherstellung des PCM-Schedulers 204 im Falle eines Ausfalls oder Neustarts verwendet werden.
  • In einigen Ausführungsformen kann der PCM-Planer 204 alle PCMs des SORS 201 mithilfe des verteilten KV-Speichers 202 ermitteln. Wie oben erwähnt, kann der verteilte KV-Speicher 202 verwendet werden, um PCM-Tenant-Zuordnungsinformationen zu speichern, und der PCM-Scheduler 204 kann PCMs mit Hilfe von Tenant-Identifikationsinformationen ermitteln, um ein entsprechendes PCM zu finden. Es sollte beachtet werden, dass der verteilte KV-Speicher 202 auch verwendet werden kann, um verteiltes Sperren, Überwachung über Pub/Sub (z. B. ist Pub/Sub eine Form der asynchronen Service-to-Service-Kommunikation, die in serverlosen und Microservices-Architekturen verwendet wird, wo jede Nachricht, die in einem Thema veröffentlicht wird, sofort von allen Abonnenten des Themas empfangen wird), Echtzeit-Ereignis-Messaging, Service-Erkennung sowie Führungswahlen bereitzustellen. In einigen Beispielen kann das Pub/Sub-Messaging der asynchronen Service-to-Service-Kommunikation entsprechen, die in Serverless- und Microservices-Architekturen verwendet wird.
  • Wie bereits erwähnt, kann der PCM-Scheduler 204 aus einer Vielzahl von PCM-Scheduler-Instanzen bestehen, um die Führungsrolle zu übernehmen. In einigen Ausführungsformen kann eine PCM-Instanz zum Master-PCM-Scheduler gewählt werden, während die übrigen PCM-Scheduler-Instanzen als Backup-PCM-Scheduler konfiguriert werden können. So kann der verteilte KV-Speicher 202 für den Fall, dass ein Master-PCM-Scheduler ausfällt, zur Wahl eines neuen Master-PCM-Schedulers aus einem der Backup-PCM-Scheduler verwendet werden. Ein neu gewählter Master-PCM-Scheduler kann einen aktuellen PCM-Scheduler-Status aus dem verteilten KV-Speicher 202 laden (es sei daran erinnert, dass der verteilte KV-Speicher 202 dazu verwendet werden kann, Mieter-PCM-Zuordnungen und mieterrelevante Informationen im Namen des PCM-Schedulers 204 zu speichern/zu sichern). In einigen Ausführungsformen kann ein neuer Master-PCM-Scheduler die neuesten Mieter-PCM-Zuordnungen für jedes PCM erhalten und diese Zuordnungen auf der Grundlage der im verteilten KV-Speicher 202 gespeicherten Daten abgleichen.
  • Um auf die PCM-Ermittlung zurückzukommen, kann sich jedes PCM 204a-d bei dem verteilten KV-Speicher 202 registrieren (z. B. durch Angabe eines Namens, der IP-Adresse des PCM/Knotens, des Zuweisungsbereichs der Endpunkte auf dem PCM/Knoten usw.), wenn das PCM in Betrieb genommen wird, und jedes PCM 204a-d kann sich selbst abmelden, bevor es außer Betrieb geht. Der PCM-Scheduler 204 kann eine gRPC-Client-Verbindung zu jedem entdeckten PCM initiieren und in regelmäßigen Abständen PCM-Zustandsprüfungen durchführen. Es folgt eine nicht abschließende Liste von RPCs, die von PCM Scheduler 204 angefordert werden können: „keep-alive/healthcheck“-RPC; „load tenant“-RPC (was sich auf das Laden des aktuellen Zustands eines Tenants aus dem redis-Cluster 208 und die Durchführung einer vollständigen Neuberechnung der Route bezieht); „unload tenant“-RPC (was sich auf die Aufgabe des Tenant-Eigentums durch ein PCM und das Flushen aller für den Tenant durchgeführten und im redis-Cluster 208 erfassten Zustandsaktualisierungen bezieht); „full compute“ RPC (zur Durchführung einer vollständigen Neuberechnung der Tenant-Route (wenn ein Datenverlust, wie oben beschrieben, festgestellt wird und/oder wenn eine Benachrichtigungswarteschlange voll ist und keine Aktualisierungen abgeholt werden können); „get current“ RPC (für den Abgleich von Tenant-Zuweisungen zwischen PCM Scheduler 204 und einem oder mehreren PCMs 206a-n); „clear tenant“ RPC (die durchgeführt werden kann, um die Daten eines Tenants zu löschen/ungültig zu machen, aber der aktuelle Zustand des Tenants wird nicht in den Redis-Cluster 208 gespült); und „clear all tenants“ RPC (die ähnlich wie die „clear tenant“ RPC durchgeführt werden kann, aberfür alle und nicht für einen einzelnen Tenant, um den Zustand eines PCM zu löschen, wenn der Zustand des PCM wiederhergestellt ist).
  • Jedes PCM (z. B. die PCMs 206a-206n) kann Routen zwischen SDWAN-Knoten erstellen (auf der Grundlage des Underlay-Routing-Daemons und über die Branch Gateways), die dann an alle CBS-Server in einem PCM-Cluster veröffentlicht werden können. Da es sich bei PCM um einen Cloud-Microservice handelt, kann sich die Anzahl der PCM-Knoten in einem PCM-Cluster je nach Anzahl der Kunden/Mieter, Routen, Tunnel usw. entsprechend erhöhen/verringern. Ein PCM-Cluster kann so konfiguriert werden, dass er mehrere verschiedene Mandanten bedient (die durch einen unten beschriebenen Bereitstellungsprozess bestimmt werden), aber ein Mandant wird nur von einem einzigen PCM-Cluster bedient, um Probleme mit der Synchronisierung der Mandanten-PCM-Zuordnung zu vermeiden. In einigen Ausführungsformen wird während der Bereitstellung ein Satz von Mandanten fest an einen PCM-Cluster mit der erforderlichen Anzahl von PCM-Knoten gebunden, und die Bindung kann auf der Anzahl von Mandanten-Präfixen (Routen), der Anzahl von Mandantengeräten usw. basieren.
  • Wenn ein PCM aus irgendeinem Grund ausfällt oder abstürzt, erfährt der PCM-Scheduler 204 (auf der Grundlage der vom PCM-Scheduler 204 angeforderten Keep-Alive-/Gesundheitsprüfungs-RPCs) schließlich von dem Ausfall/Absturz. Der PCM-Scheduler 204 kann alle Tenants, die dem ausgefallenen PCM zugeordnet sind, einem anderen PCM neu zuweisen. Wenn PCM Scheduler 204 nicht in der Lage ist, eine Verbindung zu einem bestimmten PCM herzustellen, z. B. aufgrund einer Netzwerkpartitionierung, kann PCM Scheduler 204 Mieter, die diesem nicht erreichbaren PCM zugeordnet sind, nach einer bestimmten Zeitspanne/Timeout-Dauer neu zuweisen. Ein PCM kann auch feststellen, dass es nicht mehr mit dem PCM-Scheduler 204 verbunden ist, und nach einer gewissen Zeitspanne/Zeitüberschreitung (die sich von der des PCM-Schedulers 204 unterscheiden kann) kann das PCM sich selbst unter Quarantäne stellen, indem es auf keine Benachrichtigungen von seinem zugehörigen CBS-Server reagiert. Auf diese Weise kann sichergestellt werden, dass nicht zwei oder mehr verschiedene PCMs zur gleichen Zeit auf denselben Mieter einwirken. Es sei darauf hingewiesen, dass es sich bei 2 um eine Beispielarchitektur handelt und dass die Anzahl der Komponenten, die Art der Verbindung/Interaktion zwischen diesen Komponenten usw. bei anderen Ausführungsformen unterschiedlich sein kann.
  • 3 zeigt eine schematische Darstellung einer PCM-Dienstinstanz gemäß einer Ausführungsform. Wie in 3 dargestellt, kann die PCM-Dienstinstanz 300 ein PCM 302A umfassen, bei dem es sich um eine Ausführungsform eines PCM handeln kann, wie z. B. PCM 206a (oben unter Bezugnahme auf 2 beschrieben). Wie oben beschrieben, kann PCM 302A Routen innerhalb eines SDWAN auf der Grundlage von Präfixen/Zuständen berechnen oder erstellen, die von einem Underlay-Routing-Daemon empfangen und von einem Tenant-Gerät (z. B. einem Zweigstellen-Gateway) über einen Kanal veröffentlicht werden. Dementsprechend kann die PCM-Dienstinstanz 300 eine Konfigurations-/Tunnelschnittstelle 304 enthalten. Zu Debugging-Zwecken kann PCM 302 einen REST-Server mit Überwachungs-/Debugging-APIs 308 enthalten, um interne Zustände verschiedener Elemente oder Komponenten offenzulegen. Solche APIs 308 können abgefragt werden, um diese internen Zustandsinformationen zu erhalten.
  • PCM 302A kann (nach der erforderlichen Synchronisierung/Re-Synchronisierung) an ein Zweigstellen-Gateway übertragen werden. Die Kommunikation über den Kanal kann über einen CBS-Server erfolgen, wobei jeder Kanal ein RPC, wie z. B. gRPC 312A, für Transportzwecke verwenden kann. 3 zeigt eine Cloud-BGP-Instanz 310A, die auf einem solchen CBS-Server gehostet oder ausgeführt wird. Typischerweise wird, wie oben beschrieben, die Implementierung eines SDWAN unter Verwendung von BGP durchgeführt, aber Standard-BGP ist möglicherweise nicht praktikabel und ermöglicht nicht die erforderliche Skalierung, die in Übereinstimmung mit verschiedenen Ausführungsformen in Betracht gezogen wird. Das heißt, dass eine SORS-Implementierung skalierbar sein soll, um mehrere Kunden/Mieter mit Zehntausenden von Geräten/Gateways, wie z. B. Zweigstellen-Gateways und VPNCs, zu bedienen. Dementsprechend sollte das CBS die Kapazität/Fähigkeit haben, eine große Anzahl solcher Geräte zu unterstützen. Um dem CBS der SORS-Implementierung die erforderliche Fähigkeit zu verleihen, wird der CBS so konfiguriert, dass er horizontal skalierbar ist, um mehrere Zweigstellen-Gateways zu bedienen. Darüber hinaus kann der CBS ein pseudo-stateless Service sein und daher mehrere Tenants gleichzeitig bedienen, ohne dass ein Hard-Binding erforderlich ist. Bindung ist beispielsweise der Prozess der Verknüpfung von Netzwerkkomponenten auf verschiedenen Ebenen, um die Kommunikation zwischen diesen Komponenten zu ermöglichen, so dass Hard-Binding in ähnlicher Weise Netzwerkkomponenten verknüpft, aber mit einer größeren Kraft, um die Komponenten zu verbinden. In einigen Beispielen ruft eine Funktion manuell eine explizite Bindung auf, um die Verwendung des Kontextes eines Objekts zu erzwingen, unabhängig davon, wo und wie diese Funktion aufgerufen wird. In einigen Beispielen kann ein und derselbe Kunde ohne Hard-Binding auf verschiedene CBS zugreifen, und mit Hard-Binding können Geräte von verschiedenen Kunden auf demselben CBS landen. Das heißt, jeder CBS-Server/jede CBS-Instanz kann jedes Gerät eines beliebigen Mandanten bedienen. Im Gegensatz dazu können Tenants, wie oben beschrieben, fest an einen bestimmten PCM-Cluster gebunden sein, d. h. nur eine PCM-Instanz kann eine Anfrage von einem beliebigen Gerät eines Tenants bedienen.
  • In einigen Ausführungsformen kann die CBS eine BGP-Routenreflektorfunktionalität implementieren, bei der nicht jedes BGP-System mit jedem anderen BGP-System ein Peering eingehen muss, sondern ein Peering zwischen einem BGP-System und einem Routenreflektor stattfindet. Routing-Ankündigungen können dann an den Routenreflektor gesendet werden, der sie an andere BGP-Systeme weiterleitet. Dementsprechend kann die Cloud-BGP-Instanz 310A eine KV-Pub/Sub-Funktion 310A-1 enthalten, um die Zustandssynchronisierung mit Branch-Gateways und Route-Pub/Sub zu ermöglichen, sowie einen Peer/Nachrichten-Handler 310A-2 (der erweitert werden kann, um andere Nutzlasttypen zu unterstützen, z. B. den Betriebsstatus von Tunneln und verkehrstechnische Routen). Es sollte klar sein, dass ein CBS Zustände für Geräteaktualisierungen, die er empfangen hat, beibehalten kann (daher nicht vollständig zustandslos/pseudo zustandslos, wie oben erwähnt), aber in Bezug auf die Geräte, die er bedienen kann, zustandslos ist (d. h. der CBS hat keine Mieteraffinität). Wie oben beschrieben, kann ein verteilter KV-Speicher verwendet werden, um die Routenüberwachung (pub-sub) zu unterstützen, die der KV pub/sub-Funktion 310A-1 entspricht, sowie um PCM-Führungsfunktionen zu unterstützen, z. B. die Wahl des Master-PCM-Schedulers und die PCM-Erkennung. Dementsprechend kann die PCM-Dienstinstanz 300 einen verteilten KV-Speicheradapter 306 enthalten.
  • Es ist anzumerken, dass die Verwendung des herkömmlichen BGP-Routing-Stacks als Routenreflektor nicht möglich ist (daher die hier offengelegte Verwendung von Cloud-BGP), nicht nur wegen der mangelnden Skalierbarkeit, sondern auch, weil herkömmliches BGP TCP für den Transport verwendet, was es schwierig macht, Verbindungen, die von verschiedenen Mietern kommen, auf einen mieterspezifischen PCM-Dienst zu verteilen. Wie bereits erwähnt, kann ein Lastausgleich (basierend auf der Identität eines Mieters (Tenant-ID)) durchgeführt werden, wobei der gesamte Verkehr, der zu einem bestimmten Mieter gehört, an das entsprechende/zugewiesene PCM gesendet wird.
  • 4 zeigt eine schematische Darstellung einer CBS-Instanz 310 gemäß einer Ausführungsform. Die Komponenten/Funktionalität der CBS-Instanz 310 sind ähnlich/entsprechen denen, die oben in Bezug auf die PCM-Dienstinstanz 300 beschrieben wurden. Das heißt, die CBS-Instanz 310 kann eine RPC, wie z. B. gRPC 312B, für Transportzwecke enthalten, um die Kommunikation zwischen der PCM-Dienstinstanz 300 und der CBS-Instanz 300 zu erleichtern, und gRPC 312C, um die Kommunikation mit den Zweigstellen-Gateways eines Mandanten (z. B. Zweigstellen-Gateway 322) zu erleichtern. Wie die PCM-Dienstinstanz 300 kann auch die CBS-Instanz 310 eine Cloud-BGP-Instanz 310B umfassen. Die Cloud-BGP-Instanz 310B kann eine KV-Pub/Sub-Funktion 310B-1 enthalten, um die Zustandssynchronisierung mit Zweigstellen-Gateways und Routen-Pub/Sub zu ermöglichen, sowie einen Peer/Nachrichten-Handler 310B-2 (der erweitert werden kann, um andere Nutzlasttypen zu unterstützen, z. B. den Betriebsstatus von Tunneln und verkehrstechnische Routen). Wie oben beschrieben, kann die PCM-Führungsfunktionalität, z. B. die Wahl des PCM-Master-Schedulers und die PCM-Erkennung, über einen verteilten KV-Speicher unterstützt werden. Dementsprechend kann die CBS-Instanz 310 einen Adapter 314 für einen verteilten KV-Speicher enthalten.
  • Wie oben erwähnt, kann Cloud BGP Route Reflectors für Peering verwenden, und daher kann die CBS-Instanz 300 eine Authentifizierungskomponente 316 für die Authentifizierung neuer Peers und die Aktivierung des Dienstes zwischen Geräten enthalten. Wie die PCM-Dienstinstanz 300 kann auch die CBS-Instanz 310 eine oder mehrere Überwachungs-/Debugging-APIs 320 enthalten, die von einem Benutzer über einen REST-Server (nicht dargestellt) aufgerufen werden können. Darüber hinaus kann die CBS-Instanz 310 einen Steuerkanal-Multiplexer/Demultiplexer 318 zur Verarbeitung anderer Steuerkanal-Anwendungsaufrufe/-Kommunikationen enthalten, z. B. Interprozesskommunikation (IPC) (z. B. Schnittstellen zur Koordinierung von Aktivitäten zwischen verschiedenen Programmprozessen usw.) und Remote-Prozeduraufrufe (RPC) (z. B. eine IPC, die es einem Computerprogramm ermöglicht, ein Unterprogramm oder eine Prozedur zur Ausführung in einem anderen Adressraum zu veranlassen usw.).
  • 5 ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 500 zur Durchführung von Dienstsicherungsfunktionen gemäß einer Ausführungsform. Bei der Rechnerkomponente 500 kann es sich beispielsweise um einen Servercomputer, einen Controller oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten und die Funktionalität einer Assurance Engine zu realisieren. In der Beispielimplementierung von 5 umfasst die Rechnerkomponente 500 einen Hardwareprozessor 502 und ein maschinenlesbares Speichermedium 504. In einigen Ausführungsformen kann die Computerkomponente 500 eine Ausführungsform eines Prozessors sein.
  • Bei dem Hardware-Prozessor 502 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in dem maschinenlesbaren Speichermedium 504 gespeichert sind. Der Hardware-Prozessor 502 kann Befehle, wie die Befehle 506-512, abrufen, dekodieren und ausführen, um Prozesse oder Operationen zum Herstellen von Verbindungen, Synchronisieren und Veröffentlichen von Routen/Zuständen zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 502 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
  • Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 504, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 504 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen RAM (NVRAM), einen elektrisch löschbaren, programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder Ähnliches handeln. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 504 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie nachstehend im Detail beschrieben, kann das maschinenlesbare Speichermedium 504 mit ausführbaren Befehlen kodiert sein, z. B. mit den Befehlen 504-512.
  • Der Hardware-Prozessor 502 kann die Funktionalität einer oder mehrerer Komponenten/Elemente eines SORS implementieren, wie z. B. SORS 201 (2), und kann die Anweisung 506 ausführen, um eine SDWAN-Geräteidentifikation zu empfangen. Das heißt, dass der CBS (implementiert über einen oder mehrere CBS-Server in einem SORS) und der PCM-Dienst (implementiert über einen oder mehrere PCM-Server in einem SORS) den Betrieb aufnehmen/initialisieren können. Die Zweigstellen-Gateways der SDWAN-Geräte der Mieter, z. B. Zweigstellen-Gateways und VPNCs, können ebenfalls ihren Betrieb aufnehmen, wobei sich die Zweigstellen-Gateways mit dem SORS verbinden, indem sie die spezifische DNS/VIP des SORS mit dem entsprechenden Zweigstellen-Gateway verwenden. Auch hier wird ein spezifischer DNS/VIP verwendet, um den Verkehr der Steuerebene vom anderen Managementverkehr zu isolieren. An diesem Punkt können sich die Branch Gateways gegenüber dem SORS identifizieren. Die Identifikationsdaten des Branch Gateways können die Seriennummer des Geräts, den Tenant Identifier, das Authentifizierungs-Token usw. enthalten.
  • Der Hardware-Prozessor 502 kann den Befehl 508 zur Authentifizierung des SDWAN-Geräts ausführen. Insbesondere wird das CBS des SORS das Zweigstellen-Gateway authentifizieren, indem es die vom Zweigstellen-Gateway empfangenen Identifikationsinformationen mit den Identifikationsinformationen abgleicht, die in einem Authentifizierungsserver oder einer Datenbank verwaltet werden. Wie oben in 4 beschrieben, kann die Authentifizierung durch den CBS unter Verwendung der Authentifizierungskomponente 316 durchgeführt werden. Wie oben beschrieben, kann das Filial-Gateway in einigen Ausführungsformen benutzerdefinierte HTTP-Header einfügen, um den Mieter des Filial-Gateways zu identifizieren. Wenn die Authentifizierung fehlschlägt, kann die Verbindung zwischen dem Filial-Gateway und dem CBS zurückgesetzt werden.
  • Der Hardware-Prozessor 502 kann die Anweisung 510 ausführen, um sich mit dem SDWAN-Gerät zu synchronisieren, basierend auf dem letzten Routenstatus und den lokalen Routenpräfixen, die dem SDWAN-Gerät zugeordnet sind. Das heißt, das Zweigstellen-Gateway und das CBS können Routeninformationen synchronisieren oder neu synchronisieren, und das Zweigstellen-Gateway kann alle erforderlichen Routenstatus und Tenant-Präfixe hochladen, die dem Zweigstellen-Gateway zugeordnet sind. Es versteht sich, dass lokale Routen oder Routenpräfixe über den Underlay-Routing-Stack gelernt werden können, die das Zweigstellen-Gateway über das CBS über einen Kanal an das PCM weiterleiten kann. In einigen Ausführungsformen kann der CBS alle bestehenden, vom PCM erstellten Routen als veraltet markieren und im Falle eines PCM-Ausfalls auf Routenaktualisierungen durch einen neuen PCM-Master warten. Wenn Routen nicht aktualisiert werden, kann das CBS diese Routen als gelöschte Routen kennzeichnen, und die Gateways der Zweigstellen können mit dem PCM synchronisiert werden.
  • Im Gegenzug kann das PCM diese neuesten Routenzustände/Präfixe (d. h. aktualisierte Routen-/Pfadinformationen) verarbeiten und neue Routen/Pfade erstellen. Das heißt, der Hardware-Prozessor 502 kann die Anweisung 512 ausführen, um die neuen Zustände an das SDWAN-Gerät zu veröffentlichen, die den neu erstellten Routen/Pfaden auf der Grundlage der neuesten Routenzustände/Präfixe entsprechen.
  • 6 zeigt eine schematische Darstellung einer Untergruppe von Virtual Private Network Clients (VPNCs), Knotengeräten und SDWAN Overlay Routing Service (SORS) in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie. Knoten 610 (dargestellt als Node-A1 610A, Node-A2 610B, Node-AN 610C, Node-B1 6100, Node-B2 610E, Node-BN 610F) und die VPNC-Geräte an entfernten Standorten 102 können eine zweischichtige Hierarchie von Geräten bilden, die mit dem SORS 201 kommunizieren und/oder auch untereinander kommunizieren. Die Untergruppe der Geräte dient nur zur Veranschaulichung und soll die hier diskutierten Ausführungsformen nicht einschränken.
  • Die Knoten 610 können ihre Konnektivitätsinformationen in-band oder outband mit Geräten oder Diensten im Cloud-Netzwerk, in einem Netzwerk eines Dritten (z. B. einem Client-Netzwerk) oder anderswo bekannt geben. In diesem Beispiel werden die Konnektivitätsinformationen an das SORS 201 übertragen (z. B. die Bekanntgabe von Routen, IPSec-Tunnel-Konnektivität usw.). SORS 201 kann die Konnektivitätsinformationen empfangen und sie verwenden, um zu bestimmen, welcher Knoten mit welchen bestimmten Geräten verbunden ist und wie sie verbunden sind. In einigen Beispielen kann SORS 201 einen Route Reflector (RR)-Prozess implementieren, um verfügbare Routen von Knoten 610 zu empfangen (z. B. Verlagerung des RR-Prozesses vom VNPC zum SORS). In anderen Ausführungsformen können die Konnektivitätsinformationen gesendet werden (z. B. Unicast usw.).
  • In einigen Beispielen kann das SORS 201 die Knoten 610 als Rechengeräte oder Eingabe-/Ausgabegeräte (E/A) gruppieren. Eine Untergruppe von Knoten 610 kann auf der Grundlage eines ähnlichen Konnektivitätsgraphen gruppiert werden. Zum Beispiel, Knoten-A1 610A, Knoten-A2 610B, Knoten-AN 610C verbindet VPNC-1 als primäres Gateway und VPNC-2 als sekundäres Gateway, die als eine Gruppe „Branch Group A 620A'' gruppiert werden. „Das Pfadberechnungsmodul (PCM) kann Routen für die gesamte Gruppe auf einmal berechnen. Die daraus resultierenden besten Routen und alternativen besten Routen können in einem Datenspeicher (z. B. einer gemeinsamen Datentabelle usw.) gespeichert werden. Die CBS-Server 210a-210d können die Routen aus diesem gemeinsamen Datenspeicher an alle Geräte der Gruppe weitergeben.
  • In einigen Beispielen kann das SORS 201 einen Topologiegraphen berechnen (z. B. eine topologische Struktur eines Netzwerks, die Darstellungen von Knoten 610 und Verbindungen zwischen ihnen als Links oder Linien zwischen den Knoten verwendet). Der Topologiegraph kann die Kommunikation und den Datenfluss zwischen den Komponenten (z. B. Knoten 610, VPNC-Geräte an entfernten Standorten 102 usw.) auf der Grundlage der logischen Topologie des Netzwerks identifizieren.
  • Anhand der Konnektivitätsinformationen und/oder des Topologiegraphen kann das SORS 201 bestimmen, welche Knoten Konnektivitätsinformationen von anderen Knoten erhalten sollen. Diese Knoten können gruppiert werden, um z. B. eine einzige Routenberechnung für die Gruppe durchzuführen, die Anzahl der im gesamten Netzwerk übertragenen elektronischen Kommunikationen zu reduzieren und/oder die Berechnungseffizienz für den Controller und die Geräte zu erhöhen.
  • 7 zeigt die Gruppierung von Zweiggeräten auf der Grundlage von Routeninformationen in Übereinstimmung mit den Ausführungsformen der hier offengelegten Technologie. Beispielsweise können Knoten 610 (dargestellt als Node-A1 610A, Node-A2 610B, Node-AN 610C, Node-B1 610D, Node-B2 610E, Node-BN 610F) mit ähnlichen Knoten gruppiert werden, die üblicherweise ähnliche Routeninformationen und/oder Eigenschaften (z. B. AS-PATH, Kosten, MED, Metric1, Metric2, Community/Extended Community) erhalten würden. In diesem Beispiel können Knoten-A1 610A, Knoten-A2 610B und Knoten-AN 610C in einer ersten Verzweigungsgruppe und Knoten-B1 610D, Knoten-B2 610E und Knoten-BN 610F in einer zweiten Verzweigungsgruppe gruppiert werden, so dass ähnliche Knoten 610 als Verzweigungsgruppen 620 gruppiert werden können (dargestellt als Verzweigungsgruppe A 620A und Verzweigungsgruppe B 620B).
  • In einigen Beispielen kann das SORS 201 alle Filialgateways automatisch als Filialgruppen 620 gruppieren und jede Filialgruppe 620 kann mit VPNC-1 und VPNC-2 als primärem und/oder sekundärem VPN-Konzentrator verbunden sein. Zum Beispiel kann die Zweiggruppe A 620A VPNC-1 an einem ersten entfernten Standort 102A als primären VPN-Konzentrator und VPNC-2 an einem zweiten entfernten Standort 102B als sekundären VPN-Konzentrator haben. Der zweiten Zweiggruppe können ebenfalls VPN-Konzentratoren zugewiesen werden, einschließlich der Zweiggruppe B 620B, die VPNC-2 an einem zweiten entfernten Standort 102B als primären VPN-Konzentrator und VPNC-1 an einem ersten entfernten Standort 102A als sekundären VPN-Konzentrator haben kann.
  • Die primäre und sekundäre Bezeichnung kann auf der Grundlage von Benutzerabsichten und/oder Rückmeldungen bestimmt werden, nachdem die Zweiggruppen 620 festgelegt wurden. Zum Beispiel kann ein Verwaltungsbenutzer festlegen, dass eine erste Gruppe primär und eine zweite Gruppe sekundär ist.
  • Sobald die Knoten 610 als Zweiggruppen 620 gruppiert sind, kann das SORS 201 die Route pro Gruppe berechnen. Dies kann dazu beitragen, Rechenressourcen zu sparen, da das SORS 201 möglicherweise nicht für jeden Knoten oder jedes Zweiggateway individuelle Routen berechnen muss und die Routenberechnungen für Knoten abstrahieren kann, die zuvor in Bezug auf ein oder mehrere Merkmale als ähnlich eingestuft wurden.
  • Die berechneten Routen können jedem Knoten 610 zur Verfügung gestellt oder bekannt gemacht werden. Zum Beispiel kann das einfache Erstellen von Zweiggruppen 620 nicht ausreichend sein, um das automatische Gruppenrouting zu implementieren. Zur Veranschaulichung: Knoten-A1 610A kann eine erste Route haben und SORS 201 kann die Route an jeden der anderen Knoten weitergeben. Wenn Knoten-A1 610A seine eigene Route empfängt, während SORS 201 Routen zur Zweiggruppe A 620A ankündigt, kann er eine Routingschleife erzeugen. In diesem Fall kann SORS 201 sicherstellen, dass es die Route von Knoten-A1 610A nicht erneut an denselben Knoten oder Peer-Knoten ankündigt, indem es jede Route mit einer Standortkennung versieht (z. B. Standardwerte für die MAC der werbenden Geräte usw.). Die Standortkennung kann eine Geräteeigenschaft sein.
  • Wenn die Kennzeichnung implementiert ist, kann die Zweiggruppe A 620A die Route empfangen und die Routen ignorieren, die mit ihrer eigenen Standortkennung gekennzeichnet sind. In diesem Beispiel kann das werbende Gerät, das sich nicht am empfangenden Gerät befindet, Routenschleifen vermeiden.
  • In einigen Beispielen kann das SORS 201 Routen an automatisch gruppierte Zweiggateways weiterleiten, ohne dass eine Routingschleife entsteht, und hilft bei der Implementierung eines hoch skalierbaren Routing-Stacks.
  • Es sei darauf hingewiesen, dass die hier verwendeten Begriffe „optimieren“, „optimal“ und dergleichen verwendet werden können, um die Leistung so effektiv oder perfekt wie möglich zu machen oder zu erreichen. Wie jedoch ein Fachmann, der dieses Dokument liest, erkennen wird, kann Perfektion nicht immer erreicht werden. Dementsprechend können diese Begriffe auch bedeuten, die Leistung so gut oder effektiv wie unter den gegebenen Umständen möglich oder praktikabel zu machen oder zu erreichen, oder die Leistung besser zu machen oder zu erreichen als die, die mit anderen Einstellungen oder Parametern erreicht werden kann.
  • 8 zeigt ein Beispiel für eine Rechnerkomponente, die zur Implementierung von Burst Preloading für die Schätzung der verfügbaren Bandbreite in Übereinstimmung mit verschiedenen Ausführungsformen verwendet werden kann. Wie in 8 dargestellt, kann die Rechnerkomponente 800 beispielsweise ein Servercomputer, ein Controller oder eine andere ähnliche Rechnerkomponente sein, die Daten verarbeiten kann. In der Beispielimplementierung von 8 umfasst die Rechnerkomponente 800 einen Hardwareprozessor 802 und ein maschinenlesbares Speichermedium 804.
  • Bei dem Hardware-Prozessor 802 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die im maschinenlesbaren Speichermedium 804 gespeichert sind. Der Hardware-Prozessor 802 kann Befehle, wie die Befehle 806-810, abrufen, dekodieren und ausführen, um Prozesse oder Operationen für das Burst-Preloading zur Schätzung der verfügbaren Bandbreite zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 802 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
  • Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 804, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. So kann das maschinenlesbare Speichermedium 804 beispielsweise ein Random Access Memory (RAM), ein nichtflüchtiges RAM (NVRAM), ein elektrisch löschbarer, programmierbarer Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder Ähnliches sein. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 804 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie unten im Detail beschrieben, kann das maschinenlesbare Speichermedium 804 mit ausführbaren Befehlen kodiert sein, zum Beispiel mit den Befehlen 806-810.
  • Der Hardware-Prozessor 802 kann den Befehl 806 ausführen, um eine Routenanzeige zu empfangen, die eine Konnektivitätsverbindung umfasst. Zum Beispiel kann der Hardware-Prozessor 802 von einer Vielzahl von Knoten eine Routenankündigung empfangen, die eine Konnektivitätsverbindung zwischen jedem der Vielzahl von Knoten und einem Virtual Private Network Concentrator (VPNC) umfasst.
  • Der Hardware-Prozessor 802 kann die Anweisung 808 ausführen, um einen Satz von Gruppen auf der Grundlage der Konnektivitätsverbindung zu bestimmen. Beispielsweise kann der Hardware-Prozessor 802 einen Satz von Gruppen aus der Vielzahl von Knoten auf der Grundlage der Konnektivitätsverbindung zwischen jedem der Vielzahl von Knoten und dem VPNC bestimmen.
  • Der Hardware-Prozessor 802 kann die Anweisung 810 ausführen, um einen Topologiegraphen und eine Routendefinition in Übereinstimmung mit der Konnektivitätsverbindung zu aktualisieren. Beispielsweise kann der Hardware-Prozessor 802 einen Topologiegraphen und eine Routendefinition entsprechend der Konnektivitätsverbindung für jede Gruppe aktualisieren. Die Mehrzahl der Knoten kann in die Lage versetzt werden, Datenpakete gemäß dem Topologiegraphen und der Routendefinition zu routen.
  • 9 zeigt ein Blockdiagramm eines beispielhaften Computersystems 900, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 900 umfasst einen Bus 902 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen, einen oder mehrere Hardware-Prozessoren 904, die mit dem Bus 902 zur Verarbeitung von Informationen verbunden sind. Der/die Hardware-Prozessoren) 904 kann/können z. B. ein oder mehrere Allzweck-Mikroprozessoren sein.
  • Das Computersystem 900 umfasst auch einen Hauptspeicher 906, wie z. B. einen Speicher mit wahlfreiem Zugriff (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 902 verbunden sind, um Informationen und Anweisungen zu speichern, die vom Prozessor 904 ausgeführt werden sollen. Der Hauptspeicher 906 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Befehlen verwendet werden, die vom Prozessor 904 ausgeführt werden sollen. Wenn solche Befehle in Speichermedien gespeichert werden, auf die der Prozessor 904 zugreifen kann, wird das Computersystem 900 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Befehlen angegebenen Operationen ausführt.
  • Das Computersystem 900 umfasst außerdem einen Festwertspeicher (ROM) 908 oder ein anderes statisches Speichergerät, das mit dem Bus 902 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 904 zu speichern. Ein Speichergerät 910, wie z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 902 verbunden, um Informationen und Anweisungen zu speichern.
  • Das Computersystem 900 kann über den Bus 902 mit einem Display 912, z. B. einer Flüssigkristallanzeige (LCD) (oder einem Berührungsbildschirm), verbunden sein, um einem Computerbenutzer Informationen anzuzeigen. Ein Eingabegerät 914, einschließlich alphanumerischer und anderer Tasten, ist mit dem Bus 902 gekoppelt, um Informationen und Befehlsauswahlen an den Prozessor 904 zu übermitteln. Eine andere Art von Benutzereingabegerät ist die Cursorsteuerung 916, wie z. B. eine Maus, ein Trackball oder Cursorrichtungstasten zur Übermittlung von Richtungsinformationen und Befehlsauswahlen an den Prozessor 904 und zur Steuerung der Cursorbewegung auf dem Display 912. In einigen Ausführungsformen können die gleichen Richtungsinformationen und Befehlsauswahlen wie bei der Cursorsteuerung über den Empfang von Berührungen auf einem Touchscreen ohne Cursor implementiert werden.
  • Das Computersystem 900 kann ein Benutzerschnittstellenmodul zur Implementierung einer grafischen Benutzeroberfläche enthalten, das in einem Massenspeichergerät als ausführbare Softwarecodes gespeichert werden kann, die von dem/den Computergerät(en) ausgeführt werden. Dieses und andere Module können beispielsweise Komponenten wie Softwarekomponenten, objektorientierte Softwarekomponenten, Klassenkomponenten und Aufgabenkomponenten, Prozesse, Funktionen, Attribute, Prozeduren, Unterprogramme, Segmente von Programmcode, Treiber, Firmware, Mikrocode, Schaltkreise, Daten, Datenbanken, Datenstrukturen, Tabellen, Arrays und Variablen umfassen.
  • Im Allgemeinen kann sich der hier verwendete Begriff „Komponente“, „Engine“, „System“, „Datenbank“, „Datenspeicher“ und dergleichen auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Ein- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es versteht sich von selbst, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufrufbar sein können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung eine Installation, Dekomprimierung oder Entschlüsselung erfordert). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts zur Ausführung durch das Computergerät gespeichert werden. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
  • Das Computersystem 900 kann die hierin beschriebenen Techniken unter Verwendung von kundenspezifischerfestverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem bewirkt oder programmiert, dass das Computersystem 900 eine Spezialmaschine ist. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 900 als Reaktion auf den/die Prozessor(en) 904 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren Befehlen ausführt/ausführen, die im Hauptspeicher 906 enthalten sind. Solche Anweisungen können in den Hauptspeicher 906 von einem anderen Speichermedium, wie z. B. dem Speichergerät 910, eingelesen werden. Die Ausführung der im Hauptspeicher 906 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 904, die hierin beschriebenen Verfahrensschritte auszuführen. In alternativen Ausführungsformen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
  • Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die eine Maschine in einer bestimmten Weise arbeiten lassen. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie die Speichervorrichtung 910. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 906. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM und EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
  • Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nicht-transitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 902 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
  • Das Computersystem 900 umfasst auch eine Netzwerkschnittstelle 918, die mit dem Bus 902 verbunden ist. Die Netzwerkschnittstelle 918 stellt eine Zweiwege-Datenkommunikationsverbindung zu einer oder mehreren Netzwerkverbindungen her, die mit einem oder mehreren lokalen Netzwerken verbunden sind. Bei der Netzwerkschnittstelle 918 kann es sich beispielsweise um eine ISDN-Karte (Integrated Services Digital Network), ein Kabelmodem, ein Satellitenmodem oder ein Modem handeln, das eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telefonleitung herstellt. Ein weiteres Beispiel: Die Netzwerkschnittstelle 918 kann eine LAN-Karte (Local Area Network) sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN (oder einer WAN-Komponente für die Kommunikation mit einem WAN) herzustellen. Es können auch drahtlose Verbindungen implementiert werden. In jeder dieser Implementierungen sendet und empfängt die Netzwerkschnittstelle 918 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen, die verschiedene Arten von Informationen darstellen.
  • Eine Netzverbindung ermöglicht in der Regel die Datenkommunikation über ein oder mehrere Netze zu anderen Datengeräten. Eine Netzverbindung kann beispielsweise eine Verbindung über ein lokales Netz zu einem Host-Computer oder zu Datengeräten herstellen, die von einem Internetdienstanbieter (ISP) betrieben werden. Der ISP wiederum bietet Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz an, das heute gemeinhin als „Internet“ bezeichnet wird. Sowohl das lokale Netz als auch das Internet verwenden elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen. Die Signale in den verschiedenen Netzwerken und die Signale auf der Netzwerkverbindung und über die Netzwerkschnittstelle 918, die die digitalen Daten zum und vom Computersystem 900 übertragen, sind Beispiele für Übertragungsmedien.
  • Das Computersystem 900 kann Nachrichten senden und Daten, einschließlich Programmcode, über das/die Netzwerk(e), die Netzwerkverbindung und die Netzwerkschnittstelle 918 empfangen. Im Internet-Beispiel könnte ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, den ISP, das lokale Netzwerk und die Netzwerkschnittstelle 918 übertragen.
  • Der empfangene Code kann vom Prozessor 904 bei seinem Empfang ausgeführt und/oder in der Speichervorrichtung 910 oder einem anderen nichtflüchtigen Speicher zur späteren Ausführung gespeichert werden.
  • Jeder der in den vorangegangenen Abschnitten beschriebenen Prozesse, Methoden und Algorithmen kann in Code-Komponenten verkörpert und vollständig oder teilweise durch diese automatisiert werden, die von einem oder mehreren Computersystemen oder Computerprozessoren mit Computerhardware ausgeführt werden. Das eine oder die mehreren Computersysteme oder Computerprozessoren können auch so betrieben werden, dass sie die Ausführung der entsprechenden Vorgänge in einer „Cloud Computing“-Umgebung oder als „Software as a Service“ (SaaS) unterstützen. Die Prozesse und Algorithmen können teilweise oder vollständig in anwendungsspezifischen Schaltkreisen implementiert sein. Die verschiedenen oben beschriebenen Merkmale und Verfahren können unabhängig voneinander verwendet oder auf verschiedene Weise kombiniert werden. Verschiedene Kombinationen und Unterkombinationen sollen in den Anwendungsbereich dieser Offenbarung fallen, und bestimmte Verfahrens- oder Prozessblöcke können in einigen Implementierungen weggelassen werden. Die hier beschriebenen Methoden und Prozesse sind auch nicht auf eine bestimmte Reihenfolge beschränkt, und die damit verbundenen Blöcke oder Zustände können in anderen geeigneten Reihenfolgen, parallel oder auf andere Weise ausgeführt werden. Blöcke oder Zustände können zu den offengelegten Beispielen hinzugefügt oder aus ihnen entfernt werden. Die Ausführung bestimmter Operationen oder Prozesse kann auf Computersysteme oder Computerprozessoren verteilt werden, die sich nicht nur auf einer einzigen Maschine befinden, sondern über eine Reihe von Maschinen verteilt sind.
  • Wie hierin verwendet, kann eine Schaltung in jeder Form von Hardware, Software oder einer Kombination davon implementiert werden. Beispielsweise können ein oder mehrere Prozessoren, Controller, ASICs, PLAs, PALs, CPLDs, FPGAs, logische Komponenten, Software-Routinen oder andere Mechanismen implementiert werden, um eine Schaltung zu bilden. Bei der Implementierung können die verschiedenen hier beschriebenen Schaltungen als diskrete Schaltungen implementiert werden, oder die beschriebenen Funktionen und Merkmale können teilweise oder insgesamt auf eine oder mehrere Schaltungen aufgeteilt werden. Auch wenn verschiedene Merkmale oder Funktionselemente einzeln als separate Schaltungen beschrieben oder beansprucht werden, können diese Merkmale und Funktionen von einer oder mehreren gemeinsamen Schaltungen gemeinsam genutzt werden, und eine solche Beschreibung soll nicht voraussetzen oder implizieren, dass separate Schaltungen erforderlich sind, um diese Merkmale oder Funktionen zu implementieren. Wenn eine Schaltung ganz oder teilweise mit Software implementiert ist, kann diese Software so implementiert werden, dass sie mit einem Computer- oder Verarbeitungssystem arbeitet, das in der Lage ist, die beschriebenen Funktionen auszuführen, z. B. das Computersystem 900.
  • Wie hierin verwendet, kann der Begriff „oder“ sowohl im einschließenden als auch im ausschließenden Sinne verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke, wie z. B. „kann“, „könnte“, „könnte“ oder „kann“, sind, sofern nicht ausdrücklich anders angegeben oder im Kontext anders verstanden, im Allgemeinen so zu verstehen, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte umfassen, während andere Ausführungsformen diese nicht umfassen.
  • Die in diesem Dokument verwendeten Begriffe und Ausdrücke sowie deren Abwandlungen sind, sofern nicht ausdrücklich anders angegeben, nicht einschränkend, sondern offen zu verstehen. Adjektive wie „konventionell“, „traditionell“, „normal“, „Standard“, „bekannt“ und Begriffe mit ähnlicher Bedeutung sind nicht so zu verstehen, dass sie den beschriebenen Gegenstand auf einen bestimmten Zeitraum oder auf einen zu einem bestimmten Zeitpunkt verfügbaren Gegenstand beschränken, sondern sollten so verstanden werden, dass sie konventionelle, traditionelle, normale oder Standardtechnologien umfassen, die jetzt oder zu einem beliebigen Zeitpunkt in der Zukunft verfügbar oder bekannt sein können. Das Vorhandensein erweiternder Wörter und Ausdrücke wie „eine oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnliche Ausdrücke in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Ausdrücke nicht vorhanden sind.

Claims (20)

  1. Eine Controller-Rechnervorrichtung, die Folgendes umfasst: einen Speicher; und einen oder mehrere Prozessoren, die so konfiguriert sind, dass sie im Speicher gespeicherte maschinenlesbare Anweisungen ausführen, um das Verfahren durchzuführen, das Folgendes umfasst: Empfangen einer Routenankündigungsnachricht von einer Vielzahl von Knoten, die eine Konnektivitätsverbindung zwischen jedem der Vielzahl von Knoten und einem Virtual Private Network Concentrator (VPNC) umfasst; Bestimmen eines Satzes von Gruppen der Vielzahl von Knoten auf der Grundlage der Konnektivitätsverbindung zwischen jedem der Vielzahl von Knoten und dem VPNC; und Aktualisieren eines Topologiediagramms und einer Routendefinition in Übereinstimmung mit der Konnektivitätsverbindung für jede der Gruppen, wobei die Mehrzahl der Knoten in der Lage ist, Datenpakete in Übereinstimmung mit dem Topologiediagramm und der Routendefinition zu routen.
  2. Die Controller-Rechnervorrichtung nach Anspruch 1, , wobei die Konnektivitätsverbindung einen primären VPNC und einen sekundären VPNC umfasst.
  3. Die Controller-Rechnervorrichtung nach Anspruch 1, wobei die Konnektivitätsverbindung nicht föderiert ist.
  4. Die Controller-Rechnervorrichtung nach Anspruch 1, wobei die Bestimmung des Satzes von Gruppen das Berechnen von Routen pro Gruppe umfasst, um Rechenressourcen zu sparen, und nicht das Berechnen von Routen pro Zweig-Gateway.
  5. Die Controller-Rechnervorrichtung nach Anspruch 1, wobei die Routenankündigungsnachricht eine Unicast-Nachricht ist.
  6. Die Controller-Rechnervorrichtung nach Anspruch 1, wobei die Konnektivitätsverbindung als Konnektivitätsdiagramm dargestellt wird.
  7. Die Controller-Rechnervorrichtung nach Anspruch 1, wobei die Anweisungen ferner das Verfahren ausführen, das Folgendes umfasst: Übertragen der Routendefinition an die Mehrzahl von Knoten, wobei die Mehrzahl von Knoten lokal auf die Routendefinition zugreift, um die Datenpakete zu routen.
  8. Ein computer-implementiertes Verfahren, das Folgendes umfasst: Empfangen einer Routenankündigungsnachricht, die eine Konnektivitätsverbindung zwischen jedem der mehreren Knoten und einem Virtual Private Network Concentrator (VPNC) umfasst, durch eine Controller-Rechenvorrichtung von einer Vielzahl von Knoten; Bestimmen eines Satzes von Gruppen der Vielzahl von Knoten durch die Controller-Rechenvorrichtung auf der Grundlage der Verbindungsverbindung zwischen jedem der Vielzahl von Knoten und dem VPNC; und Aktualisieren eines Topologiediagramms und einer Routendefinition in Übereinstimmung mit der Konnektivitätsverbindung für jede der Gruppen durch die Steuerrechnervorrichtung, wobei die Mehrzahl der Knoten in der Lage ist, Datenpakete in Übereinstimmung mit dem Topologiediagramm und der Routendefinition zu routen.
  9. Verfahren nach Anspruch 8, wobei die Konnektivitätsverbindung einen primären VPNC und einen sekundären VPNC umfasst.
  10. Verfahren nach Anspruch 8, wobei die Konnektivitätsverbindung nicht föderiert ist.
  11. Verfahren nach Anspruch 8, wobei die Bestimmung des Satzes von Gruppen die Berechnung von Routen pro Gruppe umfasst, um Rechenressourcen zu sparen, und nicht die Berechnung von Routen pro Zweiggateway.
  12. Verfahren nach Anspruch 8, wobei die Routenankündigungsnachricht eine Unicast-Nachricht ist.
  13. Verfahren nach Anspruch 8, wobei die Konnektivitätsverbindung als Konnektivitätsdiagramm dargestellt wird.
  14. Verfahren nach Anspruch 8, ferner umfassend: Übertragen der Routendefinition an die Mehrzahl von Knoten, wobei die Mehrzahl von Knoten lokal auf die Routendefinition zugreift, um die Datenpakete zu routen.
  15. Ein nicht-transitorisches, computerlesbares Speichermedium, das eine Vielzahl von Anweisungen speichert, die von einem oder mehreren Prozessoren ausgeführt werden können, wobei die Vielzahl von Anweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen,: von einer Vielzahl von Knoten eine Routenankündigungsnachricht empfangen, die eine Konnektivitätsverbindung zwischen jedem der Vielzahl von Knoten und einem Virtual Private Network Concentrator (VPNC) umfasst; Bestimmen eines Satzes von Gruppen aus der Vielzahl von Knoten auf der Grundlage der Konnektivitätsverbindung zwischen jedem aus der Vielzahl von Knoten und dem VPNC; und Aktualisieren eines Topologiediagramms und einer Routendefinition in Übereinstimmung mit der Konnektivitätsverbindung für jede der Gruppen, wobei die Mehrzahl der Knoten in der Lage ist, Datenpakete in Übereinstimmung mit dem Topologiediagramm und der Routendefinition zu routen.
  16. Computerlesbares Speichermedium nach Anspruch 15, wobei die Konnektivitätsverbindung einen primären VPNC und einen sekundären VPNC umfasst.
  17. Computerlesbares Speichermedium nach Anspruch 15, wobei die Konnektivitätsverbindung nicht föderiert ist.
  18. Computerlesbares Speichermedium nach Anspruch 15, wobei das Bestimmen des Satzes von Gruppen das Berechnen von Routen pro Gruppe umfasst, um Rechenressourcen zu sparen, und nicht das Berechnen von Routen pro Zweiggateway.
  19. Computerlesbares Speichermedium nach Anspruch 15, wobei die Routenankündigungsnachricht eine Unicast-Nachricht ist.
  20. Computerlesbares Speichermedium nach Anspruch 15, wobei die Konnektivitätsverbindung als Konnektivitätsdiagramm dargestellt ist.
DE102022108273.3A 2021-10-12 2022-04-06 Plattform für automatische gruppierung und routing Pending DE102022108273A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/499,804 US20230110199A1 (en) 2021-10-12 2021-10-12 Auto-grouping and routing platform
US17/499,804 2021-10-12

Publications (1)

Publication Number Publication Date
DE102022108273A1 true DE102022108273A1 (de) 2023-04-13

Family

ID=85705613

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022108273.3A Pending DE102022108273A1 (de) 2021-10-12 2022-04-06 Plattform für automatische gruppierung und routing

Country Status (3)

Country Link
US (1) US20230110199A1 (de)
CN (1) CN115967664A (de)
DE (1) DE102022108273A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412951B (zh) * 2018-10-12 2021-06-22 华为技术有限公司 一种发送路由信息的方法和装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7376743B1 (en) * 2002-04-02 2008-05-20 Cisco Technology, Inc. Method and apparatus for load balancing in a virtual private network
US7266715B1 (en) * 2003-04-29 2007-09-04 Cisco Technology, Inc. Methods and apparatus for maintaining a virtual private network connection
US7647426B2 (en) * 2006-01-12 2010-01-12 Cisco Technology, Inc. Method and apparatus for achieving Border Gateway Protocol convergence using alternate route information
US8320361B2 (en) * 2009-02-27 2012-11-27 Cisco Technology, Inc. Advertising alternate paths at border gateway protocol route reflectors
US8443435B1 (en) * 2010-12-02 2013-05-14 Juniper Networks, Inc. VPN resource connectivity in large-scale enterprise networks
JP6358959B2 (ja) * 2012-01-30 2018-07-18 アライドテレシスホールディングス株式会社 常用冗長リンクを備えた階層ネットワーク
US9537749B2 (en) * 2012-06-06 2017-01-03 Tufin Software Technologies Ltd. Method of network connectivity analyses and system thereof
US9531565B2 (en) * 2013-12-20 2016-12-27 Pismo Labs Technology Limited Methods and systems for transmitting and receiving packets
CA2911730C (en) * 2014-11-10 2019-10-01 Maged E. Beshai Distributed determination of routes in a vast communication network
US9894103B2 (en) * 2015-08-28 2018-02-13 Nicira, Inc. Performing source network address translation based on remote device management attributes
US10680965B1 (en) * 2019-01-17 2020-06-09 Hewlett Packard Enterprise Development Lp Redistribution of VPN tunnels among VPN concentrators
US10778537B1 (en) * 2019-02-19 2020-09-15 Cisco Technology, Inc. Presenting devices from an aggregated node within a network topology
US11658882B1 (en) * 2020-01-21 2023-05-23 Vmware, Inc. Algorithm-based automatic presentation of a hierarchical graphical representation of a computer network structure

Also Published As

Publication number Publication date
US20230110199A1 (en) 2023-04-13
CN115967664A (zh) 2023-04-14

Similar Documents

Publication Publication Date Title
US10757006B1 (en) Enhanced traffic flow in software-defined networking controller-based architecture
US20210036951A1 (en) Segment routing with fast reroute for container networking
US10659358B2 (en) Method and apparatus for advanced statistics collection
Oktian et al. Distributed SDN controller system: A survey on design choice
US11558293B2 (en) Network controller subclusters for distributed compute deployments
US10938660B1 (en) Automation of maintenance mode operations for network devices
US11201782B1 (en) Automation of maintenance mode operations for network devices
JP5976942B2 (ja) ポリシーベースのデータセンタネットワーク自動化を提供するシステムおよび方法
DE102021109547A1 (de) Sdwan overlay- routing- dienst
US9710762B2 (en) Dynamic logging
US11750464B2 (en) Global network state management
KR20210095888A (ko) 세분화된 네트워크 엘리먼트를 포함하는 로직 라우터
DE102014117461A1 (de) Hybrider SDN-Controller
DE102014117460A1 (de) Programmierbares verteiltes Networking
US10379890B1 (en) Synchronized cache of an operational state of distributed software system
US20160253046A1 (en) Recording system state data and presenting a navigable graphical user interface
DE112019005826T5 (de) Lastverteilter Zugang zu verteilten Endpunkten unter Verwendung globaler Netzwerkadressen
Bahnasse et al. Smart hybrid SDN approach for MPLS VPN management on digital environment
Mukerjee et al. Understanding tradeoffs in incremental deployment of new network architectures
DE102022108273A1 (de) Plattform für automatische gruppierung und routing
US10142200B2 (en) Methods and systems for a network appliance module enabling dynamic VDC aware span
US10009253B2 (en) Providing shared resources to virtual devices
US20240056498A1 (en) Scalable creation of connections
WO2024035634A1 (en) Scalable creation of connections
DE102021125850A1 (de) Paketinternes versions-tagging unter verwendung einer perimeter-nat

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R082 Change of representative

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB - PATENT- , DE

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB PATENTANWA, DE