DE112019000666T5

DE112019000666T5 - Dynamische rekonfiguration einer softwarearchitektur für eine ccap (converged cable access platform)

Info

Publication number: DE112019000666T5
Application number: DE112019000666.5T
Authority: DE
Inventors: Adam Levy; Andrey Ter-Zakgariants; Anna Kopelnik; Nitin Sasi Kumar
Original assignee: Harmonic Inc
Current assignee: Harmonic Inc
Priority date: 2018-02-05
Filing date: 2019-02-04
Publication date: 2020-10-15
Also published as: WO2019152942A3; GB2584046A; GB2584046B; WO2019152942A2; GB202011904D0

Abstract

Lösungsansätze für eine Converged Cable Access Platform (CCAP)-Verarbeitung. Eine softwarebasierte CCAP-Verarbeitung wird auf einer oder mehreren physischen Maschinen ausgeführt. Die softwarebasierte CCAP-Umgebung wird durch eine Mehrzahl von Funktionsblöcken unterhalten, die jeweils in Software implementiert sind und eine spezifische Funktion durchführen, welche die softwarebasierte CCAP-Umgebung unterstützt. Die Mehrzahl von Funktionsblöcken führen ihre spezifische Funktion jeweils asynchron zueinander durch. Für die softwarebasierte CCAP-Umgebung wird eine Konfiguration vorgehalten, welche die Mehrzahl von Funktionsblöcken jeweils separat für eine oder mehrere Data Over Cable Service Interface Specification (DOCSIS)-Dienstgruppen informiert. Die Konfiguration kann eine oder mehrere DOCSIS-Dienstgruppen bezüglich ihrer Zugehörigkeit zu einem jeweiligen Funktionsblock als logische Einheit behandeln.

Description

GEBIET DER ERFINDUNG
Ausführungsformen der Erfindung betreffen allgemein eine softwarebasierte CCAP (Converged Cable Access Platform).
HINTERGRUND
Eine CCAP (Converged Cable Access Platform) ist ein von CableLabs geleitetes Vorhaben, das zwei Projekte technisch und operativ vereint: CMAP (Converged Multiservice Access Platform), unter der Leitung von Comcast Corp., und CESAR (Converged Edge Services Access Router), unter der Leitung von Time Warner Cable Inc.
DOCSIS (Data Over Cable Service Interface Specification) ist ein Telekommunikationsstandard, der verwendet wird, um einen Internetzugang über ein Kabelmodem bereitzustellen.
Derzeit ist es branchenübliche Praxis, eine CCAP-Funktionalität in einer Spezial-Hardware zu implementieren, und zwar beispielsweise TCAMs für ein Klassifizieren und FPGAs für Scheduling und Replikation von Paketen (TCAM = Ternary Content-Addressable Memory = ternärer inhaltsadressierbarer Speicher; FPGA = Field-Programmable Gate Arrays = vor Ort programmierbare Gatter-Anordnung).
Figurenliste
Ausführungsformen der Erfindung sind beispielhaft und nicht einschränkend in den Figuren der anliegenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen; in diesen sind:

1A ein Blockdiagramm einer softwarebasierten CCAP gemäß einer Ausführungsform der Erfindung;
1B ein Ablaufdiagramm, das die Funktionsschritte einer Durchführung einer CCAP-Verarbeitung gemäß einer Ausführungsform der Erfindung darstellt;
2A eine Darstellung eines Downstream- und Upstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung;
2B ein Ablaufdiagramm, das die Funktionsschritte eines Downstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung darstellt;
3 ein Ablaufdiagramm, das die Funktionsschritte eines Upstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung darstellt; und
4 ein Blockdiagramm, das ein Computersystem darstellt, auf dem eine Ausführungsform der Erfindung implementiert sein kann.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es werden hier Lösungsansätze für eine softwarebasierte CCAP (Converged Cable Access Platform) vorgestellt, bei der eine Mehrzahl von Funktionsblöcken verwendet werden. In der folgenden Beschreibung sind zu Erläuterungszwecken zahlreiche spezifische Details dargelegt, um für ein grundlegendes Verständnis der Ausführungsformen der hier beschriebenen Erfindung zu sorgen. Es versteht sich jedoch, dass die hier beschriebenen Ausführungsformen der Erfindung ohne diese spezifischen Details ausgeführt sein können.
In anderen Fällen sind allgemein bekannte Strukturen und Vorrichtungen in Form eines Blockdiagramms dargestellt oder werden auf einer höheren Ebene erörtert, um zu vermeiden, dass die Lehren der Ausführungsformen der Erfindung unnötigerweise unklar werden.
Bei einer softwarebasierten CCAP (Converged Cable Access Platform) handelt es sich um Software, welche die Funktionen eines Hardware-basierten CCAP durchführt. Die softwarebasierten CCAP kann auf Hardware-Bauteilen ausgeführt werden, die einen COTS-Switch/Router (COTS = Commercial Off-the-Shelf = kommerzielle Produkte aus dem Regal/ „von der Stange“) und einen oder mehrere COTS-Compute-Server beinhalten. Ein kommerzielles Beispiel eines softwarebasierten CCAP ist CableOS, das von Harmonic, Inc. von San Jose, Kalifornien, bezogen werden kann.
Ausführungsformen der Erfindung betreffen eine softwarebasierte CCAP-Umgebung, bei der vollständig mittels Software implementierte Funktionsblöcke verwendet werden. Bei einer Ausführungsform werden die Funktionen einer softwarebasierten CCAP-Umgebung mittels einer Mehrzahl von Funktionsblöcken durchgeführt. Bei jedem der Funktionsblöcke kann der Fokus auf einer spezifischen Funktion liegen. Somit ist jeder Funktionsblock eine in sich abgeschlossene Funktionseinheit.
1A ist ein Blockdiagramm einer softwarebasierten CCAP (Converged Cable Access Platform) gemäß einer Ausführungsform der Erfindung. Wie in 1A dargestellt, kann eine softwarebasierte CCAP-Umgebung 12 auf einer oder mehreren physischen Maschinen 10 ausgeführt werden. Jede der physischen Maschinen 10 kann unter Verwendung eines COTS-Switch/Router und eines oder mehrerer COTS-Compute-Server implementiert werden (COTS = Commercial Off-the-Shelf = kommerzielle Produkte aus dem Regal/ „von der Stange“). Die Funktionsweise einer einzelnen physischen Maschine 10 wird später noch mit Bezug auf 4 detaillierter beschrieben.
1B ist ein Ablaufdiagramm, das die Funktionsschritte einer Durchführung einer CCAP-Verarbeitung gemäß einer Ausführungsform der Erfindung darstellt. In Schritt 50 wird eine softwarebasierte CCAP-Umgebung 12 auf einer oder mehreren physischen Maschinen 10 ausgeführt. Die softwarebasierte CCAP-Umgebung 12 kann durch eine Mehrzahl von Funktionsblöcken 14 unterhalten werden. Wie durch den Tiefstellungsindex der Funktionsblöcke 14 in 1A angegeben, kann die Mehrzahl von Funktionsblöcken 14 einer beliebigen Anzahl von Funktionsblöcken in der Mehrzahl von Funktionsblöcken 14 entsprechen.
Jeder Funktionsblock 14 verarbeitet einen Satz von Eingangsgrößen und produziert einen Satz von Ausgangsgrößen. Der Satz von in einen einzelnen Funktionsblock 14 hineingehenden Eingangsgrößen kann Ereignissen, einem Signal und/oder Nachrichten entsprechen, die entweder als Ausgangsgröße anderer Funktionsblöcke 14 erzeugt werden oder extern erzeugt werden. Der Satz von Ausgangsgrößen eines Funktionsblocks 14 kann durch einen oder mehrere weitere Funktionsblöcke 14 als Eingangsgröße genutzt werden. Beispielsweise kann die Ausgangsgröße des Funktionsblockes 14₁ durch den Funktionsblock 14₂ als Eingangsgröße genutzt werden. Jeder der Mehrzahl von Funktionsblöcken 14 kann in seinem eigenen separaten Container ausgeführt werden, beispielsweise, jedoch nicht eingeschränkt auf, eine virtuelle Maschine.
Das Ziel von Ausgangsgrößen eines Funktionsblockes 14 können einer oder mehrere andere spezifische Funktionsblöcke 14 sein. Auch kann der Satz von Ausgangsgrößen, die durch einen einzelnen Funktionsblock 14 erzeugt werden, eine oder mehrere Ausgangsgrößen beinhalten.
Gewisse Typen von Funktionsblöcken 14 (hier als „Vermittler-Funktionsblock“ oder „Verteiler-Funktionsblock“ bezeichnet) können einen Satz von Ausgangsgrößen analysieren und entscheiden, welcher Funktionsblock 14 diesen Satz von Ausgangsgrößen verarbeiten/empfangen sollte. Mit anderen Worten kann ein Vermittler-Funktionsblock 14 veranlassen, dass der durch einen ersten Funktionsblock 14 erzeugte Satz von Ausgangsgrößen zu einem zweiten Funktionsblock 14 als Eingangsgröße geleitet wird und somit anschließend durch diesen genutzt wird.
Bei den Funktionsblöcken 14 kann ein synchrones Ausführen, ein asynchrones Ausführen und/oder ein parallel erfolgendes Ausführen stattfinden. Bei einem Funktionsblock 14 einer Ausführungsform kann ein Ausführen immer dann erfolgen, wenn bei dem Funktionsblock 14 ein Satz von Eingangsgrößen zur Verarbeitung vorliegt. Bei einer zur Laufzeit erfolgenden Ausführung kann ein Scheduling eines Funktionsblocks so erfolgen, dass eine Ausführung in einem einzelnen Thread 16, in mehreren Threads 16 eines einzelnen Prozesses, in einer Mehrprozessverarbeitung, auf mehreren Rechenknoten oder in einer beliebigen Kombination von diesen erfolgt. Bei einem speziellen Funktionsblock 14 kann die Ausführung so angepasst werden, dass ein Wechsel von einem oder mehreren der Folgenden vorgenommen wird: (a) von Ausführung in einem einzelnen Thread 16 zu Ausführung in mehreren Threads 16, (b) von Ausführung in mehreren Threads 16 zu Ausführung in einem einzelnen Thread 16, (c) von Ausführung auf mehreren Rechenknoten einer oder mehrerer physischer Maschinen 10 zu Ausführung auf einem einzelnen Rechenknoten einer oder mehrerer physischer Maschinen 10, und (d) von Ausführung auf einem einzelnen Rechenknoten einer oder mehrerer physischer Maschinen 10 zu Ausführung auf mehreren Rechenknoten einer oder mehrerer physischer Maschinen 10.
Erneut bezugnehmend auf 1B wird in Schritt 60 von 1 angegeben, dass eine oder mehrere Konfigurationsdateien 18 für eine softwarebasierte CCAP-Umgebung 12 vorgehalten werden. Mittels einer oder mehrerer Konfigurationsdateien 18 wird jeder der Mehrzahl von Funktionsblöcken einzeln informiert, wie ein Betrieb erfolgen soll. Beispielsweise wird durch eine oder mehrere Konfigurationsdateien 18 jeder der Mehrzahl von Funktionsblöcken einzeln informiert, wie ein Betrieb bezüglich einer oder mehrerer DOCSIS-Dienstgruppen (DOCSIS = Data Over Cable Service Interface Specification; Dienstgruppe = SG) erfolgen soll. Bei einer Ausführungsform können eine oder mehrere DOCSIS-Dienstgruppen durch eine oder mehrere Konfigurationsdateien 18 bezüglich ihrer Zugehörigkeit zu Funktionsblöcken 14 als logische Einheit behandelt werden. Beispielsweise kann ein Satz von DOCSIS-Dienstgruppen (bei denen es sich wahrscheinlich lediglich um eine Teilmenge der Gesamtanzahl von DOCSIS-Dienstgruppen handelt) einander zugeordnet werden, sodass sie als einzelne Einheit behandelt werden, wodurch verhindert wird, dass bei ihnen eine in unterschiedliche Weise erfolgende Zuordnung durchgeführt wird.
Bei Ausführungsformen kann ein Funktionsblock 14 angewiesen werden, für eine einzelne DOCSIS-Dienstgruppe oder für mehrere DOCSIS-Dienstgruppen eine Bearbeitung durchzuführen. Zur Verdeutlichung kann bei einer Ausführungsform ein erster Funktionsblock 14 angewiesen werden, für eine einzelne DOCSIS-Dienstgruppe eine Bearbeitung durchzuführen, während ein zweiter Funktionsblock 14 angewiesen wird, für mehrere DOCSIS-Dienstgruppen eine Bearbeitung durchzuführen.
Die Implementierung der zur Laufzeit erfolgenden Ausführung einer softwarebasierten CCAP-Umgebung 12 kann unter Verwendung von Bibliothek-APIs ausgeführt werden. Die Funktionsweise der zur Laufzeit erfolgenden Ausführung kann unter Verwendung einer oder mehrerer Konfigurationsdateien 18 gesteuert werden, die spezifizieren, wie gewisse Funktionen durchgeführt werden sollen. Es wird hier angemerkt, dass die durch einen jeweiligen Funktionsblock 14 implementierte Software-Logik keine Kenntnis davon zu haben braucht, wie und wo dessen Ausführung planmäßig erfolgen soll.
Gewisse Ausführungsformen können Funktionsblöcke 14 wie hier beschrieben verwenden, um das DOCSIS-Protokoll zu implementieren, jedoch ist es bei Ausführungsformen auch möglich, Funktionsblöcke 14 zu verwenden, um eine beliebige Funktionalität durchzuführen, die herkömmlicherweise durch eine CCAP-Vorrichtung durchgeführt wurde.
Bei einer Ausführungsform kann ein Funktionsblock 14 durch ein als Thread ausführbares Objekt implementiert werden. Ein nicht einschränkendes, illustrierendes Beispiel eines als Thread ausführbaren Objektes ist eine Instanz einer C++-Klasse. Zur Verdeutlichung kann ein separates, als Thread ausführbares Objekt eine Funktionalität zur Unterstützung des DOCSIS-Protokolls durchführen, beispielsweise ein Ranging eines Modems und eine Registrierung eines Modems. Eine Gruppe von als Thread ausführbaren Objekten kann in einem einzelnen Thread ausgeführt werden, beispielsweise einem Thread 16₁ . Ein einzelnes als Thread ausführbares Objekt kann in mehreren Threads ausgeführt werden, beispielsweise den Threads 16₁-16₃ . Es ist möglich, dass ein als Thread ausführbares Objekt keine Kenntnis vom Threading-Modell hat, das von der softwarebasierten CCAP-Umgebung 12 zur Laufzeit verwendet wird, und deren Operation kann unter Verwendung einer oder mehrerer Konfigurationsdateien 18 konfiguriert sein, die von einem jeweiligen als Thread ausführbaren Objekt gelesen wird.
Beim Stand der Technik wurde die Architektur herkömmlicher CMTS-Software für spezifische Anwendungsfälle erstellt (CMTS = Cable Modem Termination System). Die Ausführung einer derartigen speziell zugeschnittenen Software erfolgte auf teurer Hardware, und zwar sogar für geringe Lasten. Weiter handelte es sich bei CMTS-Software des Standes der Technik um eine monolithische Architektur, bei der keine anforderungsgemäße Skalierung einzelner Funktionen erfolgte.
Im Gegensatz zum Stand der Technik wird durch eine Mehrzahl von Funktionsblöcken 14 ermöglicht, dass bei Ausführungsformen eine dynamische Anpassung an die sich ändernden gegenwärtigen Erfordernisse vorgenommen wird. Beispielsweise kann eine softwarebasierte CCAP-Umgebung 12 ein einen einzelnen Thread aufweisendes Modell verwenden, wenn eine geringe Ressourcenmenge einer oder mehrerer physischer Maschinen 10 zur Verfügung steht; ein derartiges geringes Niveau an verfügbaren Ressourcen kann dynamisch bestimmt werden, und zwar als unterhalb eines gewissen Schwellenwerts befindlich. Alternativ kann von der softwarebasierten CCAP-Umgebung 12 ein mehrere Threads aufweisendes Modell verwendet werden, wenn eine große Leistung/ eine große Anzahl von Ressourcen zur Verfügung steht. Als weitere Option kann eine softwarebasierte CCAP-Umgebung 12 einer Ausführungsform eine Mischung von Modellen verwenden, um eine Anpassung einzelner Funktionen an die aktuell erfahrene Belastung vorzunehmen. In vorteilhafter Weise wird bei Ausführungsformen für eine softwarebasierte CCAP-Umgebung 12 keine Software-Neugestaltung benötigt, um nahezu jeden CMTS-Anwendungsfall zu unterstützen.
Wenn die der softwarebasierten CCAP-Umgebung 12 zur Verfügung stehenden Rechenressourcen begrenzt sind, können sich zwei oder mehr als Thread ausführbare Objekte einen einzelnen Thread 16 teilen. Zur Durchführung einer lastbasierten Skalierung ist es möglich, als Thread ausführbare Objekte in separaten Threads 16 auszuführen. Bei einer Ausführungsform kann die Zuordnung von als Thread ausführbaren Objekten zu Threads 16 auf einer statischen Konfiguration basieren, beispielsweise basierend auf den erwarteten Lastmustern, die durch eine oder mehrere Konfigurationsdateien 18 spezifiziert sind. Bei weiteren Ausführungsformen kann die Zuordnung von als Thread ausführbaren Objekten zu Threads dynamisch zur Laufzeit erfolgen, beispielsweise basierend auf den beobachteten Lastmustern und der Verfügbarkeit von Rechenressourcen, die durch eine oder mehrere Konfigurationsdateien 18 spezifiziert sind.
Bei einer Ausführungsform mit eingeschränkten CPU-Ressourcen und geringer Last ist es möglich, dass alle als Thread ausführbaren Objekte in einem einzelnen Thread 16 ausgeführt werden. Bei Ausführungsformen, die große Last und verfügbare Rechenressourcen aufweisen, können als Thread ausführbare Objekte in separaten Threads 16 ausgeführt werden und/oder jeder Thread 16 kann auf einem separaten CPU-Kern laufen, um eine große Last zu bewältigen.
Ausführungsformen können eine Zuordnung zwischen Funktionsblöcken 14 und Threads 16 basierend auf beobachteten Lastmustern durchführen. Beispielsweise kann eine große Last bei gewissen Funktionen (beispielsweise Modem-Ranging) vorliegen, jedoch geringe Lasten bei anderen Funktionen vorliegen. Demzufolge können Ausführungsformen darauf reagieren, indem die für ein Modem-Ranging verantwortlichen Funktionsblöcke 14 auf einem separaten Thread 16 ausgeführt werden, jedoch alle anderen Funktionsblöcke 14 auf einem gemeinsam genutzten Thread 16 ausgeführt werden. In vorteilhafter Weise kann eine dynamische Änderung der Zuordnung zwischen Funktionsblöcken 14 und Threads 16 basierend auf der beobachteten Last vorgenommen werden.
Bei Ausführungsformen der Erfindung kann eine Anpassung der Zuordnung zwischen Funktionsblöcken 14 und Threads 16 basierend auf einer manuellen Konfiguration oder in autonomer Weise basierend auf einer beobachteten Last und verfügbaren Ressourcen einer oder mehrerer physischer Maschinen 10 vorgenommen werden. Bei einigen Ausführungsformen kann eine automatische Anpassung der Zuordnung zwischen Funktionsblöcken und Threads 16 gemäß einem vorab programmierten oder erstellten Modell erfolgen. Beispielsweise kann einer Lernfunktion eine manuelle Konfiguration zugeführt werden, wobei diese das vorab programmierte Modell mit der Zeit verfeinert.
Wie zuvor erwähnt, kann ein Funktionsblock 14 einen Satz von Eingangsgrößen verarbeiten, um einen Satz von Ausgangsgrößen zu erzeugen. Ein Satz von Eingangsgrößen kann einer gewissen Menge an Paketen entsprechen, so dass ein Funktionsblock 14 ein gewisses Ausmaß an Bearbeitung betreffend einen Satz von Paketen durchführt. Der durch einen Funktionsblock 14 erzeugte Satz von Ausgangsgrößen kann einer gewissen Menge an Paketen entsprechen, die für eine nächste Bearbeitungsstufe bereit sind. Somit können, da der Satz von durch einen Funktionsblock erzeugten Ausgangsgrößen als Satz von Eingangsgrößen zu einem unterschiedlichen Funktionsblock 14 geroutet werden kann, Funktionsblöcke 14 in einer Pipeline oder als Satz von Stufen betrieben werden. Die nachfolgend erörterten Stufen können jeweils durch einen oder mehrere Funktionsblöcke 14 implementiert sein.
Einer durch einen oder mehrere Funktionsblöcke 14 implementierten Stufe kann ein Satz von Ressourcen zugeordnet werden, um deren Ausführung zu optimieren, und zwar im Hinblick auf den größeren Zusammenhang, in welchem eine Stufe zum Einsatz kommt (beispielsweise, jedoch nicht eingeschränkt auf, die Gesamtmenge verfügbarer Ressourcen, die anderen Nutzer dieser Ressourcen, und die durch die Stufe bewerkstelligte Arbeitslast).
LOCKING-FREIE RINGE
Ausführungsformen der Erfindung können Funktionsblöcke verwenden, um die Funktionen eines auf der MAC-Schicht erfolgenden Downstream-Forwarding bei DOCSIS zwischen mehreren Software-Cores eines COTS-Switch/Router (bei gewissen Ausführungsformen als CRE (Core Routing Engine) bezeichnet) einer virtuellen CCAP aufzuteilen. Bei gewissen Ausführungsformen wird das DPDK (Data Plane Development Kit) genutzt, das sich durch das Merkmal von Locking-freien Ringe zwischen den Cores auszeichnet. Derartige Locking-freie Ringe enthalten Zeiger, die auf gemeinsam genutzte DPDK-MBUFs zeigen (MBUFs = Message Buffers = Nachrichtenpuffer). Jedes MBUF weist einen Header, der eine DPDK-MBUF betreffende Bibliotheksinformation enthält, sowie eine Struktur auf, die sich zwischen dem Ende des MBUF-Headers und dem Anfang der Paketdaten befindet und die als MBUF-„Headroom“ bezeichnet wird. Bei Ausführungsbeispielen wird ein Speichern von für ein DOCSIS-Forwarding nützlicher Information in dem MBUF-Headroom verlangt.
Bei Ausführungsformen der Erfindung können „Ein-Erzeuger-Ein-Abnehmer“-Ringe von DPDK verwenden, um eine Synchronisierung von Threads zwischen mehreren Erzeugern oder mehreren Abnehmern zu vermeiden. Jeder Thread überprüft wiederholt die Verfügbarkeit jeglicher Pakete auf jedem der Ringe, die er empfängt.
1 ist eine Darstellung eines Downstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung. Der Verteiler-Thread 110 von 1 ist ein Thread, der verantwortlich dafür ist, alle ankommenden physischen Pakete von dem Trunk-Ethernetport zu empfangen, der an einen COTS-Switch/Router (welcher bei einer Ausführungsform einer CRE entsprechen kann) angeschlossen ist. Die von dem Verteiler-Thread 110 empfangenen ankommenden physischen Pakete beinhalten über das Internet transportierte Downstream-Pakete sowie Upstream-Pakete, die mittels Tunneling von einem Remote-PHY-Gerät (RPD) eingespeist wurden.
Obschon Ausführungsformen der Erfindung hauptsächlich in Bezug darauf beschrieben sind, dass der Verteiler-Thread 110 mittels Software implementiert ist, sei angemerkt, dass bei weiteren Ausführungsformen der Erfindung die Funktionen des Verteiler-Thread 110 in Form von Hardware ausgeführt sein können. Beispielsweise können gewisse Ausführungsformen eine Netzwerkkarte (NIC) verwenden, welche die dem Verteiler-Thread 110 zugewiesenen Funktionen durchführt. Ein derartiges Ausführungsbeispiel kann eine Verteiler-Komponente beinhalten, bei der es sich um ein Hardware-Bauteil handelt, beispielsweise, jedoch nicht eingeschränkt auf, eine NIC, wobei dieses konfiguriert ist, die dem Verteiler-Thread 110 zugewiesenen Funktionen durchzuführen, wie hier erörtert. Weitere Ausführungsformen der Erfindung können eine Verteiler-Komponente beinhalten, welche die dem Verteiler-Thread 110 zugewiesenen Funktionen wie hier erörtert teilweise mit einem Hardware-Bauteil und teilweise mittels Software durchführt.
Upstream-Pakete können in das L2TPv3-Protokoll gekapselt sein und werden an eine L2TPv3-LCCE (LCCE = Logical Control Connection Entity) adressiert, die auf einem COTS-Switch/Router (bei einem Ausführungsbeispiel z. B. eine CRE (Core Routing Engine)) implementiert ist. Bei einer Ausführungsform dieser Erfindung wird eine lokal verwaltete MAC-Adresse dem LCCE zugewiesen, und zwar von der Form 02:xx:xx:xx:xx:xx, so dass der Verteiler-Thread 110 ein mittels Tunneling übertragenes L2TPv3-Paket rasch erkennen kann und ein Forwarding dieses Paketes an den UsMac-Thread 112 durchführen kann, der eine Upstream-Verarbeitung durchführt. Der Verteiler-Thread 110 führt ein Forwarding aller anderen empfangenen Pakete an einen von einer Mehrzahl von DSPP-Threads 114 durch, bei denen es sich um Threads handelt, die für eine Downstream-Verarbeitung verantwortlich sind. Um dies zu bewerkstelligen, kann der Verteiler-Thread 110 ein Hashing der Quellen- und Ziel-MAC- und/oder -IP-Adressen durchführen, um eine Lastverteilung zwischen den DSPP-Threads 114 durchzuführen.
AUSFÜHRUNGSUMGEBUNGEN
Bevor die Funktionsweise von Downstream- und Upstream-Datenströmen erörtert wird, ist es hilfreich, die Beziehung zwischen den in 1 dargestellten operativen Stufen und den logischen Cores zu verstehen. Die in 1 dargestellten operativen Stufen entsprechen der Verteilerstufe (entsprechend der Verteiler-Komponente), der DSPP-Stufe (DSPP = Downstream-Paketverarbeitung) (entsprechend der Mehrzahl von DSPP-Threads 114), der DsEnc-Stufe (DsEnc = Downstream-Verschlüsselung) (entsprechend der Mehrzahl von DsEnc-Threads 116), der TM-Stufe (TM = Datenverkehrsverwalter) (entsprechend der Mehrzahl von TM-Threads 118), der DsMac-Stufe (DsMac = Downstream-Medienzugangssteuerung) (entsprechend der Mehrzahl von DsMac-Threads 120), der UsMac-Stufe (UsMac = Upstream-Medienzugangssteuerung) (entsprechend einem UsMac-Thread 112), und der USPP-Stufe (USPP = Upstream-Paketverarbeitung) (entsprechend einer UsMac-Komponente). Die funktionalen Komponenten in jeder dieser Stufen wird später noch detaillierter erläutert. Wie hier verwendet, beinhaltet ein logischer Core einen physischen CPU-Core, beispielsweise die Hyper-Threading-Technologie von Intel®, oder einen virtuellen CPU-Core.
Bei gewissen Ausführungsformen der Erfindung kann jede in 1 dargestellte operative Stufe auf separaten logischen Cores ausgeführt werden. Bei weiteren Ausführungsformen der Erfindung können zwei oder mehr in 1 dargestellte operative Stufen in einem einzelnen logischen Core ausgeführt werden.
Bei noch weiteren Ausführungsformen der Erfindung können alle in 1 dargestellten operativen Stufen in einem einzelnen logischen Core ausgeführt werden, und zwar entweder mittels eines manuellen Scheduling (z. B. Round-Robin) oder durch ein mittels Zeitscheiben erfolgenden nebenläufigen Scheduling der Stufen in dem einzelnen Core. Weitere Ausführungsformen der Erfindung können ermöglichen, dass ein Benutzer konfiguriert, welcher logische Core eine jeweilige operative Stufe ausführen sollte, und zwar ohne Einschränkung, derart, dass der Benutzer beispielsweise konfigurieren kann, dass ein einzelner logischer Core alle operativen Stufen ausführt oder eine Mehrzahl von logischen Cores jeweils eine unterschiedliche operative Stufe ausführen.
DOWNSTREAM-DATENFLÜSSE
2 ist ein Ablaufdiagramm, das die Funktionsschritte eines Downstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung darstellt. Die Schritte von 2 werden nachfolgend mit Bezug auf 1 erläutert.
Bei Schritt 210 empfängt der Verteiler-Thread 110 ankommende physikalische Downstream-Pakete, z. B. durch das Internet transportierte Pakete.
Danach führt bei Schritt 220 der Verteiler-Thread 110 ein Forwarding der empfangenen Downstream-Pakete an einen von einer Mehrzahl von DSPP-Threads 114 durch. Ein DSPP-Thread 114 ist für ein Zuordnen eines Downstream-Paketes zu einem DOCSIS-Dienstdatenstrom verantwortlich. Alle DSPP-Threads 114 haben Zugang zu derselben Datenbank von Downstream-Klassifizierern. Ein DSPP-Thread 114 klassifiziert ein Paket unter Verwendung eines internen Index, der als TmFlowIndex (Datenverkehrsverwalter-Datenstromindex) bezeichnet wird. Alle DSPP-Threads 114 und alle TM-Threads 118 verwenden den gleichen TmFlowIndex. Ein DSPP-Thread 114 speichert den TmFlowIndex, zu dem er das Paket zugeordnet hat, in dem MBUF-Headroom-Feld.
In DOCSIS gehört jeder Downstream-Dienstdatenstrom zu einer einzelnen DOCSIS-„MAC-Domain“, die von Ausführungsformen der Erfindung durch eine MAC-Domain-ID identifiziert wird. Der DSPP-Thread 114 speichert auch die MAC-Domain-ID des Dienstdatenstroms eines Paketes in dem MBUF-Headroom. DOCSIS definiert auch das Konzept einer MD-DSSG (MD-DSSG = MAC-Domain downstream service group = MAC-Domain-Downstream-Dienstgruppe), die den Satz von Downstream-Kanälen in einer MAC-Domain beinhaltet, der ein einzelnes CM erreicht. Der DSPP-Thread 114 einer Ausführungsform platziert in einem MBUF-Headroom eine systemeindeutige Kennung der MD-DSSG, welche den Dienstdatenstrom des Paketes enthält. Die MAC-Domain-ID oder die MD-DSSG-Kennung werden verwendet, um auszuwählen, zu welchem TM-Thread durch DsEnc ein Forwarding eines Downstream-Paketes durchgeführt wird, das es von dem DSPP-Thread 114 empfängt.
Bei Schritt 230 führt einer von einer Mehrzahl von DsEnc-Threads 116 eine Verschlüsselung der Downstream-Pakete durch. Um dies zu bewerkstelligen, kann ein spezieller DsEnc-Thread 116 ein Downstream-Paket unter Verwendung eines gemeinsam genutzten Hardware-Bauteils verschlüsseln, beispielsweise des QuickAssist-Moduls von Intel®. Mehrere DsEnc-Threads 116 können sich lediglich eines oder zwei Hardware-Module teilen (z. B. eines oder zwei je COTS-Switch/ Router (der in einem Ausführungsbeispiel als „Core-Server“ (CS) bezeichnet werden kann). Demgemäß kann die Warteschlangenverzögerung des gemeinsam benutzten Verschlüsselungsmechanismus variabel sein. Um die Variabilität der Verzögerung von abgehenden Paketen nach einer Gesamtdurchsatz-Begrenzungsfunktion des Datenverkehrsverwalters zu verringern, erfolgt die Verschlüsselung durch den DsEnc-Thread 116, bevor ein Datenverkehrsverwaltungs-Scheduling erfolgt. Bei Ausführungsformen der Erfindung wird in vorteilhafter Weise eine Verschlüsselung durchgeführt, bevor das Scheduling von Paketen erfolgt. Bei aktuellen branchenüblichen CMTS-Implementierungen wird zunächst ein Scheduling von Paketen und danach eine Verschlüsselung in kommerziellen DOCSIS-Chips durchgeführt, beispielsweise, jedoch nicht eingeschränkt auf den Chip BCM3215 von Broadcom Corporation, der die Downstream-MAC-Funktionen durchführt.
Um das Auftreten von ,Fehlschlägen‘ des Cache („Cache Misses“) in DsEnc-Threads 116 zu verringern, wird jedem DOCSIS-Dienstdatenstrom ein einzelner DsEnc-Thread 116 zugeordnet. Somit wird die Tastungsinformation und Statistiken für einen Dienstdatenstrom in lediglich einem einzelnen DSPP-Core-L1-Cache vorgehalten. Der entsprechende DSPPzu-DsEnc-Ring für jeden DSPP-Thread 114 wird an einen DSPP-Thread 114 übermittelt, wenn ein Dienstdatenstrom hinzugefügt wird.
Bei einem Ausführungsbeispiel kann die Funktionalität, die vorstehend mit Bezug auf die Mehrzahl von DsEnc-Threads beschrieben wurde, zumindest teilweise in Hardware anstatt ausschließlich mittels Software implementiert werden. Bei einem derartigen Ausführungsbeispiel kann die Funktionalität, die hier als einer Mehrzahl von DsEnc-Threads 116 zugeteilt oder durch diese durchgeführt beschrieben wurde, durch eines oder mehrere DsEnc-Hardware-Bauteile durchgeführt werden, die einer Hardware-Karte entsprechen können, welche die Operationen eines Verschlüsselns von Downstream-Paketen beschleunigt. Wie hier verwendet, beinhaltet der Begriff ,DsEnc-Komponente‘ sowohl eine Software-Implementierung als auch eine Hardware-Implementierung, sowie eine Implementierung, die sowohl Hardware als auch Software beinhaltet. Es werden zwar Ausführungsbeispiele hauptsächlich in Bezug darauf beschrieben, dass DsEnc-Threads 116 in Software implementiert sind, für Fachleute versteht es sich jedoch, dass weitere Ausführungsbeispiele verwendet werden können, bei denen DsEnc-Threads 116 teilweise oder vollständig mittels Hardware implementiert sind.
Danach verarbeitet bei Schritt 240 ein geeigneter TM-Thread 118 das Paket. Jede DOCSIS-MAC-Domain ist einem einzelnen TM-Thread 118 (TM = Datenverkehrsmanager) zugewiesen. Ein TM-Thread 118 führt ein Einreihen von Paketen in eine je Datenstrom vorhandene Warteschlange durch und führt ein Scheduling von Paketen für eine Übertragung unter Verwendung eines hierarchischen Mehrebenen-Paket-Schedulers durch. Jeder SF (Dienstdatenstrom), und somit jeder TmFlowIndex, gehört zu einer einzelnen MAC-Domain. Wenn die Steuerebene einen neuen TmFlowIndex einem DsEnc-Thread 116 hinzufügt, liefert die Steuerebene auch einen Zeiger auf den zutreffenden DsEnc-zu-TM-Ring, um den TM-Thread 118 zu erreichen, welcher der MAC-Domain des Dienstdatenstroms zugewiesen wurde.
Ausführungsbeispiele der Erfindung erfordern, dass MAC-Domains ein TM-Thread 118 zugewiesen wird. Dies ist dadurch begründet, dass die meisten MAC-Domains aus stark überlappenden DCSs (Downstream Channel Sets = Sätzen von Downstream-Kanälen) mit gemeinsam genutzten Downstream-Kanälen besteht. Dadurch, dass man das gesamte Scheduling von DCSs, die denselben Kanal benutzen, in demselben Kanalsatz gehalten wird, wird ein nebenläufiger Inter-Core-Zugriff auf Speicherdatenstrukturen vermieden. Ein TM-Thread 118 führt ein Scheduling eines jeweiligen Paketes auf einen speziellen Downstream-HF-Kanal durch.
Falls eine MAC-Domain aus disjunkten (d. h. nicht-überlappenden) SGs (Downstream-Dienstgruppen) besteht, dann können Ausführungsbeispiele die disjunkten Sätze von SGs unterschiedlichen TM-Threads 118 zuweisen und dabei weiterhin eine Inter-Core-Koordination einer je Paket vorhandenen Scheduling-Information vermeiden.
Bei Schritt 250 führt ein DsMac-Thread 120 eine Kapselung eines Paketes in einen L2TPv3-DEPI-Tunnel zu dem RPD (Remote-PHY-Gerät) durch, welches den Downstream-Kanal überträgt. Jeder Downstream-Kanal wird einem einzigen DsMac-Thread 120 zugewiesen. Ein einziger DsMac-Thread 120 kann für jeden Kanal verwendet werden, um einen Einzel-Core-Betrieb von je Paket vorhandenen Sequenznummern aufrechtzuerhalten. Derartige je Paket vorhandene Sequenznummern beinhalten eine MPEG-Sequenznummer oder eine PSP-Sequenznummer.
Nach dem Kapseln eines Paketes bei Schritt 260 sendet der DsMac-Thread 120 das Paket aus dem DPDK-Ethernet-Port eines Trunk-Ports an die CRE.
In vorteilhafter Weise teilen sich der Verteiler-Thread 110, die Mehrzahl von DSPP-Threads 114, die Mehrzahl von DsEnc-Threads 116, die Mehrzahl von TM-Threads 118 und die Mehrzahl von DsMac-Threads 120 alle dieselbe Multi-Core-CPU und denselben Hardware-Bus für Chip-Signale von der CPU an den Speicher.
UPSTREAM-DATENSTRÖME
3 ist ein Ablaufdiagramm, das die Funktionsschritte eines Upstream-Forwarding bei DOCSIS gemäß einer Ausführungsform der Erfindung darstellt. Die Schritte von 3 werden nachfolgend mit Bezug auf 1 erläutert.
Bei Schritt 310 empfängt der Verteiler-Thread 110 ankommende Upstream-Pakete, z. B. Pakete, die mittels Tunneling von einem RPD (Remote-PHY-Gerät) eingespeist wurden.
Bei Schritt 320 führt der Verteiler-Thread 110, wenn er erkennt, dass ein empfangenes Paket ein Upstream-Paket ist, ein Forwarding des Upstream-Paketes an einen UsMac-Thread 112 zur Verarbeitung durch. Upstream-Pakete können in das L2TPv3-Protokoll gekapselt sein und werden an eine L2TPv3-LCCE (LCCE = Logical Control Connection Entity) adressiert, die auf einem COTS-Switch/Router (bei einem Ausführungsbeispiel z. B. eine CRE) implementiert ist. Bei einer Ausführungsform dieser Erfindung wird eine lokal verwaltete MAC-Adresse dem LCCE zugewiesen, und zwar von der Form 02:xx:xx:xx:xx:xx, so dass der Verteiler-Thread 110 ein mittels Tunneling übertragenes L2TPv3-Paket rasch erkennen kann und ein Forwarding dieses Paketes an den UsMac-Thread 112 durchführen kann, der eine Upstream-Verarbeitung durchführt.
Bei Schritt 330 empfängt der UsMac-Thread 110 Upstream-Pakete, die per Tunneling an eine LCCE-MAC-Adresse gesendet wurden. Der UsMac-Thread 112 setzt die Sequenzen von Upstream-Bursts von einem jeweiligen Upstream-Kanal wieder zusammen und trennt die Bursts in separate Upstream-Pakete auf, und zwar jeden in sein eigenes MBUF.
Danach sendet bei Schritt 340 der UsMac-Thread 112 die separaten Datenpakete an einen USPP-Thread 122. Der UsMac-Thread 112 führt ein separates Erkennen von Upstream-Bandbreitenanfrage-MMMs (MMMs = Mac Management Messages = MAC-Verwaltungsnachrichten) durch und leitet diese weiter an eine (nicht dargestellte) Scheduling-Software-Anwendung für ein Upstream-DOCSIS-Scheduling. Der UsMac-Thread 112 erkennt auch weitere Upstream-MAC-MMMs und leitet diese zur Bearbeitung an einen DOCSIS-Protokoll-Softwareprozess weiter.
Bei Schritt 350 führt der USPP-Thread 122 eine Quellenadressenprüfung für Upstream-IP-Pakete sowie jegliche VLAN-Kapselung durch, die für einen DOCSIS-L2VPN-Betrieb erforderlich ist.
Bei einem Ausführungsbeispiel kann die Funktionalität, die vorstehend mit Bezug auf den USPP-Thread 122 beschrieben wurde, zumindest teilweise in Hardware anstatt ausschließlich mittels Software implementiert werden. Bei einem derartigen Ausführungsbeispiel kann die Funktionalität, die hier als dem USPP-Thread 122 zugeteilt oder durch diesen durchgeführt beschrieben wurde, durch eines oder mehrere USPP-Hardware-Bauteile durchgeführt werden, die einer Hardware-Karte entsprechen können, welche die Operationen eines Verschlüsselns von Upstream-Paketen beschleunigt. Wie hier verwendet, beinhaltet der Begriff ,USSP-Komponente‘ und ,USSP-Stufe‘ sowohl eine Software-Implementierung als auch eine Hardware-Implementierung, sowie eine Implementierung, die sowohl Hardware als auch Software beinhaltet. Es werden zwar Ausführungsbeispiele hauptsächlich in Bezug darauf beschrieben, dass der USPP-Thread 122 in Software implementiert ist, für Fachleute versteht es sich jedoch, dass weitere Ausführungsbeispiele verwendet werden können, bei denen der USPP-Thread 122 teilweise oder vollständig mittels Hardware implementiert ist.
Bei Schritt 260 führt der USPP-Thread 122 ein Forwarding von Paketen direkt an den DPDK-Ethernet-Port für die Ethernet-Trunk-Schnittstelle an einem COTS-Switch/Router durch (wobei es sich bei diesem bei einem Ausführungsbeispiel um einen CRE handeln kann).
Es können mehrere Paare aus UsMac-Thread 122/ USPP-Thread 122 erzeugt werden, in welchem Fall in vorteilhafter Weise eine LCCE-IP-Adresse einem einzelnen UsMac-Thread 112 zugewiesen wird und der Verteiler-Thread 112 ein Forwarding von Upstream-Paketen an das geeignete Paar aus UsMac-Thread 122/ USPP-Thread 122 basierend auf der LCCE-IP-Zieladresse durchführt, wodurch ein Duplizieren von je CM ermittelter Upstream-Quellenadressen-Prüfungsinformation und einer je Dienstdatenstrom ermittelten Statistikinformation zwischen Cores vermieden wird, was die Wahrscheinlichkeit von Fehlschlägen des L1-Cache („L1 Cache Misses“) vermindert. Die Tatsache, dass bei Ausführungsbeispielen gewissen DOCSIS-Komponenten eine spezielle Instanz einer Verarbeitungsstufe in einem CPU-Core zugewiesen wird, ist einzigartig und stellt einen großen erfinderischen Schritt für die CMTS-Industriebranche dar. Der in der Softwarebranche üblicherweise verwendete Mechanismus, um eine Arbeit zwischen mehreren CPU-Cores aufzuteilen, besteht in symmetrischem Multiprocessing und einem Lastausgleich zwischen den Cores, bei geringer oder nicht vorhandener Kenntnis der Anwendungs-Domain der Softwareprozesse. Beispiele eines Zuweisens von DOCSIS-Komponenten an Verarbeitungsstufen beinhalten: Zuweisen eines DOCSIS-Dienstdatenstroms an eine einzelne DsEnc-Stufe, Zuweisen einer DOCSIS-MAC-Domain oder einer MAC-Domain-Downstream-Dienstgruppe zu einer einzelnen TM-Stufe, Zuweisen eines DOCSIS-Downstream-Kanals zu einer einzelnen DSMAC-Stufe, Zuweisen einer DOCSIS-LCCE zu einer einzelnen US MAC-Stufe, und Zuweisen eines DOSCIS-Dienstdatenstroms zu einer einzelnen USPP-Stufe.
HOHE UND NIEDRIGE PRIORITÄT AUFWEISENDE RINGE
Es ist möglich, dass während eines stark ausgelasteten Betriebs die Auslastung jeglicher Thread-Instanz zu groß ist, um mit ankommenden Paketen Schritt zu halten, was zu einem Stau und letztendlich einem Verlust von Daten von MBUFs auf den mit diesen Thread-Instanzen befassten Ringen führen kann. Gewisse Ausführungsbeispiele können Datenringe von variierendem Prioritätsgrad verwenden, so dass bei Datenverkehr geringerer Priorität eine Stauung auftritt und dieser Drops erleidet, bevor dies bei Ringen höherer Priorität der Fall ist. Ausführungsformen können Datenringe von beliebiger Prioritätsgradzahl verwenden, z. B. können zwei Grade vorhanden sein, so dass Datenringen lediglich eine ,hohe‘ oder eine ,niedrige‘ Priorität zugewiesen werden kann, oder es können drei oder mehr Grade vorhanden sein, so dass ein beliebiger Grad an Granularität verwendet werden kann, um eine Rangfolge von Datenringen basierend auf Priorität herzustellen.
Ringe hoher Priorität können in vorteilhafter Weise für gewisse Datenverkehrsklassen verwendet werden. Beispielsweise werden bei einem Ausführungsbeispiel, in abnehmender Prioritätsrangfolge, Ringe hoher Priorität in vorteilhafter Weise für die folgenden Datenverkehrsklassen verwendet: Downstream-DOCSIS-MAPs und UCDs, Upstream-Bandbreitenanfragen, Downstream- und Upstream-Sprachnutzdaten, und schließlich alle anderen DOCSIS-MMMs (MMMs = Mac Management Messages = MAC-Verwaltungsnachrichten).
HARDWAREIMPLEMENTIERUNG
Bei einer Ausführungsform kann eine softwarebasierte CCAP-Umgebung 12 auf einer oder mehreren physischen Maschinen 10 ausgeführt werden (CCAP = Converged Cable Access Platform). Bei einer Ausführungsform kann jede physische Maschine einem Computersystem entsprechen. 4 ist ein Blockdiagramm, das ein Computersystem 400 darstellt, welches verwendet werden kann, um eine Ausführungsform der Erfindung zu implementieren. Bei einer Ausführungsform beinhaltet das Computersystem 400 einen Prozessor 404, einen Hauptspeicher 406, einen ROM 408, eine Speichervorrichtung 410 und eine Kommunikationsschnittstelle 418. Das Computersystem 400 beinhaltet mindestens einen Prozessor 404 zum Verarbeiten von Information. Das Computersystem 400 beinhaltet auch einen Hauptspeicher 406, wie beispielsweise einen RAM (Random Access Memory = Speicher mit wahlfreiem Zugriff) oder eine andere dynamische Speichervorrichtung zum Speichern von Informationen und Anweisungen, die durch den Prozessor 404 auszuführen sind. Der Hauptspeicher 406 kann auch für ein Speichern von temporären Variablen oder weiterer Zwischeninformation während eines Ausführens von durch den Prozessor 404 auszuführenden Anweisungen verwendet werden. Das Computersystem 400 beinhaltet einen ROM (Read Only Memory = Nur-Lese-Speicher) 408 oder eine andere statische Speichervorrichtung zum Speichern von statischer Information und Anweisungen für den Prozessor 404. Eine Speichervorrichtung 410, wie beispielsweise eine Magnetplatte oder eine optische Platte, ist für ein Speichern von Information und Anweisungen vorgesehen.
Ausführungsformen der Erfindung betreffen die Verwendung eines Computersystems 400 für ein Implementieren der hier beschriebenen Verfahren. Gemäß einer Ausführungsform der Erfindung werden diese Verfahren durch das Computersystem 400 ansprechend darauf durchgeführt, dass der Prozessor 404 eine oder mehrere Sequenzen von einer oder mehreren im Hauptspeicher 406 befindlichen Anweisungen ausführt. Derartige Anweisungen können in den Hauptspeicher 406 von einem anderen maschinenlesbaren Medium, wie beispielsweise der Speichervorrichtung 410, eingelesen werden. Ein Ausführen der im Hauptspeicher 406 enthaltenen Sequenzen von Anweisungen veranlasst den Prozessor 404, die hier beschriebenen Prozessschritte auszuführen. Bei alternativen Ausführungsformen kann ein fest verdrahteter Schaltkreis verwendet werden, anstelle oder in Kombination mit Softwareanweisungen, um Ausführungsformen der Erfindung zu implementieren. Somit sind Ausführungsformen der Erfindung nicht auf irgendeine spezifische Kombination aus Hardware-Schaltkreisen und Software eingeschränkt.
Der Begriff „nicht-transitorisches maschinenlesbares Speichermedium“, wie hier verwendet, bezieht sich auf jegliches körperlich greifbare Medium, das am Speichern von Anweisungen teilnimmt, die dem Prozessor 404 zum Ausführen geliefert werden können. Nicht einschränkende, illustrierende Beispiele von maschinenlesbaren Medien beinhalten beispielsweise eine Floppy-Disk, eine flexible Disk, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, ein RAM, ein PROM, ein EPROM, ein FLASH-EPROM, einen beliebigen anderen Speicherchip oder -patrone oder ein beliebiges anderes Medium, von dem ein Computer lesen kann.
Verschiedene Formen von nicht-transitorischen maschinenlesbaren Medien können daran beteiligt sein, eine oder mehrere Sequenzen aus einer oder mehreren Anweisungen an den Prozessor 404 zur Ausführung zu transportieren. Beispielsweise können sich die Anweisungen anfänglich auf einer Magnetplatte eines entfernt befindlichen Computers befinden. Der entfernte Computer kann die Anweisungen in seinen dynamischen Speicher laden und die Anweisungen über eine Netzwerkanbindung 420 zum Computersystem 400 senden.
Die Kommunikationsschnittstelle 418 stellt eine Zweiweg-Datenkommunikationsverbindung zu einer Netzwerkanbindung 420 bereit, die mit einem lokalen Netzwerk verbunden ist. Beispielsweise kann eine Kommunikationsschnittstelle 418 eine ISDN-Karte (ISDN = Integrated Services Digital Network = dienstintegrierendes digitales Netz) oder ein Modem sein, um eine Datenkommunikationsverbindung zu einem korrespondierenden Typ von Telefonleitung bereitzustellen. Als weiteres Beispiel kann eine Kommunikationsschnittstelle 418 eine LAN-Karte (LAN = Local Area Network = Lokales Netzwerk) sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN bereitzustellen. Es können auch Funkanbindungen implementiert sein. Bei jeder derartigen Implementierung führt die Kommunikationsschnittstelle 418 ein Senden und Empfangen von elektrischen, elektromagnetischen oder optischen Signalen durch, die digitale Datenströme transportieren, welche verschiedene Typen von Information repräsentieren.
Die Netzwerkanbindung 420 stellt typischerweise eine Datenkommunikation über eines oder mehrere Netzwerke zu anderen Datengeräten bereit. Beispielsweise kann die Netzwerk-Anbindung 420 eine Verbindung über ein lokales Netzwerk zu einem Host-Computer oder zu Datenanlagen bereitstellen, die durch einen Internetdienstanbieter (ISP) betrieben werden.
Das Computersystem 400 kann Nachrichten senden und Daten, einschließlich Programmcode, empfangen, und zwar über das/die Netzwerk(e), die Netzwerkanbindung 420 und die die Kommunikationsschnittstelle 418. Beispielsweise könnte ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, einen lokalen ISP, ein lokales Netzwerk, und danach an die Kommunikationsschnittstelle 418 übertragen. Der empfangene Code kann durch den Prozessor 404 bei Empfang ausgeführt werden, und/oder in einer Speicher-vorrichtung 410 oder einem anderen nicht-flüchtigen Speicher zur späteren Ausführung gespeichert werden.
In der vorhergehenden Beschreibung wurden Ausführungsformen der Erfindung mit Bezug auf zahlreiche spezifische Details beschrieben, die von Implementierung zu Implementierung variieren können. Somit ist der einzige und ausschließliche Indikator, was die Erfindung ist und was seitens der Anmelder als Erfindung beabsichtigt ist, der Satz der Ansprüche, die aus dieser Anmeldung hervorgehen, und zwar in der spezifischen Form, in welcher derartige Ansprüche zu erstellen sind, einschließlich jeglicher anschließender Korrekturen. Jegliche Definitionen, die für in derartigen Ansprüchen enthaltene Begriffe hier ausdrücklich dargelegt sind, sollen für die Bedeutung derartiger Begriffe wie in den Ansprüchen verwendet maßgeblich sein. Somit sollte keine Einschränkung, Element, Eigenschaft, Merkmal, Vorteil oder Attribut, das in einem Anspruch nicht ausdrücklich dargelegt ist, den Schutzumfang dieses Anspruchs in irgendeiner Weise einschränken. Die Beschreibung und die Zeichnungen sind demgemäß in einem illustrierenden und nicht in einem einschränkenden Sinn zu verstehen.

Claims

Eines oder mehrere nicht-transitorische computerlesbare Speichermedien, die eine oder mehrere Sequenzen von Anweisungen zur Durchführung einer Converged Cable Access Platform (CCAP)-Verarbeitung speichern, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen durch einen oder mehrere Prozessoren veranlasst: Ausführen einer softwarebasierten CCAP-Umgebung auf einer oder mehreren physischen Maschinen, wobei die softwarebasierte CCAP-Umgebung durch eine Mehrzahl von Funktionsblöcken unterhalten wird, wobei jeder der Mehrzahl von Funktionsblöcken in Software implementiert ist und eine spezifische Funktion durchführt, welche die softwarebasierte CCAP-Umgebung unterstützt, und wobei die Mehrzahl von Funktionsblöcken ihre spezifische Funktion jeweils asynchron zueinander durchführen; und Vorhalten einer Konfiguration für die softwarebasierte CCAP-Umgebung, welche jeden der Mehrzahl von Funktionsblöcken separat bezüglich einer oder mehrerer Data Over Cable Service Interface Specification (DOCSIS)-Dienstgruppen informiert.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei die eine oder mehreren DOCSIS-Dienstgruppen bezüglich ihrer Zugehörigkeit zu einem jeweiligen der Mehrzahl von Funktionsblöcken durch die Konfiguration als logische Einheit behandelt werden.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: Anpassen eines Ausführens eines speziellen Funktionsblocks der Mehrzahl von Funktionsblöcken, so dass ein Wechsel von einem oder mehreren der folgenden Ausführungen vorgenommen wird: (a) von Ausführung in einem einzelnen Thread zu Ausführung in mehreren Threads, (b) von Ausführung in mehreren Threads zu Ausführung in einem einzelnen Thread, (c) von Ausführung auf mehreren Rechenknoten zu Ausführung auf einem einzelnen Rechenknoten, und (d) von Ausführung auf einem einzelnen Rechenknoten zu Ausführung auf mehreren Rechenknoten.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei die Mehrzahl von Funktionsblöcken jeweils in einem separaten Container ausgeführt werden.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: Anweisen eines ersten Funktionsblocks der Mehrzahl von Funktionsblöcken, für eine einzelne DOCSIS-Dienstgruppe eine Bearbeitung durchzuführen; und Anweisen eines zweiten Funktionsblocks der Mehrzahl von Funktionsblöcken, für mehrere DOCSIS-Dienstgruppen eine Bearbeitung durchzuführen.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Messen eines Satzes von verfügbaren Ressourcen des einen oder der mehreren Rechenknoten; ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit unterhalb eines vordefinierten Schwellenwertes liegt, Aktualisieren einer Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass die Funktionsblöcke jeweils in einem separaten Ausführungs-Thread ausgeführt werden; und ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit auf oder oberhalb des vordefinierten Schwellenwertes liegt, Aktualisieren der Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit,, um zu veranlassen, dass die Funktionsblöcke jeweils in mehreren Ausführungs-Threads ausgeführt werden.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Messen eines Satzes von verfügbaren Ressourcen des einen oder der mehreren Rechenknoten; ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit unterhalb des vordefinierten Schwellenwertes liegt, Aktualisieren einer Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass ein erster Teil der Funktionsblöcke in einem separaten Ausführungs-Thread ausgeführt wird; und ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit auf oder oberhalb eines vordefinierten Schwellenwertes liegt, Aktualisieren der Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass ein zweiter Teil der Funktionsblöcke in mehreren Ausführungs-Threads ausgeführt wird.
Eines oder mehrere nicht-transitorische computerlesbare Speichermedien nach Anspruch 1, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Verändern während der Laufzeit, ob mindestens einer der Mehrzahl von Funktionsblöcken auf Basis eines einzelnen Threads oder auf Basis mehrerer Threads ausgeführt wird, und zwar basierend auf beobachteten Lastmustern und einer Verfügbarkeit von Rechenressourcen.
Eine oder mehrere Vorrichtungen zur Durchführung einer CCAP-Verarbeitung, aufweisend: einen oder mehrere Prozessoren; und ein oder mehrere nicht-transitorische computerlesbare Speichermedien, die eine oder mehrere Sequenzen von Anweisungen speichern, die bei Ausführung veranlassen: Ausführen einer softwarebasierten CCAP-Umgebung auf einer oder mehreren physischen Maschinen, wobei die softwarebasierte CCAP-Umgebung durch eine Mehrzahl von Funktionsblöcken unterhalten wird, wobei jeder der Mehrzahl von Funktionsblöcken in Software implementiert ist und eine spezifische Funktion durchführt, welche die softwarebasierte CCAP-Umgebung unterstützt, und wobei die Mehrzahl von Funktionsblöcken ihre spezifische Funktion jeweils asynchron zueinander durchführen; und Vorhalten einer Konfiguration für die softwarebasierte CCAP-Umgebung, welche jeden der Mehrzahl von Funktionsblöcken separat bezüglich einer oder mehrerer DOCSIS-Dienstgruppen informiert.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei die eine oder mehreren DOCSIS-Dienstgruppen bezüglich ihrer Zugehörigkeit zu einem jeweiligen der Mehrzahl von Funktionsblöcken durch die Konfiguration als logische Einheit behandelt werden.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: Anpassen eines Ausführens eines speziellen Funktionsblocks der Mehrzahl von Funktionsblöcken, so dass ein Wechsel von einem oder mehreren der folgenden Ausführungen vorgenommen wird: (a) von Ausführung in einem einzelnen Thread zu Ausführung in mehreren Threads, (b) von Ausführung in mehreren Threads zu Ausführung in einem einzelnen Thread, (c) von Ausführung auf mehreren Rechenknoten zu Ausführung auf einem einzelnen Rechenknoten, und (d) von Ausführung auf einem einzelnen Rechenknoten zu Ausführung auf mehreren Rechenknoten.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei die Mehrzahl von Funktionsblöcken jeweils in einem separaten Container ausgeführt werden.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: Anweisen eines ersten Funktionsblocks der Mehrzahl von Funktionsblöcken, für eine einzelne DOCSIS-Dienstgruppe eine Bearbeitung durchzuführen; und Anweisen eines zweiten Funktionsblocks der Mehrzahl von Funktionsblöcken, für mehrere DOCSIS-Dienstgruppen eine Bearbeitung durchzuführen.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Messen eines Satzes von verfügbaren Ressourcen des einen oder der mehreren Rechenknoten; ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit unterhalb des vordefinierten Schwellenwertes liegt, Aktualisieren einer Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass die Funktionsblöcke jeweils in einem separaten Ausführungs-Thread ausgeführt werden; und ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit auf oder oberhalb eines vordefinierten Schwellenwertes liegt, Aktualisieren der Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass die Funktionsblöcke jeweils in mehreren Ausführungs-Threads ausgeführt werden.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Messen eines Satzes von verfügbaren Ressourcen des einen oder der mehreren Rechenknoten; ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit unterhalb des vordefinierten Schwellenwertes liegt, Aktualisieren einer Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass ein erster Teil der Funktionsblöcke in einem separaten Ausführungs-Thread ausgeführt wird; und ansprechend auf ein Bestimmen, dass der Satz von verfügbaren Ressourcen derzeit auf oder oberhalb eines vordefinierten Schwellenwertes liegt, Aktualisieren der Konfiguration der Mehrzahl von Funktionsblöcken während der Laufzeit, um zu veranlassen, dass ein zweiter Teil der Funktionsblöcke in mehreren Ausführungs-Threads ausgeführt wird.
Eine oder mehrere Vorrichtungen nach Anspruch 9, wobei das Ausführen der einen oder mehreren Sequenzen von Anweisungen weiter veranlasst: dynamisches Verändern während der Laufzeit, ob mindestens einer der Mehrzahl von Funktionsblöcken auf Basis eines einzelnen Threads oder auf Basis mehrerer Threads ausgeführt wird, und zwar basierend auf beobachteten Lastmustern und einer Verfügbarkeit von Rechenressourcen.
Verfahren zur Durchführung einer CCAP-Verarbeitung, beinhaltend: Ausführen einer softwarebasierten CCAP-Umgebung auf einer oder mehreren physischen Maschinen, wobei die softwarebasierte CCAP-Umgebung durch eine Mehrzahl von Funktionsblöcken unterhalten wird, wobei jeder der Mehrzahl von Funktionsblöcken in Software implementiert ist und eine spezifische Funktion durchführt, welche die softwarebasierte CCAP-Umgebung unterstützt, und wobei die Mehrzahl von Funktionsblöcken ihre spezifische Funktion jeweils asynchron zueinander durchführen; und Vorhalten einer Konfiguration für die softwarebasierte CCAP-Umgebung, welche jeden der Mehrzahl von Funktionsblöcken separat bezüglich einer oder mehrerer DOCSIS-Dienstgruppen informiert.
Verfahren nach Anspruch 17, wobei die eine oder mehreren DOCSIS-Dienstgruppen bezüglich ihrer Zugehörigkeit zu einem jeweiligen der Mehrzahl von Funktionsblöcken durch die Konfiguration als logische Einheit behandelt werden.
Verfahren nach Anspruch 1, weiter beinhaltend: Anpassen eines Ausführens eines speziellen Funktionsblocks der Mehrzahl von Funktionsblöcken, so dass ein Wechsel von einem oder mehreren der folgenden Ausführungen vorgenommen wird: (a) von Ausführung in einem einzelnen Thread zu Ausführung in mehreren Threads, (b) von Ausführung in mehreren Threads zu Ausführung in einem einzelnen Thread, (c) von Ausführung auf mehreren Rechenknoten zu Ausführung auf einem einzelnen Rechenknoten, und (d) von Ausführung auf einem einzelnen Rechenknoten zu Ausführung auf mehreren Rechenknoten.
Verfahren nach Anspruch 17, weiter beinhaltend: Anweisen eines ersten Funktionsblocks der Mehrzahl von Funktionsblöcken, für eine einzelne DOCSIS-Dienstgruppe eine Bearbeitung durchzuführen; und Anweisen eines zweiten Funktionsblocks der Mehrzahl von Funktionsblöcken, für mehrere DOCSIS-Dienstgruppen eine Bearbeitung durchzuführen.