4. Historical Codepoint Definitions and PHB Requirements (Historische Codepunkt-Definitionen und PHB-Anforderungen)
Das DS-Feld hat eine begrenzte Abwärtskompatibilität mit der aktuellen Praxis, wie in diesem Abschnitt beschrieben. Die Abwärtskompatibilität wird auf zwei Arten angegangen. Erstens gibt es Per-Hop-Verhalten, die bereits weit verbreitet sind (z.B. solche, die die in [RFC1812] spezifizierten IPv4 Precedence Queuing-Anforderungen erfüllen), und wir möchten deren fortgesetzte Verwendung in DS-konformen Knoten ermöglichen. Darüber hinaus gibt es mehrere Codepunkte, die der historischen Verwendung des IP Precedence-Feldes entsprechen, und wir reservieren diese Codepunkte, um auf PHBs abgebildet zu werden, die die in Abschnitt 4.2.2.2 spezifizierten allgemeinen Anforderungen erfüllen. Die spezifischen Differentiated Services PHBs, auf die diese Codepunkte abgebildet werden, können (MAY) jedoch zusätzliche Spezifikationen haben.
Es wird kein Versuch unternommen, die Abwärtskompatibilität mit den "DTR"- oder TOS-Bits des IPv4 TOS-Oktetts aufrechtzuerhalten, die in [RFC791] definiert sind.
4.1 A Default PHB (Ein Standard-PHB)
Ein "Default"-PHB muss (MUST) in einem DS-konformen Knoten verfügbar sein; dies ist das allgemein verfügbare Best-Effort-Weiterleitungsverhalten (best-effort forwarding behavior) in bestehenden Routern, die in [RFC1812] standardisiert sind. In Abwesenheit anderer Vereinbarungen wird angenommen, dass Pakete zu diesem Aggregat gehören. Solche Pakete können (MAY) ohne Einhaltung bestimmter Regeln in das Netzwerk eingespeist werden, und das Netzwerk wird so viele dieser Pakete wie möglich und so schnell wie möglich liefern, vorbehaltlich anderer Ressourcen-Richtlinien-Beschränkungen. Eine vernünftige Implementierung dieses PHB ist eine Warteschlangen-Disziplin, die Pakete dieses Aggregats überträgt, wenn die Ausgangsverbindung nicht zur Erfüllung eines anderen PHB benötigt wird. Eine vernünftige Richtlinie für die Konstruktion von Diensten ist sicherzustellen, dass das Aggregat nicht "ausgehungert" (starved) wird, was durch einen Mechanismus in jedem Knoten durchgesetzt werden könnte, der minimale Ressourcen (z.B. Puffer, Bandbreite) für das Default-Verhaltensaggregat reserviert. Dies ermöglicht es Absendern, die sich der differenzierten Dienste nicht bewusst sind, das Netzwerk weiterhin so zu nutzen, wie sie es heute tun. Die Auswirkungen der Einführung differenzierter Dienste in einer Domäne auf die Diensterwartungen von Kunden und Peers sind eine komplexe Angelegenheit, die politische Entscheidungen durch die Domäne beinhaltet und außerhalb des Umfangs dieses Dokuments liegt.
Der empfohlene (RECOMMENDED) Codepunkt für das Default-PHB ist das Bitmuster '000000'; der Wert '000000' muss (MUST) auf ein PHB abgebildet werden, das diese Spezifikationen erfüllt. Der für das Default-Verhalten gewählte Codepunkt ist mit der bestehenden Praxis [RFC791] kompatibel. Wenn ein Codepunkt nicht auf ein standardisiertes oder lokal verwendetes PHB abgebildet ist, sollte (SHOULD) er auf das Default-PHB abgebildet werden.
Pakete, die ursprünglich für das Default-Verhalten markiert wurden, können (MAY) mit einem anderen Codepunkt neu markiert werden, wenn sie eine Grenze in eine DS-Domäne durchqueren, und können mit einem anderen PHB innerhalb dieser Domäne weitergeleitet werden, vorbehaltlich einer gewissen ausgehandelten Vereinbarung zwischen Peer-Domänen.
4.2 Once and Future IP Precedence Field Use (Frühere und zukünftige Verwendung des IP Precedence-Feldes)
Wir möchten eine gewisse Form der Abwärtskompatibilität mit der aktuellen Verwendung des IP Precedence-Feldes (Bits 0-2 des IPv4 TOS-Oktetts) aufrechterhalten. Es gibt Router, die das IP Precedence-Feld verwenden, um verschiedene Per-Hop-Weiterleitungsbehandlungen auf ähnliche Weise wie hier für das DSCP-Feld vorgeschlagen auszuwählen. Daher kann durch ordnungsgemäße Konfiguration dieser Router eine einfache Prototyp-Differentiated Services-Architektur schnell bereitgestellt werden. Da die heutigen IP-Systeme außerdem die Position des IP Precedence-Feldes verstehen, besteht eine geringere Wahrscheinlichkeit katastrophaler Ausfälle während der anfänglichen Bereitstellung, wenn diese Bits auf ähnliche Weise verwendet werden, wenn DS-konforme Geräte bereitgestellt werden. Mit anderen Worten, strikte DS-Konformität muss nicht allgegenwärtig sein, selbst innerhalb des Netzwerks eines einzelnen Dienstanbieters, wenn die Bits 0-2 des DSCP-Feldes auf ähnliche oder inklusive Weise wie die bereitgestellte Verwendung des IP Precedence-Feldes verwendet werden.
4.2.1 IP Precedence History and Evolution in Brief (Geschichte und Entwicklung von IP Precedence in Kürze)
Das IP Precedence-Feld ist sozusagen der Vorgänger des DS-Feldes. IP Precedence und das IP Precedence-Feld wurden erstmals in [RFC791] definiert. Die Werte, die das 3-Bit-IP-Precedence-Feld annehmen kann, wurden verschiedenen Verwendungen zugewiesen, einschließlich Netzwerk-Kontrollverkehr, Routing-Verkehr und verschiedenen Privilegienstufen. Die niedrigste Privilegienstufe wurde als "Routine-Verkehr" betrachtet. In [RFC791] wurde der Begriff Precedence allgemein definiert als "Ein unabhängiges Maß für die Wichtigkeit dieses Datagramms". Nicht alle Werte des IP Precedence-Feldes sollten eine Bedeutung über Grenzen hinweg haben. Zum Beispiel: "Die Network Control-Prioritätsbezeichnung ist nur zur Verwendung innerhalb eines Netzwerks vorgesehen. Die tatsächliche Verwendung und Kontrolle dieser Bezeichnung liegt bei jedem Netzwerk." [RFC791]
Die frühen BBN IMPs implementierten die Precedence-Funktionalität, aber frühe kommerzielle Router und UNIX-IP-Weiterleitungscode implementierten sie im Allgemeinen nicht. Als Netzwerke komplexer wurden und Kundenanforderungen zunahmen, entwickelten kommerzielle Router-Anbieter Möglichkeiten zur Implementierung verschiedener Arten von Warteschlangen-Diensten, einschließlich Priority Queuing. Diese basierten im Allgemeinen auf Richtlinien, die in Filtern im Router kodiert waren, die IP-Adressen, IP-Protokollnummern, TCP- oder UDP-Ports und andere Header-Felder untersuchten. IP Precedence war eine der Optionen, die diese Filter untersuchen konnten.
Kurz gesagt, IP Precedence ist nicht weit verbreitet und weit genutzt, wenn nicht wie in [RFC791] beabsichtigt. Dies wurde in [RFC1122] anerkannt, das besagte, dass die Verwendung des IP Precedence-Feldes gültig war, aber die spezifischen Prioritätszuweisungen von [RFC791] lediglich historisch waren.
4.2.2 Subsuming IP Precedence into Class Selector Codepoints (Eingliederung von IP Precedence in Class Selector Codepoints)
Eine Spezifikation der Paketweiterleitungsbehandlung, die heute durch das IP Precedence-Feld ausgewählt wird, müsste ziemlich allgemein sein; möglicherweise nicht spezifisch genug, um vorhersehbare Dienste im Rahmen der differenzierten Dienste zu konstruieren. Um eine teilweise Abwärtskompatibilität mit der bekannten aktuellen Verwendung des IP Precedence-Feldes aufrechtzuerhalten, ohne die zukünftige Flexibilität zu opfern, haben wir einen Ansatz gewählt, der die Mindestanforderungen für eine Reihe von PHBs beschreibt, die mit den meisten bereitgestellten Weiterleitungsbehandlungen kompatibel sind, die durch das IP Precedence-Feld ausgewählt werden. Darüber hinaus stellen wir eine Reihe von Codepunkten bereit, die auf PHBs abgebildet werden müssen (MUST), die diese Mindestanforderungen erfüllen. Die PHBs, auf die diese Codepunkte abgebildet werden, können (MAY) zusätzlich zu den hier angegebenen Mindestanforderungen eine detailliertere Spezifikationsliste haben. Andere Codepunkte können (MAY) auf dieselben PHBs wie diese abgebildet werden. Wir nennen diese Menge von Codepunkten die Class Selector Codepoints und die Mindestanforderungen für die PHBs, auf die diese Codepunkte abgebildet werden können, die Class Selector PHB Requirements.
4.2.2.1 The Class Selector Codepoints (Die Class Selector Codepoints)
Die DS-Feldwerte 'xxx000|xx' oder DSCP = 'xxx000' mit nicht spezifiziertem CU-Subfeld sind als Satz von Class Selector Codepoints reserviert. Die PHBs, auf die diese Codepunkte abgebildet werden, müssen (MUST) die Class Selector PHB Requirements erfüllen, zusätzlich zum Beibehalten der Default-PHB-Anforderungen (Abschnitt 4.1) für den Codepunkt '000000'.
4.2.2.2 The Class Selector PHB Requirements (Die Class Selector PHB-Anforderungen)
Ein Class Selector Codepoint mit einem größeren numerischen Wert als ein anderer Class Selector Codepoint hat eine höhere relative Ordnung (higher relative order), und ein Class Selector Codepoint mit einem kleineren numerischen Wert als ein anderer Class Selector Codepoint hat eine niedrigere relative Ordnung (lower relative order). Die Menge der PHBs, auf die die acht Class Selector Codepoints abgebildet werden, muss (MUST) mindestens zwei unabhängig weitergeleitete Verkehrsklassen erzeugen, und das durch einen Class Selector Codepoint ausgewählte PHB sollte (SHOULD) einem Paket eine Wahrscheinlichkeit zeitgerechter Weiterleitung (probability of timely forwarding) geben, die nicht niedriger ist als die, die Paketen gegeben wird, die mit einem Class Selector Codepoint niedrigerer relativer Ordnung markiert sind, unter vernünftigen Betriebsbedingungen und Verkehrslasten. Ein verworfenes Paket wird als extremer Fall unzeitgemäßer Weiterleitung (extreme case of untimely forwarding) betrachtet. Darüber hinaus muss (MUST) das durch die Codepunkte '11x000' ausgewählte PHB einem Paket eine bevorzugte Weiterleitungsbehandlung (preferential forwarding treatment) gegenüber dem durch den Codepunkt '000000' ausgewählten PHB geben, um die gängige Verwendung der IP Precedence-Werte '110' und '111' für Routing-Verkehr zu erhalten.
Darüber hinaus sollten (SHOULD) die durch verschiedene Class Selector Codepoints ausgewählten PHBs unabhängig weitergeleitet werden; das heißt, Pakete, die mit verschiedenen Class Selector Codepoints markiert sind, können (MAY) neu geordnet werden. Ein Netzwerkknoten kann (MAY) Grenzen für die Menge der für jedes dieser PHBs verfügbaren Knotenressourcen durchsetzen.
Eine PHB-Gruppe mit einer Spezifikation, die diese Anforderung erfüllt, wird als Class Selector Compliant PHBs bezeichnet.
Die Class Selector PHB Requirements für den Codepunkt '000000' sind mit denen kompatibel, die für das Default-PHB in Abschnitt 4.1 aufgeführt sind.
4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence Compatibility (Verwendung der Class Selector PHB-Anforderungen für IP Precedence-Kompatibilität)
Ein DS-konformer Netzwerkknoten kann mit einer Reihe von einer oder mehreren Class Selector Compliant PHB-Gruppen bereitgestellt werden. Dieses Dokument legt fest, dass die Menge der Codepunkte 'xxx000' auf eine solche Menge von PHBs abgebildet werden muss (MUST). Da es auch zulässig ist, mehrere Codepunkte auf dasselbe PHB abzubilden, kann (MAY) ein Anbieter oder Netzwerkadministrator einen Netzwerkknoten so konfigurieren, dass Codepunkte unabhängig von den Bits 3-5 des DSCP-Feldes auf PHBs abgebildet werden, wodurch ein Netzwerk erzeugt wird, das mit der historischen Verwendung von IP Precedence kompatibel ist. So würde beispielsweise der Codepunkt '011010' auf dasselbe PHB abgebildet wie der Codepunkt '011000'.
4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant PHB Groups (Beispielmechanismen zur Implementierung von Class Selector Compliant PHB-Gruppen)
Ein Class Selector Compliant PHB kann durch verschiedene Mechanismen realisiert werden, einschließlich Strict Priority Queuing, Weighted Fair Queueing (WFQ), WRR oder Varianten [RPS, HPFQA, DRR] oder Class-Based Queuing [CBQ]. Der Unterschied zwischen PHBs und Mechanismen wird in Abschnitt 5 ausführlicher beschrieben.
Es ist wichtig zu beachten, dass diese Mechanismen über andere PHBs (standardisiert oder nicht) verfügbar sein könnten, die auf bestimmten Anbietergeräten verfügbar sind. Zum Beispiel könnte ein zukünftiges Dokument eine Strict Priority Queuing PHB-Gruppe für eine Reihe empfohlener Codepunkte standardisieren. Ein Netzwerkadministrator kann diese Router so konfigurieren, dass sie das Strict Priority Queuing PHB mit den Codepunkten 'xxx000' auswählen, in Übereinstimmung mit den Anforderungen dieses Dokuments.
Als weiteres Beispiel könnte ein anderer Anbieter den CBQ-Mechanismus auf einem Router einsetzen. Der CBQ-Mechanismus kann verwendet werden, um eine Reihe von Class Selector Compliant PHBs zu implementieren, die einen breiteren Funktionsumfang haben als eine Reihe von PHBs, die lediglich die minimalen Class Selector PHB-Anforderungen erfüllen, zusätzlich zur Implementierung eines Strict Priority Queuing PHB.
4.3 Summary (Zusammenfassung)
Dieses Dokument definiert die Codepunkte 'xxx000' als Class Selector Codepoints. Die durch diese Codepunkte ausgewählten PHBs müssen (MUST) die in Abschnitt 4.2.2.2 beschriebenen Class Selector PHB Requirements erfüllen. Dies wurde getan, um ein nützliches Maß an Abwärtskompatibilität mit der aktuellen Verwendung des IP Precedence-Feldes im Internet aufrechtzuerhalten, ohne die zukünftige Flexibilität übermäßig einzuschränken. Darüber hinaus wird der Codepunkt '000000' als Internet-Default-PHB-Wert verwendet und ist daher nicht konfigurierbar. Die anderen sieben nicht-null Class Selector Codepoints sind nur insoweit konfigurierbar, als sie auf PHBs abgebildet werden, die die Anforderungen von Abschnitt 4.2.2.2 erfüllen.