DE10357582A1

DE10357582A1 - Klassenbasierte Ratensteuerung unter Verwendung eines Leaky Bucket mit einer Vielzahl von Grenzwerten

Info

Publication number: DE10357582A1
Application number: DE10357582A
Authority: DE
Inventors: Linghsiao Wang; Craig Barrack
Original assignee: Zarlink Semiconductor VN Inc
Current assignee: Zarlink Semiconductor VN Inc
Priority date: 2002-12-13
Filing date: 2003-12-08
Publication date: 2004-09-02
Also published as: TW200415891A; CN1514609A; FR2850816A1; KR100644445B1; KR20040052198A; TWI247507B; US20040151184A1

Abstract

Es werden Einrichtungen und Verfahren zum Vorsehen einer Ratensteuerung an einem Benutzerzugangspunkt eines Netzkantenknotens eines paketvermittelten Kommunikationsnetzes beschrieben. Es werden Ratensteuerungsmechanismen sowohl in bezug auf Eingangs- als auch Ausgangsratensteuerung unter Erhalt der Güte der Diensteunterstützung angegeben. Eine Vielzahl von Grenzwerten, die einem einzigen Leaky Bucket pro Verkehrsflußrichtung zugeordnet sind, ermöglichen es dem Mechanismus, Verkehrsraten auf der Basis eines Verkehrsklassen-Prioritätskriteriums selektiv zu steuern.

Description

Die Erfindung betrifft das Verkehrsmanagement in paketvermittelten Kommunikationsnetzen und insbesondere die Steuerung von Verkehrstransportraten an einem Rand eines Kommunikationsnetzes.
Hintergrund der Erfindung
Die Steuerung der Inhalts- bzw. Datenverkehrsrate ist ein Mechanismus, der an einer Teilnehmeranschlußstelle (102) am Rand eines paketvermittelten Kommunikationsnetzes 100 eines Diensteanbieters angewandt wird, wie beispielhaft in 1 gezeigt ist. Ein Kommunikationsnetzkantenknoten 102 ermöglicht charakteristisch eine Bündelung des Aufwärtsinhaltverkehrs und eine Inhaltsverteilung als Abwärtsinhaltsverkehr. Daher bezieht sich der Steuerungsmechanismus der Inhaltsverkehrsrate auf zwei Arten der Ratensteuerung.
In Bezug auf die Inhaltsverteilung begrenzt die Ausgangsratensteuerung den gesamten Abwärtsverkehr, der an dem Netzkantenknoten 102 austritt, über einen Ausgabeport 104, der dem Benutzer zugeordnet ist. Eine Kommunikationsnetzzugangseinrichtung 108, die dem Anwender 106 zugeordnet und mit dem Ausgabeport 104 verbunden ist, ist eventuell nicht imstande, einen beliebig langen Datenburst zu verarbeiten, der mit Drahtgeschwindigkeit von dem Netzkantenknoten 102 empfangen wird, und zwar aus einer Reihe von Gründen, die nachstehend aufgeführt, jedoch nicht darauf beschränkt sind: Die Netzzugangseinrichtung 108 hat nur einen kleinen Paketempfangs-Cache, die Netzzugangseinrichtung 108 kann eine Paketklassifizierung nur mit einer niedrigen Rate ausführen, die Netzzugangseinrichtung 108 hat eine begrenzte Speicherzugangsbandbreite usw. In Abhängigkeit von dem speziellen Einsatz und den unterstützten Diensten muß die Netzzugangseinrichtung 108 eventuell auch hochkomplexe Paketverarbeitungsvorgänge ausführen, die nachstehend aufgeführt, jedoch nicht darauf beschränkt sind:
Verschlüsselung/Entschlüsselung des Inhalts, protokollspezifische Operationen an Sprache und/oder Bild, Gebührenabrechnung usw., wodurch die Ressourcen an der Netzzugangseinrichtung 108 weiter abnehmen und Verzögerungen bei der Inhaltsverarbeitung entstehen. Typischerweise ist der Vergleichspunkt für die Verarbeitung in einer solchen Netzzugangseinrichtung 108 die Anzahl von unterstützten Inhaltsflüssen gegenüber der Frage, ob Pakete mit Drahtgeschwindigkeit verarbeitet werden.
Natürlich kann die Eingangsratensteuerung an der Netzzugangseinrichtung 108 als Ersatz für die Ausgangsratensteuerung an dem Netzkantenknoten 102 ausgeführt werden, und zwar anscheinend mit gleichartiger Wirkung. Es bestehen einige Unterschiede insbesondere bei der Anwendung der Eingangsratensteuerung, wobei die Netzzugangseinrichtung 108 eventuell keine andere Wahl hat, als ankommende Pakete, die nicht gehandhabt werden können, zu verwerfen, weil die Ressourcen an der Netzzugangseinrichtung 108 erschöpft sind. Daher ist typischerweise für solche Entwicklungen eine gewisse Form der Ausgangsratensteuerung am Netzkantenknoten 102 notwendig, um eine Überlastung der Netzzugangseinrichtung 108 zu verhindern. Die Ausgangsratensteuerung an dem Netzkantenknoten 102 kann bevorzugt werden, und zwar besonders dann, wenn der Netzkantenknoten 102 Pufferspeicherressourcen mit großem Inhalt hat, so daß er lange Datenbursts überleben kann, ohne überlastet zu werden, wodurch auf die lange Sicht Paketverluste verringert werden.
Was die Inhaltsbündelung oder -zusammenfassung betrifft, so begrenzt die Eingangsratensteuerung den Umfang des Aufwärtsverkehrs, der an dem Netzkantenknoten 102 von einem gegebenen Eingangsport 110 eintritt, der dem Benutzer 106 zugeordnet ist. In Anbetracht der vorstehenden Ausführungen ist die Eingangsratensteuerung ein erwünschtes Feature an dem Netzkantenknoten 102, und zwar auch dann, wenn, wie es im Jahr 2002 gewöhnlich der Fall war, ein Schicht-2-Netzkantenknoten 102 wie etwa ein Digital Subscriber Line Aggregation Modul (DSLAM) – was keine Einschränkung darstellt – genügend Datenzwischenspeicherressourcen hat, um ankommenden Aufwärtsverkehr mit Drahtgeschwindigkeit an sämtlichen Eingangsports 110 unbegrenzt lang abzuwickeln.
In Bezug auf Entwicklungen, bei denen jeder Port 104/110 einem einzigen Benutzer 106 zugewiesen ist, kann es erwünscht sein, den Abwärts- /Aufwärtsverkehr, der über jeden Port 104/110 befördert wird, unabhängig von anderen Ports 104/110 und unabhängig von der wahren maximalen Datentransportgeschwindigkeit des Ports 104/110 und den Fähigkeiten der Netzzugangseinrichtung 108 zu begrenzen. Der Diensteanbieter kann dann verschiedene Dienstebenen auf der Basis von bestimmten ausgehandelten Abwärts- und Aufwärts-Bandbreitenzuweisungen für jeden Benutzer 106 anbieten. Eingangs-/Ausgangs-Ratensteuerungsparameter an dem Netzkantenknoten 102 müssen je Port 104/110 konfigurierbar sein, um unterschiedliche Dienstebenen bereitzustellen.
Derzeit bekannte Implementierungen der Eingangs- wie auch der Ausgangsratensteuerung wenden eine wohlbekannte Technik an, die als Leaky-Bucket-Regulierung bezeichnet wird. Die Leaky-Bucket-Regulierung verwendet einen einfachen Algorithmus mit zwei Parametern "b" und "r". Der erste Parameter b stellt die Bucketgröße in verfügbaren Tokens dar (die typischerweise den verfügbaren Speicherressourcen entspricht). Ein Parameter "R" repräsentiert die tatsächliche Tokenverringerungsrate, so daß man sagt, daß Tokens, die für einen verfolgten transportierten Inhalt repräsentativ sind, aus dem Bucket mit der Rate R bis zu einer maximalen Anzahl von Tokens b entfernt werden. Tokens sind für beförderte Nutzdateneinheiten wie die folgenden – jedoch ohne Beschränkung auf diese – repräsentativ: Bits, Bytes, Wörter, Rahmen fester Größe usw. Nachstehend sollen Tokens ohne Verlust der allgemeinen Bedeutung Bytes darstellen, die in einem Portpuffer 112/114 gespeichert sind. Tokens werden mit einer Rate "r" (das ist der zweite Leaky-Bucket-Parameter) zu dem Bucket zurückgeleitet, die für die Rate repräsentativ ist, mit der Inhalt durch ihn verarbeitet wird.
Tokens werden aus dem Bucket entnommen und ihm hinzugefügt in Form von Tokengruppen, die für die Größe von entsprechenden beförderten Paketen repräsentativ sind. Jedes ankommende Inhaltspaket erfordert es daher, daß bei seinem Auftreten eine vorbestimmte Anzahl Tokens n aus dem Bucket entnommen wird, während Speicherplatz an dem Netzkantenknoten 102 verbraucht wird. Wenn an dem Netzkantenknoten 102 Speicherplatz vorhanden ist und wenn daher mindestens n Tokens in dem Bucket sind, werden n Tokens aus dem Bucket entnommen, und es erfolgt keine weitere Aktion. Wenn jedoch an dem Netzkantenknoten 102 ungenügend Speicherplatz vorhanden ist und somit in dem Bucket n Tokens nicht verfügbar sind, wenn das entsprechende Paket ankommt, wird statt dessen eine regulierende Aktion ausgeführt.
Wenn man r gleich einer gewünschten regulierten Rate wie etwa einer ausgehandelten Dienstrate annimmt, dann folgt, daß eine regulierende Aktion nur erfolgt, wenn – und nur wenn – die unregulierte Inhaltstransportrate R während irgendeines Zeitintervalls die regulierte ausgehandelte Dienstrate r überschreitet. In bezug auf die Eingangsratensteuerung entnimmt jedes von der Netzzugangseinrichtung 108 empfangene Paket Tokens aus der Belegung eines Bucketverfolgungs-Eingangspuffers 114, und die regulierende Aktion kann entweder das Verwerfen des Pakets oder die Auslösung einer Flußsteuerung an diesem Eingangsport 110 sein. In bezug auf eine Ausgangsratensteuerung fügt jede Paketübertragung von dem entsprechenden Ausgangspuffer 112 des Ausgangsports 104 immer dann Tokens zu der Belegung des Bucketverfolgungs-Ausgangspuffers 112 hinzu, wenn die Abwärtsstrecke frei ist und mindestens ein Paket in der Übertragungs-Warteschlange in dem Ausgangsportpuffer 112 ist. In bezug auf die Ausgangsratensteuerung ist es unter der Annahme, daß an dem Netzkantenknoten 102 genügend Speicherressourcen vorhanden sind, erwünscht, daß Pakete, die ausgehend von dem entfernten Quellnetzknoten die gesamte Kommunikationsnetzinfrastruktur durchlaufen haben, so nahe am Zielnetzknoten 106 nicht verworfen werden, um nicht einen großen Inhaltstransport-Overhead auszulösen.
Die oben beschriebene klassische Leaky-Bucket-Ratenregulierung ist mit mindestens zwei Problemen behaftet. Angenommen, R ist die der Aufwärtsstrecke und somit dem Eingangsport 110 zugeordnete Drahtgeschwindigkeit. Wenn an dem Eingangsport 110 ein Burst von Paketen einer Größe L>>b ankommt, beginnt der Eingangs-Leaky-Bucket bald damit, ein Verhältnis von 1 – r/R der ankommenden Pakete während des Bursts zu verkleinern. Da die ausgehandelte (regulierte) Rate r der Aufwärtsstrecke viel kleiner als R sein kann – um einen Faktor von 10 oder mehr -, werden eventuell während eines solchen Datenbursts mehr als 90 % der Pakete herausgenommen. Wenn diese Pakete ein Bestandteil einer Transport Control Protocol über Internet Protocol (TCP/IP)-Datensitzung sind, bringt der plötzliche Mangel an Bestätigungen für 90 % Pakete die Übertragung praktisch zum Stillstand, da auf den Verkehrsburst mit reguliertem Inhalt ein entsprechender Burst von nichtbestätigten Paketneuübertragungen folgt, wodurch der Inhalts- /Paketdurchsatz dramatisch und unnötigerweise reduziert wird.
Ein zweiter Nachteil der klassischen Leaky-Bucket-Ratenregulierung besteht darin, daß Paketverarbeitungsprioritäten nicht berücksichtigt werden. Wenn unter erneuter Bezugnahme auf das vorhergehende Beispiel mehr als 90 % der Pakete während eines langen Bursts verworfen werden, werden die Verkehrsklassenzuordnungen der verworfenen Pakete in der Regulierungsaktion nicht reflektiert, was somit zu einer unzulänglichen Dienstleistungsgüte führt. Wenn die klassische Leaky-Bucket-Ratenregulierung für den Ausgang angewandt wird, kann die vorübergehende Unterbrechung der Paketübertragung dazu führen, daß durch Pakete hoher Priorität eine inakzeptable Latenz bewirkt wird.
Derzeitige Hardwareausbildungen für die Ratensteuerung, die eine Differenzierung der Verkehrsklassen vorsehen, haben den Nachteil einer sehr komplexen Implementierung. Typischerweise erfordern solche Ausbildungen die Verwendung eines separaten klassischen Leaky Bucket für jede zu regulierende Verkehrsflußgruppe – einen Port pro Klasse oder sogar einen pro Inhaltsfluß. Die vereinte Komplexität einer solchen mit roher Gewalt implementierten Maßnahme ist umwerfend. Daher sind riesige Mengen von Parallelität erforderlich, weil viele Hardware-Zustandsmaschinen gleichzeitig dafür zuständig sein müssen, jedem Bucket periodisch Tokens hinzuzufügen. Alternativ können zwar weniger Zustandsmaschinen verwendet werden, aber dann muß jede einzelne eine Untermenge der Gesamtzahl von Buckets abwickeln, wodurch die Verarbeitungszeiten scharf beschränkt werden.
Das Vorsehen eines klassischen Leaky Bucket pro Port pro Verkehrsklasse in Hardware führt nicht nur zu Implementierungen mit hoher Gatezahl, sondern ist auch übermäßig restriktiv. Ein Mitarbeiter, der Benutzer 106 (Teilnehmer) bringt, weiß häufig nicht, wie er die ausgehandelte Bandbreite zwischen einer Vielzahl von Verkehrsklassen oder Mikroflüssen pro Benutzer zuteilen soll, so daß es umständlich ist, die Fülle von Parametern zu programmieren. Selbst wenn Bandbreitenzuweisungen angemessen bekannt sind, können sich diese Zuweisungen über die Zeit sehr rasch ändern, was zu einem extremen Konfigurationsstau führt. Es sei beispielsweise angenommen, daß der Benutzer 106 für jede einzelne von drei Verkehrsklassen 0, 1 und 2 jeweils 10 Mbps aushandelt. Die Ratenregulierung, die drei klassische Leaky Buckets verwendet, sieht die Möglichkeit nicht vor, daß der Benutzer 106 eine Kombination von 30 Mbps in einem anderen Verhältnis zu einem späteren Zeitpunkt senden möchte, was dazu führt, daß Pakete aufgrund eines Mangels an Flexibilität unnötigerweise verworfen werden.
Am Eingangsport 110 sind die Verkehrsklassen typischerweise nur lokal von Bedeutung, und zwar zum Zweck des Definierens von unterschiedlichen Dienstebenen. Daher sollte es keinen Grund geben, die Übertragung des Benutzers 106 zu blockieren, weil sie nicht zu den spezifischen Klassenzuweisungen paßt, obwohl die bezahlte Gesamtbandbreite von 30 Mbps nicht erschöpft ist.
Die Forschung auf dem Gebiet der Verkehrszuweisung umfaßt das Dokument Request For Comments (RFC 2698) "A Two Rate Three Color Marker", das hier summarisch eingeführt wird. Gemäß dem Standard RFC 2698 werden klassifizierte Pakete eines bestimmten Flusses verfolgt, während die Pakete einen Netzknoten durchlaufen, und werden bei Eintritt mit einer von drei "Farben" markiert, wobei der Status von zwei dem Fluß zugeordneten Eingangs-Leaky-Buckets genutzt wird. Beim Austritt, nachdem die Pakete den Netzknoten durchlaufen haben, können die Pakete verworfen werden, wenn die Strecke blockiert ist. Das Verwerfen von Paketen basiert teilweise auf den Farben, mit denen die Pakete markiert wurden. Wenn die Lehre von RFC 2698 für die Behandlung der Ratensteuerung in Bezug auf eine Auf- und eine Abwärtsstrecke zwischen einem Netzkantenknoten und einer Netzzugangseinrichtung angewandt würde, dann würden jedoch ganz abgesehen von der beschriebenen komplexen Vielfach-Bucket-Implementierung komplexe Aspekte, die den Paketdurchlauf über den Netzkantenknoten betreffen, die Implementierung kompliziert machen und Hardware-Implementierungen verhindern, weil die Farbmarkierung von Paketen und das Verwerfen von Paketen auf der Basis einer Farbe jeweils an typischerweise getrennter Eingangshardware und Ausgangshardware ausgeführt werden müssen.
Ein Stand der Technik, US-PS 6 167 027 mit dem Titel "Flow Control Technique for X.25 Traffic in a High Speed Packet Switching Network", ausgegeben am 26. Dezember 2000 für Aubert et al., beschreibt einen präventiven X.25-Flußsteuerungsmechanismus: Jeder Zugangsknoten in einem Netz weist eine Leaky-Bucket-Komponente auf. Jedesmal, wenn ein ankommendes Paket von der Leaky-Bucket-Komponente empfangen wird, wird die Anzahl von verfügbaren Tokens mit zwei vorbestimmten Grenzwerten verglichen. Wenn die Anzahl der verfügbaren Tokens geringer als der niedrige Grenzwert ist, werden Bestätigungen von empfangenen Paketen unterbrochen, was zu einer Unterbrechung von Paketen führt, die von den ausgebenden zugehörigen X.25-Terminals übertragen werden. Die Unterbrechung der Paketübertragung führt zu einer Regenerierung der Anzahl von Tokens in dem Tokenpool, während vorher empfangene Pakete unter Verarbeitung durchgelassen werden. Wenn die Anzahl von Tokens den hohen Grenzwert erreicht, werden erneut Bestätigungen erzeugt, um die Paketübertragungen wieder aufzunehmen. Die beiden Grenzwerte haben im wesentlichen die Rolle, über Zustände von "Bucket leer" und "Bucket voll" zu unterrichten. Die Lösung ist zwar innovativ, sie zeigt aber die oben angesprochenen Nachteile des klassischen Leaky Bucket wie folgt: Insbesondere in einer X.25-Umgebung folgen auf mit hohen Raten ankommende unbestätigte Pakete mit Sicherheit entsprechende Paketneuübertragungen mit hohen Raten; und Verkehrsklassenzuweisungen werden bei der Durchführung der vorgeschlagenen Flußsteuerung nicht in Betracht gezogen.
Der Stand der Technik nach der US-Patentanmeldung mit dem Titel "Method and apparatus for guaranteeing data transfer rates and enforcing conformance with traffic profiles in a packet network", die unter der Nummer 20020036984A1 am 28. März 2002 für Chiussi et al. veröffentlicht wurde, beschreibt die Erzwingung der Konformität mit Verkehrsprofilen unter Verwendung von zwei Leaky Buckets pro Fluß. Dies ist zwar innovativ, wie oben erwähnt wurde, aber die Verwendung von zwei Leaky Buckets wird als unnötig komplex angesehen.
Der Stand der Technik nach der US-Patentanmeldung mit dem Titel "Gigabit Switch with Fast Filtering Processor", veröffentlicht unter der Nummer 20020012585A1 am 31. Januar 2002 für Klakunte et al., beschreibt die Verkehrsinhaltsverfolgung über einen klassischen Leaky Bucket zum Zweck der Verkehrsformung in Vermittlungspaketen. Dies ist zwar innovativ, es ist aber beim Entnehmen von Tokens aus dem und der Hinzufügung von Tokens zu dem klassischen Leaky Bucket eine vorherige komplexe Bestimmung in Bezug darauf erforderlich, ob Pakete innerhalb oder außerhalb eines Profils sind.
Es wird nach einer Port-basierten Implementierung gesucht, die zur Hardware-Implementierung geeignet ist und Aspekte eines Dienstebereitstellungsmodells behandelt, bei dem Anwender den vollen Nutzen aus der von ihnen bestellten Bandbreite ziehen. Es besteht also ein Bedarf zur Überwindung der oben angesprochenen Beschränkungen.
Zusammenfassung der Erfindung
Gemäß einem Aspekt der Erfindung ist eine Ausgangsratensteuereinrichtung vorgesehen, die den Inhalts- bzw. Datenverkehr überwacht, der von einem Netzkantenknoten eines paketvermittelten Kommunikationsnetzknotens übertragen wird. Die Ausgangsratensteuereinrichtung weist einen Leaky Bucket auf, der eine ursprüngliche maximale Anzahl Tokens hat, die abnimmt, während Pakete in einem zugehörigen Ausgangspuffer mit einer Empfangstokenrate für die Übertragung empfangen werden. Eine Vielzahl von Tokenverfügbarkeit-Grenzwertregistern bezeichnen eine entsprechende Vielzahl von Tokenmengen, die Tokenverfügbarkeitsbereiche definieren. Und eine Paketübertragungunterdrückungs-Steuereinrichtung unterdrückt selektiv die Übertragung eines Pakets, das eine Verkehrsklassenzuordnung hat, die darauf basiert, daß ein aktueller Tokenverfügbarkeitswert innerhalb eines Tokenverfügbarkeitsbereichs ist, der die Übertragungsunterdrückung von Paketen der Verkehrsklasse bezeichnet.
Gemäß einem anderen Aspekt der Erfindung ist eine Eingangsratensteuereinrichtung vorgesehen, die den Inhalts- bzw. Datenverkehr überwacht, der an einem Netzkantenknoten eines paketvermittelten Kommunikationsnetzknotens empfangen wird. Die Eingangsratensteuereinrichtung weist einen Leaky Bucket auf, der eine ursprüngliche maximale Anzahl Tokens hat, die abnimmt, während mit einer Empfangstokenrate empfangene Pakete akzeptiert werden. Eine Vielzahl von Tokenverfügbarkeit-Grenzwertregistern bezeichnen eine entsprechende Vielzahl von Tokenmengen, die Tokenverfügbarkeitsbereiche definieren. Eine Vielzahl von Paketverwerfungs-Wahrscheinlichkeitsregistern ist vorgesehen, und jedes Paketverwerfungs-Wahrscheinlichkeitsregister bezeichnet eine Wahrscheinlichkeit, mit der Pakete einer bestimmten Verkehrsklasse zu verwerfen sind, wenn ein aktueller Tokenverfügbarkeitspegel innerhalb eines Tokenverfügbarkeitsbereichs ist. Und eine Paketakzeptanzsteuereinrichtung ist vorgesehen, die selektiv zufällig Pakete verwirft, die eine Verkehrsklassenzuordnungen haben, die darauf basiert, daß der aktuelle Tokenverfügbarkeitspegel innerhalb eines Tokenverfügbarkeitsbereichs ist, der die zufällige Paketverwerfung von Paketen der Verkehrsklasse bezeichnet.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zur Durchführung der Ausgangsratensteuerung angegeben. Das Verfahren umfaßt das selektive Unterdrücken der Paketübertragung für ein Paket einer bestimmten Verkehrsklasse, wenn ein aktueller Tokenverfügbarkeitspegel eines Leaky Bucket, der Paketübertragungen verfolgt, zwischen zwei Tokenverfügbarkeits-Grenzpegeln von einer Vielzahl von Tokenverfügbarkeits-Grenzpegeln ist.
Gemäß noch einem anderen Aspekt der Erfindung wird ein Verfahren zur Durchführung der Eingangsratensteuerung angegeben. Das Verfahren umfaßt das zufällige Verwerfen von Paketen einer bestimmten Verkehrsklasse, wenn ein aktueller Tokenverfügbarkeitspegel eines Leaky Bucket, der Pakete verfolgt, zwischen zwei Tokenverfügbarkeits-Grenzpegeln von einer Vielzahl von Tokenverfügbarkeits-Grenzpegeln ist.
Die Vorteile ergeben sich daraus, daß eine Vielzahl von Grenzwerten einem einzigen Leaky Bucket pro Verkehrsflußrichtung zugeordnet ist, was dem Ratensteuerungsmechanismus erlaubt, Verkehrsraten auf der Basis eines Verkehrsklassenkriteriums selektiv zu steuern.
Kurze Beschreibung der Zeichnungen
Die Merkmale und Vorteile der Erfindung ergeben sich im einzelnen aus der nachstehenden genauen Beschreibung der beispielhaften Ausführungsformen unter Bezugnahme auf die beigefügten Zeichnungen; diese zeigen in:
1 ein schematische Ansicht, die gemäß einer beispielhaften Ausführungsform der Erfindung zusammenwirkende Elemente zeigt, die einen ratengesteuerten Inhaltsaustausch zwischen einer Netzzugangseinrichtung und Kommunikationsnetzrandeinrichtungen ermöglichen;
2 eine schematische Ansicht, die gemäß der beispielhaften Ausführungsform der Erfindung drei Ausgangsraten-Steuerungsszenarien für Verkehrsinhalte zeigen, die über einen Benutzerausgangsport eines Netzkantenknotens transportiert werden; und
3 eine schematische Ansicht, die gemäß der beispielhaften Ausführungsform der Erfindung drei Eingangsraten-Steuerungsszenarien für Verkehrsinhalte zeigen, die über einen Benutzereingangsport eines Netzkantenknotens transportiert werden.
Es ist zu beachten, daß gleiche Merkmale in den beigefügten Zeichnungen gleiche Bezugszeichen aufweisen.
Genaue Beschreibung der beispielhaften Ausführungsformen
Unter Bezugnahme auf 1 weist gemäß einer beispielhaften Ausführungsform der Erfindung eine Ausgangsratensteuereinrichtung 200 folgendes auf: Ein Paketklassifizierungsmodul 202, eine Unterdrückungssteuereinheit 204, eine Vielzahl von Tokenverfügbarkeit-Grenzwertregistern 206, ein Bucketgrößenregister 208 und ein Aktuelle-Tokenverfügbarkeit-Register 210.
Gemäß der beispielhaften Ausführungsform der Erfindung wird ein einzelner Leaky Bucket pro Ausgangsport 104 für die Durchführung der Ausgangsratensteuerung in Bezug auf den gesamten Inhalt verwendet, der über den Ausgangsport 104 transportiert wird. Das Bucketgrößenregister 208 enthält einen Wert "b", der die maximale Anzahl von Tokens darstellt, die dem Bucket für die Implementierung der Ausgangsratensteuerung an dem Ausgangsport 104 zugewiesen sind.
Es wird darauf hingewiesen, daß die Größe b des bei der Ausgangsratensteuerung verwendeten Leaky Bucket, wenn sie mit der Größe jedes Tokens multipliziert wird, höchstens gleich der Größe des Ausgangsportpuffes 212 ist. Der Wert b kann entweder extern eingestellt werden und/oder kann während der Initialisierung des Netzkantenknotens 102 auf einen bestimmten Wert eingestellt werden. Durch Verwendung eines Ausgangsportpuffers 112, der größer als der Leaky Bucket ist, kann die Paketübertragung über die Abwärtsstrecke unterdrückt werden, ohne Pakete zu verwerfen.
Bei der Initialisierung wird der Wert des Aktuelle-Tokenverfügbarkeit-Registers 210 mit b eingestellt. Nachdem ein über den Ausgangsport 104 zu transportierendes Paket in dem Ausgangsportpuffer 112 gespeichert ist, wird bei der Zeitplanung des Pakets für die Übertragung dann, wenn die Anzahl von Tokens, die zum Speichern des Pakets in dem Ausgangsportpuffer 112 erforderlich ist, kleiner als der Wert des Aktuelle-Tokenverfügbarkeit-Registers 210 ist, der Wert des Aktuelle-Tokenverfügbarkeit-Registers 210 um diese Anzahl von Tokens verringert. Pakete werden über den Ausgangsport 104 über die Abwärtsstrecke immer dann übertragen, wenn die Abwärtsstrecke frei ist und ein Paket in dem Ausgangsportpuffer 112 verfügbar ist. Der Wert des Aktuelle-Tokenverfügbarkeit-Registers 210 wird mit der ausgehandelten Abwärtsstreckenrate r inkrementiert, während die verfügbaren Tokens in dem Bucket periodisch aufgefüllt werden.
Gemäß der beispielhaften Ausführungsform der Erfindung berücksichtigt die Ausgangsratensteuerung an dem Netzkantenknoten 102 die Tatsache, daß die Pakete das gesamte Netz von entfernten Quellen kommend durchlaufen haben und ein Verwerfen von Paketen so nahe am Zielbenutzerknoten 106 in dem Kommunikationsnetz 100 zu einem großen Transport-Overhead führen würde. Daher wird die Ausgangsratensteuerung unter der Annahme der Verfügbarkeit eines ausreichenden Speichers 112 an dem Netzkantenknoten 102 am besten über eine Pakettransportunterdrückung im Gegensatz zu einem Verwerfen von Paketen erzwungen. Es stellt sich die folgende Frage: Warum soll, wenn die Pakete die Langestreckenübertragung überstanden haben, der Netzkantenknoten 102 belastet werden, und warum werden die Pakete nicht einfach über die Abwärtsstrecke übertragen, um die Nutzung von Speicherressourcen an dem Netzkantenknoten 102 zu verringern? Vom Standpunkt der Nutzung der Speicherressource wäre es zwar sinnvoll, den Ausgangspuffer 112 schnellstmöglich zu leeren, aber die Nutzung von mehr Bandbreite, als ausgehandelt und bezahlt wurde, erzeugt auch Nebensprechen in benachbarten Abwärts- und Aufwärtsstrecken, die andere Benutzer 106 bedienen, wodurch die den anderen Nutzern 106 gebotenen Dienste verschlechtert werden.
Es ist wichtig, erneut zu betonen, daß das, was unterdrückt wird, eine Paketübertragung über die Abwärtsstrecke mit der Absicht ist, daß die Pakete zu einem späteren Zeitpunkt übertragen werden. Daher gibt die Unterdrückungssteuereinrichtung 204 ihr Unterdrückungssignal 214 an einen Zeitplaner 212 ab. Da der Zeitplaner 212 den Ausgangsport 104 im Durchschnitt mit der ausgehandelten Abwärtsstreckenservicerate r bedient, werden dem Bucket durchschnittlich Tokens mit der ausgehandelten Abwärtsstreckenservicerate r hinzugefügt.
Während der Initialisierung und/oder durch Rekonfiguration des Netzkantenknotens 102 werden N Grenzwertregister 206 mit Leaky-Bucket- Tokenverfügbarkeitswerten besetzt. Gemäß der beispielhaften Ausführungsform der Erfindung definieren die N Grenzwertregisterwerte Tokenverfügbarkeitsbereiche, die einer konstruierten Antwort auf die Bandbreitennutzung in bezug auf Paketverkehrsklassen entsprechen, die an dem Netzkantenknoten 102 unterstützt werden. Die Werte der Grenzwertregister 206 können als Tokens oder Prozentsätze der Bucketgröße b ausgedrückt sein. Tatsächliche Grenzwertregisterwerte sind in Tokens ausgedrückt. Da die Anzahl von Verkehrsklassen, die von dem Netzkantenknoten 102 unterstützt wird, bei der Auslegung des Netzkantenknotens bekannt ist, können standardmäßige Grenzwertregisterwerte während der Entwicklung vorgesehen werden, wodurch Konfigurations-Overheads minimiert werden.
Das Paketklassifizierungsmodul 202 klassifiziert Pakete nach Maßgabe von M Verkehrsklassen, die von dem Netzkantenknoten 102 unterstützt werden. Gemäß der beispielhaften Ausführungsform der Erfindung wird die Ausgangsratensteuerung durch die Unterdrückungssteuereinheit 204 ausgeführt, und zwar auf der Basis des Werts des Aktuelle-Tokenverfügbarkeit-Registers 210, verglichen mit den Werten der N Grenzwertregister 206 in bezug auf Pakete einer bestimmten Klassenzuordnung.
Gemäß einer Implementierung mit zwei Grenzwertregistern (N, 1) erhält man das folgende kombinierte Ausgangsratensteuerungsverhalten:
ungeachtet der Anzahl M von Verkehrsklassen, die von dem Netzkantenknoten 102 unterstützt werden. 2 zeigt drei beispielhafte Ausgangsraten-Steuerungsszenarien in bezug auf eine allgemeine Implementierung.
Gemäß der beispielhaften Ausführungsform der Erfindung ermöglicht bei der Verwendung einer Vielzahl von Tokenverfügbarkeits-Grenzwerten in Bezug auf einen einzigen Leaky Bucket die vorgesehene Ausgangsratensteuerung ein selektives Anhalten der Zeitplanung der Übertragung von Verkehrsklassen mit niedrigerer Priorität, wenn der Bucket nicht genügend Tokens aufweist. Außerdem kann jede einzelne Klasse von Paketen, die transportiert werden, die gesamte ausgehandelte Bandbreite r der Abwärtsstrecke nutzen, solange der gebündelte Verkehr weniger als die ausgehandelte Bandbreite r erfordert (oder gleich dieser ist).
In Abhängigkeit von dem Zeitplanungsalgorithmus, der von dem Zeitplaner 212 bei der Bedienung des Ausgangsportpuffes 112 angewandt wird, können Nebeneffekte vorhanden sein, die mit der zeitweisen Unterbrechung der Übertragungszeitplanung für Pakete von einer oder mehreren Verkehrsklassen zusammenhängen. Solche Aspekte liegen zwar außerhalb des Umfangs der vorliegenden Offenbarung, für den Designer/Bediener ist es jedoch wichtig, die Auswirkung einer Ausgangsratensteuerung auf bestimmte Zeitplanungs-Implementierungen sorgfältig in Betracht zu ziehen. Ein Echtzeitverkehr mit strengen Latenzgrenzen wie etwa Sprache-über-Paket-Implementierungen – jedoch nicht hierauf beschränkt – zieht den meisten Nutzen aus der angegebenen Vorgehensweise, da Pakete, die anderen Verkehrsklassen zugeordnet sind, zu Gunsten dieser Vorgehensweise verzögert (unterdrückt) werden.
Gemäß der beispielhaften Ausführungsform der Erfindung kann durch die Kombination einer Verkehrsklassenunterscheidung und einer Steuerung vom Leaky-Bucket-Typ bei der Durchführung der Ausgangsratensteuerung die Dienstgüte adäquat gewährleistet werden, indem eine Unterscheidung zwischen Paketen mit unterschiedlichen Verkehrsklassenzuordnungen auf einfache und flexible Weise erfolgt.
Unter Bezugnahme auf 1 weist gemäß der beispielhaften Ausführungsform der Erfindung eine Eingangsratensteuereinrichtung 300 folgendes auf: ein Paketklassifizierungsmodul 302, eine Akzeptanzsteuereinheit 304, eine Vielzahl von Tokenverfügbarkeits-Grenzwertregistern 306 und eine entsprechende Vielzahl von Verwerfungswahrscheinlichkeitsregistern 316, ein Bucketgrößenregister 308 und ein Aktuelle-Tokenverfügbarkeit-Register 310.
Gemäß der beispielhaften Ausführungsform der Erfindung wird ein einziger Leaky Bucket je Eingangsport 110 bei der Durchführung der Eingangsratensteuerung in Bezug auf die gesamten Inhalte verwendet, die über den Eingangsport 110 transportiert werden. Das Bucketgrößenregister 308 hält einen Wert b, der die maximale Anzahl von Tokens darstellt, die dem Bucket bei der Implementierung der Eingangsratensteuerung am Eingangsport 110 zugewiesen sind.
Es ist zu beachten, daß die Größe b des bei der Eingangsratensteuerung verwendeten Leaky Bucket, multipliziert mit der Größe jedes Tokens, höchstens gleich der Größe des Eingangsportpuffers 114 ist. Der Wert b kann entweder extern eingestellt werden und/oder kann während der Initialisierung des Netzkantenknotens 102 mit einem bestimmten Wert vorgegeben werden. Durch die Verwendung eines Eingangsportpuffers 112, der größer als der Leaky Bucket ist, kann eine "Verkehrsschwäche" in der Anzahl von transportierten Paketen erzeugt werden, um Auswirkungen der Paketeingangsratensteuerung über die Aufwärtsstrecke mit dem Ziel zu maskieren, Auswirkungen einer wiederholten Paketübertragung zu minimieren, die mit Fällen einer Paketverwerfung einhergehen.
Bei der Initialisierung wird der Wert des Aktuelle-Tokenverfügbarkeit-Registers 310 mit b vorgegeben. Wenn beim Empfang eines Pakets über den Eingangsport 110 die Anzahl von Tokens, die zum Speichern des Pakets in dem Eingangsportpuffer 114 erforderlich ist, niedriger als der Wert des Aktuelle-Tokenverfügbarkeit-Registers 310 ist, wird der Wert des Aktuelle-Tokenverfügbarkeit-Registers 310 um diese Anzahl von Tokens verringert. Von einem Systemzeitplaner, der für die Bedienung des Eingangsports 110 verwendet wird, wird erwartet, daß er im Durchschnitt den Eingangsport 110 mit der ausgehandelten Aufwärtsdienstrate r bedient, und daher werden dem Bucket im Durchschnitt Tokens mit der ausgehandelten Aufwärtsdienstrate r hinzugefügt.
Gemäß der beispielhaften Ausführungsform der Erfindung berücksichtigt die Eingangsratensteuerung an dem Netzkantenknoten 102 die Tatsache, daß die Pakete ausgehend von der Netzzugangseinrichtung nur einen einzigen Abschnitt 108 durchlaufen haben, und das Verwerfen von Paketen bei der Durchführung der Eingangsratensteuerung führt daher nur zu einem relativ geringen Pakettransport-Overhead in dem Kommunikationsnetz.
Es ist wichtig, erneut zu betonen, daß verworfene Pakete zu einem späteren Zeitpunkt von dem Netzknoten 106 des Benutzers (oder der Netzzugangseinrichtung 108) erneut übertragen werden. Typischerweise wartet der Benutzernetzknoten 106 eine vorbestimmte Zeitdauer vor einer erneuten Übertragung. Das Verwerfen einer großen Anzahl von Paketen in einem großen Burst führt zu einer unmittelbaren Nichtverfügbarkeit von Paketen für die Übertragung während der vorbestimmten Warteperiode, gefolgt von einem anschließenden Burst von Paketen nach Ablauf der Warteperiode. Das Vorsehen einer Verkehrsschwäche in der Anzahl der transportierten Pakete kann die Abwesenheit von Paketen während der vorbestimmten Warteperiode mildern, während gleichzeitig eine Gesamtverzögerung eingeführt wird, verhindert jedoch nicht den folgenden Burst.
Gemäß der beispielhaften Ausführungsform der Erfindung wird bei der Implementierung der Eingangsratensteuerung eine frühzeitige Paketverwerfungsdisziplin angewandt, die Paketverkehrsklassen höherer Priorität bevorzugt, während die Tokens in dem Bucket abnehmen.
Während der Initialisierung des Netzkantenknotens 102 und/oder durch Rekonfigurierung werden N Grenzwertregister 306 mit Leaky-Bucket-Tokenverfügbarkeitswerten besetzt. Gemäß der beispielhaften Ausführungsform der Erfindung definieren die Werte der N Grenzwertregister Tokenverfügbarkeitsbereiche, die einer konstruierten Antwort auf die Bandbreitennutzung in Bezug auf Paketverkehrsklassen entsprechen, die an dem Netzkantenknoten 102 unterstützt werden. Die Werte der Grenzwertregister 306 können als Tokens oder Prozentsätze der Bucketgröße b angegeben sein.
Tatsächliche Grenzwertregisterwerte werden in Tokens ausgedrückt. Da bei der Auslegung des Netzkantenknotens die Anzahl von Verkehrsklassen bekannt ist, die von dem Netzkantenknoten 102 unterstützt werden, können Standard-Grenzwertregisterwerte vorgesehen werden, wodurch die Konfiguration während der Entwicklung minimiert wird.
Während der Initialisierung des Netzkantenknotens 102 und/oder durch Rekonfigurieren werden N Verwerfungswahrscheinlichkeitsregister 316 mit Verwerfungswahrscheinlichkeitswerten besetzt, die den Tokenverfügbarkeitsbereichen entsprechen. Da bei der Auslegung des Netzkantenknotens die Anzahl von Verkehrsklassen bekannt ist, die von dem Netzkantenknoten 102 unterstützt werden, können Standard-Verwerfurigswahrscheinlichkeitsregisterwerte während der Entwicklung vorgesehen werden, um Konfigurations-Overheads zu minimieren.
Das Paketklassifizierungsmodul 302 klassifiziert Pakete in Übereinstimmung mit M Verkehrsklassen, die von dem Netzkantenknoten 102 unterstützt werden. Gemäß der beispielhaften Ausführungsform der Erfindung wird die Eingangsratensteuerung durch die Akzeptanzsteuereinheit 304 ausgeführt, und zwar auf der Basis des Werts des Aktuelle-Tokenverfügbarkeit-Registers 310 im Vergleich mit den Werten der N Grenzwertregister 306, bezogen auf Pakete einer bestimmten Klassenzuordnung. Tatsächliche Pakete einer bestimmten Verkehrsklasse werden nach dem Zufallsprinzip verworfen, wobei die Verwerfungswahrscheinlichkeit in dem entsprechenden Verwerfungswahrscheinlichkeitsregister 316 angegeben ist.
Bei einer Implementierung mit zwei Grenzwertregistersn (N, 1) und zwei Verwerfungswahrscheinlichkeitsregistern erhält man das nachstehende kombinierte Eingangsratensteuerverhalten:

ungeachtet der Anzahl M von Verkehrsklassen, die von dem Netzkantenknoten 102 unterstützt werden. 3 zeigt drei beispielhafte Szenarien der Eingangsratensteuerung in Bezug auf eine allgemeine Implementierung.
Das dargestellte Verfahren der Eingangsratensteuerung stellt den Paketen der höchsten Verkehrsprioritätsklasse so etwas wie einen reservierten Tokenpool zur Verfügung, während der Diensteanbieter gleichzeitig sicherstellt, daß keine Extraressourcen genutzt werden. Das TCP-Verhalten wird durch die Zufälligkeit der probabilistischen Paketverwerfung weiter verbessert.
Pakete können am Eingang auch aus anderen Gründen als der Eingangsratensteuerung verworfen werden, beispielsweise wegen einer unzureichenden Paketspeicherressource im Netzkantenknoten 102 an der Abstromseite des Eingangsports 110. Es ist wichtig, daß Tokens nur dann aus dem Bucket entnommen werden, wenn das Paket letztlich weitergeleitet wird. Dies kann bei der Implementierung einen zentralen Aufseher über die Paketverwerfung erforderlich machen, der als Eingang das Akzeptanzsteuersignal 314 erhält.
Dadurch, daß bei der beispielhaften Ausführungsform der Erfindung die Vielzahl von Tokenverfügbarkeitsgrenzwerten und frühzeitiger Zufallsverwerfung mit Leaky Bucket kombiniert wird mit zufälliger Paketverwerfung bei der Durchführung der Eingangsratensteuerung, während die Tokens in dem Bucket weniger werden, wird während eines großen Bursts von Paketen eine elegantere Unteraussteuerung für TCP-Übertragungen gewährleistet.
Gemäß einer anderen beispielhaften Ausführungsform der Erfindung kann eine Paketverwerfung am Eingang einer Netzzugangseinrichtung 108 unter Anwendung der Leaky-Bucket-Regulierung angewandt werden. Die Vorgehensweise kann bei Produkten angewandt werden, die für ein ökonomisches Modell entwickelt wurden, wobei ein Benutzer 106 "gefräßig" sein darf, aber der Diensteanbieter sich an eine Vereinbarung über die Verbindungsgüte (SLA) hält, die dem Benutzer 106 Bandbreite garantiert, die nicht besser und nicht schlechter als ein vereinbarter Rahmen ist.
Somit stellt die vorliegende Erfindung einen Mechanismus für die Eingangs- und Ausgangsratensteuerung in Paketnetzknoten bereit, der zu Qualität der Diensteunterstützung führt.
Die angegebenen Ausführungsformen sind nur beispielhaft, und für den Fachmann ist ersichtlich, daß Abwandlungen der oben beschriebenen Ausführungsformen möglich sind, ohne vom Umfang der Erfindung abzuweichen. Der Umfang der Erfindung ist ausschließlich durch die beigefügten Patentansprüche definiert.

Claims

Ausgangsratensteuereinrichtung zur Überwachung von Datenverkehr, der von einem Netzkantenknoten eines paketvermittelten Kommunikationsnetzknotens übertragen wird, gekennzeichnet durch a. einen Leaky Bucket, der eine ursprüngliche maximale Anzahl von Tokens hat, die abnimmt, während Pakete mit einer Empfangstokenrate in einem zugehörigen Ausgangspuffer für die Übertragung empfangen werden; b. eine Vielzahl von Tokenverfügbarkeits-Grenzwertregistern, die eine entsprechende Vielzahl von Tokenmengen bezeichnen, die Tokenverfügbarkeitsbereiche definieren; und c. eine Paketübertragungunterdrückungs-Steuereinheit, die die Übertragung eines Pakets, das eine Verkehrsklassenzuordnung hat, selektiv auf der Basis eines aktuellen Tokenverfügbarkeitswerts unterdrückt, der innerhalb eines Tokenverfügbarkeitsbereichs ist, der die Übertragungsunterdrückung von Paketen der Verkehrsklasse bezeichnet.
Ausgangsratensteuereinrichtung nach Anspruch 1, gekennzeichnet durch ein Klassifizierungsmodul, das empfangene Pakete nach Maßgabe einer Vielzahl von Verkehrsklassen klassifiziert.
Ausgangsratensteuereinrichtung nach Anspruch 1, gekennzeichnet durch einen Zeitplaner, der die Paketübertragungszeitplanung in Abhängigkeit von einem Paketübertragungunterdrückungssignal verzögert, das von der Paketübertragungunterdrückungs-Steuereinheit abgegeben wird.
Ausgangsratensteuereinrichtung nach Anspruch 1, gekennzeichnet durch ein Bucketgrößenregister, das einen Wert hält, der für eine maximale Anzahl von dem Leaky Bucket zugewiesenen Tokens repräsentativ ist.
Ausgangsratensteuereinrichtung nach Anspruch 4, gekennzeichnet durch einen Ausgangspuffer, wobei die Größe des Leaky Bucket, ausgedrückt in Tokens, höchstens gleich der Größe des Ausgangspuffers ist, wobei die Verwendung eines Ausgangspuffers, der größer als der Leaky Bucket ist, die Unterdrückung einer Paketübertragung ohne Verwerfen von Paketen zuläßt.
Ausgangsratensteuereinrichtung nach Anspruch 1, dadurch gekennzeichnet, daß die Ausgangsratensteuereinrichtung einem Ausgangsport des Netzkantenknotens zugeordnet ist.
Kommunikationsnetzknoten, dadurch gekennzeichnet, daß er mindestens eine Eingangsratensteuereinrichtung nach Anspruch 1 aufweist.
Kommunikationsnetzknoten, dadurch gekennzeichnet, daß er mindestens eine Eingangsratensteuereinrichtung nach Anspruch 1 aufweist, die mindestens einem Ausgangsport davon zugeordnet ist.
Eingangsratensteuereinrichtung zur Überwachung von Datenverkehr, der an einem Netzkantenknoten eines paketvermittelten Kommunikationsnetzknotens empfangen wird, gekennzeichnet durch a. einen Leaky Bucket, der eine ursprüngliche maximale Anzahl von Tokens hat, die abnimmt, während mit einer Empfangstokenrate empfangene Pakete akzeptiert werden; b. eine Vielzahl von Tokenverfügbarkeits-Grenzwertregistern, die eine entsprechende Vielzahl von Tokenmengen bezeichnen, die Tokenverfügbarkeitsbereiche definieren; c. eine Vielzahl von Paketverwerfungs-Wahrscheinlichkeitsregistern, wobei jedes Paketverwerfungs-Wahrscheinlichkeitsregister eine Wahrscheinlichkeit bezeichnet, mit der Pakete einer bestimmten Verkehrsklasse zu verwerfen sind, wenn ein aktueller Tokenverfügbarkeitswert innerhalb eines Tokenverfügbarkeitsbereichs ist; und d. eine Paketakzeptanzsteuereinheit, die selektiv zufällig Pakete, die eine Verkehrsklassenzuordnung haben, darauf basierend verwirft, daß der aktuelle Tokenverfügbarkeitswert innerhalb eines Tokenverfügbarkeitsbereichs ist, der eine zufällige Paketverwerfung von Paketen der Verkehrsklasse bezeichnet.
Eingangsratensteuereinrichtung nach Anspruch 9, gekennzeichnet durch ein Klassifizierungsmodul, das empfangene Pakete in Abhängigkeit von einer Vielzahl von Verkehrsklassen klassifiziert.
Eingangsratensteuereinrichtung nach Anspruch 9, gekennzeichnet durch ein Bucketgrößenregister, das einen Wert hält, der für eine maximale Anzahl von dem Leaky Bucket zugewiesenen Tokens repräsentativ ist.
Eingangsratensteuereinrichtung nach Anspruch 9, gekennzeichnet, durch einen Eingangspuffer, wobei die Größe des Leaky Bucket, ausgedrückt in Tokens, höchstens gleich der Größe des Eingangspuffers ist und die Verwendung eines Eingangspuffers, der größer als der Leaky Bucket ist, eine Verkehrsschwäche in Bezug auf die Anzahl von für die Übertragung verfügbaren Paketen ermöglicht, um die Auswirkungen der durchgeführten Eingangsratensteuerung zu maskieren.
Eingangsratensteuereinrichtung nach Anspruch 9, dadurch gekennzeichnet, daß die Eingangsratensteuereinrichtung einem Eingangsport des Netzkantenknotens zugeordnet ist.
Kommunikationsnetzknoten, dadurch gekennzeichnet, daß er mindestens eine Eingangsratensteuereinrichtung nach Anspruch 9 aufweist.
Kommunikationsnetzknoten, dadurch gekennzeichnet, daß er mindestens eine Eingangsratensteuereinrichtung nach Anspruch 9 aufweist, die mindestens einem Eingangsport davon zugeordnet ist.
Verfahren zur Durchführung einer Ausgangsratensteuerung, gekennzeichnet durch die folgenden Schritte: selektives Unterdrücken der Paketübertragung für ein Paket einer bestimmten Verkehrsklasse, wenn ein aktueller Tokenverfügbarkeitswert eines Leaky Bucket, der Paketübertragungen verfolgt, zwischen zwei Tokenverfügbarkeitsgrenzwerten von einer Vielzahl von Tokenverfügbarkeitsgrenzwerten liegt.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 16, wobei die Paketübertragung selektiv unterdrückt wird, dadurch gekennzeichnet, daß das Verfahren ferner den Schritt aufweist: selektives Unterdrücken der Paketübertragungszeitplanung.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 17, gekennzeichnet durch den Schritt: neue Zeitplanung für die Übertragung des Pakets.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 16, gekennzeichnet durch einen vorhergehenden Schritt: Klassifizieren von Paketen nach Maßgabe einer Vielzahl von Verkehrsklassen.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 16, gekennzeichnet durch einen Schritt: a. Feststellen, ob in dem Leaky Bucket eine Vielzahl von Tokens entsprechend einer Größe des Pakets verfügbar ist; und b. selektives Unterdrücken der Paketübertragung, wenn in dem Leaky Bucket eine unzureichende Menge an Tokens verfügbar ist.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 20, wobei die Paketübertragung selektiv unterdrückt wird, gekennzeichnet durch einen Schritt: selektives Unterdrücken der Paketübertragungszeitplanung.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 21, gekennzeichnet durch einen Schritt: Speichern des Pakets in einem Ausgangspuffer.
Verfahren zur Durchführung der Ausgangsratensteuerung nach Anspruch 21, gekennzeichnet durch einen Schritt: neue Zeitplanung für die Übertragung des Pakets.
Verfahren zur Durchführung einer Eingangsratensteuerung, gekennzeichnet durch den folgenden Schritt: selektives zufälliges Verwerfen von Paketen einer bestimmten Verkehrsklasse, wenn ein aktueller Tokenverfügbarkeitswert eines Pakete verfolgenden Leaky Bucket zwischen zwei Tokenverfügbarkeits-Grenzwerten von einer Vielzahl von Tokenverfügbarkeits-Grenzwerten ist.
Verfahren zur Durchführung der Eingangsratensteuerung nach Anspruch 24, wobei Pakete zufällig verworfen werden, gekennzeichnet durch einen Schritt: zufälliges Verwerfen von Paketen mit einer entsprechenden Verwerfungswahrscheinlichkeit.
Verfahren zur Durchführung der Eingangsratensteuerung nach Anspruch 24, gekennzeichnet durch einen vorhergehenden Schritt: Klassifizieren von Paketen nach Maßgabe einer Vielzahl von Verkehrsklassen. Verfahren zur Durchführung der Eingangsratensteuerung nach Anspruch 24, gekennzeichnet durch einen Schritt: a. Feststellen, ob eine Vielzahl von Tokens, die einer Größe des Pakets entsprechen, in dem Leaky Bucket verfügbar ist; und b. selektives Verwerfen des Pakets, wenn in dem Leaky Bucket eine ungenügende Menge an Tokens verfügbar ist.