EP2002611A1

EP2002611A1 - Verfahren und vorrichtung zur datenverkehrsglättung

Info

Publication number: EP2002611A1
Application number: EP07703771A
Authority: EP
Inventors: Oliver Veits
Original assignee: Siemens Enterprise Communications GmbH and Co KG
Current assignee: Unify GmbH and Co KG
Priority date: 2006-03-31
Filing date: 2007-01-10
Publication date: 2008-12-17
Also published as: DE102006015046A1; US7965723B2; CN101427529B; US20090168792A1; DE102006015046B4; WO2007113013A1; CN101427529A

Abstract

Die Erfindung bildet ein Verfahren zur Datenverkehrsglättung weiter, bei der eine Zwischenspeicherung und Weiterleitung eintreffender Datenpakete erfolgt, indem ein Overhead von Verwaltungsinformationen berücksichtigt wird, welcher in einer später erfolgenden Protokollkonvertierung an das Datenpaket angehängt wird. Die Erfindung löst das Problem unterschiedlicher Datenpaketlängen in der Weise, dass vor Weiterleitung eines Datenpakets durch einen Router ermittelt wird, welche Datenpaketlänge das Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt. Diese Protokollkonvertierung wird zu einem späteren Zeitpunkt, beispielsweise von einem DSL-Modem vorgenommen. 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 nach der Protokollkonvertierung. 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 damit sowohl für VoIP als auch für Datenübertragung eine Bandbreite einer DSL-Verbindung voll nutzbar ist.

Description

Beschreibung

Verfahren und Vorrichtung zur Datenverkehrsglattung

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Datenverkehrsglattung.

Im Stand der Technik sind bereits Verfahren und Vorrichtungen zur Datenverkehrsglattung 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 Datenverkehrsglattung 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 der 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, wahrend ausgangsseitig nur eine niedrigere Datenübertragungsrate realisierbar oder erlaubt ist. Das Netzelement verfugt 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 Ubertragungselement geboten sein, welches nur eine begrenzte Datenübertragungsrate verarbeiten kann.

Ein bekanntes Verfahren zur Datenverkehrsglattung 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 (»Bücket«) 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 geloscht bzw. aus dem Eimer entfernt wird. Die Anzahl von Datenpaketen, die die Vorrichtung pro Token passieren darf, entspricht einer Datenpaketubertragungsrate . Diese ist üblicherweise durch Veränderung der zeitlichen Periode neu erzeugter Tokens einstellbar.

Die bisher bekannten Maßnahmen zur Verkehrsglattung an einem Netzelement weisen unter anderem ein Problem dahingehend auf, dass keine Einstellung einer Datenpaketubertragungsrate optimal für alle Datenpaketlangen ist.

Dieses Problem wird anschaulicher mit der Betrachtung des eingangs genannten, mit dem Netzelement verbundenen Ubertragungselement, welches nur eine begrenzte Datenübertragungsrate verarbeiten kann. Die Begrenzung ergibt sich beispielsweise durch eine geforderte begrenzte Datenübertragungsrate am Ausgang des Ubertragungselements, welche somit auch auf den mit dem Netzelement verbundenen Eingang des Ubertragungselements ruckwirkt. Derartige Ubertragungselemente sehen ein Verwerfen von Datenpaketen vor, wenn die eintreffende Datenübertragungsrate die zulassige ausgangsseitige Datenübertragungsrate zu überschreiten droht. Verworfene Datenpakete werden dabei nicht an den Ausgang weitergeleitet, sondern stattdessen geloscht.

Wird im Ubertragungselement 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 zusatzlich ein Wechsel in der Ubertragungsweise sein. Zum Beispiel kann die mit den Datenpaketen zu transportierende Nutzinformation der am Ubertragungselement eintreffenden Datenpakete variabler Datenpaketlange so umgeschichtet werden, dass am Ausgang des Ubertragungselement ausschließlich Datenpakete mit konstanter Datenpaketlange vorgesehen sind. Für eintreffende Datenpakete, deren Lange niedriger ist als die der konstanten Lange ausgehender Datenpakete, ist dagegen eine Auffüllung mit arbiträren Fullbits vorgesehen, welche keine Informationen beinhalten. Dieser Vorgang des Auffullens wird in der Fachwelt auch als »Padding« bezeichnet. Auch diese Fullbits 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 Ubertragungselement zu einem Datenpaket hinzugefugten Datenverwaltungsteile, z.B. Fullbits, Header oder Trailer, bewirken also eine ausgangsseitige Datenübertragungsrate, welche aufgrund der unterschiedlichen Lange der Datenpakete nicht proportional zur am Netzelement einstellbaren Datenpaketubertragungsrate ist.

Damit ist das eingangs dargestellte Problem verstandlich, dass keine Einstellung einer Datenpaketubertragungsrate optimal für alle Datenpaketlangen ist. Bei einer gegebenen Datenpaketubertragungsrate des Netzelements ist der im Ubertragungselement erzeugte Overhead für niedrige

Datenpaketlangen hoher als der für höhere Datenpaketlangen erzeugte Overhead. Eine »vorsichtige« niedrige Einstellung der Datenpaketubertragungsrate, welche ein regelmäßiges hohes Aufkommen - oder auch unregelmäßig auftretende Peeks - von Datenpaketen mit einer niedrigen Datenpaketlange erwartet, wurde bei Datenpaketen mit einer hohen Datenpaketlange zu einer ineffizienten Auslastung des Datendurchsatzes fuhren. Umgekehrt konnte man für Datenpakete großer Datenpaketlange 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 ermittelt wird, welche Datenpaketlänge das Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt. Diese Protokollkonvertierung wird zu einem späteren Zeitpunkt, also nach seiner Weiterleitung, beispielsweise von einem nach einem betrachteten Netzelement angeordneten Ubertragungselement vorgenommen. Die Weiterleitung des Datenpakets erfolgt erfindungsgemaß in Abhängigkeit von der ermittelten zu erwarteten Datenpaketlange .

Dies bedeutet beispielsweise, dass mehrere Datenpakete mit niedriger Datenpaketlange wegen eines zu erwartenden höheren Overheads nicht so schnell weitergeleitet werden, wie nach aus dem Stand der Technik bekannten Verfahren zur Datenverkehrsglattung zu erwarten wäre. Damit wird einem Datenverlust vorgebeugt.

Umgekehrt können mit den erfindungsgemaßen Mitteln Datenpakete mit hoher Datenpaketlange wegen eines oben erklarten zu erwartenden niedrigeren Overheads genau so schnell oder sogar schneller weitergeleitet werden, wie nach aus dem Stand der Technik bekannten Verfahren zur Datenverkehrsglattung zu erwarten wäre.

Das erfindungsgemaße Verfahren ist also von der Idee getragen, dass nicht die aus Sicht des die

Datenverkehrsglattung durchfuhrenden Netzelements gemessene Datenübertragungsrate das einzustellende Kriterium ist, sondern die Datenübertragungsrate, die man nach der Protokollkonvertierung messen wurde. Um eine solche Datenübertragungsrate einzustellen, werden die bekannten Mittel zur Datenverkehrsglattung beibehalten und erfindungsgemaß verfeinert, indem die Datenpaketlange in einer nachfolgenden Protokollkonvertierung mit einbezogen wird.

Die Aufgabe wird in analoger Weise durch Einsatz einer Vorrichtung mit den Merkmalen des nebengeordneten Patentanspruchs 6 gelost.

Ein wesentlicher Vorteil der erfindungsgemaßen Mittel ist darin zu sehen, dass ein zu erreichender Datendurchsatz unabhängig von einer Datenpaketgroß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 Peeks - 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äß eines bekannten Token-Bucket-Verfahrens . 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 hinzugefugten Verwaltungsinformation keine feste Große darstellt, sondern - wie erläutert - eine Funktion der ursprunglichen Datenpaketlange ist. Diese Funktion ist zwar üblicherweise linear, jedoch nicht notwendigerweise proportional zur ursprunglichen Datenpaketlange. Neben einem proportionalem 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 Prufsumme zur Nachprufbarkeit der Datenvollstandigkeit des Datenpakets enthalten. Gemäß einer anderen Ausgestaltung der Erfindung wird der Parameter von der nachfolgenden Einheit übermittelt, also beispielsweise der Ubertragungseinheit . 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 Ausfuhrung des erfindungsgemaßen Verfahrens vor, das als Router ausgestaltet zur Anbindung eines Rechners an eine Breitbandverbindung bzw. DSL-Verbindung dient. Das Ubertragungselement ist dabei beispielsweise ein separates

DSL-Modem, das alternativ mit dem Router eine Einheit bildet.

Ein Ausfuhrungsbeispiel mit weiteren Vorteilen und Ausgestaltungen der Erfindung wird im folgenden anhand der Zeichnung naher erläutert.

Dabei zeigen:

Fig. 1: ein Strukturbild zur schematischen Darstellung einer Verbindung eines Rechners über ein

Netzelement mit einem Ubertragungselement; Fig. 2: ein Strukturbild zur schematischen Darstellung einer Mehrzahl von Protokollkonvertierungen eines Datenpakets;

Fig. 3: ein Strukturbild zur schematischen Darstellung einer unterschiedlichen Auswirkung angehängter

Verwaltungsinformation an Datenpakete mit unterschiedlichen Datenpaketlängen; und Fig. 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 eine Datenpakete für eine Sprachkommunikation als zeitkritisch charakterisiert ist, indem diese eine entsprechende Identifikationsbezeichnung enthalten, jedoch hat sich eine derartige Differenzierung von Verkehrsklassen (Sprach- bzw. Datenkommunikation) bislang nicht in allen Kommunikationskomponenten durchgesetzt .

Figur 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 Ausfuhrungen.

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 gewahrleistet 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 vielfaches 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, wurden daher im Modem MOD verworfen, d.h. geloscht werden. Um diesen Datenverlust zu vermeiden, ist im Router ROU, also ein Netzelement im Sinne der Erfindung, ein Verfahren zur Datenverkehrsglattung implementiert, welche die Datenpaketubertragungsrate in Richtung des verbundenen Ubertragungselements, d.h. Modem MOD begrenzt. Die bereits erwähnte Bevorzugung von Datenpaketen, welche Sprachkommunikation enthalten, fuhrt ebenfalls zu einer Notwendigkeit einer Datenverkehrsglattung.

Ein üblicherweise im Router ROU implementiertes Verfahren zur Datenverkehrsglattung bzw. Traffic Shaping, sieht eine Implementierung eines Token-Bucket-Algorithmus vor. Dabei wird am Router ROU eine feste Datenpaketubertragungsrate eingestellt, mit der Datenpakete an das Modem MOD gesendet werden dürfen. Dabei hat sich gezeigt, dass es keine fest einzustellende Datenpaketubertragungsrate gibt, welche für alle Datenpaketlangen gleichermaßen geeignet wäre. Bei

Datenpaketen mit einer hohen Datenpaketlange wirken sich zusatzlich 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 Figur 3 gezeigt. Die Figur 3 zeigt ein erstes Datenpaket Pl.1, mit einem Nutzdatenteil PL (»Payload«) . Dieses Datenpaket wird Pl .1 einer Protokollkonvertierung unterworfen. Das nach der

Protokollkonvertierung resultierende Datenpaket Pl.2 weist einen zusätzlichen - schraffiert dargestellten - Nachrichtenkopfeintrag oder Header HDl.2 auf. Der Header HDl.2 wird durch die entsprechende Protokollkonvertierung an das ursprüngliche Datenpaket Pl .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 Pl .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 HDl.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.

Figur 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 HDl mit einer Länge von 20 Byte. Der erste Header HDl 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 eingefugt. Der zweite Header HD2 wird im Zuge einer Protokollkonvertierung in das Protokoll IP (»Internet Protocol«) hinzugefugt.

In einer weiteren dritten Protokollkonvertierung 3 wird ein dritter Header HD3, entsprechend dem PPP (Point to Point Protocol) mit einem Umfang von 5 Byte eingefugt. Zusatzlich ist in diesem Protokoll die Einfügung eines dritten Trailers TR3 vorgesehen. Ein Trailer ist ein Datenverwaltungsteil, der an das Ende eines Datenpakets angefugt wird. Der Trailer enthalt üblicherweise Informationen zum Erkennen und Korrigieren von Ubertragungsfehlern . Eine solche Information unterstutzt beispielsweise eine zyklische Redundanzprufung bzw. CRC, »Cyclic Redundancy Check«.

In einer vierten Protokollkonvertierung 4 wird ein vierter Header HD4 mit einem Umfang von 14 Bytes eingefugt. Weiterhin wird ein vierter Trailer TR4 mit einem Umfang von 4 Byte an das Ende des Datenpakets angehängt. Die entsprechende Protokollkonvertierung fuhrt zu einem Ethernet Frame.

Eine fünfte Protokollkonvertierung 5 fuhrt Die fünfte Protokollkonvertierung 5 fuhrt zu einem ATM-Protokoll (Asynchronous Transfer Mode) , bei dem einer Aufteilung des

Datenpakets in mehrere Zellen mit einer konstanten Lange von 53 Byte vorgesehen ist. Der Nutzdatenteil des PL des vormaligen Datenpakets mit einer in weiten Bereichen variablen Lange, wird aufgeteilt in mehrere Nutzdatenteile PL mit einer konstanten Lange von 48 Bytes. Jedem

Nutzdatenanteil PL von 48 Byte ist dabei ein Header von HD5 mit einem Umfang von 5 Byte vorangestellt. Datenpakete mit einer festgelegten Lange 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 Figur 1 erläuterten dritten Verbindung 3 in einer so genannten »AAL 5« betrieben wird. AAL (Asynchronous Transfer Mode Adaption Layer) bezeichnet eine Dienstklasse für eine Datenübertragung. Die fünfte Dienstklasse AAL 5 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 einer pro Datenpaket konstanten Anteil, 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 Figur 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 Lange der hinzugefugten Verwaltungsinformation erfolgt beispielsweise auf Basis mindestens eines einstellbaren und/oder ubermittelbaren Parameters. Dieser Parameter wird beispielsweise in einer Rechenvorschrift benutzt, welche den durch die

Protokollkonvertierung zu erwartenden Overheads in Abhängigkeit von der ursprunglichen Datenpaketlange liefert.

Bei hinreichender Genauigkeit sind beispielsweise zwei Parameter einstellbar, wobei ein erster Parameter den konstanten Anteil einer Verwaltungsinformationslange und ein zweiter Parameter einen proportionalen Anteil charakterisiert, wobei letzterer von der ursprunglichen Datenpaketlange abhangt.

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 Datenpaketlange nach Protokollkonvertierung ergibt.

Mit der so berechneten Datenpaketlange wird das

Warteschlangenverfahren - das beispielsweise gemäß des bekannten Token-Bucket-Verfahrens ausgestaltet ist - zur Datenverkehrsglattung im Router ROU modifiziert.

Fig. 4 zeigt eine bildlich zu verstehende Darstellung eines erfindungsgemaß 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 geloscht bzw. aus dem Eimer BU entfernt wird. Die Anzahl von Datenbytes, die die Vorrichtung pro Token passieren darf, entspricht einer Datenübertragungsrate.

Erfindungsgemaß wird dieses Verfahren dahingehend verbessert, dass bei Eintreffen eines Datenpakets Pl an einem - nicht dargestellten - Eingang des Routers ROU nach den obigen Maßgaben berechnet wird, welche Lange das Datenpaket Pl nach einem Durchlaufen des nachfolgenden Modems MOD einschließlich aller Verwaltungsinformationen haben wird. Diese Lange 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 Große bezuglich der gesamten Datenpaketlange behandelt wird und erst nach einer Protokollkonvertierung im Modem MOD mit dieser Datenpaketlange vorliegt. Das erste Datenpaket Pl liegt im Gegenzug als reales, weiterzuleitendes Datenpaket Pl 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 Pl in Abhängigkeit von der vorausgehend ermittelten Datenpaketlange erfolgt, indem die Loschung von Tokens TK entsprechend der zu erwartenden Lange des Datenpaket P2 erfolgt.

Übersteigt die Datenpaketlange des fiktiven zweiten Datenpakets P2 den Restinhalt des Eimers BU, wird das Datenpaket Pl erst gesendet, wenn der Eimer BU eine hinreichende Anzahl von Tokens TK aufweist. Im anderen Fall wird das Datenpaket Pl gesendet und die Datenpaketlange des fiktiven zweiten Datenpakets P2 vom Inhalt des Token Bücket 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

Patentansprüche

1. Verfahren zur Datenverkehrsglättung für eine Mehrzahl weiterzuleitender Datenpakete, umfassend folgende Schritte: al) Zwischenspeicherung eintreffender Datenpakete, b) Weiterleitung zwischengespeicherter Datenpakete anhand eines Warteschlangenverfahrens zur Datenverkehrsglättung, d a d u r c h g e k e n n z e i c h n e t , a2) dass vor der Weiterleitung eines Datenpakets ermittelt wird, welche Datenpaketlänge das weitergeleitete Datenpaket nach einer Hinzufügung von Verwaltungsinformationen im Zuge einer Protokollkonvertierung einnimmt, a3) dass die Weiterleitung des Datenpakets in Abhängigkeit von der gemäß Schritt a2) ermittelten Datenpaketlänge erfolgt .

2. 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.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Warteschlangenverfahren gemäß Schritt b) nach dem bekannten Token-Bucket-Verfahren ausgestaltet ist.

4. 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.

5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verwaltungsinformation von einem mit dem Netzelement verbundenen Ubertragungselement eingefugt werden.

6. Netzelement mit Wartschlangenverwaltungsmittel zur Zwischenspeicherung eintreffender Datenpakete und zur

Weiterleitung zwischengespeicherter Datenpakete anhand eines

Warteschlangenverfahrens zur Datenverkehrsglattung, gekennzeichnet durch,

Mittel zur Ermittlung einer Datenpaketlange des weitergeleiteten Datenpakets nach einer Hinzufugung von

Verwaltungsinformationen im Zuge einer

ProtokolIkonvertierung,

Mittel zur Steuerung der Weiterleitung des Datenpakets in

Abhängigkeit von der ermittelten Datenpaketlange.

7. Netzelement nach Anspruch 6, gekennzeichnet durch, eine Ausgestaltung der Wartschlangenverwaltungsmittel auf Basis von periodisch erzeugten Tokens, wobei ein Token nach einer Weiterleitung einer einstellbaren Anzahl von

Datenpaketen oder einer einstellbaren Datenmenge geloscht wird.

8 . Net zelement nach einem der Ansprüche 6 bi s 7 , g e k e n n z e i c h n e t d u r c h , eine Ausgestaltung als Router.

9. Router nach Anspruch 8, mit Mitteln zum Anschluss eines DSL-Modems .

10. Router nach Anspruch 8, mit einem integrierten DSL-Modem.