DE102006015046B4

DE102006015046B4 - Verfahren und Vorrichtung zur Datenverkehrsglättung

Info

Publication number: DE102006015046B4
Application number: DE102006015046A
Authority: DE
Inventors: Oliver Dr. 85221 Veits
Original assignee: Siemens AG
Current assignee: Unify GmbH and Co KG
Priority date: 2006-03-31
Filing date: 2006-03-31
Publication date: 2011-08-18
Anticipated expiration: 2026-04-01
Also published as: US20090168792A1; DE102006015046A1; WO2007113013A1; EP2002611A1; CN101427529B; US7965723B2; CN101427529A

Abstract

Verfahren zur Datenverkehrsglättung für eine Mehrzahl weiterzuleitender Datenpakete, umfassend folgende Schritte: a1) Zwischenspeicherung eintreffender Datenpakete, b) Weiterleitung zwischengespeicherter Datenpakete anhand eines Warteschlangenverfahrens zur Datenverkehrsglättung, dadurch gekennzeichnet, a2) dass vor der Weiterleitung eines Datenpakets an ein mit einem Netzelement verbundenes Übertragungselement ermittelt wird, welche Datenpaketlänge das weitergeleitete Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt, wobei die Verwaltungsinformation von dem verbundenen Übertragungselement hinzugefügt wird, a3) dass die Weiterleitung des Datenpakets vom Netzelement in Abhängigkeit von der gemäß Schritt a2) ermittelten Datenpaketlänge erfolgt.

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Datenverkehrsglättung.
Im Stand der Technik sind bereits Verfahren und Vorrichtungen zur Datenverkehrsglättung bzw. »Traffic Shaping« bekannt. Ein Ziel solcher Verfahren ist eine Regulierung einer Datenübertragungsrate mit dem Ziel einer möglichst kontinuierlichen Datenübermittlung ohne Verluste.
Ein Einsatz solcher Verfahren zur Datenverkehrsglättung empfiehlt sich beispielsweise bei einer Weiterleitung von Datenpaketen über Netzelemente wie z. B. Router. An einem Eingang eines solchen Netzelements mit einer variablen Datenübertragungsrate eintreffende Datenpakete werden dabei auf einen Ausgang der Vorrichtung so übergeben, dass die ausgangsseitige Datenübertragungsrate im Idealfall konstant, zumindest aber nach oben begrenzt ist.
Bei derartigen Netzelementen tritt oftmals der Fall auf, dass eingangsseitig eintreffende Datenpakete mit hoher Datenübertragungsrate eintreffen, während ausgangsseitig nur eine niedrigere Datenübertragungsrate realisierbar oder erlaubt ist. Das Netzelement verfügt hierbei über einen Pufferspeicher zur Zwischenspeicherung von Datenpaketen bis zu ihrer Weiterleitung.
Eine ausgangsseitig geforderte niedrigere Datenübertragungsrate kann z. B. durch ein mit dem Netzelement verbundenes Übertragungselement geboten sein, welches nur eine begrenzte Datenübertragungsrate verarbeiten kann.
Ein bekanntes Verfahren zur Datenverkehrsglättung ist das Token-Bucket-Verfahren. Zur Implementierung dieses Verfahrens mittels einer entsprechenden Software ist eine periodische Erzeugung von »Tokens« vorgesehen, die bildlich in einen Eimer (»Bucket«) fallen. Das Verfahren sieht vor, dass für ein im Eimer befindliches Token eine bestimmte Anzahl von Datenpakete die Vorrichtung passieren darf, wobei das Token mit dem Passieren der vorgesehenen Anzahl von Datenpaketen gelöscht bzw. aus dem Eimer entfernt wird. Die Anzahl von Datenpaketen, die die Vorrichtung pro Token passieren darf, entspricht einer Datenpaketübertragungsrate. Diese ist üblicherweise durch Veränderung der zeitlichen Periode neu erzeugter Tokens einstellbar.
Die bisher bekannten Maßnahmen zur Verkehrsglättung an einem Netzelement weisen unter anderem ein Problem dahingehend auf, dass keine Einstellung einer Datenpaketübertragungsrate optimal für alle Datenpaketlängen ist.
Dieses Problem wird anschaulicher mit der Betrachtung des eingangs genannten, mit dem Netzelement verbundenen Übertragungselements, welches nur eine begrenzte Datenübertragungsrate verarbeiten kann. Die Begrenzung ergibt sich beispielsweise durch eine geforderte begrenzte Datenübertragungsrate am Ausgang des Übertragungselements, welche somit auch auf den mit dem Netzelement verbundenen Eingang des Übertragungselements rückwirkt. Derartige Übertragungselemente sehen ein Verwerfen von Datenpaketen vor, wenn die eintreffende Datenübertragungsrate die zulässige ausgangsseitige Datenübertragungsrate zu überschreiten droht. Verworfene Datenpakete werden dabei nicht an den Ausgang weitergeleitet, sondern stattdessen gelöscht.
Wird im Übertragungselement eine Protokollkonvertierung durchgeführt, werden die empfangenen Datenpakete in bekannter Weise vor deren Weiterleitung mit weiteren Datenverwaltungsteilen versehen, welche in der Fachwelt auch als >>Overhead<< bezeichnet wird.
Bestandteil der Protokollkonvertierung kann dabei zusätzlich ein Wechsel in der Übertragungsweise sein. Zum Beispiel kann die mit den Datenpaketen zu transportierende Nutzinformation der am Übertragungselement eintreffenden Datenpakete variabler Datenpaketlänge so umgeschichtet werden, dass am Ausgang des Übertragungselements ausschließlich Datenpakete mit konstanter Datenpaketlänge vorgesehen sind. Für eintreffende Datenpakete, deren Länge niedriger ist als die der konstanten Länge ausgehender Datenpakete, ist dagegen eine Auffüllung mit arbiträren Füllbits vorgesehen, welche keine Informationen beinhalten. Dieser Vorgang des Auffüllens wird in der Fachwelt auch als »Padding« bezeichnet. Auch diese Füllbits sind Datenverwaltungsteile und somit ein Overhead gegenüber der mit den Datenpaketen zu transportierenden Nutzinformation. Die Nutzinformation eines Datenpakets wird in der Fachwelt auch als >>Payload<< bezeichnet.
Die im Übertragungselement zu einem Datenpaket hinzugefügten Datenverwaltungsteile, z. B. Füllbits, Header oder Trailer, bewirken also eine ausgangsseitige Datenübertragungsrate, welche aufgrund der unterschiedlichen Länge der Datenpakete nicht proportional zur am Netzelement einstellbaren Datenpaketübertragungsrate ist.
In der Druckschrift von BLOUIN, Francois; DRWIEGA, Tadeusz; MISTRY, Nalin [u. a.]: Performance Evaluation of Rate Control and QoS Capabilities of GRAS. IEEE Communications Society Globecom Workshops, 2004, Seiten 293–301, ist ein Broadband Remote Access Server (GRAS) offenbart, in dem Maßnahmen zur Datenverkehrsglättung getroffen werden. Der GRAS ist dabei in der Lage, Verwaltungsinformationen einer Protokollwandlung unmittelbar zu verwenden, da die Protokollwandlung in diesem GRAS selbst stattfindet.
In US 6,757,249 B1 ist ein Verfahren beschrieben, bei dem Paket-Header-Information und Paketgröße-Information zu einer oder mehreren Pipeline-Stufen dargestellt werden, wobei die Paket-Header-Information und die Paket-Größe-Information einem Paket entsprechen. Danach wird innerhalb einer Stufe der Pipeline mit der Paket-Header-Information die Ausgangkapazität für das Paket festgestellt. Nachfolgend wird innerhalb einer Stufe der Pipeline die Ausgangkapazität mit der Paketgröße verglichen zur Bestimmung der passenden Verzögerung für das Paket.
Damit ist das eingangs dargestellte Problem verständlich, dass keine Einstellung einer Datenpaketübertragungsrate optimal für alle Datenpaketlängen ist. Bei einer gegebenen Datenpaketübertragungsrate des Netzelements ist der im Übertragungselement erzeugte Overhead für niedrige Datenpaketlängen höher als der für höhere Datenpaketlängen erzeugte Overhead. Eine »vorsichtige« niedrige Einstellung der Datenpaketübertragungsrate, welche ein regelmäßiges hohes Aufkommen – oder auch unregelmäßig auftretende Peaks – von Datenpaketen mit einer niedrigen Datenpaketlänge erwartet, würde bei Datenpaketen mit einer hohen Datenpaketlänge zu einer ineffizienten Auslastung des Datendurchsatzes führen. Umgekehrt könnte man für Datenpakete großer Datenpaketlänge am Netzelement eine höhere Datenpaketübertragungsrate einstellen, während die selbe Datenpaketübertragungsrate bei niedrigen Datenpaketlängen zu einem Verwerfen von Datenpaketen führen würde.
Aufgabe der Erfindung ist es, ein Verfahren anzugeben, mit dem mit einfachen Mitteln eine effiziente Datenverkehrsglättung zu erreichen ist, welche nicht von der Datenpaketlänge der weitergegebenen Datenpakete abhängt.
Eine Lösung der Aufgabe erfolgt durch ein Verfahren mit den Merkmalen des Patentanspruchs 1.
Die Erfindung bildet ein bekanntes Verfahren zur Datenverkehrsglättung dahingehend weiter, dass ein Overhead in Form von Verwaltungsinformationen berücksichtigt wird, welcher in einer später erfolgenden Protokollkonvertierung an das Datenpaket angehängt wird.
Das Verfahren, auf dem mit den erfindungsgemäßen Mitteln aufgebaut wird, sieht eine Zwischenspeicherung und Weiterleitung eintreffender Datenpakete anhand eines Warteschlangenverfahrens vor. Ein solches Warteschlangenverfahren ist beispielsweise nach dem Prinzip eines FIFO (>>First In First Out<<) konzipiert und sieht eine gesteuerte Weiterleitung von Datenpaketen gemäß einer vorgebbaren Datenpaketübertragungsrate vor. Die Datenpaketübertragungsrate entspricht dabei einer Anzahl weitergeleiteter Datenpakete pro Zeiteinheit.
Die erfindungsgemäße Weiterbildung dieses Verfahrens löst das Problem unterschiedlicher Datenpaketlängen damit, dass vor Weiterleitung eines Datenpakets an ein mit einem Netzelement verbundenes Übertragungselement ermittelt wird, welche Datenpaketlänge das Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt, wobei die Verwaltungsinformationen von dem verbundenen Übertragungselement hinzugefügt werden. Diese Protokollkonvertierung wird zu einem späteren Zeitpunkt, also nach seiner Weiterleitung, beispielsweise von einem nach einem betrachteten Netzelement angeordneten Übertragungselement vorgenommen. Die Weiterleitung des Datenpakets vom Netzelement erfolgt erfindungsgemäß in Abhängigkeit von der ermittelten zu erwarteten Datenpaketlänge.
Dies bedeutet beispielsweise, dass mehrere Datenpakete mit niedriger Datenpaketlänge wegen eines zu erwartenden höheren Overheads nicht so schnell weitergeleitet werden, wie nach aus dem Stand der Technik bekannten Verfahren zur Datenverkehrsglättung zu erwarten wäre. Damit wird einem Datenverlust vorgebeugt.
Umgekehrt können mit den erfindungsgemäßen Mitteln Datenpakete mit hoher Datenpaketlänge wegen eines oben erklärten zu erwartenden niedrigeren Overheads genau so schnell oder sogar schneller weitergeleitet werden, wie nach aus dem Stand der Technik bekannten Verfahren zur Datenverkehrsglättung zu erwarten wäre.
Das erfindungsgemäße Verfahren ist also von der Idee getragen, dass nicht die aus Sicht des die Datenverkehrsglättung durchführenden Netzelements gemessene Datenübertragungsrate das einzustellende Kriterium ist, sondern die Datenübertragungsrate, die man nach der Protokollkonvertierung messen würde. Um eine solche Datenübertragungsrate einzustellen, werden die bekannten Mittel zur Datenverkehrsglättung beibehalten und erfindungsgemäß verfeinert, indem die Datenpaketlänge in einer nachfolgenden Protokollkonvertierung mit einbezogen wird.
Die Aufgabe wird in analoger Weise durch Einsatz einer Vorrichtung mit den Merkmalen des nebengeordneten Patentanspruchs 5 gelöst.
Ein wesentlicher Vorteil der erfindungsgemäßen Mittel ist darin zu sehen, dass ein zu erreichender Datendurchsatz unabhängig von einer Datenpaketgröße verbessert wird. Mit den bisher bekannten Verfahren musste zur Vermeidung eines Datenpaketverlustes eine »vorsichtige« niedrige Einstellung der Datenpaketübertragungsrate eingestellt werden, welche ein regelmäßiges hohes Aufkommen – oder auch unregelmäßig auftretende Peaks – von Datenpaketen mit einer niedrigen Datenpaketlänge erwartet. Eine solche niedrige Einstellung der Datenpaketübertragungsrate führte bei Datenpaketen mit einer hohen Datenpaketlänge zu einer ineffizienten Auslastung des Datendurchsatzes.
Ein weiterer wesentlicher Vorteil der erfindungsgemäßen Mittel besteht darin, dass mit dessen Anwendung bei einem hohen Aufkommen von Datenpaketen mit niedrigen Datenpaketlängen ein Verwerfen von Datenpaketen ausgeschlossen wird.
Weitere Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Eine Ausgestaltung der Erfindung betrifft die Realisierung des bekannten Warteschlangenverfahrens auf Basis von periodisch erzeugten Tokens, beispielsweise gemäß einem bekannten Token-Bucket-Verfahren. Ein Token wird nach einer Weiterleitung einer einstellbaren Anzahl von in der Warteschlange wartenden Datenpaketen gelöscht. Alternativ wird ein Token nach Weiterleitung einer einstellbaren Datenmenge gelöscht, beispielsweise bei Weiterleitung von 1 kByte. Periodisch erzeugte Tokens bilden bei einem geringen Datendurchsatz einen >>Vorrat<< für eine Datenpaketübertragungsrate bei einem anwachsenden Datendurchsatz.
Eine vorteilhafte Ausgestaltung der Erfindung betrifft die Ermittlung der hinzugefügten Verwaltungsinformation und damit der Datenpaketlänge, welche das Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt. Gemäß einer Ausgestaltung der Erfindung ist mindestens ein Parameter einstellbar. Hierbei ist zu beachten, dass der Umfang der zu erwartenden hinzugefügten Verwaltungsinformation keine feste Größe darstellt, sondern – wie erläutert – eine Funktion der ursprünglichen Datenpaketlänge ist. Diese Funktion ist zwar üblicherweise linear, jedoch nicht notwendigerweise proportional zur ursprünglichen Datenpaketlänge. Neben einem proportionalen Anteil tritt noch ein konstanter Parameter zu dieser Funktion hinzu, der sich aus einer am Anfang oder Ende des konvertierten Datenpakets angehängten Verwaltungsinformation ergibt. Eine solche anfangsseitig bzw. endseitig angeordnete Verwaltungsinformation wird oftmals auch als Header bzw. Trailer bezeichnet und kann unter anderem eine Prüfsumme zur Nachprüfbarkeit der Datenvollständigkeit des Datenpakets enthalten. Gemäß einer anderen Ausgestaltung der Erfindung wird der Parameter von der nachfolgenden Einheit übermittelt, also beispielsweise der Übertragungseinheit. Da die Art der dortigen Protokollkonvertierung üblicherweise für einen längeren Zeitraum gleich bleibt, ist eine regelmäßige Abfrage üblicherweise nicht notwendig.
Eine dingliche Ausgestaltung der Erfindung sieht ein Netzelement zur Ausführung des erfindungsgemäßen Verfahrens vor, das als Router ausgestaltet zur Anbindung eines Rechners an eine Breitbandverbindung bzw. DSL-Verbindung dient. Das Übertragungselement ist dabei beispielsweise ein separates DSL-Modem, das alternativ mit dem Router eine Einheit bildet.
Ein Ausführungsbeispiel mit weiteren Vorteilen und Ausgestaltungen der Erfindung wird im folgenden anhand der Zeichnung näher erläutert.
Dabei zeigen:
1: ein Strukturbild zur schematischen Darstellung einer Verbindung eines Rechners über ein Netzelement mit einem Übertragungselement;
2: ein Strukturbild zur schematischen Darstellung einer Mehrzahl von Protokollkonvertierungen eines Datenpakets;
3: ein Strukturbild zur schematischen Darstellung einer unterschiedlichen Auswirkung angehängter Verwaltungsinformation an Datenpakete mit unterschiedlichen Datenpaketlängen; und
4: eine bildliche Darstellung eines erfindungsgemäß modifizierten Token-Bucket-Verfahrens.
Das erfindungsgemäße Verfahren wird im Folgenden beispielhaft anhand einer DSL-Verbindung (Digital Subscriber Line) dargestellt. Eine solche Art einer Breitbandverbindung wird auch im häuslichen Bereich zunehmend, neben einer Datenkommunikation, auch zur Sprachkommunikation verwendet. Eine Sprachkommunikation über paketorientierte Datennetzwerke wird häufig auch als VoIP bzw. >>Voice Over Internet Protocol<< bezeichnet.
Für eine paketorientierte Sprachkommunikation müssen im Allgemeinen Datenpakete, welche die Sprachinformation enthalten, mit einer höheren Priorität zwischen dem Rechner bzw. Telefon und dem verbundenen Datennetzwerk ausgetauscht werden als Datenpakete, welche für eine Datenkommunikation dienen. Zwar sind im Stand der Technik Mittel bekannt, mit denen Datenpakete für eine Sprachkommunikation als zeitkritisch charakterisiert sind, indem diese eine entsprechende Identifikationsbezeichnung enthalten, jedoch hat sich eine derartige Differenzierung von Verkehrsklassen (Sprach- bzw. Datenkommunikation) bislang nicht in allen Kommunikationskomponenten durchgesetzt.
1 zeigt einen Rechner PC, welcher über eine erste Verbindung 1 mit einem Router ROU verbunden ist. Der Router ROU ist über eine zweite Verbindung 2 mit einem Modem MOD verbunden, welches seinerseits über eine dritte Verbindung 3 mit einem paketorientiertem Netzwerk NW verbunden ist. Der Router ROU entspricht einem Netzelement im Sinne der vorhergehenden Ausführungen.
Die zweite Verbindung 2, über die der Router ROU mit dem Modem MOD verbunden ist, ist üblicherweise als Fast Ethernet ausgestaltet. Eine solche Verbindungsweise bzw. Protokoll gewährleistet eine maximale Datenübertragungsrate von 100 MBit/s. Die Datenübertragungsrate der dritten DSL-Verbindung 3 zwischen dem Modem MOD und dem paketorientierten Netzwerk NW, ist je nach Ausgestaltung der Verbindung 3 um ein vielfa ches niedriger zu halten. Diese Bandbreite wird daher im folgenden auch als Flaschenhals oder >>Bottleneck<<-Bandbreite bezeichnet, da sie bei einer DSL-Verbindung ein limitierender Faktor für die Datenkommunikation ist.
Datenpakete, welche auf der zweiten Verbindung 2, die durch die dritte Verbindung 3 begrenzte Datenübertragungsrate überschreiten, würden daher im Modem MOD verworfen, d. h. gelöscht werden. Um diesen Datenverlust zu vermeiden, ist im Router ROU, also ein Netzelement im Sinne der Erfindung, ein Verfahren zur Datenverkehrsglättung implementiert, welche die Datenpaketübertragungsrate in Richtung des verbundenen Übertragungselements, d. h. Modem MOD begrenzt. Die bereits erwähnte Bevorzugung von Datenpaketen, welche Sprachkommunikation enthalten, führt ebenfalls zu einer Notwendigkeit einer Datenverkehrsglättung.
Ein üblicherweise im Router ROU implementiertes Verfahren zur Datenverkehrsglättung bzw. Traffic Shaping, sieht eine Implementierung eines Token-Bucket-Algorithmus vor. Dabei wird am Router ROU eine feste Datenpaketübertragungsrate eingestellt, mit der Datenpakete an das Modem MOD gesendet werden dürfen. Dabei hat sich gezeigt, dass es keine fest einzustellende Datenpaketübertragungsrate gibt, welche für alle Datenpaketlängen gleichermaßen geeignet wäre. Bei Datenpaketen mit einer hohen Datenpaketlänge wirken sich zusätzlich angehängte Verwaltungsinformationen (Overhead) nicht so stark aus wie im Fall von Datenpaketen mit niedriger Datenpaketlänge. Für Datenpakete mit hoher Datenpaketlänge ist daher eine höhere Datenpaketrate zulässig, während dieselbe Datenpaketübertragungsrate bei Datenpaketen mit niedriger Datenpaketlänge zu Datenpaketverlusten im Modem MOD führt.
Dieser Effekt wird im Folgenden anhand von 3 gezeigt. Die 3 zeigt ein erstes Datenpaket P1.1, mit einem Nutzdatenteil PL (>>Payload<<). Dieses Datenpaket wird P1.1 einer Protokollkonvertierung unterworfen. Das nach der Protokollkonvertierung resultierende Datenpaket P1.2 weist einen zusätzlichen – schraffiert dargestellten – Nachrichtenkopfeintrag oder Header HD1.2 auf. Der Header HD1.2 wird durch die entsprechende Protokollkonvertierung an das ursprüngliche Datenpaket P1.1 hinzugefügt.
Weiterhin sind zwei zweite Datenpakete P2.1 gezeigt, die bezüglich ihrer Datenpaketlänge um ein vielfaches kleiner als das erste Datenpaket P1.1 sind. Eine entsprechende Protokollkonvertierung führt zur Hinzufügung eines zweiten Headers HD2.2, welcher bezüglich seiner Größe mit dem ersten Header HD1.2 übereinstimmt. Die gesamten Verwaltungsinformationen, hier die angehängten Header HD2.2, übersteigen bei kurzen Datenpaketen den relativen Anteil von Verwaltungsinformationen bei langen Datenpaketen.
Im folgenden wird unter weiterer Bezugnahme auf die Funktionseinheiten der jeweils vorhergehenden Figuren eine Protokollkonvertierung näher erläutert.
2 zeigt eine Mehrzahl von Protokollkonvertierungen, welche auf ein erstes Datenpaket 1 ausgeübt werden. Das erste Datenpaket 1 besteht aus einem Nutzdatenanteil PL mit einer Länge von 1452 Byte und einem ersten Header HD1 mit einer Länge von 20 Byte. Der erste Header HD1 wird durch das Protokoll TCP (>>Transmission Control Protocol<<) eingefügt.
In einem zweiten Schritt 2 wird ein zweiter Header HD2 mit einem Umfang von 20 Byte eingefügt. Der zweite Header HD2 wird im Zuge einer Protokollkonvertierung in das Protokoll IP (>>Internet Protocol<<) hinzugefügt.
In einer weiteren dritten Protokollkonvertierung 3 wird ein dritter Header HD3, entsprechend dem PPP (Point to Point Protocol) mit einem Umfang von 5 Byte eingefügt. Zusätzlich ist in diesem Protokoll die Einfügung eines dritten Trailers TR3 vorgesehen. Ein Trailer ist ein Datenverwaltungsteil, der an das Ende eines Datenpakets angefügt wird. Der Trailer enthält üblicherweise Informationen zum Erkennen und Korrigieren von Übertragungsfehlern. Eine solche Information unterstützt beispielsweise eine zyklische Redundanzprüfung bzw. CRC, >>Cyclic Redundancy Check<<.
In einer vierten Protokollkonvertierung 4 wird ein vierter Header HD4 mit einem Umfang von 14 Bytes eingefügt. Weiterhin wird ein vierter Trailer TR4 mit einem Umfang von 4 Byte an das Ende des Datenpakets angehängt. Die entsprechende Protokollkonvertierung führt zu einem Ethernet Frame.
Eine fünfte Protokollkonvertierung 5 führt zu einem ATM-Protokoll (Asynchronous Transfer Mode), bei dem einer Aufteilung des Datenpakets in mehrere Zellen mit einer konstanten Länge von 53 Byte vorgesehen ist. Der Nutzdatenteil des PL des vormaligen Datenpakets mit einer in weiten Bereichen variablen Länge, wird aufgeteilt in mehrere Nutzdatenteile PL mit einer konstanten Länge von 48 Bytes. Jedem Nutzdatenanteil PL von 48 Byte ist dabei ein Header HD5 mit einem Umfang von 5 Byte vorangestellt. Datenpakete mit einer festgelegten Länge werden üblicherweise als Frames bezeichnet. An das Ende des letzten Frames wird noch ein Trailer angehängt, der in der Zeichnung nicht dargestellt ist.
Das ATM-Protokoll entspricht dem Protokoll, welches auf der aus 1 erläuterten dritten Verbindung 3 in einer so genannten >>AAL5<< betrieben wird. AAL (Asynchronous Transfer Mode Adaption Layer) bezeichnet eine Dienstklasse für eine Datenübertragung. Die fünfte Dienstklasse AAL5 wird benutzt, um Datenpakete über ATM-Netze zu übertragen. Beispielsweise überträgt das DSL-Modem MOD Daten mittels AAL5 zum DSLAM.
Der Anteil der durch die Protokollkonvertierung hinzugefügten Header erhöht die Länge des Datenpakets, gemessen zur ursprünglichen Dateilänge, in einer im wesentlichen proportionalen Weise. Demgegenüber verursacht ein angehängter Trailer im wesentlichen eine Hinzufügung eines pro Datenpaket konstanten Anteils, so dass Datenpakete unterschiedlicher Größe um einen konstanten Anteil verlängert werden.
Die im Modem MOD durchgeführte Protokollkonvertierung in das ATM-Protokoll verursacht also sowohl einen von der Datenpaketlänge unabhängigen konstanten Anteil als auch einen von der Datenpaketlänge proportional abhängigen Anteil.
Das erfindungsgemäße Verfahren, welches im Beispiel der 1 im Router ROU implementiert ist, sieht nun eine Bestimmung vor, welche Datenpaketlänge ein jeweiliges Datenpaket in einer Warteschlange nach Passieren des Modems MOD einschließlich der an das Datenpaket angehängten Verwaltungsinformation haben wird. Die Verwaltungsinformation setzt sich dabei aus einem konstanten Anteil, welcher durch einen ATM-Schicht-3-Header verursacht wird und einem proportionalen Anteil, welcher durch einen Schicht-2-Header verursacht wird, zusammen.
Erfindungsgemäß wird im Router ROU vor der Weiterleitung eines Datenpakets an das Modem MOD ermittelt, welche Datenpaketlänge das Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt.
Die Ermittlung der Länge der hinzugefügten Verwaltungsinformation erfolgt beispielsweise auf Basis mindestens eines einstellbaren und/oder übermittelbaren Parameters. Dieser Parameter wird beispielsweise in einer Rechenvorschrift benutzt, welche den durch die Protokollkonvertierung zu erwartenden Overhead in Abhängigkeit von der ursprünglichen Datenpaketlänge liefert.
Bei hinreichender Genauigkeit sind beispielsweise zwei Parameter einstellbar, wobei ein erster Parameter den konstanten Anteil einer Verwaltungsinformationslänge und ein zweiter Parameter einen proportionalen Anteil charakterisiert, wobei letzterer von der ursprünglichen Datenpaketlänge abhängt.
Alternativ zu einer Einstellung ist auch eine Übermittlung des mindestens einen Parameters vom Modem MOD an den Router ROU von Vorteil.
Im Anschluss wird pro Datenpaket ein relativer Overhead bestimmt, der sich aus einem Quotienten zwischen der errechneten Verwaltungsinformation und der errechneten Datenpaketlänge nach Protokollkonvertierung ergibt.
Mit der so berechneten Datenpaketlänge wird das Warteschlangenverfahren – das beispielsweise gemäß dem bekannten Token-Bucket-Verfahren ausgestaltet ist – zur Datenverkehrsglättung im Router ROU modifiziert.
4 zeigt eine bildlich zu verstehende Darstellung eines erfindungsgemäß modifizierten Token-Bucket-Verfahrens. Zur Implementierung dieses Verfahrens mittels einer entsprechenden Software ist eine periodische Erzeugung von Tokens TK durch eine bildlich zu verstehende Erzeugungseinheit GE vorgesehen, wobei die Tokens nach ihrer Erzeugung in einen bildlichen Eimer BU fallen und somit für den Fall, dass zunächst keine Weiterleitung von Datenpaketen erfolgt, einen Vorrat bilden.
Das bislang bekannte Token-Bucket-Verfahren sieht vor, dass für ein im Eimer BU befindliches Token TK eine bestimmte Anzahl von Datenbytes die Vorrichtung passieren darf, wobei das Token TK mit dem Passieren der vorgesehenen Anzahl von Datenbytes gelöscht bzw. aus dem Eimer BU entfernt wird. Die Anzahl von Datenbytes, die die Vorrichtung pro Token passieren darf, entspricht einer Datenübertragungsrate.
Erfindungsgemäß wird dieses Verfahren dahingehend verbessert, dass bei Eintreffen eines Datenpakets P1 an einem – nicht dargestellten – Eingang des Routers ROU nach den obigen Maßgaben berechnet wird, welche Länge das Datenpaket P1 nach einem Durchlaufen des nachfolgenden Modems MOD einschließlich aller Verwaltungsinformationen haben wird. Diese Länge ist in einem bildlich zu verstehenden zweiten Datenpaket P2 an der rechten Seite des Eimers dargestellt, wobei die Verwaltungsinformationen gestrichelt dargestellt sind. Das zweite Datenpaket P2 ist insofern fiktiv, da es nur als rechnerische Größe bezüglich der gesamten Datenpaketlänge behandelt wird und erst nach einer Protokollkonvertierung im Modem MOD mit dieser Datenpaketlänge vorliegt. Das erste Datenpaket P1 liegt im Gegenzug als reales, weiterzuleitendes Datenpaket P1 im Router ROU vor.
Das fiktive zweite Datenpaket P2 ist bildlich mit Tokens TK >>gefüllt<<. Mit dieser bildlichen Darstellung wird symbolisiert, dass die Weiterleitung des Datenpakets P1 in Abhängigkeit von der vorausgehend ermittelten Datenpaketlänge erfolgt, indem die Löschung von Tokens TK entsprechend der zu erwartenden Länge des Datenpaket P2 erfolgt.
Übersteigt die Datenpaketlänge des fiktiven zweiten Datenpakets P2 den Restinhalt des Eimers BU, wird das Datenpaket P1 erst gesendet, wenn der Eimer BU eine hinreichende Anzahl von Tokens TK aufweist. Im anderen Fall wird das Datenpaket P1 gesendet und die Datenpaketlänge des fiktiven zweiten Datenpakets P2 vom Inhalt des Token Bucket abgezogen. Diese abgezogene Datenpaketlänge wird in der Zeichnung durch die Tokens TK symbolisiert, mit denen das zweite Datenpaket P2 gefüllt ist.
Das erfindungsgemäße Verfahren hat insbesondere den Vorteil, dass sowohl für niedrige als auch für hohe Datenpaketlängen eine Quality of Service sichergestellt ist und sowohl für niedrige als auch für hohe Datenpaketlängen die volle Bandbreite der DSL-Verbindung voll nutzbar ist.

Claims

Verfahren zur Datenverkehrsglättung für eine Mehrzahl weiterzuleitender Datenpakete, umfassend folgende Schritte: a1) Zwischenspeicherung eintreffender Datenpakete, b) Weiterleitung zwischengespeicherter Datenpakete anhand eines Warteschlangenverfahrens zur Datenverkehrsglättung, dadurch gekennzeichnet, a2) dass vor der Weiterleitung eines Datenpakets an ein mit einem Netzelement verbundenes Übertragungselement ermittelt wird, welche Datenpaketlänge das weitergeleitete Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt, wobei die Verwaltungsinformation von dem verbundenen Übertragungselement hinzugefügt wird, a3) dass die Weiterleitung des Datenpakets vom Netzelement in Abhängigkeit von der gemäß Schritt a2) ermittelten Datenpaketlänge erfolgt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Warteschlangenverfahren gemäß Schritt b) auf Basis von periodisch erzeugten Tokens arbeitet, wobei ein Token nach einer Weiterleitung einer einstellbaren Anzahl von Datenpaketen oder einer einstellbaren Datenmenge gelöscht wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Warteschlangenverfahren gemäß Schritt b) nach dem bekannten Token-Bucket-Verfahren ausgestaltet ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ermittlung eines Umfangs der hinzugefügten Verwaltungsinformation auf Basis mindestens eines einstellbaren und/oder übermittelbaren Parameters erfolgt.
Netzelement mit Wartechlangenverwaltungsmittel zur Zwischenspeicherung eintreffender Datenpakete und zur Weiterleitung zwischengespeicherter Datenpakete anhand eines Warteschlangenverfahrens zur Datenverkehrsglättung, gekennzeichnet durch, Mittel zur Ermittlung einer Datenpaketlänge des an ein mit dem Netzelement verbundenes Übertragungselement weitergeleiteten Datenpakets nach einer Hinzufügung von Verwaltungsin formationen im Zuge einer Protokollkonvertierung, wobei die Verwaltungsinformation von dem verbundenen Übertragungselement hinzugefügt wird, Mittel zur Steuerung der Weiterleitung des Datenpakets in Abhängigkeit von der ermittelten Datenpaketlänge.
Netzelement nach Anspruch 5, gekennzeichnet durch, eine Ausgestaltung der Warteschlangenverwaltungsmittel auf Basis von periodisch erzeugten Tokens, wobei ein Token nach einer Weiterleitung einer einstellbaren Anzahl von Datenpaketen oder einer einstellbaren Datenmenge gelöscht wird.
Netzelement nach einem der Ansprüche 5 bis 6, gekennzeichnet durch, eine Ausgestaltung als Router.
Netzelement ausgestaltet als Router nach Anspruch 7, mit Mitteln zum Anschluss eines DSL-Modems.
Netzelement ausgestaltet als Router nach Anspruch 7, mit einem integrierten DSL-Modem.