Netzwerkverkehr, der in eine DiffServ-Domäne eintritt, wird einer Klassifizierung und Aufbereitung unterzogen. Ein Verkehrsklassifizierer kann viele verschiedene Parameter in eingehenden Paketen untersuchen, wie Quelladresse, Zieladresse oder Verkehrstyp, und einzelne Pakete einer bestimmten Verkehrsklasse zuordnen. Verkehrsklassifizierer können alle DiffServ-Markierungen in empfangenen Paketen beachten oder diese Markierungen ignorieren oder außer Kraft setzen. Um eine strenge Kontrolle über das Volumen und die Art des Verkehrs in einer bestimmten Klasse zu haben, kann ein Netzwerkbetreiber entscheiden, Markierungen am Eingang der DiffServ-Domäne nicht zu berücksichtigen. Der Verkehr in jeder Klasse kann weiter konditioniert werden, indem der Verkehr Ratenbegrenzern, Traffic-Polizern oder Shapern unterworfen wird.
Das Verhalten pro Hop wird durch das DS-Feld im IP-Header bestimmt. Das DS-Feld enthält den 6-Bit-DSCP-Wert. Explicit Congestion Notification (ECN) belegt die niederwertigsten 2 Bits des IPv4-TOS-Feldes und des IPv6-Traffic-Class (TC)-Feldes.
Theoretisch könnte ein Netzwerk bis zu 64 verschiedene Verkehrsklassen haben, die die 64 verfügbaren DSCP-Werte nutzen. Die DiffServ-RFCs empfehlen bestimmte Kodierungen, schreiben sie aber nicht vor. Dies gibt einem Netzwerkbetreiber große Flexibilität bei der Definition von Verkehrsklassen. In der Praxis verwenden die meisten Netzwerke jedoch die folgenden, allgemein definierten Per-Hop-Verhaltensweisen:
- Default Forwarding (DF) PHB – das ist typischerweise Best-Effort-Verkehr
- Expedited Forwarding (EF) PHB – dediziert für verlustarmen Verkehr mit geringer Latenz
- Assured Forwarding (AF) PHB – gibt die Zusicherung der Zustellung unter vorgeschriebenen Bedingungen
- Class Selector PHBs – die die Abwärtskompatibilität mit dem IP-Präzedenzfeld aufrechterhalten.
Default ForwardingEdit
Ein Default Forwarding (DF) PHB ist das einzige erforderliche Verhalten. Im Wesentlichen wird jeder Verkehr, der nicht die Anforderungen einer der anderen definierten Klassen erfüllt, DF verwendet. Normalerweise hat DF Best-Effort-Weiterleitungseigenschaften. Der empfohlene DSCP-Wert für DF ist 0.
Expedited ForwardingEdit
Die IETF definiert das Verhalten von Expedited Forwarding (EF) in RFC 3246. Das EF PHB hat die Eigenschaften geringe Verzögerung, geringer Verlust und geringer Jitter. Diese Eigenschaften sind für Sprache, Video und andere Echtzeitdienste geeignet. EF-Verkehr erhält oft eine strikte Prioritätswarteschlange vor allen anderen Verkehrsklassen. Da eine Überlastung des EF-Verkehrs zu Warteschlangenverzögerungen führt und die Jitter- und Verzögerungstoleranzen innerhalb der Klasse beeinträchtigt, können Zulassungskontrolle, Traffic Policing und andere Mechanismen auf EF-Verkehr angewendet werden. Der empfohlene DSCP für EF ist 101110B (46 oder 2EH).
Voice AdmitEdit
Die IETF definiert das Voice Admit-Verhalten in RFC 5865. Der Voice Admit PHB hat identische Eigenschaften wie der Expedited Forwarding PHB. Allerdings wird auch der Voice Admit-Verkehr vom Netzwerk über ein Call Admission Control (CAC)-Verfahren zugelassen. Der empfohlene DSCP für Voice Admit ist 101100B (44 oder 2CH).
Assured ForwardingEdit
Die IETF definiert das Assured Forwarding (AF) Verhalten in RFC 2597 und RFC 3260. Assured Forwarding ermöglicht es dem Betreiber, die Zustellung zu gewährleisten, solange der Verkehr eine bestimmte abonnierte Rate nicht überschreitet. Verkehr, der die abonnierte Rate überschreitet, wird mit höherer Wahrscheinlichkeit verworfen, wenn ein Stau auftritt.
Die AF-Verhaltensgruppe definiert vier separate AF-Klassen, wobei der gesamte Verkehr innerhalb einer Klasse die gleiche Priorität hat. Innerhalb jeder Klasse wird den Paketen eine Abwurfpriorität zugewiesen (hoch, mittel oder niedrig, wobei eine höhere Prioritätsstufe mehr Abwürfe bedeutet). Aus der Kombination von Klassen und Drop-Präzedenz ergeben sich zwölf separate DSCP-Kodierungen von AF11 bis AF43 (siehe Tabelle).
| Klasse 1 | Klasse 2 | Klasse 3 | Klasse 4 | |
|---|---|---|---|---|
| Niedrige Abwurfwahrscheinlichkeit | AF11 (DSCP 10) 001010 | AF21 (DSCP 18) 010010 | AF31 (DSCP 26) 011010 | AF41 (DSCP 34) 100010 |
| mittlere Abwurfwahrscheinlichkeit | AF12 (DSCP 12) 001100 | AF22 (DSCP 20) 010100 | AF32 (DSCP 28) 011100 | AF42 (DSCP 36) 100100 |
| Hohe Abwurfwahrscheinlichkeit | AF13 (DSCP 14) 001110 | AF23 (DSCP 22) 010110 | AF33 (DSCP 30) 011110 | AF43 (DSCP 38) 100110 |
Ein gewisses Maß an Priorität und proportionaler Fairness wird zwischen Verkehr in verschiedenen Klassen definiert. Sollte es zu einem Stau zwischen den Klassen kommen, erhält der Verkehr in der höheren Klasse Vorrang. Anstelle einer strikten Prioritäts-Warteschlangenbildung werden wahrscheinlich ausgewogenere Algorithmen zur Bedienung von Warteschlangen wie Fair Queuing oder Weighted Fair Queuing verwendet. Wenn innerhalb einer Klasse ein Stau auftritt, werden die Pakete mit der höheren Abwurfpriorität zuerst verworfen. Um Probleme im Zusammenhang mit Tail-Drop zu vermeiden, werden oft ausgefeiltere Drop-Selection-Algorithmen wie Random Early Detection verwendet.
Class SelectorEdit
Vor DiffServ konnten IPv4-Netzwerke das IP-Präzedenzfeld im TOS-Byte des IPv4-Headers verwenden, um Prioritätsverkehr zu kennzeichnen. Das TOS-Oktett und die IP-Präzedenz waren nicht weit verbreitet. Die IETF einigte sich auf die Wiederverwendung des TOS-Oktetts als DS-Feld für DiffServ-Netzwerke. Um die Abwärtskompatibilität mit Netzwerkgeräten zu erhalten, die noch das Precedence-Feld verwenden, definiert DiffServ den Class Selector PHB.
Die Class Selector-Codepunkte haben die binäre Form ‚xxx000‘. Die ersten drei Bits sind die IP-Präzedenzbits. Jeder IP-Präzedenzwert kann auf eine DiffServ-Klasse abgebildet werden. IP-Präzedenz 0 wird auf CS0 abgebildet, IP-Präzedenz 1 auf CS1, und so weiter. Wenn ein Paket von einem nicht-DiffServ-fähigen Router empfangen wird, der IP-Präzedenzmarkierungen verwendet hat, kann der DiffServ-Router die Kodierung trotzdem als Class Selector-Codepunkt verstehen.
Spezifische Empfehlungen für die Verwendung von Class Selector-Codepunkten finden sich in RFC 4594.
KonfigurationsrichtlinienBearbeiten
RFC 4594 bietet detaillierte und spezifische Empfehlungen für die Verwendung und Konfiguration von Codepunkten.
| Serviceklasse | DSCP Name | DSCP Wert | Konditionierung am DS-Rand | PHB | Queuing | AQM |
|---|---|---|---|---|---|---|
| Netzsteuerung | CS6 | 48 | Siehe Abschnitt 3.1 | RFC 2474 | Rate | Ja | Telefonie | EF | 46 | Polizei mit sr+bs | RFC 3246 | Priorität | Nein |
| Signaling | CS5 | 40 | Police using sr+bs | RFC 2474 | Rate | Nein |
| Multimedia Conferencing | AF41, AF42, AF43 | 34, 36, 38 | Verwendung von zweistuf, dreifarbige Markierung (wie RFC 2698) | RFC 2597 | Rate | Ja pro DSCP |
| Echtzeit-time interactive | CS4 | 32 | Police using sr+bs | RFC 2474 | Rate | No |
| Multimedia-Streaming | AF31, AF32, AF33 | 26, 28, 30 | Zwei-Raten-Verwendung, drei-Farbmarkierung (wie RFC 2698) | RFC 2597 | Rate | Ja per DSCP |
| Broadcast Video | CS3 | 24 | Polizei mit sr+bs | RFC 2474 | Rate | Nein |
| Low-Latenzdaten | AF21, AF22, AF23 | 18, 20, 22 | Zwei-Raten-Verwendung, drei-Farbmarkierung (wie RFC 2698) | RFC 2597 | Rate | Ja pro DSCP |
| OAM | CS2 | 16 | Police mit sr+bs | RFC 2474 | Rate | Ja |
| High-Durchsatzdaten | AF11, AF12, AF13 | 10, 12, 14 | Zwei-Raten-Verwendung, drei-Farbmarkierung (wie RFC 2698) | RFC 2597 | Rate | Ja pro DSCP |
| Standard | DF | 0 | Nicht anwendbar | RFC 2474 | Rate | Ja |
| Niedrig-Priorität | CS1 | 8 | Nicht anwendbar | RFC 3662 | Rate | Ja |