Institut für Kommunikationsnetze und Rechnersysteme - Universität ...

– 119 –
DSCP-Werte festgelegten PHBs oder PHB-Gruppen AF und EF (siehe Abschnitt 3.3.3.3)
keine explizite Berücksichtigung. Das bedeutet, dass die hier definierten Regeln zur differenzierten
Behandlung im DiffServ-Sinn als neue PHB-Gruppe anzusehen sind. Grundsätzlich
besteht jedoch die Möglichkeit, eine Abbildung auf entsprechende AF-/EF-PHBs herzustellen.
Eine weitere Eingrenzung stellt die Voraussetzung dar, dass keinerlei absolute Garantien gegeben
werden sollen. Dies erlaubt den Verzicht auf einige Verkehrsmanagement-Funktionen. So
wird angenommen, dass weder eine Quellflusskontrolle existiert, die z. B. nach dem Prinzip
des Leaky Bucket Pakete abhängig von der Verkehrscharakteristik bestimmten Klassen zuordnet
(siehe Abschnitt 3.2.2), noch eine Annahmesteuerung, durch die das Verkehrsaufkommen
insgesamt begrenzt wird. Das hier betrachtete Schema sieht lediglich vor, die in den Netzknoten
vorhandenen Ressourcen (gemäß Abschnitt 3.2.1) per Scheduling und Puffermanagement
an aggregierte Verkehrsströme zu vergeben, sodass eine relative Differenzierung ermöglicht
wird.
Das Schema ist dabei nicht zwangsläufig auf das Kernnetz beschränkt, sondern kann bis hin
zum Nutzer sichtbar sein, der aus einer Reihe von Dienstgüteklassen wählen kann. In diesem
Fall muss durch ein Priority Pricing (siehe Abschnitt 3.2.6.5) sichergestellt werden, dass durch
höhere Entgelte für Klassen mit besserer Behandlung ein Anreiz zur Benutzung der „schlechteren“
Klassen geschaffen wird. Dabei ist auch vorstellbar, dass Nutzer (selbst oder mittels
Anwendungen mit entsprechenden Adaptionsmechanismen) während einer Verbindung die
Dienstgüteklasse wechseln, um schließlich die aus ihrer Sicht bestmögliche Kombination aus
QoS und Preis zu finden (vgl. Bild 4.9 in Abschnitt 4.3.4). Der Fall, dass wie bei der Anwendung
des Leaky Bucket aufeinander folgende Pakete des gleichen Verkehrsflusses mit ständig
wechselnden DSCP-Werten markiert werden, soll jedoch hier nicht betrachtet werden.
Eine weitere Voraussetzung, von der hier ausgegeangen werden soll, ist die häufig vorgeschlagene
Trennung von elastischem und Echtzeitverkehr [86, 235, 242]. Der Grund für eine solche
Trennung liegt in den unterschiedlichen Anforderungen dieser beiden Verkehrsarten. Wie oben
angedeutet, kann die Erkennung der Zugehörigkeit zu einer der beiden Verkehrsarten über die
Kennzeichnung des Transportprotokolls im Kopf von IP-Paketen erfolgen. Dabei kann vereinfachend
angenommen werden, dass elastischer Verkehr als Transportprotokoll TCP verwendet,
während der in Echtzeitanwendungen erzeugte Verkehr UDP-basiert ist. Alternativ dazu können
für die beiden Verkehrsarten unterschiedliche Bereiche für DSCP-Werte festgelegt werden,
sodass bei der Klassifizierung im Kern nur noch der DSCP berücksichtigt werden muss.
Zusätzlich zu der Möglichkeit, elastischen und echtzeitkritischen Verkehr zu trennen, sollen
innerhalb jeder der beiden Verkehrsarten mehrere Dienstgüteklassen unterschieden werden.
Damit ist es möglich, den gleichen Dienst (z. B. WWW oder VoIP) in unterschiedlicher Qualität
anzubieten oder auf die Anforderungen verschiedener Dienste innerhalb der gleichen
Gruppe (z. B. Echtzeitanwendungen mit unterschiedlich starken Verzögerungsanforderungen)