DE69935006T2

DE69935006T2 - Vorrichtung und verfahren zum setzen von prioritäten für multicast-sendepakete in einer netz-dienstklasse

Info

Publication number: DE69935006T2
Application number: DE69935006T
Authority: DE
Inventors: Kalevi Matti Lexington KILKKI; Pekka Jussi RUUTU
Original assignee: Nokia Oyj
Current assignee: Vringo Infrastructure Inc
Priority date: 1998-12-10
Filing date: 1999-12-09
Publication date: 2007-11-15
Anticipated expiration: 2019-12-10
Also published as: DE69935006D1; AU2170600A; US6549938B1; EP1135962B1; CN1335038A; JP2002532992A; WO2000035241A1; EP1135962A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Netzwerkkommunikationssysteme im Allgemeinen und ein Verfahren und ein System zum Bereitstellen von Bestimmungen zum Annehmen und Verwerfen von Paketen auf einer Multi-User-Basis für Multicast-Übertragungen, welche eine prioritätsbasierte Dienstgüte implementieren, im Besonderen.
HINTERGRUND DER ERFINDUNG
Der Stand der Kommunikationstechnologie, insbesondere jener, die das Internet betrifft, erlebt gegenwärtig stetigen Wandel sowie rasches und oftmals unkoordiniertes Wachstum. Die Allgegenwart und Vielfältigkeit von Personalcomputern und Set-Top-Boxes setzt die Anbieter von Kommunikationssysteminfrastruktur erheblich unter Druck, um dem gewaltigen Anstieg der Anzahl neuer User Rechnung zu tragen, die unmittelbaren Zugang zu Internet- und anderen Netzwerk-Ressourcen fordern. Die rasante Entwicklung neuer und hochentwickelter Software, die Benutzern derartiger Dienste zur Verfügung gestellt wird, stellt zusätzliche Ansprüche an die Systeminfrastruktur.
Das Abwickeln von Geschäften über das Internet und andere Netzwerke ist eine Vorgangsweise, die zusehends an Akzeptanz und Beliebtheit gewinnt. So etwa verrechnen herkömmliche Online-Dienste, beispielsweise die von Internet-Providern angebotenen, Kunden für gewöhnlich eine monatliche Gebühr für den Zugang zu Basisdiensten und -ressourcen, beispielsweise proprietäre und öffentliche Informationsdatenbanken. Derartige herkömmliche Service-Provider bewerben auch eine beliebige Anzahl von Produkten oder Diensten, die vom Benutzer online eingekauft werden können.
Andere Formen der Kommerzialisierung des Internets, die zur Zeit in Erwägung gezogen oder implementiert werden, umfassen das Anbieten von Video- oder Audio-Conferencing-Diensten und eine Vielfalt anderer Echtzeit- und Nichtechtzeit-Dienste. Die Anbieter dieser Dienste sowie die Anbieter von Kommunikationssysteminfrastruktur werden zur Zeit mit einer Anzahl von komplexen Problempunkten konfrontiert, u.a. mit dem Management der Netzwerkkapazität, der Last und des Verkehrs, um Echtzeit-, Nichtechtzeit- und High-Bandwidth-Dienste zu unterstützen, und die Implementierung eines realisierbaren Verrechnungsschemas, das die Nutzung derartiger Dienste berücksichtigt.
Die Kommunikationsbranche wendet erhebliches Augenmerk und beträchtliche Investitionen für eine konkrete Technologie, die als asynchroner Transfermodus (ATM) bezeichnet wird, als mögliche Lösung für aktuelle und absehbare Infrastruktureinschränkungen auf. Fachleute werden erkennen können, dass ATM ein Kommunikations-Networking-Konzept darstellt, welches in der Theorie zahlreiche der vorhin genannten Problempunkte löst, beispielsweise durch Bereitstellen einer Fähigkeit, um einen Anstieg der Netzwerklast zu verwalten, Unterstützen von sowohl Echtzeit- als auch Nichtechtzeit-Anwendungen und Anbieten einer garantierten Service-Level-Qualität in bestimmten Umständen.
Eine herkömmliche ATM-Dienstarchitektur sieht für gewöhnlich eine Anzahl von vordefinierten Dienstgüteklassen vor, die oft als Dienstkategorien bezeichnet werden. Jede dieser Dienstkategorien umfasst eine Anzahl von Dienstgüte(QoS)-Parametern, welche das Wesen der jeweiligen Dienstkategorie definieren. Mit anderen Worten sieht eine spezifizierte Dienstkategorie Leistung für eine virtuelle ATM-Verbindung (VCC oder VPC) auf eine Weise vor, die durch eine Untermenge der ATM-Leistungsparameter angegeben wird. Die in der unten genannten Spezifikation des ATM Forum definierten Dienstkategorien umfassen beispielsweise eine Kategorie konstante Bitrate (CBR), eine Kategorie Echtzeit variable Bitrate (rt-VBR), eine Kategorie Nichtechtzeit variable Bitrate (nrt-VBR), eine Kategorie unspezifizierte Bitrate (UBR) und eine Kategorie verfügbare Bitrate (ABR).
Die Dienstklasse konstante Bitrate soll Echtzeitanwendungen unterstützen, die eine feste Menge an Bandbreite während des Bestands der Verbindung benötigen. Eine bestimmte Dienstgüte wird ausgehandelt, um den CBR-Dienst bereitzustellen, wobei die QoS-Parameter die Charakterisierung der Spitzenzellrate (PCR), der Zellverlustrate (CLR), der Zelltransferverzögerung (CTD) und der Zellverzögerungsvariation (CDV) umfassen. Herkömmliche ATM-Verkehrsmanagementschemata gewährleisten, dass die mit dem Benutzer vertraglich vereinbarte QoS aufrechterhalten wird, um beispielsweise Echtzeitanwendungen, beispielsweise Circuit-Emulations- und Voice/Video-Anwendungen, die stark eingeschränkte Verzögerungsvariationen voraussetzen, zu unterstützen.
Die Dienstklasse Nichtechtzeit-VBR soll Nichtechtzeitanwendungen unterstützen, wobei der resultierende Netzwerkverkehr als häufige Datenbursts aufweisend charakterisiert werden kann. Gleicherweise kann die Dienstkategorie Echtzeit variable Bitrate verwendet werden, um „burst-freudige" Netzwerkverkehrsbedingungen zu unterstützen. Die Dienstkategorie rt-VBR unterscheidet sich von der Dienstkategorie nrt-VBR darin, dass die erstere dazu gedacht ist, Echtzeitanwendungen, beispielsweise Voice- und Video-Anwendungen, zu unterstützen. Sowohl die Dienstkategorie Echtzeit-VBR als auch die Dienstkategorie Nichtechtzeit-VBR sind im Sinne einer Spitzenzellrate (PCR), einer Dauerzellrate (SCR) und einer maximalen Burstgröße (MBS) charakterisiert.
Die Dienstkategorie unspezifizierte Bitrate (UBR) wird oft als „Best-Effort-Service" betrachtet, da sie keine verkehrsbezogenen Dienstgarantien spezifiziert. Demnach ist die Dienstkategorie UBR dazu gedacht, Nichtechtzeit-Anwendungen unterstützen, u.a. herkömmliche Rechnerkommunikationsanwendungen wie Dateitransfers und E-Mail.
Die Dienstkategorie verfügbare Bitrate (ABR) sorgt für die Zuweisung von verfügbarer Bandbreite zu Benutzern durch Regeln der Verkehrsrate durch Verwendung eines Rückkopplungsmechanismus. Der Rückkopplungsmechanismus gestattet das Variieren von Zellübertragungsraten, um dadurch Verkehrsengpässe zu regeln oder zu vermeiden und die verfügbare Bandbreite effektiver zu nutzen. Eine Ressourcen-Management(RM)-Zelle geht der Übertragung von Datenzellen voran, welche von der Quelle zum Ziel und zurück zur Quelle übertragen wird, um der Quelle Verkehrsinformationen zur Verfügung zu stellen.
Wenngleich die oben beschriebene derzeitige ATM-Dienstarchitektur scheinbar, wenigstens auf einer konzeptuellen Ebene, brauchbare Lösungen für die zahlreichen Probleme liefert, mit denen die Kommunikationsbranche konfrontiert wird, erfordert ATM gemäß seiner gegenwärtigen Definition die Implementierung eines komplexen Verkehrsmanagementschemas, um die in den verschiedenen gegenwärtig berücksichtigten ATM-Spezifikationen und Empfehlungen dargelegten Zielsetzungen zu erfüllen. Um den Verkehrsfluss in einem Netzwerk effektiv zu managen, müssen herkömmliche ATM-Verkehrsmanagementschemata eine ungeheure Anzahl von Verkehrsbedingungsindikatoren bewerten, u.a. Dienstklassenparameter, Verkehrsparameter, Dienstgüteparameter und dergleichen. Eine nicht den Anspruch auf Vollständigkeit erhebende Auflistung derartiger Parameter und anderer Überlegungen zum ATM-Verkehrsmanagement ist in der ITU-T Recommendation 1.371 mit dem Titel Traffic Control and Congestion Control in B-ISDN und in der Traffic Management Specification, Version 4.0 (af-tm-0056.000, April 1996), veröffentlicht vom Technical Committee des ATM Forum, zu finden.
Ungeachtet der Komplexität herkömmlicher ATM-Verkehrsmanagementschemata unterlassen es die derzeitigen ATM-Spezifikationen und -Empfehlungen, dem Bedarf von Dienstanbietern an einer Methodik, die das exakte und zuverlässige Verrechnen von Diensten ermöglicht, welche durch einen Benutzer des Netzwerks in Anspruch genommen werden, geeignet Rechnung zu tragen. Auch wenn man davon ausginge, dass ein Verrechnungsschema, das die meisten oder alle der gegenwärtig definierten ATM-Verkehrsmanagementeigenschaften berücksichtigt, entwickelt werden könnte, wäre ein derartiges Schema zwangsläufig komplex und müsste für gewöhnlich von hochqualifizierten Bedienpersonen verwaltet werden. Die hohen Gemein- und Wartungskosten, um ein derartiges Verrechnungsschema zu unterstützen, würden höchstwahrscheinlich an den Netzwerkanbieter und letztlich an den Netzwerkbenutzer weitergegeben.
Die vorliegende Erfindung ist in einer Netzwerkdienstklasse anwendbar, welche eine prioritätsbasierte Dienstgüte beinhaltet. Diese Dienstklasse, die in weiterer Folge als Dienstklasse Simple Integrated Media Access (SIMA) bezeichnet wird, stellt eine Netzwerkmanagementarchitektur bereit, die dem Konzept und ihrer Implementierung nach einfach ist und dennoch den Dienstgüteanforderungen ausreichend gerecht wird, um eine Vielfalt von Netzwerkdiensten, umfassend Echtzeit- und Nichtechtzeitdienste, zu unterstützen. Sie sorgt auch für die Implementierung einer einfachen und wirksamen Verrechnungsfunktionalität, welche die Nutzung von Netzwerkdiensten ausweist.
Allerdings werden bei der Verwendung eines derartigen prioritätsbasierten Dienstgüteschemas alle Pakete getrennt gehandhabt, derart, dass jedes ankommende Paket an einem Kernnetzwerkknoten einzeln auf seine Priorität oder, alternativ dazu, auf seine Drop Preference analysiert wird. Dies kann, wie unten ausführlicher dargelegt wird, in Multicast-Situationen unzulässig sein.
Multicasting ist die Übertragung von Paketen von einer Quelle zu mehreren Empfängern oder Benutzern. Beispielsweise sendet bei einer Video-Broadcasting-Anwendung der Server dasselbe Bild an jeden Client. Ein Problem ist, dass eine prioritätsbasierte QoS, beispielsweise die bei SIMA implementierte, zu einer völlig unterschiedlichen Dienstgüte an jedem der verschiedenen Zweige der Multicast-Übertragung führen kann. Wenngleich dies in vielen Situationen zulässig sein kann, gibt es Situationen, in denen vorgezogen wird, eine ähnliche Dienstgüte für alle Empfänger der Multicast-Übertragung zu gewährleisten. Beispielsweise möchte ein Server, der Video-Multicasting bereitstellt, eventuell sicherstellen, dass jeder seiner Clients ein Videobild empfängt, welches unabhängig vom Standort des empfangenden Benutzers eine annähernd konstante Qualität aufweist.
Die Publikation „Large Capacity multiclass ATM Core Switch Architecture" von B.L. Mark et al. offenbart das Unterstützen von Multicast-Verbindungen in einem ATM-Switch. Aus diesem Dokument geht hervor, dass Multicast-Verkehr die höchste Priorität eingeräumt werden muss. Wie allerdings in Zusammenhang mit der vorliegenden Erfindung beschrieben wird, ist es nicht unbedingt erstrebenswert, Multicast-Paketen einfach die höchstmögliche Priorität zuzuweisen. Demzufolge besteht ein Bedarf an einem System und einem Verfahren zum Bereitstellen von Bereitstellen von Bestimmungen zum Annehmen und Verwerfen von Paketen auf einer Multi-User-Basis für Multicast-Übertragungen, welche eine prioritätsbasierte Dienstgüte implementieren. Die vorliegende Erfindung sieht eine ähnliche Dienstgüte für alle Empfänger der Multicast-Übertragung vor und löst demnach diese und andere Unzulänglichkeiten des Standes der Technik und bietet zusätzliche Vorteile gegenüber dem Stand der Technik.
KURZDARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft ein System und ein Verfahren zum Erzielen einer vergleichbaren Dienstgüte für jeden der Empfänger einer Multicast-Übertragung, welche eine prioritätsbasierte Dienstgüte beinhaltet.
Gemäß einer Ausführungsform der Erfindung wird ein Verfahren zum Außerkraftsetzen von Paketannahmekriterien bereitgestellt, die an jeder einzelnen Verbindung eines Netzwerkknotens eingerichtet sind, um kollektive Paketannahmekriterien für jedes Paket einer Multicast-Übertragung bereitzustellen, welche für die einzelnen Verbindungen bestimmt ist. Die Paketannahmekriterien werden von jeder der einzelnen Verbindungen in dem Netzwerkknoten, welche für die Multicast-Übertragung bestimmt sind, erfasst. Eine Multicast-Paketpriorität wird für jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf einer Gesamtanalyse der Paketannahmekriterien von jeder der einzelnen Verbindungen berechnet. Jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, wird basierend auf der berechneten Multicast-Paketpriorität kollektiv angenommen oder verworfen.
Gemäß einer anderen Ausführungsform der Erfindung wird ein Verfahren zum Außerkraftsetzen von Paketannahmekriterien bereitgestellt, die an jeder einzelnen Verbindung eines Netzwerkknotens eingerichtet sind, um kollektive Paketannahmekriterien für jedes Paket einer Multicast-Übertragung bereitzustellen, welche für die einzelnen Verbindungen bestimmt ist. Die Paketannahmekriterien werden von jeder der einzelnen Verbindungen in dem Netzwerkknoten, welche für die Multicast-Übertragung bestimmt sind, erfasst. Eine Multicast-Paketpriorität wird für jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf einer Gesamtanalyse der Paketannahmekriterien von jeder der einzelnen Verbindungen berechnet. Die Paketannahmekriterien von jeder der Verbindungen in dem Netzwerkknoten werden basierend auf der berechneten Multicast-Paketpriorität modifiziert. Jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, wird basierend auf den berechneten Multicast-Paketannahmekriterien einzeln angenommen oder verworfen.
Gemäß einem anderen Aspekt der Erfindung wird ein System zum Verteilen von Multicast-Paketen an eine Mehrzahl von Bestimmungsorten in einem Netzwerk mit mindestens einem Knoten zwischen der Quelle und der Mehrzahl von Bestimmungsorten bereitgestellt, wobei entweder virtuelle oder reelle Verbindungen zwischen der Quelle und jedem aus der Mehrzahl von Bestimmungsorten hergestellt sind, um eine Multicast-Übertragung der Multicast-Pakete vorzusehen. Das System umfasst eine Mehrzahl von Paket-Scheduling-Modulen, eines für jede Verbindung an dem Knoten. Jedes Paket-Scheduling-Modul nimmt Pakete an oder verwirft diese, basierend auf einer zulässigen Paketpriorität seiner entsprechenden Verbindung. Das System umfasst ferner ein Multicast-Prioritätsmanagementmodul, welches mit jedem aus der Mehrzahl von Paket-Scheduling-Modulen gekoppelt ist, um die entsprechenden zulässigen Paketprioritäten zu empfangen. Durch Verwendung dieser zulässigen Paketprioritäten werden die Multicast-Pakete, die für die Bestimmungsorte bestimmt sind, basierend auf der Gesamtknotenpriorität, die aus den zulässigen Paketprioritäten von jedem der Paket-Scheduling-Module abgeleitet wurde, kollektiv angenommen oder verworfen.
Gemäß noch einer anderen Ausführungsform der Erfindung wird eine Netzwerkvorrichtung bereitgestellt. Die Netzwerkvorrichtung ist konfiguriert, um sich mit einem Multicast-Sender und einem Multicast-Paket-Empfänger zu verbinden und um Pakete, die von dem Multicast-Sender zu dem Multicast-Paket-Empfänger hingesendet werden, zu verarbeiten. Die Netzwerkvorrichtung umfasst ein Paket-Scheduling-Modul, welches konfiguriert ist, um Pakete basierend auf Paketpriorität anzunehmen oder zu verwerfen, und ein Multicast-Prioritätsmanagementmodul, welches mit dem Paket-Scheduling-Modul gekoppelt ist, wobei das Multicast-Prioritätsmanagementmodul konfiguriert ist, um Paketprioritätsdaten zu empfangen und zu verarbeiten und um Multicast-Pakete anzunehmen oder zu verwerfen, die basierend auf Knotenprioritätsdaten, welche aus den Paketprioritätsdaten abgeleitet werden, zu dem Multicast-Paket-Empfänger übertragen werden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Flussdiagramm, welches eine allgemeine Vorgangsweise zum Kommunizieren von Informationszellen zwischen einem Benutzer-Netzwerk-Interface und einem Netzwerk mittels eines Nominalbitratendienstes gemäß der vorliegenden Erfindung darstellt;
2 ist ein Systemblockdiagramm einer Nominalbitratendienstarchitektur gemäß der vorliegenden Erfindung;
3 stellt eine Vorgangsweise zum Übertragen von Informationszellen zwischen einem Benutzer-Netzwerk- Interface und einem Netzwerk mittels eines Nominalbitratendienstes gemäß der vorliegenden Erfindung ausführlicher dar;
4 zeigt, in Form eines Flussdiagramms, eine allgemeine Vorgangsweise zum Filtern von Zellen an einem Netzwerkknoten in einem Nominalbitratendienst;
5 ist ein Blockdiagramm einer Ausführungsform eines Systems zum Filtern von Zellen an einem Netzwerkknoten gemäß einem Nominalbitratendienst;
6 ist ein Blockdiagramm einer alternativen Ausführungsform eines Systems zum Filtern von Zellen an einem Netwerkknoten gemäß einem Nominalbitratendienst;
7 ist ein Blockdiagramm, welches ein SIMA-Netzwerk darstellt, das Zugangsknoten und Kernknoten umfasst;
8 ist ein Blockdiagramm, das einen Kernknoten in einem SIMA-Netzwerk darstellt, welcher ein Multicast-Prioritätsmanagementmodul gemäß der vorliegenden Erfindung beinhaltet;
9 ist ein Blockdiagramm einer Ausführungsform einer Zell-Scheduling-und-Puffer-Einheit (SBU) gemäß der vorliegenden Erfindung;
10 ist ein Blockdiagramm, das einen Kernknoten in einem SIMA-Netzwerk darstellt, der eine verteilte Multicast-Prioritätsmanagementfunktionalität gemäß der vorliegenden Erfindung beinhaltet;
11 ist ein Flussdiagramm einer Weise, auf welche die Multicast-Prioritätsmanagementfunktion gemäß der vorliegenden Erfindung realisiert ist;
12 und 13 sind Flussdiagramme, die Ausführungsformen darstellen, in welchen ein Multicast-Paket, welches von dem Multicast-Prioritätsmanagementmodul angenommen wird, durch die einzelnen Scheduling- und Puffer-Einheiten gehandhabt wird;
14 ist ein Flussdiagramm, das verschiedene Ausführungsformen der Erfindung darstellt, in welchen die Multicast-Drop-Preference mittels der erfassten an den SBUs erlaubten Drop Preference bestimmt wird; und
15 ist ein Flussdiagramm eines beispielhaften Verfahrens gemäß der vorliegenden Erfindung.
AUSFÜHRLICHE BESCHREIBUNG DER VERSCHIEDENEN AUSFÜHRUNGSFORMEN
In der folgenden Beschreibung der verschiedenen Ausführungsformen wird auf die beiliegenden Zeichnungen Bezug genommen, die einen Teil hievon bilden und in welchen veranschaulichend verschiedene Ausführungsformen dargestellt werden, in denen die Erfindung realisiert werden kann. Es versteht sich, dass andere Ausführungsformen verwendet und konstruktionelle und funktionelle Modifikationen vorgenommen werden können, ohne vom Umfang der Erfindung abzuweichen.
Die vorliegende Erfindung betrifft ein System und ein Verfahren zum Annehmen und Verwerfen von Multicast-Sendepaketen in einer Netzwerkdienstklasse, die eine prioritätsbasierte Dienstgüte implementiert. Jeder der Kernnetzwerkknoten trifft Multicast-Paketannahmeentscheidungen vor der Lieferung der Multicast-Pakete an deren einzelne geschaltete Verbindungen. Diese kollektive Paketannahmefunktion ermöglicht, allen Empfängern der Multicast-Übertragung eine ähnliche Dienstgüte bereitzustellen, auch in Fällen, in denen einzelne Verbindungen der Multicast-Übertragung eventuell anderns konfiguriert sind, um eine unterschiedliche Dienstgüte für die verschiedenen Verbindungen und Endbenutzer bereitzustellen.
Ein Netzwerk, das gemäß den Grundsätzen der vorliegenden Erfindung implementiert wurde, stellt eine prioritätsbasierte Dienstgüte bereit, beispielsweise wie bei der Dienstklasse SIMA, die eine nominale Bitrate (NBR) beinhaltet. Während das Multicast-Verfahren und -System gemäß der vorliegenden Erfindung auf verschiedene herkömmliche Netzwerkschaltsysteme anwendbar sein kann, erhält man einen Überblick über die Grundsätze der Erfindung am besten in Zusammenschau mit den folgenden Diagrammen, in welchen eine SIMA-Netzwerk-Dienstklasse gemäß der vorliegenden Erfindung dargestellt und beschrieben wird.
Die Realisierung und die Vorteile eines SIMA-Netzwerks können auf eine Weise, die in diesem Dokument und im US-Patent Nr. 6,163,808 mit dem Titel „Network Adjusts Cell Transfer Capacity In Response To A Change In The Actual Bit Rate Relative To The Nominal Bit Rate" beschrieben ist, bestimmt werden. Um allerdings ein Verständnis für ein Netzwerk, das eine SIMA-Dienstklasse beinhaltet, zu erlangen, wird das Konzept der SIMA-Nominalbitrate (NBR) unten allgemein beschrieben.
Nunmehr auf 1 Bezug nehmend wird darin eine allgemeine Methodik zum Übertragen von Informationen zwischen einem Benutzer-Netzwerk-Interface und einem Netzwerk über eine NBR-Dienst-Verbindung dargestellt. Zunächst handelt oder wählt ein Benutzer eine Nominalbitrate mit dem Netzwerkbetreiber aus, was vor oder zum Zeitpunkt des Aufbaus der Verbindung durchgeführt werden kann. Bei einer Ausführungsform informiert der Benutzer den Netzwerkbetreiber, dass eine gewünschte NBR erforderlich ist, und die angeforderte Verbindungsbandbreite wird dem Benutzer zugewiesen. Der Netzwerkbetreiber muss gemäß dieser Ausführungsform nicht die Aufgabe des Analysierens der aktuellen Netzwerklastbedingungen, die an den Kernnetzwerkknoten vorliegen, vor dem Aufbau oder Abbau einer NBR-Verbindung durchführen. Bei einer alternativen Ausführungsform führt der Netzwerkbetreiber die Aufgabe des Bestimmens des Netzwerklaststatus vor dem Aufbau oder Abbau einer NBR-Verbindung durch, wenngleich diese Aufgabe in einem geeignet ausgelegten Netzwerk, das einen NBR-Dienst unterstützt, eventuell nicht notwendig ist.
Je nach der konkreten Anwendung wählt 42 der Benutzer eine Echtzeit- oder eine Nichtechtzeit-Verbindung aus. Der Vorgang des Bestimmens des Prioritätsgrads (PL) jeder Zelle, der die Wichtigkeit oder Kritikalität der Zelle relativ zu anderen Zellen angibt, umfasst das Messen 44 der tatsächlichen oder gemessenen Bitrate (MBR) der gewählten Echtzeit- oder Nichtechtzeit-Verbindung an dem UNI. Der Prioritätsgrad jeder Zelle wird an dem UNI bestimmt 46. Bei einer Ausführungsform der Erfindung wird ein Verhältnis des MBR und des NBR verwendet, um den PL zu bestimmen 46.
Nach dem Berechnen des Prioritätsgrads jeder Zelle an dem UNI werden die Zellen 48 zu dem Netzwerk, beispielsweise zu einem Knoten des Netzwerks, übertragen. Ein Netzwerkknoten führt nach dem Eintreffen einer Zelle, die von dem UNI übertragen wird, einen Zellfiltervorgang durch, durch welchen der Knoten bestimmt, ob eine bestimmte Zelle angenommen oder verworfen wird. Der Zellfiltervorgang umfasst das Bestimmen 50 des Zustands eines oder mehrerer Puffer oder Speicher des Netzwerkknotens, um einen Puffer- oder Speicher-Belegtheitsgrad zu ermitteln. Basierend auf dem Prioritätsgrad der Zelle und dem Zustand des Knotenpuffers nimmt der Knoten eine Zelle an oder verwirft diese 52. Zellen, welche die Filterkriterien erfüllen, die an dem Knoten bestimmt sind, werden angenommen, gepuffert und schließlich auf eine Weise, die der für die Verbindung erwarteten Dienstgüte entspricht, zu einem anderen Knoten im Netzwerk oder einem anderen Netzwerk übertragen 54.
Betreffend die Ausführungsform, die in Form eines Blockdiagramms in 2 dargestellt ist, ist dort ein Benutzer 20 dargestellt, der sich eines UNI 24 bedient, um mit einem Netzwerk 30 zu kommunizieren. Der Benutzer 20 handelt mit dem Netzwerkbetreiber 22 eine Nominalbitrate aus. Der Netzwerkbetreiber 22 evaluiert die NBR-Anforderung des Benutzers auf der Basis einer Anzahl von Faktoren, u.a. der mit anderen Benutzern 20 ausgehandelten NBR, der Anzahl und Art von verschiedenen Verbindungen, die anderen Benutzern des Netzwerks zugewiesen sind, und anderen Faktoren, welche die Netzwerkkapazität und den Verkehrsfluss beeinflussen. Im Prinzip kann die NBR Null sein, wobei in diesem Fall allen Zellen, die durch das UNI 24 kommuniziert werden, die niedrigste Priorität innerhalb des Netzwerks 30 zugewiesen wird. Der Wert der NBR kann auch größer als die Übertragungskapazität an dem UNI 24 sein. Ist beispielsweise der Wert von NBR erheblich größer als die Übertragungskapazität, wird allen Zellen, die von dem UNI 24 übertragen werden, die höchste Priorität innerhalb des Netzwerks 30 zugewiesen. Es wird festgehalten, dass der Prioritätsgrad einer Zelle gemäß der Definition dieses Dokuments eine Bedeutung innerhalb eines Netzwerks oder einer Anzahl von Netzwerken hat, welches/welche das NBR-Dienst-Konzept unterstützt. Zellen, die über ein Netzwerk hinaus transportiert werden, das einen NBR-Dienst anbietet, beispielsweise durch Verwendung eines Netzwerk/Netzwerk-Interface (NNI), können gemäß der Verkehrsmanagementstrategie, die von einem derartigen anderen Netzwerk verwendet wird, verarbeitet werden.
Im Gegensatz zu herkömmlichen Netzwerkdiensten, die konzipiert sind, um eine garantierte Dienstgüte bereitzustellen, garantiert der Netzwerkbetreiber 22 nicht die kontinuierliche Verfügbarkeit der vom Benutzer ausgehandelten NBR. Ein geeignet ausgelegtes Netzwerk sollte jedoch eine ausreichende Bandbreite bereitstellen, um die Verfügbarkeit einer eingerichteten NBR praktisch sicherzustellen, wenn auch nicht zu garantieren. Es wird festgehalten, dass alle Benutzer, die Daten mit einer äquivalenten NBR übertragen, annähernd dieselbe Dienstgüte vorfinden.
Nach Einrichtung einer NBR mit dem Netzwerkbetreiber 22 ist dem Benutzer 20 gestattet, Informationen über das Netzwerk 30 zu einem gewünschten Bestimmungsort 36 zu kommunizieren. Eine Messeinheit 26 misst die tatsächliche oder augenblickliche Bitrate (d.h. die MBR) jeder Zelle, die zwischen dem UNI 24 und dem Netzwerk 30 kommuniziert wird. Ehe eine Zelle das UNI 24 verlässt, bestimmt eine Prioritätsgradberechnungseinheit 28 einen Prioritätsgrad für die Zelle mittels der ausgehandelten NBR und der MBR. Gemäß einer Ausführungsform kann einer bestimmten Zelle einer von acht Prioritätsgraden zugewiesen werden. Die Prioritätsgradberechnungseinheit 28 bestimmt den Prioritätsgrad einer bestimmten Zelle durch Berechnen eines Verhältnisses von MBR zu NBR. Der durch die Berechnungseinheit 28 bestimmte Prioritätsgrad wird der Zelle zugewiesen, welche dann von dem UNI 24 zu dem Netzwerk 30 übertragen wird.
Das UNI 24 überträgt die Zelle, welche Prioritätsgradinformationen enthält, zu einem Knoten des Netzwerks 30, beispielsweise dem Knoten_A 32. Der Knoten_A 32 nimmt die Zelle, die von dem UNI 24 eingeht, basierend auf dem Prioritätsgrad der Zelle und der Pufferkapazität des Knotens_A 32 an oder verwirft diese. Im Allgemeinen werden mit zunehmendem Belegtheitsgrad (d.h. mit zunehmender Befüllung) des Puffers oder Speichers von Knoten_A 32 Zellen mit einer niedrigeren Priorität (d.h. einem höheren Prioritätsgradwert) zu Gunsten der Annahme von Zellen mit einer höheren Priorität (d.h. einem niedrigeren Prioritätsgradwert) verworfen. Mit abnehmendem Belegtheitsgrad (d.h. einem abnehmenden Füllstand) des Puffers von Knoten_A 32 wird der Knoten_A 32 zusehends toleranter gegenüber der Annahme von Zellen mit niedrigerer Priorität (d.h. höheren Prioritätsgradwerten). Zellen, die in Knoten_A 32 gepuffert sind, werden in der Folge zu einem anderen Knoten im Netzwerk 30, beispielsweise dem Knoten_B 34, oder einem anderem Netzwerk und schließlich zu einem Endbestimmungsort 36 übertragen.
Das beispielhafte Netzwerk 30, das für Zwecke dieser Beschreibung verwendet wird, ist als ein Netzwerk mit zwei Zwischenknoten 32 und 34 dargestellt. Diese Knoten stellen Netzwerkdatenkommunikationselemente, beispielsweise Router, Switches und Multiplexer, dar. Wie jedoch für Fachleute zu erkennen sein wird, kann die vorliegende Erfindung auch in verschiedenen Mehrknoten-Netzwerkstrukturen, beispielsweise Mehrpunkt-, Stern-, Ring-, Schleifen- und Maschen-Netzwerktopologien implementiert werden, die in Netzwerken von Local Area Netzwerken (LANs) bis hin zu proliferativen Global Area Netzwerken (GAN) wie dem Internet zur Verwendung kommen.
3–5 veranschaulichen eine Vorgangsweise zum Scheduling und Puffern von Zellen gemäß einer Ausführungsform einer NBR-Dienst-Methodik. Nunmehr auf 3 Bezug nehmend richtet ein Benutzer eine NBR mit einem Netzwerkbetreiber ein 60. Es kann erstrebenswert, wenn auch nicht unbedingt erforderlich sein, die Dienstklasse 62 zunächst auf eine Nichtechtzeit(nrt)-Dienstklasse als Standardeinstellung einzustellen. Je nach einer konkreten Anwendung benötigt der Benutzer eventuell eine Echtzeit(rt)-Dienstklasse 64, die vom Benutzer direkt oder für gewöhnlich durch die Anwendungs- oder Kommunikationssoftware des Benutzers eingestellt werden kann. Benötigt der Benutzer eine Echtzeitverbindung, dann weist jede Zelle, die von dem UNI des Benutzers übertragen wird, das Dienstklassenbit in dem Zellenheader auf, welches eingestellt ist, um anzuzeigen, dass die Payload der Zelle Echtzeitinformationen 70 enthält. Es wird festgehalten, dass innerhalb des Kontexts eines Netzwerks, welches gemäß dem NBR-Konzept der vorliegenden Erfindung implementiert wurde, von Echtzeit-Dienstklassenverbindungen erwartet wird, dass sie praktisch jedwede Echtzeit-Anwendung unterstützen, ohne dass konkrete Zelltransferverzögerungs(CTD)- und Zellverzögerungsvariations(CDV)-Parameter angegeben werden müssen. Demnach wird der herkömmliche Vorgang des Einstellens von CTD- und CDV-Bits des Zellheaders auf geeignete Werte, um den Echtzeit-Dienstanforderungen der Verbindung Rechnung zu tragen, zur Gänze umgangen.
Wenn der Benutzer keine Echtzeit-Dienst-Verbindung benötigt, bleibt der standardmäßige Nichtechtzeit-Dienstklassenzustand aktiv. Demnach wird das rt/nrt-Dienstklassenbit jedes Zellenheaders eingestellt, um anzuzeigen, dass die Payload der Zelle Nichtechtzeit-Informationen 66 umfasst. Es wird festgehalten, dass sich der in diesem Dokument offenbarte NBR-Dienst nicht des Zellverlustprioritäts(CLP)-Schemas bedient, das von herkömmlichen ATM-Verkehrsmanagementlösungen verwendet wird. Demnach kann das CLP-Bit in dem Zellenheader stattdessen verwendet werden, um zwischen Echtzeit- und Nichtechtzeit-Payloads zu unterscheiden.
Bei der oben beschriebenen Ausführungsform wird jede Zelle, die über eine Verbindung übertragen wird, entweder als Echtzeit-Zelle oder als Nichtechtzeit-Zelle bezeichnet, beispielsweise durch entsprechendes Einstellen des rt/nrt-Dienstklassenbits des Zellenheaders. Bei einer alternativen Ausführungsform kann, je nach den Anforderungen eines Benutzers, eine Verbindung entweder als Echtzeit- oder als Nichtechtzeit-Verbindung bezeichnet werden, und den Zellen, die über eine derartige Verbindung kommuniziert werden, muss nicht einzeln ein Echtzeit- oder ein Nichtechtzeit-Status zugewiesen werden. Jeder Knoten für eine bestimmte Verbindung kann beispielsweise einen Tabellensuchvorgang nach dem Eintreffen einer Zelle am Knoten durchführen, um festzustellen, ob die Zelle zu einer Echtzeit- oder einer Nichtechtzeit-Verbindung gehört. Demnach muss gemäß dieser Ausführungsform ein Zellenheaderbit nicht zum Unterscheiden zwischen Echtzeit- und Nichtechtzeit-Zellen reserviert werden.
Nachdem das rt/nrt-Dienstklassen-Headerbit auf die oben beschriebene Weise eingestellt wurde, wird die tatsächliche Bitrate einer bestimmten Zelle, die zwischen dem UNI und dem Netzwerk übertragen werden soll, gemessen 74. Da in der Praxis die tatsächliche Bitrate im Lauf der Zeit einer erheblichen Variabilität unterliegen kann, bedient sich eine Messeinheit des UNI eines mittelnden Messprinzips, um die tatsächliche oder augenblickliche Bitrate MBR_i, zu ermitteln.
Im Allgemeinen misst das UNI 74 die tatsächliche Bitrate einer Zelle, beispielsweise der Zelle_i, durch Nähern der tatsächlichen oder augenblicklichen Bitrate der Verbindung innerhalb einer Messperiode mit einer Dauer, die für die konkrete Verbindung (z.B. eine Echtzeit- oder eine Nichtechtzeit-Verbindung) geeignet ist. Die vorliegende Erfindung sorgt für die Messung der augenblicklichen Bitrate MBR_i.
Nach Ermittlung 74 der gemessenen Bitrate MBR_i der i-ten Zelle wird der Prioritätsgrad der i-ten Zelle anhand der gemessenen Bitrate MBR_i und der Nominalbitrate NBR berechnet. Gemäß einer Ausführungsform wird angenommen, dass eine Zelle mittels eines Zellpriorisierungsschemas, das sich acht Prioritätsgraden bedient, von anderen Zellen unterschieden werden kann. Um anzuzeigen, welcher der acht Prioritätsgrade einer bestimmten Zelle zugewiesen ist, weist jede Zelle drei Bits für diesen Zweck zu.
Gemäß aktuellen ATM-Spezifikationen wird eine ATM-Zelle als eine Übertragungseinheit spezifiziert, die einen Rahmen von fester Größe aufweist, welcher aus einem 5-Oktett-Header und einer 48-Oktett-Payload besteht. Es ist zu erkennen, dass die Notwendigkeit, drei Bits in dem Zellenheader für den Zweck des Angebens des Zellprioritätsgrades zuzuweisen, die Verwendung von aktuell definierten ATM-Headerbits erfordern kann. Beispielsweise kann es möglich sein, das aktuelle Generic Flow Control(GFC)-Feld zu verwenden, das insgesamt vier Bits darstellt. In diesem Fall können drei Bits zum Angeben des Zellprioritätsgrades und ein Bit als rt/nrt-Dienstklassenbit zugewiesen werden. Gemäß einer anderen Ausführungsform kann es möglich sein, weitere Headerbits für den Zweck des Angebens eines von acht Prioritätsgraden und der rt/nrt-Dienstklasse durch Abweichen von der einen Fünf-Oktett-Header vorsehenden ATM-Spezifikation zuzuweisen.
Demnach können andere Headerbits umdefiniert werden, um Zellprioritätsgrad- und Dienstklassenangaben darzustellen. Alternativ dazu können ein oder mehrere Bits, die erforderlich sind, um Zellprioritätsgrad und/oder Dienstklasse anzugeben, außerhalb des aktuell definierten ATM-Zellenheaders angeordnet sein. Die Notwendigkeit, eine geringfügige Modifikation an der bestehenden ATM-Zellenheaderdefinition vorzunehmen, wird durch die erheblichen Vorteile, die durch Verwendung des NBR-Dienstschemas der vorliegenden Erfindung entstehen, beispielsweise eine beträchtliche Reduktion der Netzwerk- und Verkehrsmanagement-Gemeinkosten und -Komplexität, stark aufgewogen.
Es versteht sich, dass die Anzahl von Prioritätsgraden kleiner als Acht oder größer als Acht sein kann. Beispielsweise können, wenn man davon ausgeht, dass vier Zellenheaderbits für Zwecke des Anzeigens des Prioritätsgrads einer Zelle zugewiesen werden, bis zu 2⁴ (d.h. 2^n-Bits) oder 16 Prioritätsgrade definiert werden. Das Erhöhen der Anzahl von Prioritätsgraden innerhalb des Kontexts eines NBR-Dienstes erlaubt dem Netzwerkbetreiber, feinere Anpassungen an die Bandbreite einer bestimmten Verbindung beim Verwalten des Netzwerkverkehrs vorzunehmen. Der Preis für diese feingradigere Regelung des Verkehrs ist das zusätzliche Zellenheaderbit oder die zusätzlichen Zellenheaderbits, das/die benötigt wird/werden, um eine größere Anzahl von Prioritätsgraden aufzulösen.
Eine Prioritätsgradberechnungseinheit bestimmt 76 den Prioritätsgrad jeder Zelle, beispielsweise der Zelle_i. Gemäß einer Ausführungsform der vorliegenden Erfindung und unter der Annahme, dass die gemessene Bitrate MBR_i ist, wenn die i-te Zelle zu dem Netzwerk übertragen wird, kann der Prioritätsgrad (PL_i) der Zelle_i anhand der folgenden Gleichung berechnet werden:
wobei [x] den Integerteil von x darstellt. Die vorliegende Erfindung sieht die Bestimmung von Zellprioritätsgraden (PL_i) mittels eines pufferbasierten Zellmessungs- und Prioritätsgradzuweisungsverfahrens vor.
Wie nachstehend gemäß einer Ausführungsform, bei welcher sowohl NBR- als auch herkömmliche ATM-Dienst-Verbindungen berücksichtigt werden, besprochen wird, ist der Prioritätsgrad Null PL = 0 für jene Verbindungen reserviert, die sich eines gewöhnlichen ATM-Dienstes mit garantierter Bandbreite und Dienstgüte bedienen. Dementsprechend kann die oben stehende Gleichung [1] modifiziert werden, um Zellprioritätsgrade zu liefern, die zwischen PL = 1 und PL = 7 liegen, derart, dass [x] den Integerteil von x darstellt, wenn 1 < x < 7.
Durch Anwendung der oben stehenden Gleichung [1] ist zu ersehen, dass, wenn eine Verbindung Netzwerkkapazität über den ausgehandelten NBR-Wert der Verbindung nutzt, der Prioritätsgrad von Zelle_i mindestens 4 ist. Es ist ferner zu ersehen, dass, wenn die momentane Bitrate an dem UNI kleiner als der ausgehandelte Wert von NBR ist, PL höchstens 4 ist. Das Prioritätsgradschema gemäß dieser Ausführungsform der vorliegenden Erfindung ermöglicht demnach die Einstellung der relativen Kapazität, die durch eine Verbindung verwendet wird, in Schritten von 2. Aus der oben stehenden Gleichung [1] geht hervor, dass für eine NBR von 100 kbit/s eine MBR größer als 566 kbit/sec einen PL von 7 ergibt und eine MBR kleiner als 8,8 kbit/s einen PL von 0 ergibt.
Die drei Prioritätsgradbits, die in dem Zellenheader zugewiesen sind, werden für jede ATM-Zelle, die von dem UNI übertragen wird, eingestellt 78. Die ATM-Zellen werden dann zu bestimmten Netzwerkknoten übertragen 80, die durch Knotenaddressierinformationen, die in dem Zellenheader bereitgestellt werden, festgelegt werden.
Es wird festgehalten, dass, wenn ein Benutzer nicht mit der Dienstgüte der Verbindung zufrieden ist, der Benutzer zwischen mindestens drei Alternativen wählen kann. Erstens kann der Benutzer wählen, die durchschnittliche Bitrate unverändert zu halten, jedoch die Variation des Verkehrsprozesses zu reduzieren. Zweitens kann der Benutzer wählen, die durchschnittliche Bitrate zu verringern oder die Nominalbitrate zu erhöhen. Eine Erhöhung der NBR führt jedoch im Allgemeinen zu einem gleichzeitigen Anstieg der Kosten für eine schnellere Verbindung. Schließlich kann der Benutzer den Netzwerkbetreiber wechseln.
In 4 ist in Form eines Flussdiagramms eine allgemeine Methodik dargestellt, mittels welcher ein Netzwerkknoten Zellen verarbeitet, die Prioritätsgradinformationen enthalten, welche von einem UNI gemäß einer Ausführungsform der vorliegenden Erfindung eingehen. 5 zeigt eine Ausführungsform von verschiedenen Komponenten eines Netzwerkknotens, die verwendet werden, um die in 4 veranschaulichte Methodik zu realisieren. Es wird angenommen, dass eine Zelle, beispielsweise die Zelle_i, an einem UNI verarbeitet wurde und Prioritätsgradinformationen umfasst, welche auf eine oben beschriebene Weise abgeleitet wurden.
Die Zelle_i wird von dem UNI zu einem Netzwerkknoten übertragen und an einem Filter 88 des Knotens empfangen. Ein Speicher-Manager 89 überprüft den Status 81 des Speichers 90, um den Belegtheitsgrad im Speicher 90 zu bestimmen. Der Speicher-Manager 89 bestimmt 82 den zulässigen Prioritätsgrad (PL_a) basierend auf dem Belegtheitszustand des Speichers 90. Im Allgemeinen erstellt der Speicher-Manager 89 eine hohe zulässige Priorität, welche einem niedrigen zulässigen Prioritäts-"Grad" entspricht, beispielsweise PL_a = 0 oder 2, wenn der Belegtheitsgrad des Speichers 90 hoch ist (d.h. wenige verfügbare Speicherplätze). Wenn der Speicher-Manager 89 ermittelt, dass der Speicher 90 über große Kapazitäten zum Aufnehmen neuer Zellen verfügt, erstellt der Speicher-Manager 89 eine niedrige zulässige Priorität, welche einem hohen zulässigen Prioritäts-„Grad", beispielsweise PL_a = 6 oder 7, entspricht. Wie für Fachleute zu erkennen sein wird, könnte die Berechnung von PL_a alternativ dazu auf nicht belegter Pufferkapazität, und nicht auf dem Pufferbelegtheitsgrad, basieren.
Wenn der Prioritätsgrad der Zelle größer als der zulässige Prioritätsgrad PL_a ist, der durch den Speicher-Manager 89 ermittelt wird 83, verwirft 84 der Filter 88 die Zelle_i. Wenn andererseits der Prioritätsgrad der Zelle kleiner gleich dem zulässigen Prioritätsgrad PL_a ist, nimmt der Filter 88 die Zelle_i an 85. Der Speicher-Manager 89 koordiniert den Transfer 86 der Zelle_i zu dem Speicher 90 und aktualisiert 87 eine Indextabelle 91, die mit dem Speicher-Manager 89 gekoppelt ist, um einen neuen Indextabelleneintrag für die neu angenommene Zelle_i hinzuzufügen. Bei einer Ausführungsform speichert die Indextabelle 91 den Ort der angenommenen Zelle_i in dem Speicher 90 und speichert auch einen Zellentypanzeiger, der angibt, ob die Zelle_i eine Echtzeit-Zelle oder eine Nichtechtzeit-Zelle ist. Demnach kann der Speicher 90 sowohl Echtzeit- als auch Nichtechtzeit-Zellen speichern.
Der Speicher-Manager 89 verwaltet in Kooperation mit der Index-Tabelle 91 Zelltransfervorgänge von dem Speicher 90 zu dem Ausgang des Speichers 90 durch Vorziehen der Echtzeit-Zellen gegenüber den Nichtechtzeit-Zellen. Beispielsweise überträgt der Speicher-Manager 89 nach dem Feststellen des Vorliegens von sowohl rt-Zellen als auch nrt-Zellen, die im Speicher 90 gespeichert sind, alle rt-Zellen zu dem Ausgang des Speichers 90, ehe irgendwelche der nrt-Zellen übertragen werden.
Wie in 6 dargestellt ist, kann ein Speicher-Manager 89 den Status eines Echtzeit-Puffers (rt-Puffers) 93 und eines Nichtechtzeit-Puffers (nrt-Puffers) 94 bestimmen. Der Speicher-Manager 89 bestimmt, auf eine der vorhin beschriebenen ähnlichen Weise, den zulässigen Prioritätsgrad PL_a für den Filter 88, basierend auf dem Status des rt-Puffers 93 und des nrt-Puffers 94. Wenn der Prioritätsgrad von Zelle_i größer als der zulässige Prioritätsgrad PL_a ist, verwirft der Filter 88 die Zelle_i. Wenn hingegen der Prioritätsgrad der Zelle_i kleiner gleich dem zulässigen Prioritätsgrad PL_a ist, wird die Zelle_i angenommen.
Der Netzwerkknoten kann ein Pufferfilterschema anwenden, welches die Filterfunktion basierend auf Paketen aus Zellen und nicht auf einzelnen Zellen durchführt. Beispielsweise kann der oben beschriebene Filtervorgang auf die erste Zelle jedes Pakets angewandt werden. Wenn die erste Zelle durch den Knoten verworfen wird, dann werden alle Zellen des Pakets, welche auf die erste Zelle folgen, ebenfalls verworfen. Wenn jedoch die erste Zelle eines Pakets angenommen wird, dann kann die Priorität aller weiteren Zellen, die zu jenem Paket gehören, erhöht werden, beispielsweise durch Ändern des Prioritätsgrads von PL = 5 auf PL = 3. Eine Zunahme von nur einem Prioritätsgrad, beispielsweise von PL = 4 auf PL = 3, wird als ausreichend angesehen, um sicherzustellen, dass es nur zu wenigen teilweise übertragenen Paketen kommt.
Ein Zellentypdetektor 92 empfängt die angenommene Zelle, die Zelle_i, von dem Filter 88 und bestimmt, ob die Zelle_i eine rt-Zelle oder eine nrt-Zelle ist. Wie vorhin besprochen wurde, umfasst der Header der Zelle_i ein Header-Bit, beispielsweise das CLP-Bit, welches anzeigt, ob die Zelle_i eine rt-Zelle oder eine nrt-Zelle ist. Der Zellentypdetektor 92 überträgt nach der Ermittlung des Dienstklassentyps der Zelle_i die Zelle_i entweder zu dem rt-Puffer 93 oder zu dem nrt-Puffer 94. Auf eine der vorhin mit Bezug auf 4 und 5 beschriebenen ähnliche Weise koordiniert der Speicher-Manager 89 die Ausgabe aus rt-Zellen bzw. nrt-Zellen von dem rt-Puffer 93 und dem nrt-Puffer 94, wobei den rt-Zellen der Vorzug gegeben wird.
Es kann erstrebenswert sein, zu Zwecken des Verbesserns der Netzwerkausdehnung und Verkehrssteuerung, zu verlangen, das jeder Benutzer des Netzwerks eine maximale NBR erwirbt. Der maximale NBR-Wert soll im Wesentlichen konstant bleiben. Darüber hinaus kann es erstrebenswert sein, zu verlangen, dass jeder Benutzer eine geeignete augenblickliche NBR auswählt, die nicht größer als die gewählte maximale NBR sein sollte. Die Auswahl einer geeigneten augenblicklichen NBR umfasst im Allgemeinen einen Kompromiss zwischen Preis und Dienstgüte. Die durch einen Benutzer erkannte Dienstgüte hängt großteils von drei Parametern, und zwar der NBR, der durchschnittlichen Bitrate und der Menge an Verkehrsvariationen, ab. Wenngleich ein Benutzer jeden beliebigen dieser Parameter ändern kann, sind die einzigen Informationen, welche das Netzwerk bei Beginn der Zellübertragung kennen muss, die NBR und die Dienstklasse (Echtzeit oder Nichtechtzeit) der Verbindung.
Wenngleich ein SIMA-Netzwerk, wie das oben beschriebene, zahlreiche Vorteile und Vorzüge aufweist, kann es zu Situationen kommen, bei denen es erstrebenswert ist, dass der konkrete Prioritätsgrad, oder die Drop Preference, außer Kraft gesetzt wird. Eine derartige Situation ist, wenn eine Multicast-Übertragung von einer Quelle zu mehreren Benutzern vorgesehen wird. Bei Verwendung des allgemeinen Prioritätsschemas eines SIMA-Netzwerks kann jeder der Zweige der Multicast-Übertragung die Multicast-Übertragung empfangen oder nicht, basierend auf der Überfüllung der jeweiligen Verbindung. Allerdings kann es erstrebenswert sein, eine vergleichbarere Dienstgüte für jeden der Empfänger einer Multicast-Übertragung sicherzustellen. In diesem Fall können die einzelnen Zellannahme-/-ablehnungsparameter außer Kraft gesetzt werden, um eine gleichmäßigere Dienstgüte vorzusehen. Die vorliegende Erfindung macht dies möglich.
7 ist ein Blockdiagramm, welches ein SIMA-Netzwerk 100 darstellt, das Zugangsknoten 102 und Kernknoten 104 implementiert. Eine typische Implementierung eines SIMA-Dienstes bedient sich zweier primärer Komponenten: Zugangsknoten (A) 102 und Kernnetzwerkknoten (C) 104, die grundlegend unterschiedliche funktionelle Kompetenzen aufweisen. Beispielsweise führen Zugangsknoten 102, die ein Benutzer-Netzwerk-Interface sein können, die Aufgaben des Messens des Verkehrs für jede Verbindung und des Ermittelns einer Zell- oder Paketpriorität basierend auf einem Verhältnis der momentanen tatsächlichen Bitrate (MBR) der Quelle zu der Nominalbitrate (NBR), die der Quelle zugewiesen ist, durch. SIMA-Netzwerkknoten 104 leiten die SIMA-Pakete vom Eingang zu dem(den) Ausgang (Ausgängen) weiter und treffen Entscheidungen in Bezug auf die Annahme und das Verwerfen von Paketen basierend auf der Priorität eines Pakets und den Belegtheitsgraden der Puffer in dem jeweiligen Kernknoten 104. Die Kernknoten müssen demzufolge keine Informationen betreffend die Eigenschaften von einzelnen Verbindungen einholen. Das Kundengerät (CE) 106 ist durch das SIMA-Netzwerk 100 über die Zugangsknoten 102 und die Kernknoten 104 mit anderen Kundengeräten verbunden.
8 ist ein Blockdiagramm, das einen Kernknoten 110 in einem SIMA-Netzwerk darstellt, der ein Multicast-Prioritätsmanagementmodul gemäß der vorliegenden Erfindung beinhaltet. Bei dem Beispiel aus 8 ist das Multicast-Prioritätsmanagementmodul durch den SIMA Multicast Handler (SMH) 112 dargestellt. In einem typischen SIMA-Netzwerk, das sich keines Multicast-Prioritätsmanagements bedient, wird ein Paket, das durch den Kernknoten 110 empfangen wird, direkt einem Routing-Modul zugeführt, das durch den Router 114 dargestellt ist. In einem derartigen Fall werden alle Eingänge, die als Eingang-1, Eingang-2 bis Eingang-M gekennzeichnet sind, direkt mit dem Router 114 gekoppelt, um zu deren entsprechender Scheduling-und-Puffer-Einheit, die als SBU-1 116, SBU-2 118 bis SBU-N 120 gekennzeichnet sind, geleitet zu werden. Wie in Zusammenhang mit 9 ausführlicher beschrieben wird, treffen die Scheduling-und-Puffer-Einheiten Entscheidungen, ob ein bestimmtes Paket angenommen oder verworfen wird, basierend auf dem aktuellen angenommenen Prioritätsgrad an dem Kernknoten 110.
Aus Gründen der Klarheit bezieht sich die folgende Beschreibung auf das Konzept der „Paket-Drop-Preference". Der Paketprioritätsgrad kann auch im Sinne seiner aktuellen „Drop Preference" gesehen werden, da ein Paket mit einer hohen Priorität nicht so leicht verworfen oder aus dem Übertragungsstrom „fallengelassen" wird. Im Fall der Anwendung auf ein NBR-System, wo ein Paket mit der Nominalbitrate übertragen wird und eine mittlere Priorität oder Drop Preference (z.B. 4) erhält, führt eine Verdopplung der Übertragungsrate zu einer Abnahme der Priorität oder Drop Preference um Eins (z.B. 3). Mit anderen Worten zeigt eine niedrigere Drop Preference, die einem Paket zugeordnet ist, an, dass es wahrscheinlicher ist, dass dieses aus dem Übertragungsstrom fallengelassen wird als ein Paket mit einer höheren Drop Preference. Die Drop Preference (DP) des Pakets zeigt die relative Priorität oder Drop Preference des Pakets selbst an, wobei sich die zulässige Drop Preference (DP_a) auf die zulässige Drop Preference an einer bestimmten Zell-Scheduling- und Puffer-Einheit (SBU) bezieht.
Die vorliegende Erfindung umfasst die Bereitstellung einer Multicast-Prioritätsmanagementfunktionalität. In 8 fängt der SMH 112 die Eingänge zum Kernknoten 110 vor dem Erreichen des Routers 114 ab. Der SMH 112 wird in SIMA-Kernknoten verwendet, um Entscheidungen bezüglich der Annahme oder Ablehnung von Multicast-Paketen vor der Lieferung des Pakets zu den einzelnen SBUs zu treffen. Dies ermöglicht es, allen Empfängern der Multicast-Übertragung eine ähnliche Dienstgüte von Multicast-Übertragungen bereitzustellen.
Der SMH 112 ist in der Lage, zwischen Multicast- und Nicht-Multicast-Paketen zu unterscheiden. Bei einer Ausführungsform der Erfindung enthält das Paket selbst eine spezielle Kennung oder einen speziellen Merker, die/der das Paket als Multicast-Paket identifiziert. Der SMH 112 extrahiert die spezielle Kennung aus dem Paket, da er ihren Byte/Bit-Lageort innerhalb des Pakets kennt. Die spezielle Kennung oder der spezielle Merker identifiziert das Paket als Multicast- oder Nicht-Multicast-Paket. Bei einer anderen Ausführungsform der Erfindung unterscheidet der SMH 112 zwischen Multicast- und Nicht-Multicast-Paketen durch Identifizieren von Paketen, die zu einem bestimmten Fluss gehören. Beispielsweise kann der SMH 112 die Quell-IP(Internet Protokoll)-Adresse oder den Quell-IP(Internet Protokoll)-Port in dem Header eines IP-Pakets analysieren und ermitteln, ob die Übertragung eine Multicast-Übertragung ist, basierend auf der Quelle des Paketflusses. Wenn das Paket kein Multicast-Paket ist, wird es einfach an jedweder zusätzlichen Funktionalität in dem SMH 112 vorbeigeführt und an den Router 114 übergeben.
Wenn ein Paket als Multicast-Übertragungspaket identifiziert wurde, wird der SMH 112 bestimmen, ob das Paket vor der Eingabe in den Router 114 angenommen oder verworfen werden sollte. Die Entscheidung, ob das Paket angenommen oder verworfen wird, ist eine Funktion der Überfüllung an manchen oder allen SBUs 116, 118 bis 120. Der SMH ist daher an die SBUs gekoppelt, derart, dass er die zulässigen oder angenommenen Drop-Preference(DP_a)-Werte von jeder der SBUs empfangen kann, wie an den Kommunikationsleitungen 122, 124 bis 126 zu ersehen ist. Wie unten ausführlicher beschrieben ist, kann die Funktion auf den Pufferbelegtheitsgraden mancher oder aller SBUs beruhen, oder sie kann auf dem zulässigen Drop-Preference-Wert mancher oder aller SBUs beruhen. Es wird vorgezogen, die Pufferbelegheitsgrade und/oder Drop-Preference-Werte von möglichst vielen SBUs zu berücksichtigen, damit für alle Verbindungen eine ähnliche Dienstgüte bereitgestellt werden kann. Wenn das Paket verworfen werden soll, kann es durch den SMH 112 sofort verworfen werden, oder es können einzelne SBUs informiert werden, das Paket zu verwerfen. Allerdings ist es am effizientesten, wenn der SMH 112 die Pakete direkt verwirft.
Wie vorhin dargelegt wurde, treffen die Zell-Scheduling-und-Puffer-Einheiten (SBUs) basierend auf dem aktuellen angenommenen Prioritätsgrad an dem Kernknoten Entscheidungen darüber, ob ein konkretes Paket angenommen oder verworfen wird, und sorgen ferner für Pufferung für Echtzeit- und Nichtechtzeit-Zellen. Nunmehr auf 9 Bezug nehmend ist darin ein Diagramm einer Zell-Scheduling-und-Puffer-Einheit (SBU) 150 gemäß einer Ausführungsform der vorliegenden Erfindung dargestellt. Wie oben beschrieben wurde, weist jede Zelle, die an einem Kernknoten 152 empfangen wird, einen dieser zugewiesenen Prioritätsgrad auf, der zuvor basierend auf Verkehrsbedingungen an einem Quell-Benutzer-Netzwerk-Interface, beispielsweise UNI 24, das in Verbindung mit 2 beschrieben wurde, zugewiesen wurde. Darüber hinaus weist jede Zelle einen dieser zugeordneten Dienstklassenanzeiger auf, der die Zelle als Echtzeit- oder Nichtechtzeit-Payload enthaltend identifiziert. Die Zell-Scheduling-und-Puffer-Einheit 150 sorgt für effiziente Verarbeitung von sowohl Echtzeit- als auch Nichtechtzeit-Zellen auf der Basis von lediglich zwei externen Überlegungen: dem Prioritätsgrad (d.h. Drop Preference) und dem Dienstklassenstatus jeder Zelle.
Wie in 9 dargestellt ist, umfasst eine Zelle, beispielsweise die Zelle_i 154, einen Prioritätsgrad (PL) 156, einen Echtzeit-/Nichtechtzeit(rt/nrt)-Anzeiger 158 und eine Payload 160. Die Zelle_i 154 wird an einem Eingang 162 der Zell-Scheduling-und-Puffer-Einheit 150 empfangen. Ein Zellfilter 164 ermittelt durch Lesen der Prioritätsgradbits PL 156 des Zellenheaders den Prioritätsgrad der Zelle_i 154. Als Teil des Zellfilterungsvorgangs wird der zulässige Prioritätsgrad PL_a basierend auf dem aktuellen Status von für gewöhnlich zwei Puffern berechnet, die in der Zell-Scheduling-und-Puffer-Einheit 150 vorgesehen sind.
Gemäß einer Ausführungsform der SBU 150 sind zwei Puffer, ein Echtzeit-Puffer 166 und ein Nichtechtzeit-Puffer 168, vorgesehen. Der Belegtheitsgrad der beiden Puffer 166, 168 wird durch Ermitteln der Anzahl von Zellen, die sich zur Zeit in dem rt-Puffer 166 befinden, welche als M_rt bezeichnet wird, und der Anzahl von Zellen, die sich zur Zeit in dem nrt-Puffer 168 befinden, welche als M_nrt bezeichnet wird, berechnet. Die Zellen werden gepuffert, ehe sie von dem Knoten 152 an die Ziel-Endeinheit 169 ausgegeben werden.
Es wird festgehalten, dass der schattierte Bereich des rt-Puffers 166 einen belegten rt-Puffer-Abschnitt 170 darstellt, während der nichtschattierte Abschnitt einen nichtbelegten rt-Puffer-Abschnitt 172 darstellt. Gleicherweise wird ein belegter nrt-Pufferabschnitt 174 des nrt-Puffers 168 durch den schattierten Bereich angezeigt, während der nichtschattierte Bereich einen nichtbelegten nrt-Puffer-Abschnitt 176 darstellt. Ferner wird festgehalten, dass jeder der Puffer 166, 168 eine Anzahl von Pufferplätzen 178 umfasst und dass die Anzahl von Nichtechtzeit-Pufferplätzen, welche den nrt-Puffer 168 definieren, für gewöhnlich die Anzahl von Pufferplätzen, welche den rt-Puffer 166 definieren, übersteigt.
Zu Zwecken der Veranschaulichung und nicht der Einschränkung werden die folgenden Pufferparameter definiert:

M_rt: = die Anzahl von Zellen im rt-Puffer 166
K_rt: = die Anzahl von Pufferplätzen im rt-Puffer 166
M_nrt: = die Anzahl von Zellen im nrt-Puffer 168
K_nrt: = die Anzahl von Pufferplätzen im nrt-Puffer 168

Ein Prozessor, der als PL_a-Logik 180 dargestellt ist, ermittelt die Anzahl von Zellen, die zur Zeit den rt-Puffer 166 belegen (M_rt), und die Anzahl von Zellen, die zur Zeit den nrt-Puffer 168 belegen (M_nrt). Der Prozessor 180 ermittelt auch die Anzahl von Pufferplätzen 178, welche den rt-Puffer 166 definieren (K_rt), und die Anzahl von Pufferplätzen 178, welche den nrt-Puffer 168 definieren (K_nrt): Die Belegtheitsgrade des rt-Puffers 166 (X_rt) und des nrt-Puffers 168 (X_nrt) werden mittels der nachstehenden Gleichungen [2] bzw. [3] ermittelt: xrt = Mrt/Krt [2] xnrt = Mnrt/Knrt [3]
Der durchschnittliche Belegtheitsgrad des gesamten Puffersystems (x) wird dann mittels einer von mehreren Möglichkeiten, u.a. beispielsweise durch Verwendung einer beliebigen der folgenden Gleichungen, ermittelt:
Der Prioritätsgrad PL 156 der Zelle_i 154 (PL_cell-i) wird mit dem Resultat verglichen, das durch Anwendung der folgenden Gleichung erhalten wird: PL < a – bx [5]wobei a und b Konstanten sind und es für Zwecke dieses Beispiels angenommen wird, dass a = b = 9. Die Zelle_i 154 wird je nach dem Ergebnis des Vergleichs, der mittels oben stehender Gleichung [5] durchgeführt wird, angenommen oder verworfen.
Es kann vorteilhaft sein, den zulässigen Prioritätsgrad PL_a mittels einer alternativen Lösung zu ermitteln. Zunächst wird angenommen, dass der Belegtheitsgrad des rt-Puffers 166 X_rt und jener des nrt-Puffers 168 X_nrt in N Stufen unterteilt sind, wobei N beispielsweise 16 oder 12 sein kann. Zu Zwecken der Veranschaulichung geht die nachstehende Tabelle 1 davon aus, dass der Belegtheitsgrad der beiden Puffer 166, 168 in N = 12 Stufen unterteilt ist. Wenn eine Zelle an der Zell-Scheduling-und-Puffer-Einheit 150 eintrifft, ermittelt der Scheduling-Prozessor 180 die aktuellen Werte von M_rt und M_nrt. Durch Anwendung einer einfachen Berechnung, insbesondere wenn K_rt, K_nrt und N von der Form 2ⁿ sind, kann ein Schätzwert des aktuellen Belegtheitsgrades von beiden Puffern 166, 168 ermittelt werden. Diese beiden Werte x_rt und x_nrt bestimmen die Zeilen und Spalten von Tabelle 1. Der Inhalt jeder Zelle von Tabelle 1 stellt den höchsten zulässigen Prioritätsgrad PL_a in Anbetracht des aktuellen Status der beiden Puffer 166, 168 nach dem Eintreffen der Zelle_i 154 dar.
TABELLE 1
Es ist ersichtlich, dass Tabelle 1 eine zweckdienliche Schätzung des höchsten zulässigen Prioritätsgrads PL_a liefert, welcher sowohl den Status als auch die relativen Größen des rt-Puffers 166 und des nrt-Puffers 168 widerspiegelt. Ein Array der Werte aus Tabelle 1 kann gegebenenfalls in einem nichtflüchtigen Speicher innerhalb des Knotens 152 gespeichert und aktualisiert werden.
10 veranschaulicht eine andere Ausführungsform eines Kernknotens 200 in einem SIMA-Netzwerk, der eine Multicast-Prioritätsmanagementfunktionalität gemäß der vorliegenden Erfindung umfasst. In dem Beispiel aus 10 ist die Multicast-Prioritätsmanagementfunktion auf die SBUs 202, 204 bis 206 verteilt. Ähnlich dem Kernknoten 110 aus 8 wird ein Paket von dem Kernknoten 200 empfangen. Bei dieser Ausführungsform wird das Paket dem Routing-Modul 208 direkt zugeführt, und alle Eingänge, die als Eingang-1, Eingang-2 bis Eingang-M gekennzeichnet sind, sind direkt mit dem Router 208 gekoppelt, um zu deren entsprechender Scheduling-und-Puffer-Einheit 202, 204 bis 206 geleitet zu werden. Bei dieser Ausführungsform treffen die Scheduling-und-Puffer-Einheiten nicht nur Paketannahmeentscheidungen, sondern führen auch eine verteilte Multicast-Prioritätsmanagementfunktion aus.
In diesem Beispiel ist es möglich, die zulässigen Drop-Preference-Werte (DP_a) von anderen SBUs im Entscheidungsfindungsprozess einer bestimmten SBU zu verwenden. Die Multicast-Prioritätsmanagementfunktion ist daher über die vorhandenen SBUs im Kernknoten verteilt. Beispielsweise werden die zulässigen Drop-Preference-Werte DP₁ und DP₂ von SBU-1 202 und SBU-2 204 SBU-n 206 bereitgestellt, wie anhand der Linien 210 bzw. 212 dargestellt ist. Gleicherweise werden die zulässigen Drop-Preference-Werte DP₁ und DP_n von SBU-1 202 und SBU-n 206 SBU-2 204 bereitgestellt, wie anhand der Linien 214 bzw. 216 dargestellt ist. Schließlich werden die zulässigen Drop-Preference-Werte DP₂ und DP_n von SBU-2 204 und SBU-n 206 SBU-1 202 bereitgestellt, wie anhand der Linien 218 bzw. 220 dargestellt ist. Die Analyse der zulässigen Drop-Preference-Werte wird in jeder der SBUs auf eine Weise, die der Analyse der zulässigen Drop Preference ähnlich ist, welche durch einen eigenen SIMA-Multicast-Handler, beispielsweise den SMH 112 auf 8, vorgesehen würde, durchgeführt. Die Analyse von derartigen zulässigen Drop-Preference-Werten wird in Zusammenhang mit der Beschreibung von 14 ausführlicher beschrieben.
11 ist ein Flussdiagramm von einer Weise, auf welche die Multicast-Prioritätsmanagementfunktion gemäß der vorliegenden Erfindung realisiert wird. Eine Quelle überträgt eine Zelle/ein Paket, welche/welches zu einem Kernknoten geleitet wird, wo diese/dieses in den Kernknoten eingegeben 230 wird. Es wird ermittelt 232, ob das Paket ein Multicast-Paket ist. Wie zuvor beschrieben wurde, kann dies durch Einbinden einer speziellen Kennung oder eines speziellen Merkers in das Multicast-Paket bewerkstelligt werden, welche/welcher das Paket als Multicast-Paket identifiziert. Alternativ dazu kann dies durch Identifizieren von Paketen, die zu einem bestimmten Fluss gehören, durch Bestimmen der Quelle des Pakets bewerkstelligt werden. Die Quelle des Pakets kann beispielsweise durch ihre Quell-IP(Internet-Protokoll)-Adresse oder ihren Quell-IP(Internet-Protokoll)-Port in dem Header eines IP-Pakets identifiziert werden. Wie für Fachleute ohne weiteres aus der vorangehenden Beschreibung zu erkennen ist, können alternativ dazu andere Multicast-Paketidentifikationsbits überwacht werden, um festzustellen, ob ein Paket ein Multicast-Paket ist oder nicht.
Wenn festgestellt wird 232, dass das Paket kein Multicast-Paket ist, wird die Paketannahme-/-ablehnungsfunktion des SIMA-Multicast-Handler umgangen 234.
Die Non-Multicast-Pakete werden zu dem Routing-Modul und von dort zu den jeweiligen Zell-Scheduling-und-Puffer-Einheiten für die individuelle Paketannahmeanalyse weitergeleitet.
Falls festgestellt wird 232, dass es sich bei dem Paket um ein Multicast-Paket handelt, werden die Informationen über die zulässige Drop-Preference (DP_a) von jeder der SBUs in dem Kernknoten erfasst 236. Eine Multicast-Drop-Preference basierend auf den erfassten DP_a- Werten von den SBUs wird bei Block 238 berechnet. Diese Multicast-Drop-Preference, die als DP_SMH bezeichnet wird, gibt den angenommenen Drop-Preference-Wert an dem SIMA-Multicast-Handler an, welcher eine Funktion der einzelnen angenommenen Drop Preferences der einzelnen SBUs ist. Verschiedene Arten zum Ermitteln der Multicast-Drop-Preference werden in Zusammenhang mit 14 beschrieben.
Wenn die DP_SMH ermittelt wurde, wird ein Vergleich zwischen der berechneten DP_SMH und der ankommenden DP der ankommenden Multicast-Pakete angestellt, und es wird ermittelt, ob die Paket-DP ausreichend hoch ist, um an dem SMH angenommen zu werden, wie bei Block 240 zu sehen ist. Wenn die Paket-DP nicht größer gleich DPSMH ist, wird das Paket verworfen 242. Andernfalls wird das Paket an dem SMH angenommen 244.
In Fällen, in denen ein Multicast-Paket durch den SIMA-Multicast-Handler angenommen wird, gibt es mehrere Möglichkeiten, wie die einzelnen SBUs angewiesen werden, um die Multicast-Pakete zu handhaben. 12 und 13 sind Flussdiagramme, die zwei Möglichkeiten darstellen, wie Pakete, die durch den SMH angenommen werden, durch die einzelnen Zell-Scheduling-und-Puffer-Einheiten verwaltet werden.
Auf 12 Bezug nehmend tritt das Paket in den Kernknoten 230 ein, wo ermittelt wird 232, ob das Paket ein Multicast-Paket ist, und, wenn dies der Fall ist, werden SBU-Drop-Preference-Informationen erfasst 236 und eine Multicast-Drop-Preference wird an dem SMH ermittelt 238, aus welcher ermittelt werden kann 240, ob das Paket angenommen wird 244. Dies verhält sich analog zu der in 11 dargestellten Ausführungsform, und, so sich das anbietet, werden gleiche Bezugszahlen verwendet. Allerdings beschreibt die Ausführungsform aus 12 eine konkrete Weise, auf welche das Multicast-Paket angenommen werden kann. Wenn ermittelt wurde 240, dass das Paket angenommen wird 244, benachrichtigt 246 der SMH die einzelnen SBUs, dass der SMH das Multicast-Paket angenommen hat. Demnach aktiviert der SMH ausdrücklich alle der einzelnen SBUs, so dass die SBU, die vom Router anvisiert wird, das Paket annehmen wird. In diesem Fall sollte der SMH ein Paket nicht annehmen, wenn auch nur eine der SBUs einen vollen Puffer aufweist. Die anvisierte SBU wird das Paket unter diesem Umständen unabhängig von ihrer eigenen zulässigen Drop Preference annehmen.
Nunmehr auf 13 Bezug nehmend wird eine andere Ausführungsform der Weise, wie das Multicast-Paket angenommen werden kann, beschrieben. Wenn ermittelt wurde 240, dass das Paket angenommen 244 wird, stellt 250 der SMH jede der Drop Preferences der SBU ein, um die Wahrscheinlichkeit der Annahme an den SBUs zu modifizieren. Mit anderen Worten können die einzelnen SBUs Pakete mit unterschiedlichen zulässigen Drop Preferences annehmen oder verwerfen, je nachdem, ob das Paket ein Multicast-Paket oder nicht ist. Beispielsweise kann der SMH ermitteln, dass das Multicast-Paket angenommen werden sollte, und wird wiederum jede der einzelnen SBUs anweisen, deren zulässige Drop Preference zu senken, um die Wahrscheinlichkeit zu erhöhen, dass die Pakete an den einzelnen SBUs angenommen werden. Die zulässige Drop Preference DP_a wird an den einzelnen SBUs nach dem Eintreffen eines Pakets berechnet, wird jedoch um einen Betrag G modifiziert, der die Verstärkung auf Grund des Multicast-Wesens des Pakets darstellt. Demnach wird das Multicast-Paket an einer einzelnen SBU angenommen, wenn: DP ≥ DPa – G [6]wobei DP die Drop Preference des Multicast-Pakets, DP_a die zulässige Drop Preference der SBU und G die von der SMH geforderte Einstellung, um die Wahrscheinlichkeit der Annahme an der SBU zu modifizieren, ist. Im Allgemeinen wird die Wahrscheinlichkeit, dass das Multicast-Paket durch die SBUs angenommen wird, erhöht, da die SBUs das Paket basierend auf der eingestellten Verwerfpriorität, wie in Block 252 dargestellt ist, annehmen oder verwerfen. So etwa werden, wenn der SMH ermittelt, dass die Wahrscheinlichkeit der Annahme an den SBUs um 2 erhöht werden sollte (d.h. G = 2) und die zulässige Drop Preference an einer bestimmten SBU 4 ist (d.h. DP_a = 4), Multicast-Pakete mit einer Drop Preference von 2 (d.h. DP = 2) an der SBU angenommen (d.h. 2 ≥ 4 – 2).
14 ist ein Flussdiagramm, das verschiedene Ausführungsformen der Erfindung darstellt, in welchen die Multicast-Drop-Preference mittels der erfassten von der SBU zugelassenen Drop-Preference-Informationen ermittelt wird. Das Paket tritt in den Kernknoten 230 ein, wo ermittelt 232 wird, ob das Paket ein Multicast-Paket ist, und wenn dies der Fall ist, werden SBU-Drop-Preference-Informationen erfasst 236 und eine Multicast-Drop-Preference an dem SMH wird ermittelt 238, aus welcher ermittelt 240 werden kann, ob das Paket verworfen 242 oder angenommen 244 wird. 14 veranschaulicht verschiedene Ausführungsformen, in welchen der SMH die Multicast-Drop-Preference ermittelt 238.
Die zu ermittelnde zulässige Drop Preference in dem SIMA-Multicast-Handler ist als DP_SMH bezeichnet.
Nehmen wir an, der Belegtheitsgrad des Nichtechtzeit-Puffers der SBU-Nummer j ist Mj_nrt und der Belegtheitsgrad des Echtzeit-Puffers der SBU-Nummer j Mj_rt. Dann erhalten wir: DPSMH = f(M1nrt , M1rt , M2rt , ..., MNnrt , MNrt ) [7]wobei N die Anzahl von Multicast-Paketen (N ist größer gleich 2) ist und f eine Funktion dieser Variablen darstellt.
Die Gleichung [7] drückt aus, dass es nicht notwendig ist, den üblichen DP_a ¹-Wert zuerst zu berechnen. Allerdings ist es in vielen Fällen zweckmäßiger, die normalen, unabhängigen DP_a-Werte in den SBUs zuerst zu berechnen und diese Informationen in Gleichung [7] zu verwenden. In diesem Fall kann die Gleichung [7] geschrieben werden als: DPSMH = f(DP1a (M1nrt , M1rt ), DP2a (M2nrt , M2rt ), ..., DPNa (MNnrt , MNrt )) [8]oder, alternativ dazu, als DPSMH = f(DP1a , DP2a , ..., DPNa ) [9]wobei DP_a ¹ die unabhängige DP_a, die in der SBU mit der Nummer i berechnet wird, bezeichnet.
Nachdem der SMH DP_SMH berechnet hat, wird das Multicast-Paket an dem SMH angenommen, wenn die Multicast-Paket-Drop-Preference DP größer gleich DP_SMH ist.
Neuerlich auf 14 Bezug nehmend und unter Verwendung der oben beschriebenen Nomenklatur werden verschiedene Ausführungsformen, in welchen der SMH die Multicast-Drop-Preference ermittelt 238, dargestellt. Es sollte sich verstehen, dass die folgenden Beispiele dem Wesen nach veranschaulichend sind und die Erfindung nicht darauf beschränkt sein sollte, da andere Ausführungsformen für Fachleute ohne weiteres aus der in diesem Dokument bereitgestellten Beschreibung ersichtlich sind.
In einer ersten Ausführungsform wird die maximale an den SBUs erlaubte Verwerfpriorität ermittelt 260. In diesem Beispiel wird das Multicast-Paket an dem SMH angenommen, wenn und nur wenn es einzeln von allen SBUs angenommen worden wäre. Diese "Alles-oder-Nichts-Lösung" setzt voraus, dass das Multicast-Paket eine Drop-Preference aufweist, die größer gleich allen einzelnen DP_a-Werten der SBUs ist. Folglich ist die angenommene Verwerfpriorität an dem SMH: DPSMH = MAX(DPia ) [10]wobei der Index i jede der SBUs darstellt, welche das Multicast-Paket weiterleiten, und MAX eine Funktion ist, um den maximalen DP_a ¹-Wert auszuwählen.
Bei einer anderen Ausführungsform wird ermittelt 262, ob eine vorgegebene Anzahl von SBUs zur Zeit eine bestimmte zulässige Drop-Preference aufweisen. In diesem Fall berechnet jede SBU ihren eigenen DP_a-Wert, und wenn mehr als eine vorgegebene Anzahl von SBUs das Multicast-Paket annehmen würden, dann wird es an dem SMH angenommen. Wenn der SMH das Multicast-Paket auf diese Weise annimmt, dann werden alle SBUs angewiesen, das Multicast-Paket anzunehmen, einschließlich jener, welche das Paket auf einer individuellen Basis nicht annehmen würden. Beispielsweise werden in Fällen, in denen zehn SBUs, die für eine Multicast-Übertragung bestimmt sind, analysiert werden, und es erforderlich ist, dass mindestens sieben der SBUs einen individuellen DP_a-Wert von 4 aufweisen, alle zehn der SBUs angewiesen, das Multicast-Paket anzunehmen, wenn mindestens sieben der SBUs einen individuellen DP_a-Wert von 4 aufweisen.
Bei einer anderen Ausführungsform wird die durchschnittliche SBU-Drop-Preference ermittelt 264. In diesem Beispiel wird das Multicast-Paket an dem SMH angenommen, wenn der SMH ermittelt, dass die durchschnittliche Drop-Preference der einzelnen SBUs größer gleich einem vorgegebenen Durchschnittswert ist. Daher wird, wenn die DP des Multicast-Pakets größer gleich diesem (gerundeten, .... oder auf andere Weise in einen Ganzzahlwert verwandelten) Durchschnittswert ist, das Multicast-Paket an dem SMH angenommen oder andernfalls verworfen. Dies ist aus der unten stehenden Gleichung [11] zu ersehen:
wobei der Summenindex j alle der am Multicasting beteiligten SBUs umfasst.
Bei noch einer anderen Ausführungsform wird eine gewichtete Durchschnitts-SBU-Drop-Preference bestimmt 266. Bei diesem Beispiel wird das Multicast-Paket an dem SMH angenommen, wenn der SMH ermittelt, dass die gewichtete Durchschnitts-Drop-Preference der einzelnen SBUs größer gleich einem Vorgabewert ist. In diesem Fall wird die DP_SMH durch Berechnen eines gewichteten Durchschnitts der DP_a-Werte von verschiedenen SBUs ermittelt, wie aus der nachstehenden Gleichung [12] hervorgeht:
wobei w_j das Gewicht ist, das der SBU-Nummer j zugewiesen wird. Beispielsweise kann die Kapazität der Ausgangsverbindungen eine Auswirkung auf das zugewiesene Gewicht haben. Zu beachten ist, dass, wenn W_j = N für alle j, die Gleichung [12] äquivalent mit dem in Gleichung [11] dargestellten Durchschnitts-DP_a-Wert-Prinzip ist.
Der SMH implementiert verschiedene Arithmetikfunktionen, um die Multicast-Drop-Preference zu ermitteln. Beispielsweise umfasst bei einer Ausführungsform der Erfindung der SMH eine Verarbeitungseinheit, die in der Lage ist, Arithmetikfunktionen wie Addieren, Subtrahieren und Vergleichen auszuführen. Wie Fachleuten bekannt ist, kann eine derartige Verarbeitungseinheit einen Maximalwert aus einer Anzahl von Werten sowie Durchschnittswerte und gewichtete Durchschnittswerte berechnen. Die Verarbeitungseinheit vermag auch eine bestimmte Anzahl von Fällen zu zählen, in denen ein Wert größer gleich einem Vorgabewert ist. Alternativ dazu können getrennte Komponenten, beispielsweise Komparatoren, Addierer oder Arithmetiklogikeinheiten (ALUs) verwendet werden.
Nunmehr auf 15 Bezug nehmend ist ein Flussdiagramm einer beispielhaften Ausführungsform der Erfindung vorgesehen. In diesem Beispiel wird angenommen, dass Multicast-Pakete basierend auf der IP-Adresse der Quelle detektiert werden. Es wird auch angenommen, dass die Entscheidungsfunktion des SMH DP_SMH = MAX(DP¹ _a) ist, wie aus der oben stehenden Gleichung [10] hervorgeht, so dass das Paket nur dann angenommen wird, wenn es einzeln in allen SBUs angenommen würde.
Ein Paket wird empfangen 280, und es wird durch Analysieren der IP-Adresse der Quelle ermittelt 282, ob das Paket ein Multicast-Paket ist. Wenn es kein Multicast-Paket ist, wird es einfach zu der Routing-Einheit weitergeleitet und schließlich von der geeigneten SBU ausgegeben. Wenn das Paket ein Multicast-Paket ist, extrahiert 286 der SMH die Drop Preference DP des Pakets. Der SMH erfasst 288 die DP_a-Werte von allen SBUs, und der maximale DP_a-Wert wird als DP_SMH ausgewählt 290. Dieser wird mit der Multicast-Paket-Verwerfpriorität DP verglichen. Wenn DP ≥ DP_SMH, dann wird das Paket angenommen und zu der Routing-Einheit weitergeleitet 284. Andernfalls wird das Multicast-Paket verworfen 294. Bei diesem konkreten Beispiel kann ein angenommenes Paket einfach zu der Routing-Einheit und schließlich zu den geeigneten SBUs weitergeleitet werden. Es besteht kein Bedarf, Informationen direkt von dem SMH zu den SBUs zu übertragen, da der SMH entweder das Paket selbst verwirft oder das Paket weiterleitet. In letzterem Fall empfängt jede SBU das Paket und legt es in ihrem Puffer. Alternativ dazu ist es möglich, Benachrichtigungsinformationen von dem SMH zu den SBUs zu übertragen, um eine oder mehrere SBUs anzuweisen, das Paket zu verwerfen.
Natürlich versteht es sich, dass verschiedene Modifikationen und Hinzufügungen an den verschiedenen oben besprochenen Ausführungsformen vorgenommen werden können. Demzufolge sollte der Umfang der vorliegenden Erfindung nicht durch die oben besprochenen konkreten Ausführungsformen eingeschränkt werden, sondern nur durch die nachstehend dargelegten Ansprüche und Äquivalente davon definiert werden.

Claims

Verfahren zum Außerkraftsetzen von Paketannahmekriterien, die an jeder einzelnen Verbindung eines Netzwerkknotens (110) eingerichtet sind, um kollektive Paketannahmekriterien für jedes Paket einer Multicast-Übertragung bereitzustellen, welche für die einzelnen Verbindungen bestimmt ist, umfassend: Erfassen (236) der Paketannahmekriterien von jeder der einzelnen Verbindungen in dem Netzwerkknoten (110), welche für die Multicast-Übertragung bestimmt sind; Berechnen (238) einer Multicast-Paketpriorität für jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf einer Gesamtanalyse der Paketannahmekriterien von jeder der einzelnen Verbindungen; und kollektives Annehmen (244) oder Verwerfen (242) jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf der berechneten Multicast-Paketpriorität.
Verfahren nach Anspruch 1, ferner umfassend das Bestimmen (232), ob das Paket ein Paket ist, welches einer Multicast-Übertragung zugeordnet ist.
Verfahren nach Anspruch 2, wobei das Bestimmen, ob das Paket ein Multicast-Übertragungspaket ist, das Überwachen eines Multicast-Anzeigers in dem Paketheader umfasst.
Verfahren nach Anspruch 2, wobei das Bestimmen, ob das Paket ein Multicast-Übertragungspaket ist, das Feststellen der Quelle des Pakets umfasst, um zu ermitteln, ob die Quelle eine Multicast-Sendequelle ist.
Verfahren nach Anspruch 4, wobei das Feststellen der Quelle des Pakets das Vergleichen der Quelladresse aus dem Paketheader mit vorgegebenen Adressen von Multicast-Paketquellen umfasst.
Verfahren nach Anspruch 2, ferner umfassend das Umgehen (234) des Erfassens der Paketannahmekriterien, das Umgehen (234) des Berechnens einer Multicast-Paketpriorität und das Umgehen (234) des kollektiven Annehmens oder Verwerfens von jedem der Pakete, wenn das Paket nicht der Multicast-Übertragung zugeordnet ist.
Verfahren nach Anspruch 6, wobei das Umgehen (234) ferner das Verwenden der Paketannahmekriterien, die an jeder einzelnen Verbindung des Netzwerkknotens eingerichtet sind, als Basis umfasst, um die Pakete, die nicht der Multicast-Übertragung zugeordnet sind, einzeln anzunehmen oder zu verwerfen.
Verfahren nach Anspruch 1, wobei das Erfassen (236) der Paketannahmekriterien von jeder der einzelnen Verbindungen das Empfangen (288) einer zulässigen Paketpriorität umfasst, welche jeder der einzelnen Verbindungen entspricht, wobei die zulässige Paketpriorität eine für die Annahme erforderliche Minimalpaketpriorität darstellt.
Verfahren nach Anspruch 8, wobei das Berechnen (238) einer Multicast-Paketpriorität das Auswählen (260) eines Maximums aus den zulässigen Paketprioritäten als Multicast-Paketpriorität umfasst.
Verfahren nach Anspruch 8, wobei das Berechnen einer Multicast-Paketpriorität das Bestimmen (262), ob eine vorgegebene Anzahl der einzelnen Verbindungen eine vorgegebene zulässige Minimalpaketpriorität aufweisen, umfasst.
Verfahren nach Anspruch 8, wobei das Berechnen einer Multicast-Paketpriorität das Berechnen (264) eines Mittelwerts der zulässigen Paketprioritäten von den einzelnen Verbindungen umfasst.
Verfahren nach Anspruch 8, wobei das Berechnen einer Multicast-Paketpriorität das Berechnen (266) eines gewichteten Mittelwerts der zulässigen Paketprioritäten von den einzelnen Verbindungen umfasst.
Verfahren nach Anspruch 1, wobei das Berechnen (238) einer Multicast-Paketpriorität das Berechnen (290) einer zusammengesetzten zulässigen Knotenpriorität in Abhängigkeit von den Paketannahmekriterien von jeder der einzelnen Verbindungen umfasst.
Verfahren nach Anspruch 1, wobei das kollektive Annehmen (244) oder Verwerfen (242) von jedem der Pakete basierend auf der berechneten Multicast-Paketpriorität das Annehmen (284) von jedem der Pakete an allen einzelnen Verbindungen umfasst, wenn die berechnete Multicast-Paketpriorität größer gleich (292) einer vorgegebenen zulässigen Multicast-Paketpriorität ist.
Verfahren nach Anspruch 14, wobei das Annehmen jedes der Pakete an allen einzelnen Verbindungen das Freigeben jeder der Verbindungen, um die Multicast-Pakete unabhängig von deren einzelnen Paketannahmekriterien anzunehmen, umfasst.
Verfahren nach Anspruch 1, wobei das kollektive Annehmen (244) oder Verwerfen (242) jedes der Pakete basierend auf der berechneten Multicast-Paketpriorität das Verwerfen (294) jedes der Pakete an allen einzelnen Verbindungen umfasst, wenn die berechnete Multicast-Paketpriorität kleiner als (292) eine vorgegebene zulässige Multicast-Paketpriorität ist.
Verfahren zum Außerkraftsetzen von Paketannahmekriterien, die an jeder einzelnen Verbindung eines Netzwerkknotens (110) eingerichtet sind, um kollektive Paketannahmekriterien für jedes Paket einer Multicast-Übertragung bereitzustellen, welche für die einzelnen Verbindungen bestimmt ist, umfassend: Erfassen (236) der Paketannahmekriterien von jeder der einzelnen Verbindungen in dem Netzwerkknoten, welche für die Multicast-Übertragung bestimmt sind; Berechnen (238) einer Multicast-Paketpriorität für jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf einer Gesamtanalyse der Paketannahmekriterien von jeder der einzelnen Verbindungen; Modifizieren (250) der Paketannahmekriterien an jeder der einzelnen Verbindungen in dem Netzwerkknoten basierend auf der berechneten Multicast-Paketpriorität; und einzelnes Annehmen oder Verwerfen (252) jedes der Pakete, welche der Multicast-Übertragung zugeordnet sind, basierend auf den modifizierten Paketannahmekriterien.
Verfahren nach Anspruch 17, wobei das Erfassen (236) der Paketannahmekriterien von jeder der einzelnen Verbindungen das Empfangen (288) einer zulässigen Paketpriorität, welche jeder der einzelnen Verbindungen entspricht, umfasst, wobei die zulässige Paketpriorität eine für die Annahme erforderliche Minimalpaketpriorität darstellt.
Verfahren nach Anspruch 18, wobei das Modifizieren der Paketannahmekriterien das Erhöhen (250) der zulässigen Paketprioritäten von jeder der einzelnen Verbindungen, um eine Wahrscheinlichkeit der Paketannahme an jeder der einzelnen Verbindungen zu erhöhen, umfasst.
Verfahren nach Anspruch 18, wobei das Modifizieren der Paketannahmekriterien das Verringern (250) der zulässigen Paketprioritäten von jeder der einzelnen Verbindungen, um eine Wahrscheinlichkeit der Paketannahme an jeder der einzelnen Verbindungen zu verringern, umfasst.
System zum Verteilen von Multicast-Paketen an eine Mehrzahl von Bestimmungsorten in einem Netzwerk (100) mit mindestens einem Knoten (110) zwischen einer Quelle (106) und einer Mehrzahl von Bestimmungsorten (104, 106), wobei Verbindungen zwischen der Quelle (106) und jedem aus der Mehrzahl von Bestimmungsorten (104, 106) hergestellt sind, um eine Multicast-Übertragung der Multicast-Pakete vorzusehen, wobei das System umfasst: eine Mehrzahl von Paket-Scheduling-Modulen (116, 118, 120), eines für jede Verbindung an dem Knoten (110), wobei jedes Paket-Scheduling-Modul (116, 118, 120) Pakete basierend auf einer zulässigen Paketpriorität von seiner entsprechenden Verbindung annimmt oder verwirft; ein Multicast-Prioritätsmanagementmodul (112), welches mit jedem aus der Mehrzahl von Paket-Scheduling-Modulen (116, 118, 120) gekoppelt ist, um die entsprechenden zulässigen Paketprioritäten zu empfangen, und um die Multicast-Pakete, die für die Mehrzahl von Bestimmungsorten (104, 106) bestimmt sind, basierend auf einer Gesamtknotenpriorität, die aus den zulässigen Paketprioritäten von jedem der Paket-Scheduling-Module (116, 118, 120) abgeleitet wurde, kollektiv anzunehmen oder zu verwerfen.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) einen Prozessor umfasst, der konfiguriert und angeordnet ist, um die Gesamtknotenpriorität basierend auf einem Maximum der zulässigen Paketprioritäten zu berechnen.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) einen Prozessor umfasst, der konfiguriert und angeordnet ist, um die Gesamtknotenpriorität basierend darauf, ob eine vorgegebene Anzahl der zulässigen Paketprioritäten größer gleich einer zulässigen Minimalpaketpriorität ist, zu berechnen.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) einen Prozessor umfasst, der konfiguriert und angeordnet ist, um die Gesamtknotenpriorität basierend auf einem Mittelwert der zulässigen Paketprioritäten zu berechnen.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) einen Prozessor umfasst, der konfiguriert und angeordnet ist, um die Gesamtknotenpriorität basierend auf einem gewichteten Mittelwert der zulässigen Paketprioritäten zu berechnen.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) einen Prozessor umfasst, der konfiguriert und angeordnet ist, um zu ermitteln, ob empfangene Pakete der Multicast-Übertragung zugeordnet sind.
System nach Anspruch 21, wobei das Multicast-Prioritätsmanagementmodul (112) zwischen jedem aus der Mehrzahl von Paket-Scheduling-Modulen (116, 118, 120) verteilt ist.
System nach Anspruch 21, wobei jedes der Paket-Scheduling-Module (116, 118, 120) mindestens einen Puffer (166, 168) umfasst, um empfangene Pakete auf eine FIFO-Vorgangsweise zu puffern.
System nach Anspruch 28, wobei das Multicast-Prioritätsmanagementmodul (112) die Multicast- Pakete, welche für die Mehrzahl von Bestimmungsorten (104, 106) bestimmt sind, basierend auf einem Belegtheitsgrad (170, 174) des mindestens einen Puffers (166, 168) kollektiv annimmt oder verwirft.
System nach Anspruch 21, wobei das System zum Ausgleichen der Dienstgüte, die in einer prioritätsbasierten Netzwerk-Dienstklasse bereitgestellt wird, bestimmt ist, wobei bei diesem System: die Quelle eine Multicast-Sendequelle (106) umfasst; die Mehrzahl von Bestimmungsorten eine Mehrzahl von Multicast-Paket-Empfängern (104, 106) umfasst; der mindestens eine Knoten (110) mit der Multicast-Sendequelle (106) und der Mehrzahl von Multicast-Paket-Empfängern (104, 106) in Reihe gekoppelt ist, wobei der mindestens eine Knoten (110) einen Router (114) umfasst, um die Multicast-Pakete zu deren entsprechenden Multicast-Paket-Empfängern (104, 106) über eine Mehrzahl von Verbindungen zwischen der Multicast-Sendequelle (106) und der Mehrzahl von Multicast-Paket-Empfängern (104, 106) zu rangieren.
Netzwerkvorrichtung, wobei die Netzwerkvorrichtung umfasst: einen Multicast-Sender; einen Multicast-Paket-Empfänger; eine Netzwerkschnittstelle, die mit dem Multicast-Sender und dem Multicast-Paket-Empfänger verbunden ist, wobei die Netzwerkschnittstelle konfiguriert ist, um sich mit einer Schnittstelle verbinden zu lassen und Pakete, die von dem Multicast-Sender ausgesendet werden und zu dem Multicast-Paket-Empfänger hingesendet werden, zu verarbeiten; ein Paket-Scheduling-Modul, welches konfiguriert ist, um Pakete basierend auf Paketpriorität anzunehmen oder zu verwerfen; und ein Multicast-Prioritätsmanagementmodul, welches mit dem Paket-Scheduling-Modul gekoppelt ist, wobei das Multicast-Prioritätsmanagementmodul konfiguriert ist, um Paketprioritätsdaten zu empfangen und zu verarbeiten, und um Multicast-Pakete anzunehmen oder zu verwerfen, die basierend auf Knotenprioritätsdaten, welche aus dem Paketprioritätsdaten abgeleitet werden, zu dem Multicast-Paket-Empfänger übertragen werden.